For WebВ последнее время сообществом фронтенд-разработчиков довольно активно обсуждается PostCSS. О том, что это и где оно применяется мы расспросили создателя PostCSS Андрея Ситника.
Привет! Спасибо, что согласился побеседовать. Я думаю, разговор всё равно более-менее спонтанный получится, так что начну с одного вопроса, а дальше уже как пойдёт. Расскажи немного о себе?
Родился во Владивостоке. Детство прожил в Йемене. Университет закончил в Питере. Сейчас работаю фронтендером над Амплифером в Злых марсианах, поддерживаю Автопрефиксер и развиваю PostCSS.
А как ты вообще стал программистом? Когда и с чего начал увлекаться этим? Какой путь совершил прежде чем прийти к фронтенду?
В детстве я не хотел быть программистом — скорее хотел стать учёным. Но у меня была большая мечта — путешествовать по миру. И я подумал, что программирование — самый простой путь к этому. А потом я написал свою первую программу, запустил её и увидел, что она заработала. Это было непередаваемое ощущение — когда что-то, что ты сделал, живёт дальше само по себе.
Дальше был Basic, Pascal, школьные олимпиады. Затем я увидел мир PHP и веба — он мне сразу очень понравился. Там была настоящая свобода. Динамический язык для творчества. И результат доступный каждому. А потом я впервые увидел Ruby on Rails. Видео «блог за 5 минут» просто будоражило, так как оно показывало, что появляется совершенно новая эпоха.
Я бы не сказал, что я стремился во фронтенд. Просто мне было проще решать задачи с визуальной точки зрения. Проще понять дизайн. Так со временем становилось всё больше фронтенда и меньше бэкенда.
Получается, ты изначально немного занимался бэкендом, писал на PHP и Ruby? Насчёт PHP ничего не скажу, но вот Ruby весьма выразительный и красивый язык. Не жалеешь о переходе на JavaScript после него?
Скажем так, на чистом JS я бы вообще не смог программировать — но CoffeeScript, ES6 сильно развивают язык до какого-то приемлемого уровня. Многих вещей мне всё ещё не хватает, но уже терпимо.
JavaScript по сравнению с CSS развивается довольно быстро. Если с появлением ES6 в языке появилось достаточно нововведений, благодаря которым можно обойтись без дополнительных инструментов вроде CoffeeScript, то в случае CSS использование различных препроцессоров уже стало стандартом де-факто. Раньше ты использовал какой-то препроцессор?
Ты так говоришь, как будто ES6 поддерживается во всех браузерах. Мы просто сменили один препроцессор, CoffeeScript, на следующий — Babel. Даже когда браузеры будут поддерживать ES6 мы всё равно будем использовать Babel ради ES7 и так далее. Но в сравнении с этим мне действительно не нравится застой в мире препроцессоров CSS — за последний год в Sass, Less, Stylus ничего не изменилось, и это приговор.
Раньше я использовал Sass, так как я из мира Ruby.
Я раньше тоже использовал Ruby Sass, но он ооочень медленный.
В мире Sass/Less/Stylus действительно практически ничего не изменилось за последнее время. Хотя свои задачи они решают неплохо. Но стабильность без всякого развития губительна.
Зато в мире CSS появились такие инструменты как Rework, а затем PostCSS. Можешь для непросвещённых читателей вкратце рассказать, что это за инструмент такой — PostCSS, а главное, зачем он нужен?
Технически PostCSS — это инструмент, который позволяет его JS-плагинам перестраивать CSS-файл. Но в реальности этот инструмент позволяет нам совсем по другому подойти к написанию CSS. На PostCSS можно написать совершенно новые инструменты, которые будут помогать писать CSS-код. Инструменты, о которых мы даже раньше и не думали. Речь идёт не о переменных или примесях — PostCSS это следующий этап, где эти вещи уже не так важны.
Например, Автопрефиксер — он сам расставляет префиксы только там, где вам нужно. Не нужно писать примеси и тому подобное — он работает с обычным CSS. Или cssnext, который откомпилирует CSS4 в обычный CSS (как Babel для ES6). Или postcss-flexbugs-fixes — он содержит в себе базу данных ошибок реализации флексбокса в браузерах. И он автоматически исправляет или предупреждает вас, когда код будет не работать из-за этих ошибок.
То есть по сути PostCSS получает написанный нами CSS (возможно невалидный), производит с ним определённые манипуляции, как-то его модифицирует и отдаёт нам уже преобразованный, валидный CSS?
Да. Например, плагин postcss-nested в 60 строк просто проходиться по CSS и заменяет a { b { } } на a b {}. Но PostCSS не только про трансформацию CSS.
Например, Твиттер использует PostCSS, чтобы проверять БЭМ-нотацию. Или плагин doiuse,который проверяет по Can I Use все ли используемые свойства поддерживаются в нужных вам браузерах. Ну и недавно анонсированный stylelint — очень умный CSS-линтер, построенный по модульный архитектуре, как ESLint.
Интересно. Ты упомянул Твиттер. На страничке PostCSS на гитхабе сказано, что PostCSS также используют Google, Alibaba и Shopify. А можно об этом подробнее? Какие задачи они решают с помощью PostCSS?
Shopify использует Автопрефиксер. Google использует Автопрефиксер и рекомендует его как единственный инструмент для работы с браузерными префиксами. Точный список плагинов у Alibaba не знаю, но они разрабатывают cssgrace и несколько плагинов для cssnext. Так что точно используют эти два. В Китае просто большая проблема с IE — там до сих пор популярные версии 8, 7 и даже иногда 6. Поэтому cssgrace — это такой cssnext наоборот. Он находит вещи, которые не поддерживаются в старом IE и вставляет хаки для него.
Твиттер пошли дальше — они совсем отказались от препроцессоров. Когда я последний раз говорил с Николасом, он сказал, что они сейчас на Rework и переходят на PostCSS.
А ещё я слышал, что bootstrap 5, вероятно, будет переписан на PostCSS. Это похоже прямо-таки на революцию в мире CSS.
Опыт твиттера весьма любопытен. Многие разработчики боятся полностью переходить на PostCSS. Они в лучшем случае используют какой-нибудь препроцессор вместе с Автопрефиксером. Можно ли уже сейчас полностью отказаться от препроцессоров и продолжить решать те же задачи, но уже с PostCSS? Или он всё же не рассчитан на то, чтобы полностью заменить препроцессоры?
PostCSS сразу создавался чтобы заменить препроцессоры. Если мы можем делать такие сложные вещи, как Автопрефиксер или cssnext, то сделать вложенность или переменные очень легко. Как раз на этой неделе вышел PreCSS — набор плагинов для PostCSS, чтобы сделать что-то типа препроцессора.
Но тут есть важный нюанс. Если ваш проект уже написан на Sass — не переводите его на PreCSS, добавьте PostCSS после Sass. Дело в том, стагнация Sass длилась очень долго. В итоге у нас есть очень много не очень правильных способов организации код. Я видел как на Sass писали прямо целые программы — и это, конечно же, плохой подход. Это как делать SQL-запросы в шаблонах — сильное смешивание кода. Поэтому в PostCSS мы немного меняем философию. Ваши стили должны быть простыми. @for нужно использовать просто — чтобы не повторять одинаковые блоки, а не чтобы писать алгоритмы. Если вам нужна сложная логика — лучше всего её вынести в JS. И когда старый проект переписывается с Sass на PostCSS — это не просто вопрос смены синтаксиса, но скорее вопрос смены мышления. Лучше всего попробовать только PostCSS без препроцессоров на новом проекте — там вам буде легче понять философию PostCSS.
Расскажи, как вообще тебе в голову пришла идея создать PostCSS? Была необходимость решить какую-то задачу, которую не могли решить препроцессоры?
Всё началось из-за ненависти. Ненависти к Compass. У них было ужасное управление проектом — ты посылаешь PR, а они молчат по месяцам. Последней каплей было, когда моя знакомая закрыла ИП в российской бюрократии проще и быстрее, чем Compass принял мой PR.
Я понял, что Compass надо заменять. И главной вещью в Compass были префиксы. Я начал думать — как можно сделать управление префиксами ещё удобнее чем сейчас. Всё по ТРИЗ — как можно было бы управлять ими вообще идеально. И пришёл к идее Автопрефиксера, который сразу вырисовывался как проект, невозможный на препроцессорах.
Но полностью идею модульных процессоров придумал TJ Holowaychuk в проекте Rework. Первая версия Автопрефиксера даже называлась rework-vendors. Однако очень быстро Автопрефиксер перерос Rework: нам требовался парсер лучше, лучше поддержка карт кода. Ребята из Rework не хотели менять архитектуру. Так что я начал PostCSS как развитие идей Rework.
Теперь ты полностью отказался от препроцессоров и на работе используешь только PostCSS?
Да. Но мне от препроцессоров было нужно весьма мало: вложенность, какой-то простой конфиг с цветами сайта, простейшие циклы и примеси, чтобы не повторять код. Единственное чего не хватает из препроцессоров — простого синтаксиса типа Stylus. Но мы работаем над этим. В PostCSS 4.2 будут разные парсеры.
О, вот это действительно круто. А как решать вопрос с подсветкой синтаксиса? Ведь, насколько мне известно, нет никаких цветовых схем, заточенных конкретно под PostCSS. Да и обилие разных плагинов усложняет эту задачу.
Плагины никакой проблемы не создают — они же не вводят новые синтаксические конструкции. Только новые свойства или @директивы. Сейчас SCSS-подсветка прекрасно работает с PostCSS — собственно PostCSS же работает с обычным CSS, только с возможностью вложенности.
В нашем сообществе в комментариях к одному из постов сказали, что было бы разумно ввести какое-нибудь специальное расширение для файлов стилей, написанных для PostCSS — ну чтобы хотя бы никакой путаницы не возникало. Что-то вроде main.pcss. Ты задумывался об этом?
У нас точно будет специальное расширение для сокращённого синтаксиса — SugarSS.
А как быть с обычным синтаксисом?
Пока не решили :). Некоторые плагины типа Автопрефиксера, cssnext или postcss-focus ничего в CSS не добавляют, им расширение не нужно. Может быть внутри проекта PreCSS придумают какое-о расширение.
PostCSS называют постпроцессором. А чем постпроцессор отличается от препроцессора? Откуда вообще взялся этот термин?
Я сам не знаю откуда он взялся. Сейчас он уже потерял свой смысл — грань слишком стёрлась. Изначально постпроцессорами называли плагины PostCSS, которые работают с обычным CSS — например, Автопрефиксер, полифиллы будущих стандартов. Но для PostCSS есть набор плагинов PreCSS, который работает полностью как препроцессор. Я стараюсь уже не употреблять термин постпроцессоры :).
Раз сам создатель рекомендует не использовать этот термин, то грех теперь его произносить :). И, наверное, последний вопрос — сколько человек на данный момент работает над PostCSS и какие у вас планы на будущее?
Поскольку у нас модульный проект, то нельзя сказать о какой-то явной команде. Скорее это такое переплетение важных модулей.
Над ядром PostCSS работаю в основном я, хотя все остальные активно помогают мне с английским. Maxime Thirouin из Франции разрабатывает cssnext и stylelint и активно участвует в сообществе. Ben Briggs из Англии ведёт разработку важных инфраструктурных плагинов типа postcss-use и помогает новичкам в gitter-чате. Jonathan Neal из США разрабатывает PreCSS. 一丝 из Китая внедряет PostCSS в Таобао и другие проеты Алибабы и ответственен за пиар в Китае. David Clark из США занимается линтерами (Stylelint и postcss-bem-linter) и пишет отличные статьи, объясняющие PostCSS новичкам.
Это самое явное ядро проекта, но так или иначе участвует примерно 90 человек — кто-то пишет плагины, кто-то рассказывает про PostCSS. И жёсткой грани между «ядром» и остальными не существует.
Ого, неплохо. А что в планах?
В версии 4.2 добавим сменяемые парсеры. Можно будет парсить SCSS, Less, и специальный синтаксис типа Stylus, где не надо будет вводить фигурные скобки ({}) и точки с запятыми (;). В версии 4.3 добавим больше API — парсер селекторов, парсер значений. А потом будет большой релиз 5.0, где мы исправим API, сделав его более логичным — всё-таки некоторые части проекта развивались стихийно. Ещё в планах сайт и маленький митапчик PostCSSConf где-нибудь в Европе.
Класс! А в специальном синтаксисе типа Stylus двоеточия останутся или нет?
Пока ещё не решили. Хочется сохранить возможность писать многострочные значения (например для длинных градиентов).
Было бы круто реализовать лаконичный синтаксис из Stylus без двоеточий. Будем ждать новостей. Спасибо за беседу! Интересно было пообщаться. Желаем успехов тебе и твоему проекту!