Всем привет!
Сейчас я расскажу вам одну странную историю. Однажды, я жил в кондоминимуме, в котором, на первом этаже, был зал для фитнеса с беговыми дорожками. В юности, я активно занимался спортом и тогда мне удалось познать состояние, которое возникает во время бега и называется «второе дыхание»: это когда вдруг начинаешь чувствовать себя окрыленным божеством, не знающим усталости. Дыхание, сердцебиение и движения тела входят в какой-то особый резонанс, и превращают тебя в бегущую машину. Ощущение тем ярче, на мой взгляд, чем больше вы НЕ любили бегать до этого момента. Так вот, я каждый день ходил мимо беговых дорожек и думал, что хорошо бы вспомнить молодость. Ну и вспомнил. Беговая дорожка отлично в этом помогла, она позволяла тонко настроить темп и достичь нужного ритма. На улице у меня так не получается: бежать с ровной скоростью по городу — очень трудно, мешают рельеф и препятствия. Через какое-то время я переехал в обычную квартиру (без фитнес-зала), и стал задумываться о приобретении собственной беговой дорожки.
Да, конечно, можно было бы просто купить абонемент в ближайший спортклуб, но я, как и многие мои коллеги во IT — социофоб. Если даже не социопат. Физические упражнения для меня — процесс интимный. Ну и использовать для тренировок любую свободную минуту также было заманчиво: «здоровье гика» и все такое… Короче, я просматривал предложения интернет магазинов, читал отзывы, прикидывал сколько на это дело можно потратить, как решать вопрос с шумом и куда эту немаленькую бандуру поставить… Затем мне в руки попала обычная скакалка, и я сказал себе: ну вот же он, неплохой вариант для кардио-тренировок без лишнего геморроя! Всего-то нужны высокие потолки и… Ничего не вышло: для того, чтобы скакать на скакалке ритмично и равномерно нужно уметь это делать. Возвращаемся к мыслям о беговой дорожке или… Погодите, а почему-бы не попробовать просто БЕГ НА МЕСТЕ? Да ну, как-то СЛИШКОМ просто и глупо. Но я попробовал. И знаете что? Это великолепно! Ощущения практически те-же, что я испытывал на беговой дорожке, только все во много раз проще: цепляешь на руку фитнес-браслет, одеваешь наушники с колбасным музлом, включаешь таймер — и вперед! Да, есть нюансы, но поверьте, они незначительны. В итоге, я уже какое-то время просто болею этой темой, вот настолько, что хочется вступить в секту таких-же сумасшедших. Вы спросите меня: что ты несешь вообще, как это все связано с веб-разработкой?
Рассмотрим популярный стек технологий для современной разработки фронтэнда:
TypeScript + LESS/SCSS/PostCSS + React + Redux/Mobx + Webpack
Де-факто, сейчас это некий стандарт. Убедиться в этом легко, анализируя вакансии. Любой новый проект в текущем году, с высочайшей долей вероятности, будет запускаться с подобным списком под капотом. Это такой хороший набор проверенных временем "беговых дорожек". Давайте вместе пройдемся по этому списку и посмотрим, что от него останется, если использовать подход «Бег на месте».
Замечательная штука. Это поймет любой, кто хоть раз писал что-то серьезное для веб. Часто в статьях о TypeScript для начинающих, приводя примеры, говорят о каких-то совсем простых и банальных вещах, типа передачи типизированных аргументов в функцию или превратностях приведения типов в JavaScript, от которых вас спасают. Но возможности TS больше и глубже чем проверки типов на стадии компиляции, он может вести разработчика «за руку» по всему проекту, подсказывая и не давая лишний раз оступиться. Но у TS есть и недостатки: он НЕ работает в браузере без транспайла и его синтаксис, скажем так, «рябит» в глазах. Когда вы работаете с фронтэндом, ваш рабочий процесс часто включает в себя проверку того, как ваш код выполняется в браузере, вам нужен постоянный доступ к нативному рантайму. Потери времени на пересборку проекта для отображения изменений, в совокупности, могут быть колоссальными. Даже если у вас все, что нужно кэшируется и оптимизируется. Что же делать? Мой вариант: использовать JS + JSDoc. Да, статический анализатор TS поддерживает формат JSDoc. При этом, вы видите в браузере свой код непосредственно и пользуетесь благами цивилизации. Блоки, описывающие типы, и прочие подсказки не смешаны с кодом и имеют явные границы, что, лично мне, очень помогает читать код «по диагонали». Если вы используете VS Code, попробовать подобный подход вы можете просто добавив строку //@ts-check в начало вашего кода. Если вам требуется поддержка устаревших браузеров, компиляция из ES6+, конечно, все равно понадобится, но уже только для production-версии. В итоге, вы упрощаете дебаг в рантайме (от которого отсутствие ошибок и предупреждений при сборке не избавит) и экономите кучу времени.
Из данного набора, моими любимыми были LESS и PostCSS. LESS я любил за более «нативный» синтаксис и относительную легкость необходимых зависимостей для окружения разработки. PostCSS помогал творить всякие хитрые фокусы с SVG и следить за префиксами. Недостатками же, как и в предыдущем пункте, я бы назвал необходимость постоянной перекомпиляции. Ну и сами зависимости. Однако, в нашем 2018-м году у нас есть такая замечательная штука, как нативные CSS-переменные! Это чрезвычайно мощная вещь, с которой не сравнится ни один препроцессор: ваши переменные вы можете переопределять прямо в рантайме! Это открывает целый мир новых возможностей. Например, вы можете очень просто, «на лету», менять темы как всего приложения, так и отдельных его блоков. Буквально, пользователь может накликать скин для приложения каким-нибудь колор-пикером и для этого не нужно держать отдельные пакеты с предварительно скомпилированными стилями или утяжелять дополнительной логикой ваш JS. И еще много всего, более тонкого и специфичного. Я выбираю нативный современный CSS. Но если вам нужно поддерживать IE11 — то печаль.
React принес нам новую концепцию модульной декомпозиции, которая очень хорошо легла на потребности клиент-сайд-разработки, ибо структура компонентов повторяла структуру представления, упрощая восприятие и принося порядок в головы разработчиков. Именно поэтому, на мой взгляд, он стал таким популярным и именно за это ему спасибо. Однако, сейчас React все больше и больше обрастает свойствами карго-культа: люди начинают тащить его в проекты только потому, что «все так делают». И это ужасно, ведь инженерный выбор, особенно в таком важном вопросе, должен быть максимально осознанным. А для осознанности нужно понимать, что у React полно недостатков. Для меня это, прежде всего, то, что он является слишком толстой абстракцией поверх нативного DOM и привносит огромное количество собственной специфики, с которой требуется разбираться вместо прямого решения задач. Особенно это чувствуется и удручает, если ваши задачи чуть менее тривиальны, чем банальные формочки. На эту тему можно долго рассуждать, вспомнить JSX, VDOM и прочее, но для нас сейчас главным является вопрос: а альтернатива то какая? Нет, не Vue. И не, тем более, Angular. Для меня это веб-компоненты: набор стандартов CustomElements + ShadowDOM + ES Modules + HTML Templates. Почему? Потому, что это стандарты, поддерживаемые самой веб-платформой, а не мета-платформы и JS-надстройки.
Разбить ваш код на аккуратные блоки и организовать его как вашей душе угодно вы можете с помощью нативных модулей. Да, модули поддерживаются всеми современными браузерами и вам не нужна пересборка в процессе разработки. Да, в модулях можно по отдельности хранить и стили и шаблоны. Да, для этих файлов можно специально включить поддержку синтаксиса и работать с ними как с нативным HTML и CSS. Жизненный цикл веб-компонентов поможет вам организовать рендер и обновления без лишнего парсинга и изменения структуры DOM. ShadowDOM позволит вам избавиться от громоздкого BEM и не беспокоиться дополнительно о инкапсуляции стилей.
ShadowDOM прозрачен для CSS-переменных и позволяет передавать параметры внутрь с любого надлежащего уровня вложенности. Это позволяет экспериментировать с параметрическим дизайном и делать много других фокусов. Веб-компоненты полноценно работают с обычным DOM API являясь при этом, полноценными html-элементами: все стандартные методы — в ваших руках. Вы можете использовать кастомные атрибуты для передачи параметров и настройки отображения (правда, в отличие от React, вы не можете передать ничего кроме строк и булевых значений, но по мне так это вовсе не проблема). Ваш код будет легче и быстрее. Поверьте, мне доводилось сравнивать. Немного грусти: у большинства пользователей все будет работать нативно, но некоторым понадобятся полифилы. Если ваша статистика и целевая аудитория, в основном, про современные браузеры — смело ныряйте в эту тему, она того стоит.
Тут сложнее. С одной стороны, есть куча статей с перечислением достоинств и недостатков и сравнениями различных подходов к хранению состояний. И чтобы перейти к конкретике — нужен конкретный кейс. Так вышло, что эта тема меня уже довольно давно преследует в работе: мне попадаются довольно сложные задачи по работе со сложноструктурированными данными. Ну и вообще: данные, близкие к реальности, никогда на практике не бывают простыми, удобно нормализованными с четкой универсальной иерархией. Чаще всего это какой-нибудь хитрый граф, который требует того, чтобы изначально закладывать в систему максимально гибкость. В этом вопросе я адепт велосипедостроения, но не стану огульно всем рекомендовать свой путь. Что я точно могу посоветовать — так это не брезговать основами современной computer science, почитать что-нибудь научно-популярное по теории графов, теории множеств, теории хаоса. Причем, я говорю не про какой-то хардкор: самые общие представления могут оказаться очень полезными и «прочистить мозги» в правильном ключе. В простом случае, вы вполне сможете «на коленке» написать свое хранилище состояний с блекджеком и подписками, и это будет не сложнее, чем копаться в документации популярных библиотек.
Отказаться от системы сборки полностью, мы, конечно, можем. Но резолвинг цепочки импортов в коде в реальном времени — штука не самая быстрая. Поэтому бандлы для production-версии нам все-же понадобятся. Ну и какая-нибудь минификация/обфускация, опять-же, и компактная папочка dist… Поэтому Webpack — оставляем. Но нам нужна для него всего пара модулей с минимальными конфигами, и никаких вотчеров и пересборок для процесса разработки. Лично мой конфиг сборки выглядит очень компактно и не требует большого числа зависимостей. В последнее время я часто слышу о новом сборщике Parcel, и его минималистичная концепция мне очень импонирует, но он, насколько я знаю, не работает с ES-модулями, и по моему, это фейл. Надеюсь это изменится.
Я часто слышу мнение о том, что если вы пишите «на ваниле» — вы неизбежно столкнетесь тем, что ваш проект скоро превратится в неподдерживаемую кашу с лапшой. Позвольте парировать: во первых, при желании, кашу можно приготовить и из реакта с редуксом (я на такое насмотрелся). А во вторых, все будет очень даже хорошо, если вы будете использовать модули, JSDoc и хорошие практики ООП. Итак, к чему мы пришли:
JS + CSS + Web Components + Webpack
Из пяти «беговых дорожек» у нас осталась только одна, существенно облегченная. И этого достаточно, чтобы почувствовать «крылья за спиной».
P. S. Я ни в коем случае не утверждаю, что мои подходы подойдут всем. Прошу расценивать сей опус хотя-бы как повод задуматься о том, что нам кажется само-собой разумеющимся.
Сейчас я расскажу вам одну странную историю. Однажды, я жил в кондоминимуме, в котором, на первом этаже, был зал для фитнеса с беговыми дорожками. В юности, я активно занимался спортом и тогда мне удалось познать состояние, которое возникает во время бега и называется «второе дыхание»: это когда вдруг начинаешь чувствовать себя окрыленным божеством, не знающим усталости. Дыхание, сердцебиение и движения тела входят в какой-то особый резонанс, и превращают тебя в бегущую машину. Ощущение тем ярче, на мой взгляд, чем больше вы НЕ любили бегать до этого момента. Так вот, я каждый день ходил мимо беговых дорожек и думал, что хорошо бы вспомнить молодость. Ну и вспомнил. Беговая дорожка отлично в этом помогла, она позволяла тонко настроить темп и достичь нужного ритма. На улице у меня так не получается: бежать с ровной скоростью по городу — очень трудно, мешают рельеф и препятствия. Через какое-то время я переехал в обычную квартиру (без фитнес-зала), и стал задумываться о приобретении собственной беговой дорожки.
Да, конечно, можно было бы просто купить абонемент в ближайший спортклуб, но я, как и многие мои коллеги во IT — социофоб. Если даже не социопат. Физические упражнения для меня — процесс интимный. Ну и использовать для тренировок любую свободную минуту также было заманчиво: «здоровье гика» и все такое… Короче, я просматривал предложения интернет магазинов, читал отзывы, прикидывал сколько на это дело можно потратить, как решать вопрос с шумом и куда эту немаленькую бандуру поставить… Затем мне в руки попала обычная скакалка, и я сказал себе: ну вот же он, неплохой вариант для кардио-тренировок без лишнего геморроя! Всего-то нужны высокие потолки и… Ничего не вышло: для того, чтобы скакать на скакалке ритмично и равномерно нужно уметь это делать. Возвращаемся к мыслям о беговой дорожке или… Погодите, а почему-бы не попробовать просто БЕГ НА МЕСТЕ? Да ну, как-то СЛИШКОМ просто и глупо. Но я попробовал. И знаете что? Это великолепно! Ощущения практически те-же, что я испытывал на беговой дорожке, только все во много раз проще: цепляешь на руку фитнес-браслет, одеваешь наушники с колбасным музлом, включаешь таймер — и вперед! Да, есть нюансы, но поверьте, они незначительны. В итоге, я уже какое-то время просто болею этой темой, вот настолько, что хочется вступить в секту таких-же сумасшедших. Вы спросите меня: что ты несешь вообще, как это все связано с веб-разработкой?
А вот как
Рассмотрим популярный стек технологий для современной разработки фронтэнда:
TypeScript + LESS/SCSS/PostCSS + React + Redux/Mobx + Webpack
Де-факто, сейчас это некий стандарт. Убедиться в этом легко, анализируя вакансии. Любой новый проект в текущем году, с высочайшей долей вероятности, будет запускаться с подобным списком под капотом. Это такой хороший набор проверенных временем "беговых дорожек". Давайте вместе пройдемся по этому списку и посмотрим, что от него останется, если использовать подход «Бег на месте».
TypeScript
Замечательная штука. Это поймет любой, кто хоть раз писал что-то серьезное для веб. Часто в статьях о TypeScript для начинающих, приводя примеры, говорят о каких-то совсем простых и банальных вещах, типа передачи типизированных аргументов в функцию или превратностях приведения типов в JavaScript, от которых вас спасают. Но возможности TS больше и глубже чем проверки типов на стадии компиляции, он может вести разработчика «за руку» по всему проекту, подсказывая и не давая лишний раз оступиться. Но у TS есть и недостатки: он НЕ работает в браузере без транспайла и его синтаксис, скажем так, «рябит» в глазах. Когда вы работаете с фронтэндом, ваш рабочий процесс часто включает в себя проверку того, как ваш код выполняется в браузере, вам нужен постоянный доступ к нативному рантайму. Потери времени на пересборку проекта для отображения изменений, в совокупности, могут быть колоссальными. Даже если у вас все, что нужно кэшируется и оптимизируется. Что же делать? Мой вариант: использовать JS + JSDoc. Да, статический анализатор TS поддерживает формат JSDoc. При этом, вы видите в браузере свой код непосредственно и пользуетесь благами цивилизации. Блоки, описывающие типы, и прочие подсказки не смешаны с кодом и имеют явные границы, что, лично мне, очень помогает читать код «по диагонали». Если вы используете VS Code, попробовать подобный подход вы можете просто добавив строку //@ts-check в начало вашего кода. Если вам требуется поддержка устаревших браузеров, компиляция из ES6+, конечно, все равно понадобится, но уже только для production-версии. В итоге, вы упрощаете дебаг в рантайме (от которого отсутствие ошибок и предупреждений при сборке не избавит) и экономите кучу времени.
LESS/SCSS/PostCSS
Из данного набора, моими любимыми были LESS и PostCSS. LESS я любил за более «нативный» синтаксис и относительную легкость необходимых зависимостей для окружения разработки. PostCSS помогал творить всякие хитрые фокусы с SVG и следить за префиксами. Недостатками же, как и в предыдущем пункте, я бы назвал необходимость постоянной перекомпиляции. Ну и сами зависимости. Однако, в нашем 2018-м году у нас есть такая замечательная штука, как нативные CSS-переменные! Это чрезвычайно мощная вещь, с которой не сравнится ни один препроцессор: ваши переменные вы можете переопределять прямо в рантайме! Это открывает целый мир новых возможностей. Например, вы можете очень просто, «на лету», менять темы как всего приложения, так и отдельных его блоков. Буквально, пользователь может накликать скин для приложения каким-нибудь колор-пикером и для этого не нужно держать отдельные пакеты с предварительно скомпилированными стилями или утяжелять дополнительной логикой ваш JS. И еще много всего, более тонкого и специфичного. Я выбираю нативный современный CSS. Но если вам нужно поддерживать IE11 — то печаль.
React
React принес нам новую концепцию модульной декомпозиции, которая очень хорошо легла на потребности клиент-сайд-разработки, ибо структура компонентов повторяла структуру представления, упрощая восприятие и принося порядок в головы разработчиков. Именно поэтому, на мой взгляд, он стал таким популярным и именно за это ему спасибо. Однако, сейчас React все больше и больше обрастает свойствами карго-культа: люди начинают тащить его в проекты только потому, что «все так делают». И это ужасно, ведь инженерный выбор, особенно в таком важном вопросе, должен быть максимально осознанным. А для осознанности нужно понимать, что у React полно недостатков. Для меня это, прежде всего, то, что он является слишком толстой абстракцией поверх нативного DOM и привносит огромное количество собственной специфики, с которой требуется разбираться вместо прямого решения задач. Особенно это чувствуется и удручает, если ваши задачи чуть менее тривиальны, чем банальные формочки. На эту тему можно долго рассуждать, вспомнить JSX, VDOM и прочее, но для нас сейчас главным является вопрос: а альтернатива то какая? Нет, не Vue. И не, тем более, Angular. Для меня это веб-компоненты: набор стандартов CustomElements + ShadowDOM + ES Modules + HTML Templates. Почему? Потому, что это стандарты, поддерживаемые самой веб-платформой, а не мета-платформы и JS-надстройки.
Разбить ваш код на аккуратные блоки и организовать его как вашей душе угодно вы можете с помощью нативных модулей. Да, модули поддерживаются всеми современными браузерами и вам не нужна пересборка в процессе разработки. Да, в модулях можно по отдельности хранить и стили и шаблоны. Да, для этих файлов можно специально включить поддержку синтаксиса и работать с ними как с нативным HTML и CSS. Жизненный цикл веб-компонентов поможет вам организовать рендер и обновления без лишнего парсинга и изменения структуры DOM. ShadowDOM позволит вам избавиться от громоздкого BEM и не беспокоиться дополнительно о инкапсуляции стилей.
ShadowDOM прозрачен для CSS-переменных и позволяет передавать параметры внутрь с любого надлежащего уровня вложенности. Это позволяет экспериментировать с параметрическим дизайном и делать много других фокусов. Веб-компоненты полноценно работают с обычным DOM API являясь при этом, полноценными html-элементами: все стандартные методы — в ваших руках. Вы можете использовать кастомные атрибуты для передачи параметров и настройки отображения (правда, в отличие от React, вы не можете передать ничего кроме строк и булевых значений, но по мне так это вовсе не проблема). Ваш код будет легче и быстрее. Поверьте, мне доводилось сравнивать. Немного грусти: у большинства пользователей все будет работать нативно, но некоторым понадобятся полифилы. Если ваша статистика и целевая аудитория, в основном, про современные браузеры — смело ныряйте в эту тему, она того стоит.
Redux/Mobx
Тут сложнее. С одной стороны, есть куча статей с перечислением достоинств и недостатков и сравнениями различных подходов к хранению состояний. И чтобы перейти к конкретике — нужен конкретный кейс. Так вышло, что эта тема меня уже довольно давно преследует в работе: мне попадаются довольно сложные задачи по работе со сложноструктурированными данными. Ну и вообще: данные, близкие к реальности, никогда на практике не бывают простыми, удобно нормализованными с четкой универсальной иерархией. Чаще всего это какой-нибудь хитрый граф, который требует того, чтобы изначально закладывать в систему максимально гибкость. В этом вопросе я адепт велосипедостроения, но не стану огульно всем рекомендовать свой путь. Что я точно могу посоветовать — так это не брезговать основами современной computer science, почитать что-нибудь научно-популярное по теории графов, теории множеств, теории хаоса. Причем, я говорю не про какой-то хардкор: самые общие представления могут оказаться очень полезными и «прочистить мозги» в правильном ключе. В простом случае, вы вполне сможете «на коленке» написать свое хранилище состояний с блекджеком и подписками, и это будет не сложнее, чем копаться в документации популярных библиотек.
Webpack
Отказаться от системы сборки полностью, мы, конечно, можем. Но резолвинг цепочки импортов в коде в реальном времени — штука не самая быстрая. Поэтому бандлы для production-версии нам все-же понадобятся. Ну и какая-нибудь минификация/обфускация, опять-же, и компактная папочка dist… Поэтому Webpack — оставляем. Но нам нужна для него всего пара модулей с минимальными конфигами, и никаких вотчеров и пересборок для процесса разработки. Лично мой конфиг сборки выглядит очень компактно и не требует большого числа зависимостей. В последнее время я часто слышу о новом сборщике Parcel, и его минималистичная концепция мне очень импонирует, но он, насколько я знаю, не работает с ES-модулями, и по моему, это фейл. Надеюсь это изменится.
Что в итоге
Я часто слышу мнение о том, что если вы пишите «на ваниле» — вы неизбежно столкнетесь тем, что ваш проект скоро превратится в неподдерживаемую кашу с лапшой. Позвольте парировать: во первых, при желании, кашу можно приготовить и из реакта с редуксом (я на такое насмотрелся). А во вторых, все будет очень даже хорошо, если вы будете использовать модули, JSDoc и хорошие практики ООП. Итак, к чему мы пришли:
JS + CSS + Web Components + Webpack
Из пяти «беговых дорожек» у нас осталась только одна, существенно облегченная. И этого достаточно, чтобы почувствовать «крылья за спиной».
P. S. Я ни в коем случае не утверждаю, что мои подходы подойдут всем. Прошу расценивать сей опус хотя-бы как повод задуматься о том, что нам кажется само-собой разумеющимся.
