Сейчас я расскажу вам одну странную историю. Однажды, я жил в кондоминимуме, в котором, на первом этаже, был зал для фитнеса с беговыми дорожками. В юности, я активно занимался спортом и тогда мне удалось познать состояние, которое возникает во время бега и называется «второе дыхание»: это когда вдруг начинаешь чувствовать себя окрыленным божеством, не знающим усталости. Дыхание, сердцебиение и движения тела входят в какой-то особый резонанс, и превращают тебя в бегущую машину. Ощущение тем ярче, на мой взгляд, чем больше вы НЕ любили бегать до этого момента. Так вот, я каждый день ходил мимо беговых дорожек и думал, что хорошо бы вспомнить молодость. Ну и вспомнил. Беговая дорожка отлично в этом помогла, она позволяла тонко настроить темп и достичь нужного ритма. На улице у меня так не получается: бежать с ровной скоростью по городу — очень трудно, мешают рельеф и препятствия. Через какое-то время я переехал в обычную квартиру (без фитнес-зала), и стал задумываться о приобретении собственной беговой дорожки.
Да, конечно, можно было бы просто купить абонемент в ближайший спортклуб, но я, как и многие мои коллеги во 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. Я ни в коем случае не утверждаю, что мои подходы подойдут всем. Прошу расценивать сей опус хотя-бы как повод задуматься о том, что нам кажется само-собой разумеющимся.
Комментарии (54)
codemafia
16.08.2018 15:00Ну и сами зависимости. Однако, в нашем 2018-м году у нас есть такая замечательная штука, как нативные CSS-переменные! Это чрезвычайно мощная вещь, с которой не сравнится ни один препроцессор: ваши переменные вы можете переопределять прямо в рантайме!
А rem/em переменные умею считать?
korobkov-k
16.08.2018 15:03Всё чаще вижу борьбу со «стандартами» и, как правило, из уст очень опытных и увлеченных фронтендщиков, которые расковыряли все стандарты, устройство браузера и конечно же свои проекты до самых корней, потратив на это N лет. Но если в команду набирают junior/middle ребят и их надо как-то организовать и поставить разработку на поток, то не легче ли жить со «стандартами», которые все знают. Если конкретно про статическую типизацию, то код в typescript будет выглядеть лаконичнее и писаться проще, чем ванилла + JSDoc, разве нет? Плюс он больше располагает к указанию типов прямо в процессе кодинга. А JSDoc — это такая штука, привязанная сбоку, на которую можно и забить, особенно если вдруг спешка.
По поводу компиляции проектов — она довольно быстрая, но это, конечно, субъективно. А с опытом, как и в других сферах программирования, приходит навык написания большего количества строк кода без ошибок. То есть опытному спецу, которому все эти типизации и компиляторы не нужны, не нужно и страницу перезагружать после каждой измененной строчки в CSS.i360u Автор
16.08.2018 15:11Вы так говорите, будто я противопоставляю подходу "по умолчанию" что-то нестандартное. Все перечисленное — и есть самые настоящие стандарты веб-платформы. И их необходимо знать разработчику на любом стеке.
Про TS — я написал: он не работает в браузере. К сожалению.
По поводу больших блоков кода и пересборки — все верно, но только до тех пор, пока вы не взялись за UI.
i360u Автор
16.08.2018 15:24Дополню: JSDoc — он слегка сбоку, да, но анализ работает и для простого JS, даже без аннотаций. И это дает привыкнуть и втянуться. А JSDoc потом уже сам в руки просится.
k12th
16.08.2018 15:44Пока веб-компоненты поддерживаются только у 60% пользователей, это будет оставаться такой же мета-платформой, с жирнючими, ЕМНИП, полифиллами. Для души дома можно и даже пожалуй нужно.
i360u Автор
16.08.2018 15:47-178.13 != 60, во первых, а во вторых полифилы не жирнее реакта. Ну и чуваки из Youtube и GitHub, к примеру, с вами не согласны.
k12th
16.08.2018 15:55Для этих (78.13 — 60)% это будет "Дорогие пользователи, чтобы насладиться нашим сайтом, пожалуйста включите настройку dom.webcomponents.shadowdom.enabled". Или "выбросьте уже свой сафари и поставьте нормальный браузер".
i360u Автор
16.08.2018 16:06-1ага, минусануть проще, чем по ссылочке сходить и глянуть, как там safari: https://caniuse.com/#feat=shadowdomv1
k12th
16.08.2018 16:08А самому сходить и увидеть что там неполная поддержка?
i360u Автор
16.08.2018 16:14А я очень хорошо знаю в чем ее неполнота, и мне она не мешает. Я еще раз повторю, я использую эти технологии сам и не на сайте "вася-пупкин.ком". Тестирую все лично в разных браузерах и на разных устройствах. Но вот обязательно найдется кто-то "очень умный" и расскажет как у меня ничего не работает, вопреки тестам и собственным глазам. Если уж минусите, потрудитесь аргументацию получше подбирать.
dagen
17.08.2018 08:25Пытались использовать в проде 4 года назад на очень большом SPA. И о бедные пользователи Firefox! С некоторой критической черты старт приложения в FF превратился в один большой многосекундный фриз. Жирность их не большая, но тяжёлое SPA полифилам было не переварить. Правда может с тех пор ситуация с полифилами изменилась?
С удовольствием посмотрю на веб-компоненты, когда в FF они наконец-то выйдут из-под флагаi360u Автор
17.08.2018 08:31За 4 года много воды утекло, и полифилы и поддержка самих компонентов — все сильно изменилось. Устаканился и сам стандарт. А в то время это скорее было превью того, как оно будет выглядеть в будущем, да.
springimport
17.08.2018 16:28На счет Утуба все понятно — нет плавности даже на 8700k. Вот так вот.
А Гитхаб вроде переписывали на что-то свое с jquery, даже была новость. Сомневаюсь что там тяжелые компоненты.
codrem
16.08.2018 16:29+1Буквально вчера смотрел конференцию на подобную тему — www.youtube.com/watch?v=HiE7FmIKOQ0
Synoptic
16.08.2018 18:10+1В прошлом году на пальцах пытался объяснить тоже самое, на примере Polymer.
К текущему моменту правда издохли HTML Imports, плюс я тоже пришел к выводу, что как минимум резольвилка модулей и прод-минификатор не лишние, но все остальное актуально.
niksite
16.08.2018 17:03+1По первому абзацу было решил вы тут изложите как организовали свое рабочее место над беговой дорожкой и занимаетесь так веб программизмом...
Если что — в Фейсбуке ребята так и работают многие, у них там есть сидячие места, стоячие и бегучие.
MetaDone
17.08.2018 10:54а я думал что будет информация которую можно вытащить из данных пробежки как-то отображаться в веб-морде, что-то типа красивых графиков скорости, пульса, восстановления пульса после окончания пробежки, чтоб за какое-то время можно было наблюдать динамику повышения тренированности, типа за месяц стал пульс быстрее в норму приходить, при определенном пульсе средняя скорость стала выше и т.п.
bgnx
16.08.2018 21:09На эту тему можно долго рассуждать, вспомнить JSX, VDOM и прочее, но для нас сейчас главным является вопрос: а альтернатива то какая? Нет, не Vue. И не, тем более, Angular. Для меня это веб-компоненты: набор стандартов CustomElements + ShadowDOM + ES Modules + HTML Templates. Почему? Потому, что это стандарты, поддерживаемые самой веб-платформой, а не мета-платформы и JS-надстройки..
Забавно, раньше под статьей про реакт или про какой-то другой js-фреймворк кто-то непонимающий обязательно напишет «А зачем оно надо, я на жуквери напишу за 15 минут» а теперь похоже настало время фраз — «зачем мне фреймворки если есть веб-компоненты»
Да, вебкомпоненты позволяют разбить на компоненты, изолировать стили и прочее, но они не никак решают самую главную проблему существования js-фреймвоков — проблему синхронизации ui и состояния. На эту тему даже есть отличная статья — medium.com/dailyjs/the-deepest-reason-why-modern-javascript-frameworks-exist-933b86ebc445.
Ну и вдобавок веб-компоненты имеют один фундаментальный недостаток — они не поддерживают svg. Вот захотите вы разбить какой-то svg-шаблон на компоненты также как и html, а нет — нельзя, приплыли. Когда же в реакте да и в остальных популярных js-фреймворках можно свободно разбивать svg на компоненты.Synoptic
16.08.2018 22:10Да, вебкомпоненты позволяют разбить на компоненты, изолировать стили и прочее, но они не никак решают самую главную проблему существования js-фреймвоков — проблему синхронизации ui и состояния.
Решения для синхронизации UI и состояния для фреймворков и компонентов доступны одни и те же.
Ну и вдобавок веб-компоненты имеют один фундаментальный недостаток — они не поддерживают svg. Вот захотите вы разбить какой-то svg-шаблон на компоненты также как и html, а нет — нельзя, приплыли.
В чем фундаментальность этого недостатка, можете привести юзкейсы, когда это надо? Фундаментальный недостаток — это такой, когда все остальные плюсы оказываются в его тени, а тут что-то не похоже.
i360u Автор
17.08.2018 07:55Проблема фреймворков в том, что они, на самом деле, НЕ решают проблему, которая обуславливает их существование. Точнее решают ее не до конца, оставляя миллион возможностей выстрелить себе в ногу в самой сложной ее части. React не умеет ничего делать с состоянием уровня приложения, он работает только с состоянием уровня компонента. А Redux — управляет глобальным состоянием, но ничего не знает про эффективные апдейты DOM. Ему это и не нужно конечно, но вот только мы уже давно вышли за пределы просто библиотеки для постройки UI. На уровне компонента, магия с динамическими привязками может впечатлить только откровенных новичков. И нужна она, по большей части, для задач организации и стандартизации структуры проекта, чтобы было удобнее работать со стандартными шаблонами. А в случае с веб-компонентами и прямым доступом к их DOM у вас нет такой необходимости. А на уровне приложения, вы очень быстро поймете, какая неудобная штука этот Redux, если ваши данные имеют какую-то более сложную структуру, чем нечто самое примитивное.
В конце концов, я написал что не призываю никого все бросать и срочно все переписывать на компонентах. Лично мне они дают очень многое, чего не давали фреймворки. Ну и размеры сборок у меня в РАЗЫ меньше, чем в проетах на реакте. И в тестах производительности они реакт уделывают. Да, пока только в Хроме, но, на минутчку, говоря о Хроме, мы уже говорим о БОЛЬШИНСТВЕ пользователей.
bgnx
17.08.2018 01:22Решения для синхронизации UI и состояния для фреймворков и компонентов доступны одни и те же.
Во фреймворках (react, vue, angular) это уже встроено а c вебкомпонентами либо придется писать код в стиле jquery вручную меняя дом-элементы либо использовать дополнительно еще фреймворк/шаблонизатор который будет менять ui в зависимости от изменения данных но тогда смысл в веб-компонентах как в самодостаточной технологии теряется.
В чем фундаментальность этого недостатка, можете привести юзкейсы, когда это надо?
Ну как же — без поддержки svg веб-компоненты это какая-то обрезанная и ограниченная версия компонентой модели. Если какой-нибудь html-шаблон можно разбить на компоненты то чем svg хуже? Как с веб-компонентами вы планируете строить какой-нибудь сложный интерфейс на svg например онлайн-фотошоп или приложение для создание презентаций где будут графики, кривые безье, сложные фигуры и т.д?Synoptic
17.08.2018 01:56Во фреймворках (react, vue, angular) это уже встроено
Что куда встроено? В коробочной поставке фреймворков для управления стейтом предлагаются немасштабируемые решения, пригодные лишь для простых приложений. Ну так такое решение и у веб-компонентов есть, вполне нативный js — гуглите Custom Events(организовать паттерн медиатор), attributeChangedCallback(пропсы прокинуть). Для чего-то более сложного хоть для React/Angular/Vue, хоть для веб-компонентов надо брать отдельное решение типа Redux/MobX.
Как с веб-компонентами вы планируете строить какой-нибудь сложный интерфейс на svg например онлайн-фотошоп или приложение для создание презентаций где будут графики, кривые безье, сложные фигуры и т.д?
Я не особо понимаю, в чем проблема делать это с использованием веб-компонентов. Вот пример. Веб-компоненты это не фреймворк, это более низкоуровневый API, но если что-то надо, никто не мешает дописать абстракций или использовать что-то готовое.
i360u Автор
17.08.2018 08:14Графики прекрасно рисуются на canvas и в WebGL, им не нужна древовидная структура документа, там вы оперируете другими сущностями. А вот чтобы нарисовать UI вокруг графиков — веб-компоненты отличный вариант. Что касается SVG — там есть инструментарий специфичный для этого формата, жаль конечно, что нельзя использовать единый подход, но ведь и простой HTML вы не сможете смешать с SVG без большого количества танцев с бубном.
i360u Автор
17.08.2018 08:22Кстати, насчет SVG, я как-то делал эксперимент с SVG на компонентах: брал дочерние компоненты с описанием элементов и рендерил соответствующие им svg-ноды в теневом DOM компонента-контейнера. Конечно это не нативная поддержка, но вполне рабочий вариант для простых случаев.
zapolnoch
17.08.2018 01:51-1Когда в браузерах не было удобной системы для работы с селекторами, мы использовали jQuery. Потом браузеры худо-бедно поддержали работу с селекторами (Document.querySelector), но нам уже не надо было, мы уже во всю писали на компонентах.
Боюсь, что, когда веб-компоненты достигнут уровня React/Angular/Vue, нам оно уже не будет нужно, мы будет писать на чем-то другом.i360u Автор
17.08.2018 07:24Селекторы — это часть DOM API. Веб-компоненты дружат с DOM API крепче чем кто-либо из списка React/Angular/Vue, ибо сами являются его частью. Веб-компонентам не нужно достигать уровня React/Angular/Vue, они не для этого существуют. Это не очередной модный хипстерский фреймворк, это новые возможности браузера (как и querySelecto когда-то).
justboris
17.08.2018 10:58синтаксис [Typescript], скажем так, «рябит» в глазах
Не очень понятно, что не так с этим синтаксисом:
const val: string = 'test';
Альтернатива с JSDoc, которую вы предлагаете, выглядит еще более громоздкой:
/** @type {String} */ const val = 'test';
LESS/SCSS/PostCSS
Одних переменных мало, для того чтобы слезть с препроцессоров. Есть еще, как минимум, вложенные стили. Ни в одном браузере их нет, а без них приходится повторять одни и те же имена классов по многу раз.
CustomElements + ShadowDOM
Сложно, поверить, что нативных технологий тут достаточно. Реакцию на изменение атрибута или событие приходится программировать руками, выходит больше кода, чем у фреймворков.
Покажите пример вашего компонента?
i360u Автор
17.08.2018 13:06Не очень понятно, что не так с этим синтаксисом
Вы привели какой-то уж слишком частный пример. Добавьте к нему интерфейсы, объявления функций от нескольких переменных, типизацию для элементов массива и т. д. И вот ваш код пестрит большой кучей лишних символов. В случае с JSDoc символов тоже немало, но они все сгруппированы отдельно. Конечно это вкусовщина, и действительно нет ничего особенно страшного в этом, можно привыкнуть. Но мой главный посыл был не в этом, а в том, что ваш код, при этом, не работает сразу в браузере. И здесь многое зависит от вашей специализации: чем в ней больше UI тем этот недостаток значительнее.
Одних переменных мало
Все верно, в препроцессорах мы еще ценим миксины. И даже есть какие-то движения по нативной реализации, но пока все плохо. Но на эту проблему можно взглянуть и под другим углом:
- Для сборки приложения вы можете использовать библиотеку UI-компонентов, в которых все стили упакованы внутри, и на более общих уровнях вам потребуется самый минимум CSS, без особой необходимости в повторениях.
- Если вы храните шаблоны в JS-модулях, как строки, вам доступна обычная интерполяция: миксуйте что угодно, добавляйте, по желанию, любую логику.
Реакцию на изменение атрибута или событие приходится программировать руками
Ее в любом случае придется программировать руками, это же логика компонента, ни один фреймворк не может сам предсказать что вы от него хотите. На изменение атрибутов веб-компоненты сами генерят сallback, и вы можете выполнить в нем любой необходимый код. Либо пробросить измененное значение на сеттер. На события компоненты реагируют как и любой другой DOM-элемент, + есть Custom Events. Не вижу тут ничего сложного.
Покажите пример вашего компонента?
Напишу ради этого статью. Разложить все по полочкам в рамках одного коммента, думаю, для меня непосильно.
justboris
17.08.2018 20:41Но мой главный посыл был не в этом, а в том, что ваш код, при этом, не работает сразу в браузере.
С этим аргмументом не спорю, все так и есть. А вот про "синтаксис рябит в глазах" — это личное предпочтение, как объективный аргумент — не засчитывается.
Для сборки приложения вы можете использовать библиотеку UI-компонентов, в которых все стили упакованы внутри
Прекрасный аргумент. Если кто-то сделает часть работы за нас, то это, конечно, хорошо, но так бывает не всегда.
i360u Автор
18.08.2018 08:53Если кто-то сделает часть работы за нас
Почему обязательно за нас? Я это сам для себя делаю. А мои коллеги пользуются готовым.
justboris
18.08.2018 13:48То есть для UI-библиотеки с кучей CSS вы настроите препроцессор с миксинами и всем таким?
А в чем тогда суть абзаца, что препроцессоры — не нужны?i360u Автор
18.08.2018 14:41Да нет же. В вашу библиотеку UI-компонентов могут входить блоки, которые являются организующими — то есть содержат типовые стили, которые вы хотите повторять по всему проекту. Потом вы просто используете специальный тег в разметке, вместо перечисления классов для каких-либо контейнеров. А необходимые параметры настраиваются CSS-переменными, в одном месте для всех вложенных блоков. Также, все необходимое вы можете указать через атрибуты. Тут меняется подход в целом, и миксины становятся компонентами. Ну и про второй пункт не стоит забывать: вы имеете полную свободу с использованием миксинов в ES-модулях, содержащих стили.
RomanPokrovskij
17.08.2018 12:04Статья поверхностная, но спасибо за возможность задать вопрос по этой фразе: «Поэтому бандлы для production-версии нам все-же понадобятся»… Алл, а что ты используешь в development версии для ускорения и упрощения (изучение поведения кода в броузере)? «Все в umd в ветке нет модулей»? require? делишь на несколько бандлов (в одном из которых твой код и только его пересобираешь)? Что-то еще?
i360u Автор
17.08.2018 12:39Простите, я не очень понял что точно и у кого конкретно вы спрашиваете, но думаю цитата из моей поверхностной статьи может быть ответом:
Разбить ваш код на аккуратные блоки и организовать его как вашей душе угодно вы можете с помощью нативных модулей. Да, модули поддерживаются всеми современными браузерами и вам не нужна пересборка в процессе разработки.
RomanPokrovskij
18.08.2018 23:58Вот вы говорите так как будто вопросов быть не может. А вопросов, конечно дурных, но сходу полно.
Ваше решение подразумевает что вы должны будете решить следующие проблемы:
1) Все пакеты (включая все сторонние) должны быть с ES6 module system. Что вообще-то специфическая ситуация. Редкий npm пакет для УИ в main field указывает js c ES6 import'ами.
2) вот у вас есть в коде `import '@babel/polyfill'` я так сходу не понимаю каким образом это в броузере разрешится в загрузку ./libs/@babel/polyfill/polyfill.js (или посчитается что `<script src=''./libs/@babel/polyfill/polyfill.js" >` произвел загрузку ) Вы соглашаетесь на «скинуть все в корневой каталог» я правильно понимаю?
3) гибридная проблема было import $ from 'JQuery' а jquery загружен в global как это будет понято броузером?
RomanPokrovskij
19.08.2018 00:14Есть еще один аспект, именно для дебуга под старыми броузерами у которых проблемы с sourceMap чисто теоритечески большая мотивация грузить скрипты «без бандлинга». Вы видимо своим решением говорите «это чисто умозрительная проблема, на самом деле все проблемы поддержки старых броузеров легко решаются и без сорс мапов и в коде бандла». Я правильно понимаю?
RomanPokrovskij
19.08.2018 00:30Уточню примером.
Вот мы пытаемся без webpackа грузить (то что с webpackом без проблем):
<script src="~/lib/jquery/dist/jquery.js"></script> <script src="~/lib/popper.js/dist/umd/popper.js" ></script> <! -- можно и esm/popper.js type="module" --> <script src="~/lib/bootstrap/dist/js/bootstrap.js"></script> <script src="~/js/Es8Test.js" type="module"></script>
При этом внутри Es8Test.js есть `import Popper from 'popper.js';`
И конечно увидим что так не работает.
Вы конечно как-то этот случай отсекли, но я вот так не вижу и этвета на вопрос «что с этим кодом не так-то»?
ermolalex
17.08.2018 14:56Зря отвергли спортклуб. Там скорее эффект «окрыленного божества» был-бы больший. В клубе кроме вас есть еще много народу, и все они находятся примерно «на одной волне», все пыхтят-стараются, думают примерно об одном (какой я молодец и пр). И на этой общей волне, возможно, будет и проще достигать нужного состояния, и оно будет ярче.
По крайней мере у меня так )))nki
17.08.2018 15:01Что бы бегать спорт зал/клуб не нужны. Если есть парк поблизости, то бегать там. Рельеф это не помеха, а разнообразие. Посмотрите в сторону трейлраннинга, может вам понравится.
i360u Автор
17.08.2018 15:04Для меня бег — что-то вроде медитации. А медитировать лучше в одиночестве.
keenondrums
17.08.2018 15:15- TS — не вижу проблемы подождать компиляции. Честно говоря, новые фичи пилю большую часть времени вообще не глядя в браузер, только код в IDE. Спустя час-другой, когда все готово, уже делаю смоук тест в браузере. Обычно все работает с минимальным шаманством как раз благодаря типизации ТС и отлову ошибок ещё во время компиляции.
- Препроцессоры — их клмбинирую с css переменными. У них есть классный синтаксический сахар для описания классов с префиксами.
- Менеджмент стейта — вы предлагаете костылировать самому то, что уже написано? Зачем? Если результат тот же, то не проще ли использовать готовое? Чтобы облегчить боль новых девов на проекте и чтобы использовать уже протестированные
i360u Автор
17.08.2018 15:36Сильно зависит от задач. Иногда я сам не заглядываю в браузер часами, иногда — жму релоад каждую пару секунд. Особенно потери на перекомпиляцию заметны при работе с UI, с визуализацией данных и при отлове странных багов. А вот проблемы с типами — большая редкость.
Префиксы (если вы говорите о префиксах в именованиях) — не особенно вам нужны, если вы работаете с ShadowDOM.
Про стейт-менеджмент — на мой взгляд, я довольно четко изложил свою позицию. Популярные решения лично меня не устраивают: если ваше приложение чуть сложнее формочки в интернет-магазине — вас ждут проблемы. Но, в вашем конкретном случае, вы можете использовать любое популярное решение. Универсальных рецептов не существует. Я люблю писать велосипеды, потому, что это интересно, это развивает, и вы можете реализовать то, чего нет в популярных либах, например графовое хранилище состояний.
alex6636
17.08.2018 23:46+1Годная статья. А то у многих разработчиков очень часто на каждую новую, даже очень простую фичу в проекте подключается новый Фреймворк (библиотека)
PaulMaly
18.08.2018 23:27Интересно, а как Web Components помогают вам с синхронизацией стейта приложения и DOM? Ведь именно это главная фича любого JS фреймворка, а вовсе не компонентный подход.
misato
Добрая тенденция