• Нужно ли использовать препроцессоры CSS?

    Vlad_IT
    @Vlad_IT Куратор тега CSS
    Front-end разработчик
    1) Препроцессоры позволяют вводить переменные и миксины. Но ведь в CSS можно просто создать свойство

    Ну, одно дело добавлять к селектору в css, другое дело захламлять html, а там уже сложнее будет менять класс (т.к. html может генерироваться как угодно).
    2) Валидность CSS.

    Ай, да на это пофиг, есть и другие средства для проверки.
    3) Компилятор из препроцессорного языка в CSS.

    Ну там легкий скриптик выполняется в сборщике автоматом (на webpack, gulp, parcel и.т.д.). Особо ничего не нагружает, на ssd при сохранении файла scss меньше чем за секунду компилируется css.
    4) Удобочитаемость кода, и простой поиск,

    А тут как раз наоборот. Искать по scss гораздо сложнее, т.к. нельзя врубить поиск по целому селектору. Но если стоит Sourcemap (грубо говоря, который учит инструменты разработчика хрома понимать scss), то уже можно спокойно смотреть в хроме номер строки, название классов и.т.д.
    5) Возможность инклюда (include) в препроцессорах.

    Оптимизация. Пока не пришел http 2, все ресурсы желательно склеивать, скрипты, стили и даже картинки в спрайты. Один файл грузится быстрее чем несколько, т.к. достаточно одного http запроса. С приходом http2 будет пофиг.
    6) Вложенность свойств.

    Ну вот смотри, есть у меня такая менюшка
    <nav class="menu">
       <ul class="menu__list">
          <li class="menu__item menu__item_active">
             <a href="#" class="menu__link">Menu 1</a>
          </li>
          <li class="menu__item">
             <a href="#" class="menu__link">Menu 2</a>
          </li>
       </ul>
    </div>

    В css мой код на БЭМ будет выглядеть вот так
    .menu {
    
    }
       .menu__list { }
       .menu__item { }
          .menu__item_active { }
          .menu__item:hover { }
       .menu__link { }

    а на scss вот так

    .menu {
       &__list { }
       &__item { 
          &:hover { }
          &_active { }
       }
       &__link { }
    }

    проще и лаконичнее. Но этой слишком простйо пример. Там еще можно добавлять медиазапросы, дополнительные модификаторы.

    7) На хабре видел в комментариях обсуждение, мол можно даже задавать в препроцессорах - какие браузеры поддерживать. Ахтунг! А зачем писать такие стили, которые не будут работать в старых браузерах?


    Это больше для вендорных префиксов и всяких полифилов. Это по моему в PostCSS юзается через doiuse, точно не знаю, в scss с таким не сталкивался. Обычно пофиг на старые ie.

    Могу предположить, что такая ситуация у меня слоилась из-за того, что я в основном пишу маленькие проекты, а в больших проектах это действительно как-то помогает, но я не могу представить такую ситуацию.

    В маленьких проектах чаще да, если нет готового сборщика, то удобнее сразу писать прототип на css. Но сейчас любой фрейморк в пару команд позволяет добавить поддержку scss.

    Это удобная штука, не нужно ее бояться, не нужно бояться webpack, фреймворки, но и не нужно фанатеть, это просто инструменты.
    Ответ написан
    2 комментария