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

    Всем привет!

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

    Да, конечно, можно было бы просто купить абонемент в ближайший спортклуб, но я, как и многие мои коллеги во 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. Я ни в коем случае не утверждаю, что мои подходы подойдут всем. Прошу расценивать сей опус хотя-бы как повод задуматься о том, что нам кажется само-собой разумеющимся.
    Поделиться публикацией
    Комментарии 147
      0
      Добрая тенденция
        0
        Ну и сами зависимости. Однако, в нашем 2018-м году у нас есть такая замечательная штука, как нативные CSS-переменные! Это чрезвычайно мощная вещь, с которой не сравнится ни один препроцессор: ваши переменные вы можете переопределять прямо в рантайме!

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

          Для этого есть calc

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

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

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

              0
              Про TS — я написал: он не работает в браузере. К сожалению.

              А какая, собственно, разница, работает он или нет? Особенно если вы этот факт не можете заметить.

                +1
                Особенно это незаметно, когда дебажишь транспилированный код, ага.
                  –2
                  Особенно это незаметно, когда дебажишь транспилированный код, ага.

                  А зачем вы дебажите транспилированный код, если можно дебажить исходник? Сами себе проблему создаете.


                  Кроме того, использование отладчиков вообще плохая практика сама по себе, т.к. потворствует написанию низкокачественного кода. Перестаньте пользоваться отладчиком и вскоре начнете писать код, для отладки которого отладчика не требуется :)

              0

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

                +1
                опытному спецу <...> все эти типизации и компиляторы не нужны

                Если вы так считаете, добро пожаловать в, например, блог PVS-Studio, много интересного узнаете :)
                0

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

                  0

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

                    0

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

                      –3

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

                        0

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

                          –1

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

                            –1

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

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

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

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

                          0
                          На счет Утуба все понятно — нет плавности даже на 8700k. Вот так вот.
                          А Гитхаб вроде переписывали на что-то свое с jquery, даже была новость. Сомневаюсь что там тяжелые компоненты.
                        +1
                        Буквально вчера смотрел конференцию на подобную тему — www.youtube.com/watch?v=HiE7FmIKOQ0
                          0

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

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

                            К текущему моменту правда издохли HTML Imports, плюс я тоже пришел к выводу, что как минимум резольвилка модулей и прод-минификатор не лишние, но все остальное актуально.
                              0
                              А что такое резольвилка модулей, раскроеете?
                                0
                                Сейчас чтобы в браузере импортировать один ES6-модуль в другой, часто надо писать что-то типа import module from '../../../../module.js'. А люди уже привыкли к тому, что есть некая логика поиска модуля, точный путь до которого не ясен — типа import module from 'module'.

                                Такого нативно пока нет, а писать точные пути быстро надоедает. Резольвилка модулей решает эту проблему.
                                  0
                                  проблему понимаю, но решения (плагин бабеля) как я понял нету?
                                    0
                                    Я использую pwa-starter-kit, там оно есть из коробки. От бабеля я как раз и хотел избавиться, когда выбирал решение под себя.
                                      0
                                      Озадачили… ну не бабель, так что-то там есть раз есть и проблема «одному в импортах нужно path, а другому npm пакет»… Или все просто: тот инструмент, что из коробки, когда из node_module в wwwroot/libs копирует — тогда и подменяет имя пакета на path. А сами вы пишите модули всегда c path в импортах? Я правильно понял?
                                        0
                                        Или все просто: тот инструмент, что из коробки, когда из node_module в wwwroot/libs копирует — тогда и подменяет имя пакета на path.

                                        Типа того. Тут в разделе «So what now?» описано, как оно работает.

                                        … Our support for bare specifiers is independent of our other build steps, like bundling. This step simply resolves specifiers and rewrites them as paths—polyserve will still serve modules, and polymer-build will output modules for browsers that support them. Bundling isn't required.
                                          0
                                          Уточню, а ваши модули всегда с точным path в импорте так? Важно для понимания, что отказ от условного «webpack» полный. Речь не идет об одновременной поддержке и бандла (скажам для прода) и es6 native modules (скажем для дева). Хочешь так, хочешь так.
                                          Извиняюсь за много вопросов, у меня тут реально аналитический паралич. Хочется выйти.
                                            0
                                            Можете посмотреть тут, как это выглядит в реальности:

                                            import { html } from '@polymer/lit-element';
                                            import { repeat } from 'lit-html/lib/repeat';
                                            import { SharedStyles } from '../../shared-styles.js';
                                            import { PageViewElement } from '../../reusable/page-view-element';
                                            import { connect } from 'pwa-helpers/connect-mixin';
                                            import './u-news-header/u-news-header';
                                            
                                            import { store } from '../../../store';
                                            import { getAllNews } from '../../../actions/news.js';
                                            


                                            Это код, с которым я работаю всегда. Как видите, тут имеются относительные пути, но самые напрягающие, типа ../../../node_modules/@polymer/polymer/lit-element/lit-element.js заменены на import { html } from '@polymer/lit-element';. Также тут можно опускать расширение файла, а нативно — нельзя.

                                            Для прода да, билдится бандл. Но отличие прод-кода от дев-кода по сравнению с бандлами крупных фреймворков только в том, что имена модулей резолвятся в понимаемые браузером ../../node_modules/etc. Лично для меня этого пока достаточно, я прод пока даже не минифицирую и благодаря http/2 скорость для меня приемлемая. Очевидный плюс — дебажить прод сверхпросто.

                                            Но если количество файлов сильно вырастет и запросы даже по http/2 сокету станут узким местом, не вижу ничего зазорного в том, чтобы собрать все в один или несколько файлов и минифицировать.
                                              0
                                              сейчас меня сбил с понталыку path '../../../store' — это не похоже на на path который резолвит броузер грузя native modules (и в github по этому path от u-news.js ничего нет)… я правильно понимаю что резольвилка модулей этот path тоже отрезолвит по правилам в то что нужно? т.е. не только npm packages она поддерживает? меня вообще то что в исходниках path означает «что угодно» — угнетало бы. напрашивается давать имена, а потом транспиля давать path по каким либо устанволенным для данной сборки правилам…
                                                +1
                                                сейчас меня сбил с понталыку path '../../../store' — это не похоже на на path который резолвит броузер грузя native modules (и в github по этому path от u-news.js ничего нет)

                                                Есть, вот же. В данном случае чтобы отрезолвить в нативный синтаксис достаточно добавить расширение .js для /store. Так оно работает и в фреймворках.

                                                Не знаю что есть npm packages, они же разные. Данная резольвилка поддерживает только ES6-модули.
                            +1

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


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

                              0
                              а я думал что будет информация которую можно вытащить из данных пробежки как-то отображаться в веб-морде, что-то типа красивых графиков скорости, пульса, восстановления пульса после окончания пробежки, чтоб за какое-то время можно было наблюдать динамику повышения тренированности, типа за месяц стал пульс быстрее в норму приходить, при определенном пульсе средняя скорость стала выше и т.п.
                              +2
                              На эту тему можно долго рассуждать, вспомнить 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 на компоненты.
                                0
                                Да, вебкомпоненты позволяют разбить на компоненты, изолировать стили и прочее, но они не никак решают самую главную проблему существования js-фреймвоков — проблему синхронизации ui и состояния.

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

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

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


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

                                    0
                                    А в случае с веб-компонентами и прямым доступом к их DOM у вас нет такой необходимости.

                                    Я правильно понимаю, что вы тут предлагаете в случае апдейта состояния приложения лезть руками в дом и его обновлять?

                                      0
                                      На уровне компонента, магия с динамическими привязками может впечатлить только откровенных новичков. И нужна она, по большей части, для задач организации и стандартизации структуры проекта, чтобы было удобнее работать со стандартными шаблонами. А в случае с веб-компонентами и прямым доступом к их DOM у вас нет такой необходимости.

                                      Такое чувство что вы либо троллите либо не работали с вебкомпонентами вручную потому что без этих самых динамических привязок данных к шаблону которые синхронизируют данные с ui (что и является главной фичей всех фреймворков) вам придется написать вручную кучу кода. Как к примеру вы собираетесь отрендерить список компонентов? Если в реакте diff уже встроен и вам нужно будет написать всего одну строчку кода


                                      <div>{state.todos.map(todo=><Todo key={todo.id} todo={todo}/>)}</div>

                                      то с веб-компонентами у которых нет биндингов (привязок данных к шаблону) вам придется писать diff вручную а это примерно в 40 раз больше строк кода


                                      //arr - новый или измененный массив todos
                                      //keyField - имя поля объекта для индефикации по ключу (todo.id)
                                      //elementName - название елемента которого нужно создать если массив пополнится
                                      //parentElement, nextElement - родительский и следующий элемент внутри и перед которым нужно сделать вставку
                                      //this.hash - хеш где ключу соответствует нода двусвязного списка
                                      //this.lastNode - ссылка на последнюю ноду двусвязного списка
                                      let nextNode = null;
                                      let oldNode = this.lastNode;
                                      for (let i = arr.length - 1; i >= 0; i--) {
                                        const item = arr[i];
                                        const key = item[keyField];
                                        let node = this.hash.get(key);
                                        if (!node) {
                                          node = { element: document.createElement(elementName), key }
                                          this.hash.set(key, node);
                                          node.element.item = item;
                                          node.element.index = i;
                                          node.element.arr = arr;
                                          parentElement.insertBefore(node.element, nextNode ? nextNode.element : nextElement)
                                        } else {
                                          if (oldNode === node) {
                                            node.element.item = item;
                                            node.element.index = i;
                                            node.element.arr = arr;
                                          } else {
                                            if (node.prev) node.prev.next = node.next;
                                            if (node.next) node.next.prev = node.prev;
                                            parentElement.insertBefore(node.element, nextNode ? nextNode.element : nextElement)
                                          }
                                        }
                                        node.next = nextNode;
                                        if (nextNode) {
                                          nextNode.prev = node;
                                        } else {
                                          this.lastNode = node;
                                        }
                                        nextNode = node;
                                        if (oldNode && oldNode === node) oldNode = oldNode.prev;
                                      }
                                      let node = nextNode && nextNode.prev;
                                      while (node) {
                                        parentElement.removeChild(node.element);
                                        this.hash.delete(node.key);
                                        node = node.prev;
                                      }
                                      if (nextNode) nextNode.prev = null;
                                        0

                                        Нет, я никого не троллю и не говорю о том, с чем сам не сталкивался и не пытаюсь тут пропихивать какую-то смутную эзотерику. Меня тут уже обвинили во всех грехах вместо конструктивного диалога, и не раз сходили в карму поклонники динамических привязок. Я устал уже повторять, что если вам они нужны — нет проблем — вы можете использовать готовые библиотеки для этого (Polymer, lit-html) в сочетании с веб-компонентами. При этом на основе самих веб-компонентов можно делать пратформонезависимые UI-библиотеки для последующего использования с любым популярным фреймворком. Также, веб-компоненты являются очень удобной основой для написания своих библиотек и фреймворков, если у вас есть своя интересная концепция либо популярные решения вам чем-то не нравятся. Чем я и занимаюсь. Веб-компоненты — это про свободу в принятии решений. Максимум технических деталей я постараюсь изложить в своей следующей статье, чтобы потом сразу на нее давать ссылку и не писать одно и то-же в каждой ветке комментов. И, судя по всему, эта статья будет последней моей статьей на эту тему.

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

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

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

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

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

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

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

                                          0

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

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

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

                                            0
                                            Пробежался глазами по статье, вступление порадовало)
                                              0
                                              синтаксис [Typescript], скажем так, «рябит» в глазах

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


                                              const val: string = 'test';

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


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

                                              LESS/SCSS/PostCSS

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


                                              CustomElements + ShadowDOM

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


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

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

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


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

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


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

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

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


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

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

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

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


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

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

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

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

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

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

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

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

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


                                                  Разбить ваш код на аккуратные блоки и организовать его как вашей душе угодно вы можете с помощью нативных модулей. Да, модули поддерживаются всеми современными браузерами и вам не нужна пересборка в процессе разработки.
                                                    0
                                                    Вот вы говорите так как будто вопросов быть не может. А вопросов, конечно дурных, но сходу полно.
                                                    Ваше решение подразумевает что вы должны будете решить следующие проблемы:
                                                    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 как это будет понято броузером?

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

                                                        Вам не нужны сорс-мапы когда вы работаете напрямую с исходниками в браузере. А если вам требуется поддержка старых браузеров — вы в любом случае будете работать с транспилированным кодом и сгенерированными сорс-мапами. Тут просто нет других вариантов, если вы хотите писать на современном JS. Я решаю этот вопрос очень просто: я не берусь за проекты, в требованиях к которым требуется поддержка всякой некрофилии. Глупо удорожать разработку в полтора-два-три раза ради несчастных полутора пользователей на древнем железе и осях. Если же, не смотря ни на что, вам такое потребуется — с очень многими современными возможностями будут проблемы, далеко не с одними модулями.

                                                          0
                                                          Сорсмапы не нужны для понимания транспиленного кода (наоборот — мешают, прячут ошибки бабеля), сорсмапы нужны для понимания «гдя я оказался» при вылете по ошибки (по крайней мере — мне). Поэтому мотивация как раз для старых броузеров «уметь» грузить все через `script src` остается. А три системы — загрузки перебор (prod, dev, legacy). dev и legacy хотелось бы объединить.

                                                          Но я понял вам не актуально. ОК.

                                                            0
                                                            На самом деле мне это тоже практически не сильно актуально, и я просто анализирую решения и их трейдофф «в голове». Поэтому и вопрос звучал так: «это чисто умозрительная проблема или как?». Допустим мы сошлись что «чисто умозрительная».
                                                        0
                                                        Уточню примером.

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

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

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

                                                            0
                                                            Я пока не могу понять Вас. Что бы вы делали в данном конкретном случае? Как сделать так чтобы popper был «виден»(резолвился) для bootstrap и для Es8Test.js загруженного как модуль? (Внутри Es8Test.js есть `import Popper from 'popper.js';`)
                                                              0
                                                              Не обязательно «Вы». Вопрос вообще ко Всем. Поделитесь опытом.
                                                        0
                                                        Разбить ваш код на аккуратные блоки и организовать его как вашей душе угодно вы можете с помощью нативных модулей.

                                                        Cформулировал ограничение: заменить загрузку `script src` (загрузку бандлера) загрузкой ES6 модулей `script type=«module»` неполучится в случае если имеет значение тот факт что script грузится синхронно, а модули — асинхронно. Т.е. в случае наличия нетривиального инлайн кода. Т.е. по-моему практически для всякой MPA ваша рекомендация неприменима, хотя может я может и не знаю как теперь готовят MPA.
                                                      +1
                                                      Зря отвергли спортклуб. Там скорее эффект «окрыленного божества» был-бы больший. В клубе кроме вас есть еще много народу, и все они находятся примерно «на одной волне», все пыхтят-стараются, думают примерно об одном (какой я молодец и пр). И на этой общей волне, возможно, будет и проще достигать нужного состояния, и оно будет ярче.
                                                      По крайней мере у меня так )))
                                                        0
                                                        Что бы бегать спорт зал/клуб не нужны. Если есть парк поблизости, то бегать там. Рельеф это не помеха, а разнообразие. Посмотрите в сторону трейлраннинга, может вам понравится.
                                                          0

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

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

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

                                                          0

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

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


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


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


                                                              +2

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

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

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

                                                                    0
                                                                    Простите, а вы не путаете синхронизацию стейта с байндингами?

                                                                    Раз есть сомнения, давайте тогда определимся с терминами:

                                                                    State — состояние компонента, его данных, либо обобщенный термин;
                                                                    Store — глобальное состояние приложения, вынесенное в отдельную сущность;
                                                                    Binding — связывание стейта и UI, а автоматической или полуавтоматической синхронизацией изменений в одну или обе стороны;

                                                                    Потому, что никакого стейта приложения в реакте и подобных либах — нет, и для этого нужны дополнительные либы.

                                                                    Конечно же там есть стейт:

                                                                    // React
                                                                    class App extends Component {
                                                                      constructor() {
                                                                        super();
                                                                        this.state = { 
                                                                            /* state */
                                                                        };
                                                                      }
                                                                    }
                                                                    
                                                                    // Vue
                                                                    new Vue({
                                                                      data: {
                                                                        /* state */
                                                                      }
                                                                    })
                                                                    

                                                                    В React даже метод называется this.setState(state);. Кроме того там есть Store (Redux/Vuex) и биндинги.

                                                                    Поэтому да, я говорю о биндингах и о стейте. Эти наиболее важные части никак не покрываются стандартном Web Components, об этом и вопрос. Потому что сама по себе декомпозиция приложения на компоненты — это даже не пол дела, сложнее всего работать со стейтом, с данными и держать UI и данные всегда up-to-date.

                                                                    Ценность фреймворков совершенно не в его компонентной модели, которую, конечно же, можно будет со временем полностью заменить на Web Components. Ценность именно в data-driven подходе к разработке, а в этом направлении стандарты не дают нам ничего.

                                                                      0

                                                                      Вы написали именно "стейт приложения", а это не стейт компонента. Стейт приложения вы можете хранить в store или в чем вашей душе угодно, и использовать любой популярный стейт-менеджер вам никто не мешает с веб-компонентами, как и использовать для байндингов и прочего сахара готовые решения типа Polymer. При этом у вас также весь рантайм разработки будет доступен без пересборки. И про реакт можете не рассказывать так подробно, я отлично его знаю.

                                                                        –1
                                                                        Вы написали именно «стейт приложения», а это не стейт компонента.

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

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

                                                                        Никакой Redux биндингами стейта и UI не занимается, также как не занимается change detection, точечными изменениями DOM и так далее, поэтому даже если я будут его использовать, большой пласт работ все еще будет не покрыт.

                                                                        как и использовать для байндингов и прочего сахара готовые решения типа Polymer.

                                                                        Так почему бы мне не использовать готовые решения, типа React/Vue/Svelte? Потому что получается с Web Components я получаю несущественную часть фукнционала, по сути только компонентный подход, а далее должен костылись или искать внешние решения для всех остальных потребностей. Зачем все это, если можно использовать готовое решение в комплексе?

                                                                        При этом у вас также весь рантайм разработки будет доступен без пересборки.

                                                                        Это такой большой плюс? Немного не уловил.
                                                                          0
                                                                          Если бы я хотел сказать про стор, я бы так и написал

                                                                          Стор — это хранилище, стейт — это состояние. Никаких иных терминологических уточнений тут не требуется. И реакт не управляет состоянием на уровне приложения, это, также — факт. Состояние на уровне компонента и глобальный стейт-менеджмент — это отдельные вопросы, которые можно разобрать, также, отдельно. В общем случае, свое отношение к ним я изложил как в статье, так и в комментариях, уже не раз. На уровне компонента, лично мне, автобайндинги не нужны, так как на определенном уровне декомпозиции с обычным DOM API — с этим нет никаких проблем, при бОльшем контроле происходящего. На уровне приложения стандартные решения упираются в сложные данные и логику: за определенным порогом вам эти библиотеки начинают больше мешать чем помогать. Но это мое частное мнение, как я уже сказал, если вы хотите больше сахара — можете использовать Polymer. Или вообще использовать классический стек, если он вам подходит больше. Такое впечатление, что люди реагируют как на красную тряпку на определенные слова а остальную статью читаю по диагонали, оставляя общий посыл за скобками.

                                                                            –1
                                                                            Стор — это хранилище, стейт — это состояние. Никаких иных терминологических уточнений тут не требуется. И реакт не управляет состоянием на уровне приложения, это, также — факт. Состояние на уровне компонента и глобальный стейт-менеджмент — это отдельные вопросы, которые можно разобрать, также, отдельно.

                                                                            А до появления Redux приложения на React были stateless что ли? То есть если бы не хранилище, то у приложений на React не было бы состояния? Что вы ерунду то пишете. Раньше просто размазывали стейт приложения по компонентам, теперь стильно и модно держать весь стейт в сторе.

                                                                            При этом как раньше это называлось состоянием приложения, так и сейчас называется. И React, управляя стейтом отдельных компонентов, всегда управлял в итоге состоянием приложения.

                                                                            На уровне компонента, лично мне, автобайндинги не нужны, так как на определенном уровне декомпозиции с обычным DOM API — с этим нет никаких проблем, при бОльшем контроле происходящего. На уровне приложения стандартные решения упираются в сложные данные и логику: за определенным порогом вам эти библиотеки начинают больше мешать чем помогать.

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

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

                                                                            Почему это? Просто у вас эта тема вообще не раскрыта в статье. Пишете о всяких там Shadow DOM, которые нужны значительно реже, чем то о чем пишу я.

                                                                            Пишете что фреймворки не нужны, потому что есть Web Components и стандарты вокруг них, но не упоминаете, что они не покрывают и половины возможностей фреймворков.
                                                                  0
                                                                  Всем привет!

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


                                                                  TypeScript

                                                                  JSDoc облагает крайне низкой выразительной мощью и крайне высокой многословностью.


                                                                  Именно транспиляция TS в JS происходит практически мгновенно. Относительно долго ждать приходится только проверки типов. Вы можете отключить проверку типов для сборки во время разработки.


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


                                                                  LESS/SCSS/PostCSS

                                                                  Транспиляция опять же практически мгновенная.


                                                                  css переменные нарушают инкапсуляцию, за которую вы далее топите.


                                                                  Нативной арифметики над цветами до сих пор нет.


                                                                  React

                                                                  Вот как раз именно формочки на реакте делать и не удобно из-за отсутствия двустороннего связывания.


                                                                  Популярным он стал больше за счёт маркетинга, чем из-за каких-то своих особых качеств.


                                                                  В энтерпрайзе популярней Angular.


                                                                  CustomElements + ShadowDOM + ES Modules + HTML Templates

                                                                  Это довольно кривоватый (чего только стоят только текстовые параметры компонент) и тормозной (dom и так не сильно шустрый, а тут ещё и многовложенный) фреймворк. Частичная встроенность его в некоторые браузеры — единственное его преимущество.


                                                                  Невозможность изменить визуальное представление вложенных компонент извне — просто вишенка на торте. Хотите модалку от Гугла, а датапикер от Яндекса — получайте лоскутное одеяло вместо интерфейса.


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


                                                                  Redux/Mobx

                                                                  То, что вы поместили их в один ряд красноречиво говорит о том, что вы не понимаете что это и о чём. redux — про процедурное программирование над глобальныхм хранилищем. mobx — про эффективную синхронизацию состояний. С redux в один ряд можно поставить разве что mobx-state-tree. А с mobx — rxjs.


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


                                                                  Webpack

                                                                  Вы предлагаете в режиме разработки пользоваться нативными импортами, а в проде всё собирать в бандлы. Это источник довольно неприятных багов вида "всё запилил, протестировал, а перед самым релизом вдруг прилетают невозможные баги от тестировщиков". Из последнего, что у нас было, — стандартный ангуляровский минификатор предположил, что обращение к полю не имеет сайд эффектов и вырезал его. У разработчика всё работает. Модульные тесты проходят. А ручное тестирование релиза выявляет проблему.


                                                                  Что в итоге

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

                                                                    +3
                                                                    css переменные нарушают инкапсуляцию, за которую вы далее топите.

                                                                    Не готов тратить время на другие пункты, но тут поясните — CSS-переменные разве не аналог публичного интерфейса для стилизации компонента? В чем тут нарушение инкапсуляции?
                                                                      –1

                                                                      css переменные имеют нелокальное действие. Если у вас есть два компонента использующих переменную foo, то вам придётся очень не сладко, чтобы изменить её только для одного из них. А вот так пугающие вас пространства имён (my_button_foo) этой проблеме не подвержены. Более того, пространства имён дают понимание какой именно компонент настраивает та или иная переменная.

                                                                        +1
                                                                        Примите уже таблетки. «Пугающее», my ass.
                                                                        jsfiddle.net/spne37hy/1

                                                                        Более того, пространства имён дают понимание какой именно компонент настраивает та или иная переменная.

                                                                        Вот бы вы писали веб-стандарты, вот было бы здорово — все было бы так, как правильно именно в вашем представлении, и сразу правильно. Жаль вас не зовут.
                                                                            0
                                                                            Я долго пытался понять, куда тут смотреть, потому что в обоих примерах все в порядке. Вот максимально упрощенный пример вашего первого кода, который, типа, не изолирован: jsfiddle.net/spne37hy/41

                                                                            Он делает ровно то, что от него требуется и работает так, как вы и написали. Если --color прокинут сверху — цвет будет --color, если нет — фоллбек. Так работают CSS-переменные.

                                                                            Префиксировать(читай, нормально называть) переменные — хорошая практика. Но опять же можно сделать так — jsfiddle.net/spne37hy/40

                                                                            Не понял я проблемы.
                                                                              0
                                                                              Ну да, подумаешь компонент ломается, если его перенести из одного места в другое. Всё нормально, просто налепим костылей с восстановлением значения переменных во вложенных элементах.

                                                                                0
                                                                                Значение переменной тут не восстанавливается, так как оно не задано — задан лишь фоллбек. Все работает так, как написано. Вините руки.
                                                                                  0
                                                                                  И этот «фолбэк» был ненамеренно переопределён, что и потребовало костыля с заданием того же значения.
                                                                                    +1
                                                                                    Он не был переопределен, цвет lime сработал потому что прилетела сверху переменная --color = lime, а значит фолбек должен быть проигнорирован. Что и сделано.
                                                                      +3
                                                                      Пожалуйста, не надо столь долгих лирических отступлений.

                                                                      Всем не угодишь. А угодить конкретно вам цели не было.


                                                                      транспиляция TS в JS происходит практически мгновенно

                                                                      У меня прямо сейчас перед глазами 2 проекта с двумя версиями одного приложения. Одно написано на реакте и TS, другое, с обновленным дизайном, написано на JS с веб-компонентами. Время реакции на изменения в коде, связанное с транспайлом, отличается ОЧЕНЬ СИЛЬНО. Настолько, что визуальные правки в версии на TS становятся болью. Я сейчас говорю не о каком-то легком дискомфорте, а о серьезных фризах в воркфлоу, которые просто уничтожают идею "дизайна в браузере". Добавьте к этому шаги на пути к определенным стейтам, и возможность работать напрямую с отдельными модулями в случае с веб-компонентами без настройки отдельных эндпоинтов. Кроме того, одной из больших проблем клиентской разработки является сегментация платформы, и в этом ключе дебаг исходного кода — в разы удобнее без пересборок. Как и профайлинг для тонкой оптимизации.


                                                                      Нативной арифметики над цветами до сих пор нет.

                                                                      Если хранить шаблоны в виде JS-строк, как это сделано, например, в новом Polymer, и в моих велосипедах, вам становится доступна вся мощь JS: все реализуется элементарно, и работа с цветами, и миксины и любые капризы завязанные на рантайм (что нереально с ПРЕпроцессорами).


                                                                      css переменные нарушают инкапсуляцию

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


                                                                      В энтерпрайзе популярней Angular

                                                                      Откуда такие данные? Какая вообще разница?


                                                                      Это довольно кривоватый (чего только стоят только текстовые параметры компонент) и тормозной (dom и так не сильно шустрый, а тут ещё и многовложенный) фреймворк.

                                                                      Блин, вы серьезно? То есть JS-абстракция над тормозным нативным DOM эффективнее чем нативно поддерживаемые низкоуровневые средства расширения его элементов? Я правильно понял? Мантра про тормозной DOM — это вообще дичь какая-то, ибо тормозной не DOM а некоторые ресурсоемкие вычисления при работе с его API. Просто избегайте их, там где можете. Мне доводилось сравнивать по производительности реактовские компоненты с веб-компонентами, угадайте, кто победил?


                                                                      Частичная встроенность его в некоторые браузеры — единственное его преимущество.

                                                                      Полная поддержка в Хром и всех его производных, от Оперы до всякой фигни на Хромиуме. С недавних пор — полная поддержка в Electron. Это не "некоторые браузеры", а ПОДАВЛЯЮЩЕЕ БОЛЬШИНСТВО пользователей по статистике. Посмотрите на цифры, я не зря приводил ссылки в статье. Частичная поддержка в Safari, которая имеет ограничения, но в общем случае просто работает (есть нюансы по селекторам в ShadowDOM, которые легко обходятся). Да, остальные работают с полифилами, и да, это ведет к просадке в производительности, но все в рамках приличия, во всяком случае, не уступает особо реактам с ангулярами.


                                                                      чего только стоят только текстовые параметры компонент

                                                                      Что не так?


                                                                      красноречиво говорит о том, что вы не понимаете что это и о чём

                                                                      Я поставил редакс и мобекс в один ряд в рамках того контекста, где это вполне корректно. Ежу понятно, что в них есть разница, но ее разбор отдельная тема, выходящая немного за рамки. Не готов сейчас начинать еще и этот холивар, по моему я это вполне ясно выразил в самой статье. Не потому, что мне знаний не хватает (я имел дело со всем списком), а потому что в этой теме дофига собственной глубины. Да и без меня уже много воды вылито на эту тему.


                                                                      Это источник довольно неприятных багов вида "всё запилил, протестировал, а перед самым релизом вдруг прилетают невозможные баги от тестировщиков". Из последнего, что у нас было, — стандартный ангуляровский минификатор предположил, что обращение к полю не имеет сайд эффектов и вырезал его.

                                                                      То есть, у вас мгновенная компиляция еще и с минификацией при разработке? Или вы работаете постоянно с продакшн сборкой? Ох…


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

                                                                      Все верно. Мой посыл был лишь в том, что всегда есть место для подумать. Есть ситуации, когда популярный "дефолтный" стек — самый разумный вариант, и таких ситуаций куча. Нужно просто отдавать себе отчет в том, что этот вариант не единственный по умолчанию. И не лучший по всем параметрам. И часто выкидывая что-то лишнее вы приобретаете гораздо большее. И новые возможности платформы могут многое изменить и сделать лучше в ваших процессах, именно поэтому их вводят в оборот серьезные бородатые разработчики браузеров, после своих ожесточенных обсуждений принимая как стандарты. Их просто необходимо знать.

                                                                        –3
                                                                        Всем не угодишь. А угодить конкретно вам цели не было.

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


                                                                        Время реакции на изменения в коде, связанное с транспайлом, отличается ОЧЕНЬ СИЛЬНО

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


                                                                        Добавьте к этому шаги на пути к определенным стейтам

                                                                        Храните стейт в соответствующих хранилищах (сессия, история, локальное, урл) и не занимайтесь ерундой с восстановлением состояния при перезагрузке.


                                                                        возможность работать напрямую с отдельными модулями в случае с веб-компонентами без настройки отдельных эндпоинтов

                                                                        Это возможность любого компонентного фреймворка.


                                                                        в моих велосипедах, вам становится доступна вся мощь JS

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


                                                                        Откуда такие данные? Какая вообще разница?

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


                                                                        То есть JS-абстракция над тормозным нативным DOM эффективнее чем нативно поддерживаемые низкоуровневые средства расширения его элементов?

                                                                        Да. Любой выход из js рантайма — медленно. Любое изменение приаттаченного узла — медленно. Обращение ко многим свойствам узла может вызвать их пересчёт. Правильная JS абстракция сводит к минимуму эти ресурсоёмкие операции. У веб-компонентов же всё взаимодействие идёт через dom.


                                                                        Мне доводилось сравнивать по производительности реактовские компоненты с веб-компонентами, угадайте, кто победил?

                                                                        Не люблю гадать. Приведите бенчмарки.


                                                                        Да, остальные работают с полифилами, и да, это ведет к просадке в производительности, но все в рамках приличия

                                                                        Мы экспериментировали с полимером на мобилках пору лет назад. Выглядело это так: компоненты в течении нескольких секунд появлялись по одному.


                                                                        Что не так?

                                                                        Может быть то, что "строка" — далеко не единственный тип данных, который используется в программировании?


                                                                        Я поставил редакс и мобекс в один ряд в рамках того контекста, где это вполне корректно.

                                                                        Что за контекст такой? Они как бы перпендикулярны, как тёплое с мягким.


                                                                        То есть, у вас мгновенная компиляция еще и с минификацией при разработке? Или вы работаете постоянно с продакшн сборкой?

                                                                        С продакшен сборкой, где нет никакой минификации. Например: http://mol.js.org/app/todomvc/-/web.js


                                                                        популярный "дефолтный" стек

                                                                        Нет никакого "дефолтного" стека. В разных компаниях популярны разные стеки. В одних React+Redux, в других Angular+NGRX, в третьих вообще SAPUI5. Я понимаю вашу боль, упомянутый вами стек — далеко не предел мечтаний. Я и сам могу много гадостей про него рассказать. Но поверьте, React+Redux — далеко не самое худшее, что вас может заставить использовать некомпетентное руководство.

                                                                          +2
                                                                          С продакшен сборкой, где нет никакой минификации. Например: mol.js.org/app/todomvc/-/web.js

                                                                          По-моему человек как раз показывает, что с помощью нативных возможностей можно перестать дебажить подобные говнобандлы.
                                                                            –3
                                                                            А мужики-то и не знают…
                                                                              +2
                                                                              Отдаю должное — не каждому в голову может прийти гениальная идея, что лучше вообще все время дебажить вырвиглазные прод-сборки, чем только тогда, когда возникают специфические для прода баги. Сурово, по-челябински.
                                                                                –2
                                                                                Не прикидывайтесь, что не знаете про сорсмапы.
                                                                                  +2
                                                                                  Которые глючат и которые с веб-компонентами тоже нафиг не сдались.
                                                                                    –1

                                                                                    Раньше глючили, да. Сейчас проблем не наблюдаю.

                                                                                      +1
                                                                                      Ну а я вот регулярно наблюдаю. Наверное, сорсмапы не глючат в $mol, в этом все дело?
                                                                                        0
                                                                                        Ну, приведите примеры глюков.
                                                                                          +1
                                                                                          За этим в гугл.
                                                                                            –1
                                                                                            И при чём тут babel?
                                                                                              +2
                                                                                              Сорсмапы только в $mol?
                                                                              0
                                                                              Все-таки не просто «при помощи одних нативных». Как минимум, приходит размен одних нативных на другие нативные (отказ от не type=«module» ) что вообще требует перестройки, и еще требуется достоточно большая подготовительная работа по настройке путей, копированию файлов(что сейчас автоматом делает бандлер). Отказ от говнобандлов в настоящий момент представляется целой эпопеей.
                                                                                0
                                                                                Все-таки не просто «при помощи одних нативных»

                                                                                Для начала научитесь цитировать собеседника правильно.
                                                                          +1
                                                                          Как жить без биндингов вы так и не показали. А ведь это основная причина появления фреймворков — отсутствие среди нативных инструментов каких либо биндингов. Нативные компоненты управляются исключительно интерактивно, ничего не зная про реактивность.

                                                                          На это вопрос я уже тоже отвечал не раз в комметах: нужны биндинги — используйте готовые решения типа Polymer или lit-html. А можно написать свои. А можно не использовать совсем и быть счастливым вполне. В ваших руках — полная свобода и куча новых возможностей. Я говорю лишь о том, что не стоит запирать себя в клетку одной мета-платформы.

                                                                            –1
                                                                            На это вопрос я уже тоже отвечал не раз в комметах: нужны биндинги — используйте готовые решения типа Polymer или lit-html.

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

                                                                              +1
                                                                              Но вы не ответили на вопрос, почему бы не использовать готовые решения вроде Ангуляра или Реакта.

                                                                              Потому что выбирая Ангуляр или Реакт ради биндингов, мы получаем в нагрузку кучу невыпиливаемых абстракций — VDOM, JSX, TypeScript, RxJS, что угодно что мне может быть совершенно не нужно.
                                                                              С тем же Polymer мы кроме биндингов и горстки хелперов мы ничего не получаем. Со своим велосипедом мы можем добавить только биндинги, если в них есть необходимость.
                                                                                –1
                                                                                Я бы с интересом послушал про случаи, где нет необходимости в биндингах.
                                                                                  0
                                                                                  Вопрос не ко мне.
                                                                                    0
                                                                                    К вам.
                                                                                      0
                                                                                      Я использую биндинги.
                                                                                        0

                                                                                        Тогда поясните, пожалуйста, ваши слова:


                                                                                        Со своим велосипедом мы можем добавить только биндинги, если в них есть необходимость.
                                                                                          0
                                                                                          Лично я использую готовые биндинги из pwa-starter-kit. Но я, в отличие от вас, не экстраполирую себя на все человечество и допускаю, что без биндингов можно и обойтись.
                                                                                            0
                                                                                            Без всего можно обойтись. Нужно ли?
                                                                                              0
                                                                                              Кому-то может и нужно, решать это не вам.
                                                                                  0
                                                                                  Потому что выбирая Ангуляр или Реакт ради биндингов, мы получаем в нагрузку кучу невыпиливаемых абстракций — VDOM, JSX, TypeScript, RxJS

                                                                                  Чем это плохо?

                                                                                    0

                                                                                    Тем, что вы получаете в нагрузку кучу сайд-эффектов, лишний код, который делает ваше приложение тяжелее в разы, усложняете без необходимости то, что может быть предельно простым, тащите в проект специфический для мета-платформ синтаксис со своими собственными заморочками, которых и без того во фронтенде достаточно? Тем, что состоянием компонента может быть не только парочка пропсов, но и положение каретки при вводе, определенное положение при прокрутке страницы, элементы из таб-индекса в фокусе, выделение текста? Тем, что работа со всем вышеперечисленным через дополнительные абстракции — это боль, потому, что источником всей правды, учитывающей вышеперечисленное, является DOM и ничто больше, и никакие внешние абстракции ничего о изменениях от непосредственных действий пользователя без обращения к DOM не знают? Тем, что для управления состоянием, в огромном количестве случаев, достаточно CSS и HTML-атрибутов? Тем, что ради изменения textContent одного элемента в DOM нет никакого смысла использовать библиотеки, так как они делают в итоге тоже самое используя тот-же DOM API? Тем, что ваше приложение тормозит, потому что использует JS там, где браузер может справится сам, используя оптимизированный код написанный вендором на C++? Продолжать?


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

                                                                                      0
                                                                                      А веб-компоненты вам дают свободу выбора: понадобились либы — юзайте, нужно кастомное решение — пишите спокойно, не беспокоясь о том, как скрещивать ужа с ежом.

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

                                                                                        0

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

                                                                                      0
                                                                                      Тем, что лично мне они могут быть не нужны.
                                                                                        0
                                                                                        Тем, что лично мне они могут быть не нужны.

                                                                                        Тогда личное вы можете их не использовать.

                                                                                          0
                                                                                          Покажите, как я могу их не использовать, используя React или Angular.
                                                                                            –1

                                                                                            Я имел ввиду, что вы можете не использовать Реакт или Ангуляр.

                                                                                              +1
                                                                                              Какой-то бессмысленный разговор вы затеяли — ну да, лично я и лично те, кому не нравятся лишние абстракции, могут не использовать React или Angular, а использовать веб-компоненты.

                                                                                              Об этом собсно эта статья.
                                                                                                +1
                                                                                                > Об этом собсно эта статья.

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

                                                                                                  +1
                                                                                                  Это разве не очевидно, что если кто-то не хочет использовать реакт или ангуляр, то может и не использовать?

                                                                                                  Конечно, неочевидно — даже в комментариях к ней представление людей о веб-компонентах какое-то крайне отдаленное или на годы устаревшее. Многие, не поверите, о них тупо не знают.
                                                                                                  Они находятся в тени популярных решений и незаслуженно обходятся вниманием, хотя ситуаций, где можно их применять с большим удобством вполне достаточно.
                                                                                  0

                                                                                  Ну то есть вы признали, что одними-то только веб стандартами не обойтись — нужны js обвязки типа polymer, lit-html, react и прочих.

                                                                                    +2
                                                                                    Веб-компоненты — не фреймворк, это низкоуровневый API, на котором можно либо построить фреймворк значительно более тонкий, чем популярные решения, либо написать свой велосипед — это для тех кто умеет и знает что делает.
                                                                                    Веб-компоненты можно использовать без этих обвязок, можно брать готовые, можно писать обвязки самостоятельно.
                                                                                    С фреймворками будете кушать, что дали + с описанными в статье минусами.
                                                                                      –1
                                                                                      Реакт в той же степени низкоуровневый API, на котором… и далее по тексту. Разница лишь в том, что одно встроено в браузеры с сооветствующим долгим циклом обновлений. А другое грузится как библиотека и может быть обновлено в любой момент. При этом вы можете грузить одну библиотеку, а можете другую. А вот с веб-компонентами — что дали, то и жуйте. Там уже починили геморрой с вытаскиванием темплейтов из теневого дома?
                                                                                        0
                                                                                        а использование веб компонентов без тенегового дома вы даже не рассматриваете? почему?
                                                                                          0
                                                                                          Это как вообще?
                                                                                            0
                                                                                            customElements.define без attachShadow — возможность мне известна как чисто теоретическая, сам не пробовал, но спросить — любопытно.
                                                                                              0
                                                                                              Да как бы смысла в этом не то чтобы много. Годится для совсем тривиальных компонент.
                                                                                                0
                                                                                                А Ваше мнение чего не хватает? Можно как и понять что вы сказали «вот shadow dom и не хватает», но в это невозможно поверить, поэтому переспрошу (а не могу поверить потому что этот вентиль на пути каскадов css и селектаров DOM — никогда не казался обязательным).
                                                                                          0
                                                                                          С такой логикой у вас что угодно API, просто не встроенное в браузере. Веб-компоненты — это браузерный API, если непонятно, React — нет.

                                                                                          То что вы недовольны, что в браузеры нативно впилили не $mol — ну то как раз понятно.
                                                                                            0
                                                                                            Веб-компоненты — это браузерный API, если непонятно, React — нет.

                                                                                            Я разве не то же самое сказал?

                                                                                              0
                                                                                              Конечно, не тоже самое:
                                                                                              Реакт в той же степени низкоуровневый API, на котором...

                                                                                              Так как Реакт более высокоуровневый, он никак не может быть в той же степени низкоуровневым. С логикой дружны?
                                                                                                –1
                                                                                                Где это вы в Реакте высокоуровневость увидели?
                                                                                                  +1
                                                                                                  Реакт создает абстракции поверх DOM API, веб-компоненты и есть DOM API. Значит Реакт более высокоуровневый, и значит с логикой все же не дружим.
                                                                                                    0
                                                                                                    Нет, веб-компоненты — такая же обёртка над DOM, как и любой другой компонентный фреймворк, только «нативная».
                                                                                                      +1
                                                                                                      Вам наверное очень жаль, что разработчики данных спецификаций так не считают.
                                                                                                        0
                                                                                                        Процитируйте же их.

                                                                                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                                                Самое читаемое