PostCSS. Майбутнє після Sass і Less

Андрій Ситник ( Iskin, Злі марсіани
Андрій Ситник

У 2013 році Holowaychuk анонсував свій проект Rework у статті «Модульний CSS-препроцессинг з Реворком» (http://tjholowaychuk.tumblr.com/post/44267035203/modular-css-preprocessing-with-rework ).

Якраз тоді я шукав якийсь інструмент для того, щоб зробити автопрефиксер. Коли я прочитав цю статтю, я був вражений, тому що це був дійсно революційний підхід, він міняв все. І тому перші версії автопрефиксера базувалися на Rework'є. Але, на жаль, Rework – це був Proof Of Concept, це було перше покоління, щоб довести, що це взагалі працює. Тому ми його жорстко форкнули, переманили всіх розробників, влаштували маленьку революцію і зробили PostCSS.

PostCSS – це друге покоління модульного процесора.



Так що ж таке PostCSS?



PostCSS – це модульний препроцесор, в ядрі якого дуже просте. Ядро складається з двох речей:

  1. Парсер, який на вхід приймає CSS-рядок і на вихід видає дерево об'єктів javascript'івських. AST (абстрактне синтаксичне дерево).
  2. Стригифайр, який він робить зворотний річ – він отримує на вхід то абстрактне дерево у вигляді об'єктів, і на вихід видає новий CSS. За замовчуванням ядро PostCSS дуже зручний, дуже корисна, але вона не робить нічого. Воно парсити ваш CSS, а потім назад перетворює його в рядок і перетворює так, що зберігається байт в байт, навіть пробільні символи.
Вся магія знаходиться в цих плагінах.

Що таке плагін? Плагін – це така функція javascript, яка на вхід приймає AST, проходиться по яким-то його вузлів, щось шукає, щось змінює, щось додає і змінене дерево повертає назад. В змінений дерево йде наступний плагін… Виходить ланцюжок. А в кінці – магічний стригифайр, який бере це відредаговане дерево, зберігає його в новий рядок, і генерує карти коду, сорсмэпа. Генерує нові, або оновлює старі.

Як говорив Торвальдс, «покажіть мені код», тому що ми всі програмісти, код – це важливо.



Як це виглядає? PostCSS – це NP-бібліотека, ми вантажимо її з NP. Далі ми створюємо інстанси, створюємо об'єкт процесора і передаємо ті плагіни, які були на минулому кроці і все. Ми беремо і через цей процесор проганяємо наш CSS. І отримуємо результат з допомогою промиса.

Приклад плагіна:



У препроцессорах можна зробити полифил для одиниці вимірювання. Давайте напишемо його на PostCSS. Плагін – це функція, яка на вхід приймає CSS, дерево об'єктів, яке буде змінної CSS. Далі у цього дерева є такі чарівні функції – щоб вам було зручно програмувати, є ітератор за всіма властивостями, всередині, воно рекурсивно. І ми беремо і проходимся по всім властивостям. Це, до речі, зауважте ES6. Ми итерируемся за всіма властивостями, шукаємо у властивостях значення rem та замінюємо його на пікселі. Закриваємо скобочки, тому що у нас, на жаль, не CoffeeScript. Це весь код, який вам потрібно написати, щоб зробити такий базовий полифил для rem'a.

В чому різниця?



Завжди потрібно знати, кого бити, а кого ні, тобто у нас повинні бути точні критерії, де препроцесор, де постпроцесор. Препроцесор – він монолітний, всі функції вбудовані в ядро, всі змінні, домішки – все це там усередині, весь синтаксис. А друга річ – у вас код прямо в шаблоні, у вас повноцінна мова програмування.

У PostCSS все у вигляді плагінів, ядро не робить нічого. А другий момент – у вас код і стилі окремо, виходить, що у вас код на нормальному мові програмування javascript, a CSS – окремо в CSS.

Чому це так важливо? Тому що ці плагіни реалізують магічну річ – еволюцію.



Вам приходить якась божевільна ідея, і ваші друзі над вами сміються. Ви берете і реалізуєте її у вигляді плагіна, наприклад, якийсь новий метод оптимізації, і публікуєте його. Над вами, на жаль, продовжують сміятися, тому що haters gonna hate, але, як мінімум, деякі люди розуміють це, починають це використовувати, перевіряти. У них виходить, їх більше беруть на роботу, а тих, хто над вами сміявся, звільняють. Через деякий час виходить, що більшість користувачів користуються вашим плагіном. Не тому що ідея гарна, а тому що вона реально працює на практиці. І коли у нас є популярність, ми можемо прийти в W3C і або їм написати чернетку, або попросити когось іншого зробити специфікацію. Тому що робити специфікацію, коли у нас немає якогось реального практичного застосування, немає практики, ніхто не знає, працює це чи ні, ніхто не буде. Але якщо у вас є популярність, ви пишете специфікацію і йдете на нове коло, нові приниження, новий плагін і т. п.

Це була теорія. Сучасна наука говорить дуже правильну річ – теорія не значить нічого без практики. Якщо ідея дійсно працює, у нас буде реальний практичний результат, у нас буде щось. Якщо PostCSS працює, значить він буде краще препроцесора, значить у нас буде щось живе, щось, що можна помацати. Давайте подивимося, чи є це.



Перше. Само собою, в PostCSS є змінні, це не складно, є вкладеність, теж не складно, з амперсандом, як всі люблять, тому що БЕМ, само собою є домішки, синтаксис трохи інший, але такий же. Але в чому важливий момент? Все це зроблено у вигляді плагінів. І змінні, і вкладеність, і домішки. Наприклад, для змінних є два плагіна, один плагін реалізує старий добрий Sass-стиль, а інший реалізує синтаксис W3C css custom properties.



Другий важливий момент – це те, що він неймовірно маленький. Наприклад, вкладеність – це 60 рядків звичайного javascript-коду. Ви можете взяти і виправити це, а якщо я відмовлюся це прийняти, ви можете взяти і форкнуть. Це зовсім не проблема, ви за день можете зробити іншу структуру.



PostCSS це не про те, щоб робити роботу Sass'а модульно, бо це ж не так круто. Модульність – не модульність, кого це хвилює? Головне питання: а чи можна зробити більше, можна зробити якусь абсолютно нову магію? І ось автопрефиксер – головний приклад, тобто ви просто пишете звичайний CSS, а автопрефиксер сам. У нього є база даних Can I Use, він сам знаходить ті властивості, яким потрібні саме зараз префікси, додає їх, при цьому роблячи будь-яку складну магію.



Більш цікавий приклад cssnext.

В Javascript зараз можна використовувати той Javascript, який ще не в браузерах, майбутній. І у вас є компілятор, який компілює його в поточний. Було б круто робити це все в CSS. Наприклад, у нас є CSS 4, там купа нових смачних речей. Наприклад, можна оголосити свій додатковий селектор, кастомный, ваш особистий і використовувати його. І для цього у нас є cssnext.

Cssnext – це транспайлер. Ви пишете CSS 4 прямо зараз, а воно компілюється в CSS 3. Це до питання про те, що неможливо зробити на Sass. Крім кастомних селекторів у вас, наприклад, є стандартизована функція робота з кольором і, в тому числі, всякі зручні скорочення. Прямо зараз, можете прийти і додати.

Але зараз буде страшна історія.



Китай, величезний ринок, багато грошей, всі справи, але там робиться – жах! Там досі популярний Е7, 8-ої і 6-ої. Це жахливо, а грошей хочеться. Тому китайська компанія Alibaba написала плагін cssgrace. Це як cssnext, тільки навпаки. Він не з хорошого робить середній, а він, навпаки, з середнього робить поганий код. Вона проходиться по вашому CSS і знаходить ті властивості, які не будуть працювати у вашому Е, і замінює їх на хакі. Це трохи схоже на домішки, але чому це круто, і чому це важливо, що це неможливо на Sass? Тому що з домішками вам потрібно пам'ятати, де вам потрібно написати домішки, ви повинні пам'ятати, що opacity не підтримується. А тут ви просто пишете і не думаєте про це, а за вас думають китайці, мільярд китайців.



Крім того, будь-яка магія з властивостями, і можна робити магію з селекторами. Є моторошний хак, було б круто сказати, що якщо у нас чотири елемента в батьків, то давай ми зробимо завширшки 25%, а якщо п'ять, то 20. І це можна зробити прямо зараз. Хак моторошний, ви вручну писати не будете, але з допомогою цього плагіна або PostCSS, він додає вам додатковий селектор.



Або інша річ. Вище все було про те, як писати код, а це про те, як робити код, щоб ваш сайт вантажився швидше.

Є спрайт, а є бесидж 3 кодування інлайн картинок, і у них є свої плюси і мінуси. От було б круто об'єднати їх. При инлайне у вас розростається ваша CSS, і виходить, що коли користувач заходить на сайт, поки він картинки не завантажить заинлайненные в CSS, він взагалі нічого не побачить – це погано. Було б круто, якщо б спочатку завантажився дизайн, а потім картинки. І для цього є чарівний плагін data-packer. Він проходиться по вашому CSS, знаходить всі картинки заинлайненные і виносить їх в окремий файл. Тому він виявляє, що два селектора використовують одну і ту ж картинку, і об'єднує ці селектори.

У підсумку, коли користувач заходить на сайт, він швиденько вантажить маленький CSS дизайну, а потім довго CSS з картинками – зручно. Тобто додаєте один плагін, і прямо зараз ваш сайт стає швидше.



Цікавий момент. Хто підтримує ІЕ9? А хто підтримує людей, у кого є кольорова сліпота? Проблема в тому, що людей, які не бачать кольори, 5%, а користувачів IE старих – менше. І це дуже важливо підтримувати. І потрібно розуміти, що це не чорно-біле зір. Всі ці жарти про світлофор – це не про колірну сліпоту. Наприклад, так (зліва) бачить здорова людина, а так (праворуч) бачить людина з колірною сліпотою. Бачите, що кнопка гірше помітна.

Це потрібно тестувати, і з допомогою PostCSS тестувати легко. Є плагін. Ви під час розробки, наприклад, робите звичайний білд і ще один білд додаєте плагін. Цей плагін проходиться по всім квітам вашого CSS і замінює їх на кольори, що бачить людина з різними типами колірної сліпоти. Звичайно ж, є більш зручні інструменти, але ми ж розуміємо, що якщо ви не використовуєте більш зручні інструменти, значить, вони вам не підходять. Але з допомогою цього можете перевіряти сайт для людей з колірною сліпотою, використовуючи ці прості інструменти.



Ось ще один цікавий момент – PostCSS можна використовувати не тільки, щоб змінювати ваш CSS, але і для того, щоб його перевіряти. Наприклад, Твіттер використовують PostCSS для свого линтера, свого БЕМ-а. Це не дуже кльовий лінтер, тому що простий, як все линтеры, які ви вже, може бути, використовуєте. А ось є крутий лінтер – doiuse:



Він працює як два префиксера, тільки він вас «б'є лінійкою по пальцях». Він зберігає в собі базу даних Can I Use, пробігає по вашому CSS і знаходить, що наприклад: «Чувак, ти мені сказав, що ти ІЕ хочеш підтримувати, а selected user не підтримується IE, ти точно впевнений, що ти його повинен був написати?». Це дуже зручна річ.



Це мій найулюбленіший плагін. Так виглядає Вікіпедія на івриті. Чому? Тому що євреї і араби пишуть в іншу сторону. Це дуже старе лист. А справа в тому, що ви ніколи не замислювалися, чому майбутнє он там, праворуч?) Майбутнє справа, тому що ми пишемо зліва направо. А якщо ми пишемо в іншу сторону, то майбутнє в нашій голові буде зліва. І тому прогрес бар для євреїв і арабів повинен йти в іншу сторону. І це стосується не тільки прогрес бару, а взагалі писемність впливає на сприйняття простору.



І що буде, якщо ИГИЛ візьме вас в рабство і змусить верстати їм сайти? Ви ж не будете підтримувати дві версії стилів. Одну для західної аудиторії, а іншу – для арабської. І тому хлопець з Йордану (він, начебто, не в ИГИЛ-е, слава богу) написав плагін, через який ви проганяє CSS, і він замінює left на right, right на left… І таку штуку він генерує сам. Тобто на вхід звичайна Вікіпедія, а на виході Вікіпедія отзеркаленная. Це мій найулюбленіший плагін, який показує, що неможливо на Sass.



Зараз я розповів лише про ті плагіни, які зараз зовсім неможливі на Sass'e, щоб вас шокувати. Насправді, у нас дуже багато різних плагінів, які іноді більш корисні, просто вони не настільки круто виглядають. Ви можете зайти на наш github і подивитися всі плагіни, там багато цікавого, багато всякого синтетичного цукру, оптимізації, розширення мови, підтримки старих браузерів і підтримки майбутніх браузерів.



Є дуже складне питання. Я показав речі, які може робити PostCSS, які неможливі на Sass. PostCSS може робити набагато більше. Це неймовірний, більш потужний інструмент, але виникає питання: а чи може більш потужний інструмент бути швидше? Тому що в libsass зробили неймовірну річ з допомогою оптимізації на Сі, вони дуже швидкі. Можна переплюнути результат libsass? І відповідь – так.



Це головний приклад, чому модульна архітектура – це так круто, так важливо. Тому що модульну архітектуру дуже легко оптимізувати. У нас купа маленьких модулів. Ми можемо зрозуміти, що у нас гальмує цей модуль, взяти і оптимізувати його. І тому PostCSS написаний на Javascript – в 4 рази швидше libsass, написаний на С++. Це до питання про те, коли бэкендер буде говорити вам про те, що «давайте тепер пишемо все на Сі, це швидше», то ні, це не швидше.

Ще раз: які переваги PostCSS, чому воно краще, ніж Sass?



  1. PostCSS набагато швидше. Тобто навіть якщо ви задоволені швидкістю libsass, використовуючи PostCSS, ви можете зробити більше речей, ви можете робити якусь складнішу оптимізацію. Це величезний простір.
  2. Друга річ – це модульність, ви можете взяти і форкнуть проект, ви можете використовувати різні ідеї.
  3. А третя річ – найважливіша, що PostCSS більше ніж Sass. Ви можете на PostCSS робити будь-яку фічу, яка є в Sass, але на Sass ви не можете зробити більшість фіч, які є в PostCSS.
Але я обдурив вас. У назві доповіді говорилося, що PostCSS – це майбутнє після Sass. Насправді, це справжнє. У нас вже прямо зараз більше півмільйона завантажень в місяць з Can I Use. Величезна аудиторія. Тому, якщо ви боїтеся з приводу продакшн-реді, не бійтеся, ми дійсно перевіряємо PostCSS на величезній аудиторії. PostCSS користуються дуже великі компанії.



Paul Irish говорив, що автопрефиксер з PostCSS використовується в Google. Taobao – це найбільший Інтернет-магазин Китаю, він не просто використовує PostCSS, різні плагіни, він їх і пише. Wordpress використовує два плагіна. Автопрефиксер rtl css – для арабської версії. І Твіттер не просто використовує PostCSS, вони в якийсь момент взяли і викинули Less. У них використовують тільки постпроцессоры. Тільки цей спосіб підходу.



Крім того, PostCSS стає трендом. Наприклад, A List Apart написала цікаву статтю про постпроцессорах, про те, як постпроцессоры PostCSS врятує нас від темної сторони CSS-процесорів (http://alistapart.com/column/what-will-save-us-from-the-dark-side-of-pre-processors).



Або наприклад, перебіжчик в наш табір, Бен Фрейн автор книги «Sass і Compass для дизайнерів» написав статтю про те, як він розлучався з Sass і переходив на PostCSS (http://benfrain.com/breaking-up-with-sass-postcss).



Але самий кльовий твіт, це кінцеве ж, Bootsstrap. Вони написали, що вони настільки натхненні CSSnext'ом, їм це так сподобалося, що Bootstrap 5 швидше за все буде на PostCSS (https://twitter.com/mdo/status/591364406816079873). Зараз він на Less, потім він буде на Sass, а Sass вони збираються викидати і переходити на PostCSS.

Тобто що я хочу, щоб ви зробили, коли прийшли на цих вихідних додому?



Перший момент: якщо ви робите якийсь цікавий інструмент для обробки CSS, подумайте про те, щоб використовувати PostCSS. PostCSS набагато краще, ніж Regexp, тому що Regexp небезпечний – вони змінюють вам карти коду і т. п. речі.

Другий момент – препроцессоры. Ось, наприклад, ще один перебіжчик в наш табір – розробник Grid'а, домішки для реалізації сітки lost, який писав Макєєв в дуже цікавому твіттері веб-стандартів, – він перейшов на постпроцессоры, йому так сподобалося, чому? Бо раніше було потрібно підтримувати три версії – одну для Stylus'а, одну для Less, іншу для Sass. Це було дуже нудно. А тут він зрозумів: навіщо це робити? Він просто візьме як автопрефиксер. Він взяв PostCSS, і його можуть використовувати користувачі Sass, користувачі Less і т. д.



Якщо ви робите сайти, робите інструмент і не використовуєте PostCSS, додайте автопрефиксер прямо зараз. Це дуже важливо, чому? Тому що Google рекомендує єдиний інструмент для роботи з префіксами. Це тільки PostCSS, всі інші елементи набагато гірше, є багато причин чому.



Третій момент. Якщо ви вже використовуєте PostCSS, наприклад, для автопрефиксера, подивіться на інші плагіни. Я раджу почати з cssnext, тому що він реально кльовий, це можливість писати CSS 4 зараз. Крім цього, подивіться список плагінів, мені здається, що це сподобається.



І четвертий момент. Якщо ви починаєте новий проект, я не рекомендую викидати Sass прямо зараз, тому що PostCSS може працювати добре і після Sass. Навіщо його викидати? Якщо ви починаєте новий проект, подумайте, а навіщо вам робити змінні, вкладеності, домішки на препроцессорах. PostCSS теж це має, якщо ви використовуєте автопрофиксер, навіщо вам парсити файл двічі? Просто додайте змінні, вкладеності, домішки в PostCSS перед вашим автопрефиксером.

Тому що IT ж не про програмування, IT не про код. Тому що, по-хорошому, аську можна було зробити в телеграмі. Чому IT з'явилося зараз? Тому що ми зараз знаходимося в тому часі, коли ми не можемо вирішити завдання, що стоять перед нами. Всі завдання, які ми вирішуємо складніше, ніж поміщається в наш розум. У цьому ідея IT. IT – це боротьба зі складністю. А що простіше – два інструменту або один? По мені, так один.

Контакти
» Iskin
» Вконтакте
» Evil martians

Ця доповідь — розшифровка одного з кращих виступів на конференції фронтенд-розробників FrontendConf. Ми вже відкрили підготовку до 2017 року, а підписавшись на список розсилки конференції Ви отримаєте 8 кращих доповідей минулого року.

Найскладніша секція майбутньої конференції HighLoad++ це "Продуктивність фронтенда". Фронтенд став великим, це вже повноцінний софт зі своєю архітектурою, моделями і даними (а не просто інтерфейс, як було раніше). Саме в цьому розрізі ми і вивчаємо його на цій секції.

Ось деякі з запланованих доповідей:

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.