Нужны ли препроцессоры в 2019 году
Препроцессоры давно стали неотъемлемым инструментом в арсенале верстальщика. Они дают нам все, что нам нужно: переменные, миксины, вложенность… Погодите. А разве современный CSS так не умеет? Или умеет? А нам точно еще нужны препроцессоры?
История
Интернет появился в начале 90х. В 1994 году впервые возникает идея о создании языка для стилизации веб-страниц. И спустя 2 года появляется CSS. CSS1 умел не много, и поддержка в браузерах была настоящей болью.
Но время шло, CSS развивался, еще спустя 2 года появился CSS2, затем, CSS2.1. Но по-прежнему оставалось много проблем:
- Не было переменных
- Не было вложеннности
- Не было модульности
- Оставались проблемы с кроссбраузерностью
И вот тогда появились они — препроцессоры!
Они были призваны решить проблемы нативного CSS и давали нам набор новых крутых фич.
И, казалось, на этом препроцессоры победили, и так мы будем жить всегда. Но и CSS все это время не стоял на месте. И вот, в марте этого года CSSWG одобрила черновик Таба Аткинса, который реализует в CSS вложенные селекторы — одну из главных фич, ради которых используют препроцессоры!
Так неужели CSS еще не проэволюционировал достаточно, чтобы уже оставить препроцессоры в прошлом? Давайте сравнивать основные фичи.
Вложенность
Как уже было сказано выше, в марте 2019 года одобрили черновик о вложенности. Он реализует в CSS новый синтаксис с & и директиву @nest.
Это пока не совсем та вложенность, которая есть в препроцессорах. Есть 2 ограничения:
- Нет склеивания классов в стиле БЭМ-а
- & всегда должен идти первым
Но больше селекторов можно реализовать, как раз, при помощи директивы nest. Например:
Увы, вложенность в CSS пока существует только на уровне спецификации, и браузерных решений нет :( Но ведь это только начало).
Переменные
Я уже писала о CSS Сustom Properties, у них куча преимуществ по сравнению с препроцессорными:
- Ведут себя как обычные CSS-свойтсва свойства (наследование, каскад)
- Знают о DOM-структуре
- Можно использовать в SVG
- Доступны из JS
С браузерной поддержкой у них уже тоже все хорошо:
Помимо CSS custom properties, в CSS есть еще один вид переменных: CSS environment variables. Они задаются user-agent-ом браузера и их можно использовать, чтобы адаптировать верстку под новые девайсы. Подробнее о них можно почитать тут.
Их можно использовать уже сегодня, более того, некоторые задачи без них просто не решаются. С препроцессорными переменными такой трюк проделать не получится.
Миксины
В CSS есть директива, которая нативно повторяет миксины — @apply. О том, как ее использовать, можно почитать здесь.
Но предложение Таба Аткинса отклонили, так что миксинов в CSS не предвидется.
Но так ли они нужны? Наиболее частый юзкейс для использования миксинов — генерация вендорных префиксов. Необходимость в этом отпала с появлением Autoprefixer-a. И проблему дублирования кода вполне можно решить правильной архитектурой верстки. Миксин легко реализуется применением нужных классов.
Математические функции
У нас уже был calc() с очень хорошей браузерной поддержкой.
И совсем недавно CSSWG приняла решение о добавлении новыйх математических функций в CSS:
Модульность
На самом деле модульность в CSS была всегда. CSS import-ы были с нами еще с IE5.5. Но мы ими не пользовались из-за багов в старых браузерах и из-за хорошей практики сокращать количество запросов к серверу. Но с приходом HTTP/2 эта необходимость отпала.
Но, по сравнению с препроцессорным, у нативного import-а есть крутое преимущество: подгрузка в зависимости от условий.
То есть я могу подгрузить отдельно стили для печати, мобильных и т.д. Препроцессорный import работает на этапе компиляции, когда доступа к media-queries нет.
Подводя промежуточные итоги, кроме миксинов в CSS уже либо есть препроцессорные фичи, либо они скоро появятся. При этом нативные переменные на голову выше препроцессорных.
А что если мы хотим новые фичи уже сегодня?
CSS будущего уже сегодня
Postcss-preset-env — плагин, который представляет из себя набор полифиллов, он позволяет использовать новые фичи, которые еще не работают в браузерах.
Он берет ваш CSS, проделывает с ним магию и преобразует в вид, понятный большинству браузеров.
Вы сами решаете, какие фичи и какие браузеры поддерживать. У него есть 5 уровней по фичам:
По умолчанию включается Stage2 — применятся все фичи, находящиеся в состоянии Working draft, и будут поддерживаться все браузеры.
И получается следующее:
Так в чем разница с препроцессорами? У PostCSS есть перед ними ряд преимуществ:
- Он умеет все то же, что и препроцессоры
- Но при этом мы продолжаем писать именно CSS, а не свой синтаксис
- PostCSS модульный. А это значит, что можно заполифилить фичу, а как только она войдет в стандарт, убрать ненужный плагин и не тащить лишние зависимости.
Но с большой силой приходит большая отвественность! Ко всему надо подходить с умом. PostCSS — это тоже не совсем CSS. Не стоит увлекаться полифиллами. Плюс, полифилл не всегда может полностью повторить поведение фичи. Например, используя полифилл для CSS custom properties, вы теряете их главное преимущество — поведение как у CSS-свойств.
Но обычно, говоря о противостоянии препроцессоров и ванильного CSS, мы только сравниваем фичи. А ведь у процессоров тоже есть свои слабые стороны.
Проблемы препроцессоров
1. Свой синтаксис
У каждого препроцессора свой собственный синтаксис, и это уже не CSS.
Мне часто отвечают на этот аргумент: да что там учить! Да, я уверена, что любой человек с головой в состоянии освоить этот синтаксис. Но зачем что-то делать, если можно этого не делать:)
Но дело даже не в сложности изучения и не в том, что новому человеку, пришедшему в команду, и не работавшему с вашим препроцессором, придется к нему привыкать. Препроцессоры дают упрощенный синтаксис, и это палка о двух концах: каждый привыкает писать, как ему нравится. И дальше вам надо следить за кодстайлом, настраивать линтер, либо проверять его глазами в код-ревью. Я уверена, что можно потратить время и силы на что-то гораздо более важное.
2. Нужна компиляция
Каждый, кто использовал препроцессоры, видел такой экран:
Когда не понятно, что поломалось, и как это чинить.
И каждое изменения требует перекомпиляции! Это занимает время и жутко бесит.
3. Лишние зависимости
Любой препроцессор — это дополнительная зависимость. А Sass, например, еще тянет за собой compass.
4. Сложнее дебажить
Находим свойство в браузере:
Открываем исходник, там этого свойства нет:
Нельзя так просто взять и найти исходник, в котором задано свойство. Поэтому нужны специальные файлы — sourcemaps. На их генерацию также нужно дополнительное время, и это, опять же, лишний файл, который надо тащить за собой.
Если эти аргументы вас все еще не убедили, вот пара сайтов, которые отказались от препроцессоров в пользу PostCSS, и это далеко не полный список.
Выводы
- На самом деле у нас уже есть все, что нужно!
- А то, чего еще нет, скоро появится. Еще нереализованные фичи можно использовать уже сегодня с помощью PostCSS.
- CSS и инструменты работы с ним эволюционировали. Раньше мы вынуждены были использовать препроцессоры за неимением лучших решений. Но вместо того, чтобы держаться за старое, лучше использовать более современные инструменты.
- Не надо привязываться к технологиям, они имеют свойство устаревать. А CSS работает везде и будет с нами всегда.
- Вместо того, чтобы изучать препроцессоры, лучше следить за новинками CSS.
