Модульний CSS: — Інструментарій, який ми маємо зараз в арсеналі — це просто казка


Інструментарій, який ми маємо зараз в арсеналі — це просто казка!
Андрій Оконечников, розробник з 15-річним стажем, з яких для користувача інтерфейсах було віддано більше десяти, Андрій розповість на HolyJS про використання PostCSS і Webpack для вирішення проблем фронтенд-розробки. Доповідь Андрія називається «Модульний CSS» і присвячений тому, як за допомогою JavaScript і AST працювати з CSS на масштабних проектах. Відштовхуючись від тематики доповіді, ми поставили Андрію кілька питань, які дозволять вам зрозуміти глибину зв'язку UI/UX з роботою frontend-розробника, а також про проблеми і майбутньому CSS на великих проектах.

Основна проблема сучасного фронтенда – заторможенність
– Багато хто звик до того, що UI-дизайнер і розробник – це не тільки два різні людини, особливо на великих проектах, вони можуть навіть майже не спілкуватися один з одним. До яким, на твій погляд, наслідків призводить така роз'єднаність?

– Я в 2007 році виступав на першому Риті з доповіддю «Професія Frontend-архітектор: хто це?» і там піднімав цю проблему. Забавно, що пройшло майже 10 років, а ситуація практично не змінилася. Розробники та дизайнери намагаються не залишати свої зони комфорту: одні постять красиві «інтерфейси» на дриббле, а інші кожний місяць переписують фронтенд, використовуючи нову технологію. Результат, як правило, дуже сумний. В інтернеті безліч незручних, сумнівної якості сайтів і веб-додатків.

– Що, на твій погляд, є основною проблемою сучасного фронтенда? Як ти думаєш, яка з цих проблем найбільш зачіпає кінцевого користувача?

– Швидкість, а краще сказати, заторможенність. Повільне завантаження, особливо помітна на мобільних пристроях, веде до того, що користувачі йдуть з сайту, не дочекавшись завантаження. І популярність SPAs (Single Page Applications) не покращує ситуацію — більшість веб-додатків спочатку завантажують величезний JS-файл, перш ніж показати хоч щось. Ну і мало хто досі робить завантаження кастомних шрифтів правильно. Тому, я думаю, найближчим часом великий упор буде робитися на оптимізацію під мобільних користувачів і поліпшення інструментів для складання та аналізу.

Твій доповідь робить упор на PostCSS і Webpack. Чому саме вони? Чому не SASS?

– Мій доповідь більше про вибір правильних інструментів для певних завдань. PostCSS і Webpack, на мій погляд, вирішують у даному контексті проблеми, які інші інструменти не можуть вирішити, або вирішують погано. Це не означає, що SASS — поганий. Просто для вирішення тих проблем, про які я розповідаю, він не дуже підходить.

«Коробкові» рішення гарні для «коробкових» завдань
– Що ти думаєш про проблеми «toolkit hell»? Постпроцессоры для css, окремі шаблонизаторы, впливає весь цей оверхед на кінцевий результат? Чи Не виходить так, що в процесі розробки відкидаються фічі, технічне виконання яких конфліктує з використанням певного набору інструментів?

– Я займаюсь веб-розробкою вже більше 15 років і, на мій погляд, той інструментарій, який ми маємо зараз в арсеналі — це просто казка! Я не розумію, як автоматична розстановка вендор-префіксів, asset bundler з вбудованими best practices для сучасного вебу або сучасний CSS-лінтер з плагінами під будь синтаксис можуть заважати в розробці фіч. Навпаки, я думаю, що враховуючи зрослу складність фронтенда, неможливо робити фічі в термін і якісно, не використовуючи сучасні інструменти. Не сперечаюся, що все це треба вивчати, налаштовувати і підтримувати і це, звичайно ж, варто часу. Просто мало хто говорить про те, скільки часу у підсумку ці інструменти економлять.

– Що ти думаєш про зростаючу популярність «коробкових» CSS-рішень, таких як Bootstrap, Material UI і Semantic UI? Багато розробники скаржаться на обмеження, які це накладає на процес і результат розробки. Можливо, більш уніфікований і візуально передбачуваний веб створить більш консистентный UX?

– Я вважаю, що «коробкові» рішення гарні для «коробкових» завдань. Якщо є завдання швидко зробити користувальницький інтерфейс, то тут, напевно, без такого фреймворку буде дуже складно. Але якщо завдання зробити щось унікальне, то такі штуки як правило будуть тільки заважати. Я не закликаю робити все самому, навіть навпаки, вважаю, що писати свій дропдаун в 2016 році — це просто нерозумно. Але, вибираючи фреймворк, розробник повинен добре розуміти всі обмеження, які він накладає. В ідеалі я б хотів побачити фреймворк, який би реалізовував стандартну бібліотеку часто використовуваних контролів таким чином, щоб можна було дуже легко змінювати їх подання, так і поведінку.

– чи Не здається тобі, що CSS в останніх стандартах кілька «переріс» свій початковий мінімалістичний декларативний дизайн? Анімації, складні селектори, потихеньку починають нагадувати XPath. Не від цього потреба в додаванні mixin-ів, змінних і інших конструкцій, більш звичних в імперативних мовах?

– Так, є таке відчуття. Мені здається, що CSS намагається стати мовою програмування. При цьому в ньому досі не вирішені проблеми ізоляції, модульності, детермінізм та інші, які в нормальних мовах вже давно не проблеми. CSS створювався не для веб-додатків і SPAs, а для оформлення гіпертекстових документів. Саме тому, мені здається, ми зараз бачимо велику активність в області CSS-in-JS — надто вже велика спокуса використовувати «нормальний» або як мінімум одну мову програмування для опису та подання UI. Я в цьому не бачу нічого поганого і готовий розглядати як CSS compilation target. В ідеалі, з боку CSS-спільноти хотілося б побачити принципово новий стандарт, який би враховував зміни ландшафт використання. Але тут є проблема, що розробники з CSS і JS-таборів дуже мало перетинаються. Я думаю, треба починати вирішувати проблему з спілкування і розуміння загальних проблем мови.

Це омана, що Developer Experience не впливає на User Experience
– Як ти визначаєш момент, коли проект став настільки великим, щоб йому знадобився інструментарій для більш організованої роботи з CSS? Наскільки ознайомлення з цим інструментарієм може загальмувати розробку для маленької команди?

– Я думаю, що це момент, коли приймається рішення про створення проекту. Тут, правда, є проблема інтересів: бізнес говорить, що треба запуститися як можна швидше, тому ми зараз будемо 6 місяців лопатою гребти все одну купу: JS, CSS — неважливо. Після запуску, правда, починається пора підтримки і розробки нових фіч. І в цей момент все треба переписувати, бо ніхто не наважується чіпати старий код (на переписування часу теж немає). Мені цей підхід здається дуже дурним, бо час на переписування можна було заощадити, якщо б спочатку використовувалися code quality tools — неважливо, знову ж таки, CSS або JS. Наскільки це може загальмувати — залежить від команди. В ідеалі інструменти не повинні затормаживать, а навпаки, прискорювати.

– Адаптивний фронтэнд — практично стандарт для користувачів у 2016 році. Спрощує твій підхід роботу з величезною кількістю дозволів, з адаптацією сайтів для людей з обмеженими можливостями?

– Мою доповідь не зовсім про це, звичайно, але висока ймовірність, що в результаті гарної архітектури проекту з'явиться більше часу на створення адаптивних версій, так і на accesibility. Але в цілому, архітектура проекту на це ніяк не впливає — це лише додаткові вимоги до якості проекту.

– Є думка, що поточний напрямок розвитку фронтэнд-фреймворків кілька нарциссично. Воно ставить у главу красу коду, правильність, модульність, сумісність, однак подібні речі на перший погляд мало впливають власне на UX. Бути може, тобі є що заперечити?

– Мені здається, це помилка, що Developer Experience не впливає на User Experience. Краса коду і модульність безпосередньо пов'язані з впевненістю розробників при внесенні змін в код, що, у свою чергу, пов'язано з якістю продукту. Кількість багів, швидкість випуску нових фіч, увага до деталей — це теж частина UX. Жоден хороший розробник не захоче працювати на проекті, де купа проблем і всім наплювати.



Всім, кому захотілося глибше зануритися в тему модульного CSS, ми пропонуємо відвідати доповідь Андрія на конференції HolyJS, де будь-JavaScript-розробник зможе знайти і багато інших, не менш цікавих тем:

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

0 коментарів

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