Бег на месте и веб-разработка +9


Всем привет!

Сейчас я расскажу вам одну странную историю. Однажды, я жил в кондоминимуме, в котором, на первом этаже, был зал для фитнеса с беговыми дорожками. В юности, я активно занимался спортом и тогда мне удалось познать состояние, которое возникает во время бега и называется «второе дыхание»: это когда вдруг начинаешь чувствовать себя окрыленным божеством, не знающим усталости. Дыхание, сердцебиение и движения тела входят в какой-то особый резонанс, и превращают тебя в бегущую машину. Ощущение тем ярче, на мой взгляд, чем больше вы НЕ любили бегать до этого момента. Так вот, я каждый день ходил мимо беговых дорожек и думал, что хорошо бы вспомнить молодость. Ну и вспомнил. Беговая дорожка отлично в этом помогла, она позволяла тонко настроить темп и достичь нужного ритма. На улице у меня так не получается: бежать с ровной скоростью по городу — очень трудно, мешают рельеф и препятствия. Через какое-то время я переехал в обычную квартиру (без фитнес-зала), и стал задумываться о приобретении собственной беговой дорожки.

Да, конечно, можно было бы просто купить абонемент в ближайший спортклуб, но я, как и многие мои коллеги во 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):

  1. misato
    /#19000353

    Добрая тенденция

  2. codemafia
    /#19000397

    Ну и сами зависимости. Однако, в нашем 2018-м году у нас есть такая замечательная штука, как нативные CSS-переменные! Это чрезвычайно мощная вещь, с которой не сравнится ни один препроцессор: ваши переменные вы можете переопределять прямо в рантайме!

    А rem/em переменные умею считать?

  3. korobkov-k
    /#19000421

    Всё чаще вижу борьбу со «стандартами» и, как правило, из уст очень опытных и увлеченных фронтендщиков, которые расковыряли все стандарты, устройство браузера и конечно же свои проекты до самых корней, потратив на это N лет. Но если в команду набирают junior/middle ребят и их надо как-то организовать и поставить разработку на поток, то не легче ли жить со «стандартами», которые все знают. Если конкретно про статическую типизацию, то код в typescript будет выглядеть лаконичнее и писаться проще, чем ванилла + JSDoc, разве нет? Плюс он больше располагает к указанию типов прямо в процессе кодинга. А JSDoc — это такая штука, привязанная сбоку, на которую можно и забить, особенно если вдруг спешка.

    По поводу компиляции проектов — она довольно быстрая, но это, конечно, субъективно. А с опытом, как и в других сферах программирования, приходит навык написания большего количества строк кода без ошибок. То есть опытному спецу, которому все эти типизации и компиляторы не нужны, не нужно и страницу перезагружать после каждой измененной строчки в CSS.

    • i360u
      /#19000477

      Вы так говорите, будто я противопоставляю подходу "по умолчанию" что-то нестандартное. Все перечисленное — и есть самые настоящие стандарты веб-платформы. И их необходимо знать разработчику на любом стеке.
      Про TS — я написал: он не работает в браузере. К сожалению.
      По поводу больших блоков кода и пересборки — все верно, но только до тех пор, пока вы не взялись за UI.

    • i360u
      /#19000569

      Дополню: JSDoc — он слегка сбоку, да, но анализ работает и для простого JS, даже без аннотаций. И это дает привыкнуть и втянуться. А JSDoc потом уже сам в руки просится.

  4. k12th
    /#19000681

    Пока веб-компоненты поддерживаются только у 60% пользователей, это будет оставаться такой же мета-платформой, с жирнючими, ЕМНИП, полифиллами. Для души дома можно и даже пожалуй нужно.

    • i360u
      /#19000685 / -1

      78.13 != 60, во первых, а во вторых полифилы не жирнее реакта. Ну и чуваки из Youtube и GitHub, к примеру, с вами не согласны.

      • k12th
        /#19000741

        Для этих (78.13 — 60)% это будет "Дорогие пользователи, чтобы насладиться нашим сайтом, пожалуйста включите настройку dom.webcomponents.shadowdom.enabled". Или "выбросьте уже свой сафари и поставьте нормальный браузер".

        • i360u
          /#19000775 / -1

          ерунду не надо писать, я использую описанный стек в проде

        • i360u
          /#19000823 / -1

          ага, минусануть проще, чем по ссылочке сходить и глянуть, как там safari: https://caniuse.com/#feat=shadowdomv1

          • k12th
            /#19000837

            А самому сходить и увидеть что там неполная поддержка?

            • i360u
              /#19000881

              А я очень хорошо знаю в чем ее неполнота, и мне она не мешает. Я еще раз повторю, я использую эти технологии сам и не на сайте "вася-пупкин.ком". Тестирую все лично в разных браузерах и на разных устройствах. Но вот обязательно найдется кто-то "очень умный" и расскажет как у меня ничего не работает, вопреки тестам и собственным глазам. Если уж минусите, потрудитесь аргументацию получше подбирать.

              • dagen
                /#19002961

                Пытались использовать в проде 4 года назад на очень большом SPA. И о бедные пользователи Firefox! С некоторой критической черты старт приложения в FF превратился в один большой многосекундный фриз. Жирность их не большая, но тяжёлое SPA полифилам было не переварить. Правда может с тех пор ситуация с полифилами изменилась?

                С удовольствием посмотрю на веб-компоненты, когда в FF они наконец-то выйдут из-под флага

                • i360u
                  /#19002979

                  За 4 года много воды утекло, и полифилы и поддержка самих компонентов — все сильно изменилось. Устаканился и сам стандарт. А в то время это скорее было превью того, как оно будет выглядеть в будущем, да.

      • springimport
        /#19005131

        На счет Утуба все понятно — нет плавности даже на 8700k. Вот так вот.
        А Гитхаб вроде переписывали на что-то свое с jquery, даже была новость. Сомневаюсь что там тяжелые компоненты.

  5. codrem
    /#19000971 / +1

    Буквально вчера смотрел конференцию на подобную тему — www.youtube.com/watch?v=HiE7FmIKOQ0

    • i360u
      /#19001035

      Приятно знать, что я не одинок :-) Чувак с бородой — на моей стороне!

    • Synoptic
      /#19001391 / +1

      В прошлом году на пальцах пытался объяснить тоже самое, на примере Polymer.

      К текущему моменту правда издохли HTML Imports, плюс я тоже пришел к выводу, что как минимум резольвилка модулей и прод-минификатор не лишние, но все остальное актуально.

  6. niksite
    /#19001137 / +1

    По первому абзацу было решил вы тут изложите как организовали свое рабочее место над беговой дорожкой и занимаетесь так веб программизмом...


    Если что — в Фейсбуке ребята так и работают многие, у них там есть сидячие места, стоячие и бегучие.

    • MetaDone
      /#19003479

      а я думал что будет информация которую можно вытащить из данных пробежки как-то отображаться в веб-морде, что-то типа красивых графиков скорости, пульса, восстановления пульса после окончания пробежки, чтоб за какое-то время можно было наблюдать динамику повышения тренированности, типа за месяц стал пульс быстрее в норму приходить, при определенном пульсе средняя скорость стала выше и т.п.

  7. bgnx
    /#19001963

    На эту тему можно долго рассуждать, вспомнить 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
      /#19002117

      Да, вебкомпоненты позволяют разбить на компоненты, изолировать стили и прочее, но они не никак решают самую главную проблему существования js-фреймвоков — проблему синхронизации ui и состояния.

      Решения для синхронизации UI и состояния для фреймворков и компонентов доступны одни и те же.
      Ну и вдобавок веб-компоненты имеют один фундаментальный недостаток — они не поддерживают svg. Вот захотите вы разбить какой-то svg-шаблон на компоненты также как и html, а нет — нельзя, приплыли.

      В чем фундаментальность этого недостатка, можете привести юзкейсы, когда это надо? Фундаментальный недостаток — это такой, когда все остальные плюсы оказываются в его тени, а тут что-то не похоже.

    • i360u
      /#19002907

      Проблема фреймворков в том, что они, на самом деле, НЕ решают проблему, которая обуславливает их существование. Точнее решают ее не до конца, оставляя миллион возможностей выстрелить себе в ногу в самой сложной ее части. React не умеет ничего делать с состоянием уровня приложения, он работает только с состоянием уровня компонента. А Redux — управляет глобальным состоянием, но ничего не знает про эффективные апдейты DOM. Ему это и не нужно конечно, но вот только мы уже давно вышли за пределы просто библиотеки для постройки UI. На уровне компонента, магия с динамическими привязками может впечатлить только откровенных новичков. И нужна она, по большей части, для задач организации и стандартизации структуры проекта, чтобы было удобнее работать со стандартными шаблонами. А в случае с веб-компонентами и прямым доступом к их DOM у вас нет такой необходимости. А на уровне приложения, вы очень быстро поймете, какая неудобная штука этот Redux, если ваши данные имеют какую-то более сложную структуру, чем нечто самое примитивное.


      В конце концов, я написал что не призываю никого все бросать и срочно все переписывать на компонентах. Лично мне они дают очень многое, чего не давали фреймворки. Ну и размеры сборок у меня в РАЗЫ меньше, чем в проетах на реакте. И в тестах производительности они реакт уделывают. Да, пока только в Хроме, но, на минутчку, говоря о Хроме, мы уже говорим о БОЛЬШИНСТВЕ пользователей.

  8. bgnx
    /#19002541

    Решения для синхронизации UI и состояния для фреймворков и компонентов доступны одни и те же.

    Во фреймворках (react, vue, angular) это уже встроено а c вебкомпонентами либо придется писать код в стиле jquery вручную меняя дом-элементы либо использовать дополнительно еще фреймворк/шаблонизатор который будет менять ui в зависимости от изменения данных но тогда смысл в веб-компонентах как в самодостаточной технологии теряется.
    В чем фундаментальность этого недостатка, можете привести юзкейсы, когда это надо?

    Ну как же — без поддержки svg веб-компоненты это какая-то обрезанная и ограниченная версия компонентой модели. Если какой-нибудь html-шаблон можно разбить на компоненты то чем svg хуже? Как с веб-компонентами вы планируете строить какой-нибудь сложный интерфейс на svg например онлайн-фотошоп или приложение для создание презентаций где будут графики, кривые безье, сложные фигуры и т.д?

    • Synoptic
      /#19002625

      Во фреймворках (react, vue, angular) это уже встроено

      Что куда встроено? В коробочной поставке фреймворков для управления стейтом предлагаются немасштабируемые решения, пригодные лишь для простых приложений. Ну так такое решение и у веб-компонентов есть, вполне нативный js — гуглите Custom Events(организовать паттерн медиатор), attributeChangedCallback(пропсы прокинуть). Для чего-то более сложного хоть для React/Angular/Vue, хоть для веб-компонентов надо брать отдельное решение типа Redux/MobX.

      Как с веб-компонентами вы планируете строить какой-нибудь сложный интерфейс на svg например онлайн-фотошоп или приложение для создание презентаций где будут графики, кривые безье, сложные фигуры и т.д?

      Я не особо понимаю, в чем проблема делать это с использованием веб-компонентов. Вот пример. Веб-компоненты это не фреймворк, это более низкоуровневый API, но если что-то надо, никто не мешает дописать абстракций или использовать что-то готовое.

    • i360u
      /#19002929

      Графики прекрасно рисуются на canvas и в WebGL, им не нужна древовидная структура документа, там вы оперируете другими сущностями. А вот чтобы нарисовать UI вокруг графиков — веб-компоненты отличный вариант. Что касается SVG — там есть инструментарий специфичный для этого формата, жаль конечно, что нельзя использовать единый подход, но ведь и простой HTML вы не сможете смешать с SVG без большого количества танцев с бубном.

    • i360u
      /#19002951

      Кстати, насчет SVG, я как-то делал эксперимент с SVG на компонентах: брал дочерние компоненты с описанием элементов и рендерил соответствующие им svg-ноды в теневом DOM компонента-контейнера. Конечно это не нативная поддержка, но вполне рабочий вариант для простых случаев.

  9. zapolnoch
    /#19002611 / -1

    Когда в браузерах не было удобной системы для работы с селекторами, мы использовали jQuery. Потом браузеры худо-бедно поддержали работу с селекторами (Document.querySelector), но нам уже не надо было, мы уже во всю писали на компонентах.
    Боюсь, что, когда веб-компоненты достигнут уровня React/Angular/Vue, нам оно уже не будет нужно, мы будет писать на чем-то другом.

    • i360u
      /#19002887

      Селекторы — это часть DOM API. Веб-компоненты дружат с DOM API крепче чем кто-либо из списка React/Angular/Vue, ибо сами являются его частью. Веб-компонентам не нужно достигать уровня React/Angular/Vue, они не для этого существуют. Это не очередной модный хипстерский фреймворк, это новые возможности браузера (как и querySelecto когда-то).

  10. Tavas
    /#19002913

    Пробежался глазами по статье, вступление порадовало)

  11. justboris
    /#19003513

    синтаксис [Typescript], скажем так, «рябит» в глазах

    Не очень понятно, что не так с этим синтаксисом:


    const val: string = 'test';

    Альтернатива с JSDoc, которую вы предлагаете, выглядит еще более громоздкой:


    /** @type {String} */
    const val = 'test';

    LESS/SCSS/PostCSS

    Одних переменных мало, для того чтобы слезть с препроцессоров. Есть еще, как минимум, вложенные стили. Ни в одном браузере их нет, а без них приходится повторять одни и те же имена классов по многу раз.


    CustomElements + ShadowDOM

    Сложно, поверить, что нативных технологий тут достаточно. Реакцию на изменение атрибута или событие приходится программировать руками, выходит больше кода, чем у фреймворков.


    Покажите пример вашего компонента?

    • i360u
      /#19004247

      Не очень понятно, что не так с этим синтаксисом

      Вы привели какой-то уж слишком частный пример. Добавьте к нему интерфейсы, объявления функций от нескольких переменных, типизацию для элементов массива и т. д. И вот ваш код пестрит большой кучей лишних символов. В случае с JSDoc символов тоже немало, но они все сгруппированы отдельно. Конечно это вкусовщина, и действительно нет ничего особенно страшного в этом, можно привыкнуть. Но мой главный посыл был не в этом, а в том, что ваш код, при этом, не работает сразу в браузере. И здесь многое зависит от вашей специализации: чем в ней больше UI тем этот недостаток значительнее.


      Одних переменных мало

      Все верно, в препроцессорах мы еще ценим миксины. И даже есть какие-то движения по нативной реализации, но пока все плохо. Но на эту проблему можно взглянуть и под другим углом:


      1. Для сборки приложения вы можете использовать библиотеку UI-компонентов, в которых все стили упакованы внутри, и на более общих уровнях вам потребуется самый минимум CSS, без особой необходимости в повторениях.
      2. Если вы храните шаблоны в JS-модулях, как строки, вам доступна обычная интерполяция: миксуйте что угодно, добавляйте, по желанию, любую логику.

      Реакцию на изменение атрибута или событие приходится программировать руками

      Ее в любом случае придется программировать руками, это же логика компонента, ни один фреймворк не может сам предсказать что вы от него хотите. На изменение атрибутов веб-компоненты сами генерят сallback, и вы можете выполнить в нем любой необходимый код. Либо пробросить измененное значение на сеттер. На события компоненты реагируют как и любой другой DOM-элемент, + есть Custom Events. Не вижу тут ничего сложного.


      Покажите пример вашего компонента?

      Напишу ради этого статью. Разложить все по полочкам в рамках одного коммента, думаю, для меня непосильно.

      • justboris
        /#19005959

        Но мой главный посыл был не в этом, а в том, что ваш код, при этом, не работает сразу в браузере.

        С этим аргмументом не спорю, все так и есть. А вот про "синтаксис рябит в глазах" — это личное предпочтение, как объективный аргумент — не засчитывается.


        Для сборки приложения вы можете использовать библиотеку UI-компонентов, в которых все стили упакованы внутри

        Прекрасный аргумент. Если кто-то сделает часть работы за нас, то это, конечно, хорошо, но так бывает не всегда.

        • i360u
          /#19006745

          Если кто-то сделает часть работы за нас

          Почему обязательно за нас? Я это сам для себя делаю. А мои коллеги пользуются готовым.

          • justboris
            /#19007245

            То есть для UI-библиотеки с кучей CSS вы настроите препроцессор с миксинами и всем таким?

            А в чем тогда суть абзаца, что препроцессоры — не нужны?

            • i360u
              /#19007335

              Да нет же. В вашу библиотеку UI-компонентов могут входить блоки, которые являются организующими — то есть содержат типовые стили, которые вы хотите повторять по всему проекту. Потом вы просто используете специальный тег в разметке, вместо перечисления классов для каких-либо контейнеров. А необходимые параметры настраиваются CSS-переменными, в одном месте для всех вложенных блоков. Также, все необходимое вы можете указать через атрибуты. Тут меняется подход в целом, и миксины становятся компонентами. Ну и про второй пункт не стоит забывать: вы имеете полную свободу с использованием миксинов в ES-модулях, содержащих стили.

  12. RomanPokrovskij
    /#19003837

    Статья поверхностная, но спасибо за возможность задать вопрос по этой фразе: «Поэтому бандлы для production-версии нам все-же понадобятся»… Алл, а что ты используешь в development версии для ускорения и упрощения (изучение поведения кода в броузере)? «Все в umd в ветке нет модулей»? require? делишь на несколько бандлов (в одном из которых твой код и только его пересобираешь)? Что-то еще?

    • i360u
      /#19004027

      Простите, я не очень понял что точно и у кого конкретно вы спрашиваете, но думаю цитата из моей поверхностной статьи может быть ответом:


      Разбить ваш код на аккуратные блоки и организовать его как вашей душе угодно вы можете с помощью нативных модулей. Да, модули поддерживаются всеми современными браузерами и вам не нужна пересборка в процессе разработки.

      • RomanPokrovskij
        /#19008213

        Вот вы говорите так как будто вопросов быть не может. А вопросов, конечно дурных, но сходу полно.
        Ваше решение подразумевает что вы должны будете решить следующие проблемы:
        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
          /#19008231

          Есть еще один аспект, именно для дебуга под старыми броузерами у которых проблемы с sourceMap чисто теоритечески большая мотивация грузить скрипты «без бандлинга». Вы видимо своим решением говорите «это чисто умозрительная проблема, на самом деле все проблемы поддержки старых броузеров легко решаются и без сорс мапов и в коде бандла». Я правильно понимаю?

        • RomanPokrovskij
          /#19008247

          Уточню примером.

          Вот мы пытаемся без 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';`

          И конечно увидим что так не работает.
          Вы конечно как-то этот случай отсекли, но я вот так не вижу и этвета на вопрос «что с этим кодом не так-то»?

  13. ermolalex
    /#19004703

    Зря отвергли спортклуб. Там скорее эффект «окрыленного божества» был-бы больший. В клубе кроме вас есть еще много народу, и все они находятся примерно «на одной волне», все пыхтят-стараются, думают примерно об одном (какой я молодец и пр). И на этой общей волне, возможно, будет и проще достигать нужного состояния, и оно будет ярче.
    По крайней мере у меня так )))

    • nki
      /#19004737

      Что бы бегать спорт зал/клуб не нужны. Если есть парк поблизости, то бегать там. Рельеф это не помеха, а разнообразие. Посмотрите в сторону трейлраннинга, может вам понравится.

      • i360u
        /#19004755

        И еще нужна хорошая погода круглый год.

        • nki
          /#19004817

          Спорное утверждение. Я в Питере круглый год бегаю на улице.

          • i360u
            /#19004915

            Везет вам. А я, знаете ли, не люблю снег и слякоть. Люди бывают разные.

    • i360u
      /#19004753

      Для меня бег — что-то вроде медитации. А медитировать лучше в одиночестве.

  14. Saitcenter
    /#19004729

    Отличная статья. Был бы приглашенным, поставил бы +))

  15. keenondrums
    /#19004795

    1. TS — не вижу проблемы подождать компиляции. Честно говоря, новые фичи пилю большую часть времени вообще не глядя в браузер, только код в IDE. Спустя час-другой, когда все готово, уже делаю смоук тест в браузере. Обычно все работает с минимальным шаманством как раз благодаря типизации ТС и отлову ошибок ещё во время компиляции.
    2. Препроцессоры — их клмбинирую с css переменными. У них есть классный синтаксический сахар для описания классов с префиксами.
    3. Менеджмент стейта — вы предлагаете костылировать самому то, что уже написано? Зачем? Если результат тот же, то не проще ли использовать готовое? Чтобы облегчить боль новых девов на проекте и чтобы использовать уже протестированные

    • i360u
      /#19004891

      1. Сильно зависит от задач. Иногда я сам не заглядываю в браузер часами, иногда — жму релоад каждую пару секунд. Особенно потери на перекомпиляцию заметны при работе с UI, с визуализацией данных и при отлове странных багов. А вот проблемы с типами — большая редкость.


      2. Префиксы (если вы говорите о префиксах в именованиях) — не особенно вам нужны, если вы работаете с ShadowDOM.


      3. Про стейт-менеджмент — на мой взгляд, я довольно четко изложил свою позицию. Популярные решения лично меня не устраивают: если ваше приложение чуть сложнее формочки в интернет-магазине — вас ждут проблемы. Но, в вашем конкретном случае, вы можете использовать любое популярное решение. Универсальных рецептов не существует. Я люблю писать велосипеды, потому, что это интересно, это развивает, и вы можете реализовать то, чего нет в популярных либах, например графовое хранилище состояний.


  16. alex6636
    /#19006343 / +1

    Годная статья. А то у многих разработчиков очень часто на каждую новую, даже очень простую фичу в проекте подключается новый Фреймворк (библиотека)

  17. PaulMaly
    /#19008143

    Интересно, а как Web Components помогают вам с синхронизацией стейта приложения и DOM? Ведь именно это главная фича любого JS фреймворка, а вовсе не компонентный подход.