• Что такое Less и Sass?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    Лень двигатель прогресса. Хороший пример - принцип DRY - Don't repeat yourself. Я весьма подозреваю что вы стараетесь соблюдать этот принцип когда делаете макеты или чем вы там занимаетесь. Так же я весьма уверен что вы хотя бы пытались чуть автоматизировать рутину своей повседневной работы. Так же у вас могли быть ситуации когда вы переиспользовали какие-то элементы. Мало ли.

    Так вот... CSS это тупая таблица стилей. Селектор и стили, ничего сверх умного тут придумать нельзя. Лет 5-10 назад было довольно модно держать один мегажирный CSS файл на 10К+ строк и радоваться жизни внося все больше изменений и т.д. Соответственно даже если вы соблюдаете всякие правила модульной верстки и все такое, у вас возникает несколько проблем:
    • организация стилей, то есть держать все в одном файле не удобно особенно когда проект длится годами
    • Дублирование стилей и селекторов. По мере развития проекта появляются какие-то снипиты которые можно реюзать. Так же у вас может появиться масса однообразных селекторов отличающихся лишь немного. При модульных подходах вложенности редко имеет место быть но все же имеет. Но не будем забывать что большинство фигачит селекторы просто так. В итоге если мы переместили блок или переименовали класс какого-то блока нужно отредактировать еще массу селекторов.
    • Привязка размеров и параметров к другим стилям, например у вас в стилях задана ширина блока, от нее зависят другие параметры, отступы для других блоков и т.д. Да, в css3 появился calc для этого но это было относительно недавно и только с недавних пор можно почти без опаски использовать эту штуку.
    • Таблицы стилей, как и HTML ориентированы на удобный разбор этого добра машиной, но не человеком. Человек же существо ленивое и как-то вот лень лишний раз скобку поставить или точку с запятой. Просто лень.


    Есть так же хорошее правило, или идея если хотите.... Если код можно сгенерить - его лучше сгенерить. То есть для решения всех выше перечисленных проблем придумали препроцессоры. Они как бы были и раньше всех этих scss/less/stylus но как-то не решали всех проблем и т.д. Что в итоге было предложено (перечисляю в том же порядке что и в списке выше).

    • У CSS есть такая штука как @ import. Но не очень круто импортировать сотню стилей в продакшене. Стоит сделать так что бы все стили были склеены при сборке проекта. Эта идея в итоге развилась и если разработчик использует это дело правильно, можно зайти в любой файл со стилями и увидеть список всего от чего зависят эти стили. Какие стили подключаются и т.д. Причем один файл с зависимостями может быть подключен в нескольких файлах а препроцессор сам разберется как и куда все вставлять сгенерив максимально оптимизированный по структуре файл. А разработчик получил четкую структуру файлов и возможность быстро найти где что и от чего зависит.
    • С селекторами проблему предложили решить наиболее логичным вариантом. Если у нас есть вложенные селекторы, то имеет смысл определять их внутри блока этого селектора. Это существенно упрощает поддержку стилей. Так же для управления снипитами и прочим добавили миксины - эдакие параметризованные или нет функции которые выплевывают шматок CSS. До появления штук вроде autoprefixer это был единственный способ писать поддерживаемые стили, использовать плюшки CSS3 и вообще новые плюшки и не сойти с ума от префиксов. Префиксы это только пример, там могут быть самые разные штуки позволяющие грамотно производить реюз стилей
    • Проблему зависимостей значений стилей друг от друга решили... собственно самым очевидным способом - переменные. Это удобно, легко поддерживать и в умелых руках это мощный инструмент. Нужно поменять базовые цвета - не нужно лазить по 100500 блоков и править значения руками, можно поправить переменные и все будет хорошо.
    • Насколько я помню SCSS/LESS не стремились решить эту проблему. Какие-то решения образовывались сами собой с течением времени. В плане минимализма и выразительности пожалуй сейчас самая крутая штука это stylus.


    Что в итоге произошло. В один прекрасный момент какие-то там рубисты придумали SCSS (они вообще не любят все что не в стиле ruby в плане минимализма и выразительности). Затем чуваки подумали и сказали, SCSS это круто но почему-то они используют синтаксис знакомый именно Ruby разработчикам а не обычные для CSS конструкции. В итоге реализовали LESS, причем его уже реализовали на javascript, что с наличием node.js позволило это все добро еще на одной платформе собирать. А так как под эту платформу и так плодили препроцессоры оно удачно вписалось.

    Далее уже шли какие-то модификации дальнейшие, вроде того же Stylus, где синтаксис упростили просто до нельзя.

    Личное мнение. На сегодняшний день я не вижу смысла использовать чистый CSS хоть на малых хоть на больших проектах. Вот вообще никакого.
    Ответ написан
    3 комментария
  • Как узнать имя "класса" в JS при передаче его в функцию?

    У вас используется анонимная функция, так что никак.
    Если у вас используется именованная функция - у неё есть свойство name. Оно не поддерживается IE, если нужна его поддержка - можно выдрать имя из исходников функции.

    function Class(){}
    Class.name // => 'Class'
    function getName(it){
      var match = /^\s*function\s+(\b\w+\b)/.exec(it);
      if(match)return match[1];
    }
    getName(Class) // => 'Class''

    Однако, это чуть менее, чем полностью бесполезно - после сжатия вашего кода имя конструктора и, соответственно, значение свойства name превратится из 'Class' в какой-нибудь 'tF'.
    Если вам нужно получить именно имя функции - добавляйте к функции и используйте свойство displayName - за одно и профилирование кода улучшите.

    function Class(){}
    Class.displayName = 'Class';
    Ответ написан
    Комментировать
  • Node.js для простых сайтов. Стоит ли забивать на PHP?

    @kxyu
    — Ненавижу лапшу из колбеков. Не представляю как можно писать что-либо серьезное на JS не используя Фреймворки, которые хоть как-то имитируют синхронность. На худой конец jQuery. Если node.js близок к нативному JS, будет сложнее. Либо придется искать фреймворк для него.


    Чтобы не было лапши из колбеков, в простых случаях достаточно просто использовать именованные, а не анонимные колбеки. В сложных случаях — async. Node.js близок к нативному JS. Но на всякий случай есть 30000 пакетов в npm.

    + Возможно, в серверной части будет не так много асинхронных задач, как во фронтэнде и не будет такой лапши из колбеков.


    Если у вас будет много синхронных задач, то Node.js не лучший выбор.

    — ПХП нравится за кучу встроенных функций (работы с массивами, строками, БД, обработкой картинок и т.д.). Если в ноде в
    функционал уровня ES4 и тупо нет библиотеки, чтобы ужать картинку на сервере не будет ли это слишком плачевным?


    В ноде нет ничего. В npm есть все. ES5.

    — Так ли страшен черт как его малюют. Понятно зачем нужна асинхронность на клиенте. Но на сервере? Только БД и связь с другими серверами (если такое встречается в реальной жизни). Может быть есть способы оптимизировать это и без асинхронности? Может быть ПХПшники через пол года придумают?


    А что еще, собственно, делает бэкэнд веб-приложения? Число пи до миллиардного знака расчитывает?

    Вывод — все в порядке, используете node.js.
    Ответ написан
    4 комментария
  • Sleep(delay) в javascript?

    SpeCT
    @SpeCT
    Не слушайте никого и делайте так, как считаете нужным. Про синхронный XHR тут уже упомянули, так что ниже код, что вы просили:

    function sleep(ms) {
    ms += new Date().getTime();
    while (new Date() < ms){}
    } 
    
    Ответ написан
    2 комментария
  • Термин для слова "говнокод"?

    vinxru
    @vinxru
    Говнокод — это код не похожий на код оппонента. Понять чужой код — это долгая и нудная работа. А если код написан так, как будто ты его написал, то ты его понимаешь и это экономит время на доработку и отладку.

    Любой начинающий программист первым делом бросается переписывать чужие программы. Даже если они абсолютно работоспособны, даже если после переписывания пропадет часть функционала и появятся баги.

    Это сказано с долей юмора конечно.

    Говнокод — это применение не самых лучших (с точки зрения большинства) решений проблемы. Ну к примеру говнокодом назовут выход из цикла установкой счетчика в максимальное значение.

    for(i=0; i<1000; i++)
      i=INT_MAX;
    


    Это полностью работоспособное решение, не тормозное, не громоздкое. Но лучше применять для этих целей break. Потому что так все привыкли. Так же говнокодом является повторение функционала стандартной библиотеки, например string или auto_ptr. А так же структура (архитектура) программы, отличная от любимой у оппонента. Например, не использование MVC при разработке программы.

    К примеру, я использую конструкцию:

    void main() {
      // ...
      void init_dialog();           init_dialog();
      void init_referenceControl(); init_referenceControl();
      void init_functionsHelp();    init_functionsHelp();
      void init_new_style();        init_new_style();
      // ...
    }
    </souce>
    
    Вместо определения функций в .H файлах, я это сделал прямо на месте. Говнокод. Можно было бы создать кучу .H файлов, использовать одну из множества библиотек выполняющих инициализацию. Но это максимально простой способ, способ без использования доп классов, функций и программ; так легче отлаживать, так наглядно изображена последовательность инициализации, так не надо писать кучу #include, и кроме функции MAIN, функции инициализации ни от куда не вызвать.
    
    Говнокод - потому что люди бы не так написали.
    Ответ написан
    3 комментария