Инструментарий, который мы имеем сейчас в арсенале — это просто сказка!
Андрей Оконечников, разработчик с 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-разработчик сможет найти и много других, не менее интересных тем:
- ECMAScript: latest and upcoming features
- Building Interactive npm Command Line Modules
- Лебедь рак и щука: как технологии тянут фронтенд на дно
- 3L3M3NT5
- Как подойти к современным веб-приложениям
- Debugging Node.js Performance Issues in Production
- WebVR is the next frontier
- A Little Closer to Frontend Bliss with Elm
- Performance Profiling for V8
- Remote (dev) tools своими руками
- Rich text editing with Draft.js
- Sharing files and data with friends using a P2P shared folder powered by javascript
Автор: JUG.ru Group
