Каждый раз, когда в какой-либо статье, либо в комментариях, упоминается группа стандартов Web Components, происходит практически одно и то же: люди, которые, зачастую, весьма слабо представляют о чем идет речь, начинают делиться «экспертными» мнениями. Каждый раз обсуждения скатываются к одному и тому же накатанному сценарию, название которого рифмуется со словом «грач». А мне очень хотелось бы позитива, конструктива и перехода к вопросам практического применения. В данной статье, я попытаюсь разом ответить на подавляющее большинство типичных вопросов и опровергнуть максимум общих заблуждений. Впоследствии, в тяжелой ситуации, можно будет отбиться одной ссылкой. Итак, поехали.
Основы
Веб-компоненты — это набор современных спецификаций, состоящий из следующих основных элементов:
Custom Elements — нативная возможность создавать свои собственные HTML-теги, с заданным поведением, внешним видом и собственной внутренней разметкой.
Shadow DOM — разделение внутренней структуры компонента с инкапсуляцией внутренних стилей и остального тела документа.
Template — специальный тег, позволяющий хранить куски разметки, применять их и многократно использовать при необходимости.
HTML Imports — возможность импорта блоков HTML, хранящихся в других HTML-файлах
Блюдо из всего вышеперечисленного можно приправить нативными CSS-переменными, нативными ES-модулями и серверным пушем HTTP/2. Еще есть слоты, кастомные атрибуты, кастомные события и прочие детали. О них немного позже, когда перейдем к практике.
Да эти ваши веб-компоненты почти нигде не поддерживаются
Сухие цифры — лучшие друзья инженера. Давайте с этого ракурса посмотрим на «почти нигде»:
Custom Elements — 78.71%
Shadow DOM — 79.12%
Template — 89.61%
HTML Imports — 69.16%
Как мы видим, вышеуказанные технологии работают в браузерах у подавляющего большинства пользователей. Картину немного портят HTML-импорты, но использовать полный набор мы не обязаны (я предпочитаю нативные ES-модули для разбития на удобные блоки всего и вся), даже по отдельности в этом списке можно найти для себя много «вкусного».
Очень рекомендую не доверять мне слепо, а сходить по приведенным ссылкам. Там вы, например, сможете увидеть текущий статус для данных спецификаций и то, что Custom Elements и Shadow DOM получили полную поддержку в Firefox, начиная с версии 63. Когда основная масса пользователей лисы обновится до этой версии, а этот момент не за горами, общие цифры станут еще немного привлекательнее. Также, вы могли обратить внимание на «неполную поддержку» Custom Elements и Shadow DOM в Safari. Яблочный браузер не даст вам унаследовать ваш компонент от встроенного нативного браузерного элемента, типа кнопки, селекта и тому подобного. Еще в Safari есть небольшие нюансы в CSS-селекторах при использовании Shadow DOM. На практике, с этим вполне можно жить и не тужить. Видимо, по традиции, аутсайдером среди современных браузеров является Microsoft Edge. Разработчики утверждают, что поддержка реализуется. Ждем.
Хорошо, а что делать с остальными ~20% пользователей?
Для поддержки этих ребят можно использовать полифилы. Да, с полифилами работать будет немного медленнее, но невооруженным глазом это не заметно. Зато у всех остальных — будет быстрее.
Пытались лет пять назад делать проект на Polymer. Все ужасно тормозило.
В те «далекие» времена, бушевал черновик стандарта (v0), поддержка которого была реализована только в Chrome. С тех пор многое изменилось: была принята новая версия стандарта — v1, нативная поддержка была реализована в различных браузерах, полифилы были переписаны, хорошие практики прошли путь устаканивания. Сам Polymer из технологического превью превратился во вполне рабочее решение, с которым приятно иметь дело.
Полимеры какие-то… Что это вообще?
Polymer — это библиотека для создания веб-компонентов. Она реализует поддержку всего того «сахара», к которому мы так привыкли при работе с популярными фронтенд-фреймворками: динамические привязки данных (bindings), репитеры для работы с массивами и т. д. На данный момент, вышла уже 3-я стабильная версия этой библиотеки. Разработка ведется при активном участии разработчиков Chrome. Экосистема поддерживается компанией Google.
Когда стоит использовать веб-компоненты?
Если вам нужна универсальная общая библиотека UI-компонентов. Случай из жизни: проект, в котором основное приложение написано на React, а бэкофис — на Angular. И хочется одинаковости и всяческого переиспользования кодовой базы. А веб-компоненты замечательно себя чувствуют в разных экосистемах.
Если вам близок подход «дизайн в браузере». Вы сможете творить без постоянных пересборок приложения и без лишних зависимостей. Это делает прототипирование весьма приятным занятием и позволяет вашему приложению плавно эволюционировать от состояния прототипа до состояния production-версии. Люблю такое.
Если вы любите старое-доброе ООП: создаете класс наследованием от HTML-елемента, реализуете в нем желаемые фишки и плюшки общего плана, а потом наследуете от него классы для специализированных компонентов. И вот у вас получился свой собственный микрофреймворк. Красота!
Если вы ненавидите БЭМ: Shadow DOM изолирует стили компонента. Нет необходимости ни в многоэтажных монструозных именованиях, ни в обеспечении навигации к декларациям в общей куче CSS. Все компактно упаковано в компоненте: стили, разметка, логика.
Если вы разрабатываете приложения на основе Electron. Текущая версия Chromium в Electron уже поддерживает все необходимое. Не смотря на общий лаг в версиях.
Если вы хотите написать свой фреймворк/библиотеку. Веб-компоненты — это отличная композиционная основа для подобных экспериментов.
Если вам нужен гибридный подход: вы реализуете классические веб-страницы с элементами SPA: кастомные теги можно использовать с любым серверным шаблонизатором, они могут являться просто частью общей разметки и отрабатывать свое назначение в нужный момент. Вы можете соблюдать тонкий баланс того, что рендерится на сервере и что работает на клиенте.
Если ваши пользователи используют современные браузеры. Само-собой.
Если вы разрабатываете PWA: основные мобильные платформы поддерживают все «из коробки». Для быстрого старта есть pwa-starter-kit.
Если вы заинтересованы в повышенной безопасности приложения а детальный аудит зависимостей для вас непомерно дорог. Тут все просто: меньше зависимостей — меньше неподконтрольных дыр.
Если вы маньяк-оптимизатор и любите работать с DOM API: веб-компоненты — это часть DOM API, со всеми стандартными возможностями обычных DOM-элементов.
Если вы обжигались о поломку обратной совместимости версий библиотек: когда все основано на хардкорном стандарте — оно как-то надежнее.
Когда вам НЕ стоит использовать веб-компоненты
Когда в требованиях к вашему проекту имеется необходимость поддержки старых и экзотических браузеров. В этом случае, вам не позавидуешь в целом. Мои соболезнования.
Когда вы разрабатываете несложные продукты с коротким жизненным циклом и у вас нет необходимости развивать единую кодовую базу.
Когда вы имеете дело, преимущественно, с легаси-кодом.
Когда вы и ваши коллеги используете только что-то модное и ничего другого знать не хотите.
Зачем мне все это? У меня есть React/Vue/Angular/etc, мне хватает...
Затем, что значительную часть того, что делает JavaScript в популярных библиотеках и фреймворках, можно переложить на более низкоуровневую браузерную реализацию. Ради скорости, сокращения непомерного объема зависимостей, сокращения самой зависимости от зависимостей. Ради добра.
Комментарии (48)
justboris
08.09.2018 17:27+3Небольшая ремарка по поводу полифиллов и работы всего этого в IE.
Дело в том, что поведение shadow dom сильно отличается от того, что было в браузерах до этого. Поэтому легко заполифиллить это не получится. Указанный в статье полифилл делает много чего:
- Полностью переписывает систему всплытия событий
- Переписывает операции с DOM-узлами: appendChild, removeChild, querySelector и т.д.
- innerHTML тоже досталось
Насколько производительно такое переписывание нативного DOM API на JS — решайте сами.
Из своего опыта скажу, что эта абстракция еще и течет. Соседняя со мной команда, которая пилит проект на Polymer, столкнулась с тем, что event.target может быть undefined. В Chrome работает как надо, в IE без полифиллов тоже, а вот IE+полифиллы — всё ломается.
Нативные веб-компоненты еще можно как-то рассматривать как полезную и перспективную технологию, но если нужна полноценная поддержка IE, то нужно тщательно подумать. Подводные камни неидеальности полифиллов всплывут внезапно.
i360u Автор
08.09.2018 18:41+1Если нужна поддержка IE — да, нужно подумать. Не всем она нужна просто, нужен анализ аудитории. Для моих приложений, доля пользователей с IE — изчезающе мизерная. Я откровенно признаю, что я на них забил, и не страдаю от этого никак: денег они не приносят.
justboris
09.09.2018 11:14доля пользователей с IE — изчезающе мизерная
Секция в статье называется "Хорошо, а что делать с остальными ~20% пользователей?". Одна пятая часть – это слишком много чтобы называться "изчезающе мизерной". Какое-то противоречие.
i360u Автор
09.09.2018 11:28~20% — это не пользователи IE. Точнее не только они. IE11 используют 2.66% от общего глобального трафика, и львиная доля это — китайцы и боты. Как я и говорил, для принятия обоснованного решения в конкретном случае — нужен анализ аудитории в рамках текущих бизнес-задач. Для кого-то игнор IE может быть неприемлемым, для кого-то наоборот. В целом же, сегментация веб-платформы на уровне поддержки стандартов — это ее главная болезнь, которую нужно лечить. И часть этого лечения заключается в принципиальной позиции разработчиков по отказу поддержки всякой некрофилии.
justboris
09.09.2018 11:36Дело не в IE и его доле, а в полифиллах в принципе. Эмулировать ShadowDOM намного сложнее и ненадежнее, чем, например, заполифиллить Array.prototype.includes.
Сборка с полифиллами сильно отличается от нативной имплементации, поэтому нужно ожидать дополнительных затрат по времени на борьбу с багами там, либо просто забить на 20% пользователей (что тоже возможно).i360u Автор
09.09.2018 11:46В Edge полифилы стабильно работают, тесты проходят. Времени больше уходит на другое: Edge, к примеру, не поддерживает свойство object-fit для canvas, подобные нюансы постоянно всплывают и требуют внимания. Но не скажу что проблемы с полифилами занимают в этом какую-либо значительную часть. В конце концов, тестирование этих решений происходит на нескольких уровнях: как самими экосистемными разработчиками, так и разработчиками "на местах". Ну и пользователей у того-же ю-туба вполне достаточно чтобы ловить основные баги.
i360u Автор
09.09.2018 11:33+1Дополню: Opera Mini, к примеру — 2.47%, это сравнимо с IE, однако этот браузер — в вечной красной зоне и не поддерживает вообще ничего. Он существует для просмотра простых HTML-страничек и никак не является платформой для приложений. Что теперь, не писать приложения для веб из-за этого?
justboris
08.09.2018 17:31Еще из дискуссии к прошлой статье остался неотвеченный вопрос, как использовать веб-компоненты без Polymer, чтобы получался компактный код без лишних повторений.
P.S. в любом случае спасибо автору за статью, за продвижение интересных идей, которые можно обсудить.
x-foby
08.09.2018 18:14+3Вы в очередной раз пытаетесь заставить нас смотреть на сравнение тёплого с мягким.
React, Vue, Angular, etc. предлагают не только и не столько собственную реализацию решений, на которых основаны web components, сколько модель работы с данными.
Писать собственные реализации flux-хранилищ, описывать собственную реактивную модель — это либо очередной велосипед, либо опять-таки куча зависимостей, от которых якобы нас спасут web components…
А обвинять людей в использовании чего-то модного и нежелании знать ничего другого — это, знаете ли, так себе. Мы в массе своей создаём продукты для бизнеса, условия диктует рынок, а не мы…i360u Автор
08.09.2018 18:31А вы, видимо, в очередной раз оказались неспособны прочитать статью полностью. Вам никто не мешает использовать тот-же Redux в сочетании с веб-компонентами. В pwa-starter-kit, к примеру, он используется по умолчанию. Веб-компоненты берут на себя вполне определенный ряд задач, как вы будете решать остальные — остается на ваше усмотрение. Равно как и в случае с React, Vue, Angular, etc. Велосипед — это лишь один из возможных подходов, который нравится лично мне, по вполне конкретным причинам. Я их привожу постоянно и не вижу в этом ничего дурного. Все популярные решения, в конце концов, начинали как велосипеды. А рынок диктует, да. Он диктует требования к надежности, скорости разработки, скорости загрузки, стоимости поддержки и т. д. И все, о чем я пишу, это ответы на эти требования.
x-foby
09.09.2018 12:43+1Ваши аргументы в статье не объективны. Вот вы говорите, что необходимо отказаться от популярных фреймворков/библиотек, ради «скорости, сокращения непомерного объема зависимостей, сокращения самой зависимости от зависимостей.»
React (react + react-dom) сам по себе тянет за собой 5(!) зависимостей:
- loose-envify
- js-tokens
- object-assign
- prop-types
- schedule
Вы вот серьёзно? Непомерного количества?
И так у вас везде.
Вы уповаете на Polymer. Ок, вопросов нет, забавная игрушка с возможной перспективой. Но скажите, почему Google всё ещё не отказался от Angular, если использование Web Components настолько быстрее/лучше/красивей/зеленее?
Почему вы такие вопросы в статье обходите стороной? Где объективизм?
Вы говорите, что все решения начинались как велосипеды, но это больше похоже на слова зелёного джуна (которым вы-то, скорее всего, не являетесь, что ещё больше пугает), неспособного разобраться в теме, не пришедшего к пониманию того, что все сегодняшние популярные решения — это старые (читай проверенные временем) решения «портированные» из других языков, парадигм и т.д.
Вы говорите, что рынок должен пойти за Web Components, потому как они отвечают его требованиям «к надежности, скорости разработки, скорости загрузки, стоимости поддержки и т. д».
Возможно! Но чтоб рынок поверил в это, нужно сначала рынку показать, что это решение используется и поддерживается крупными игроками (надежность), что на рынке есть достаточное количество специалистов, работавших с этим решением (скорость разработки и стоимость поддержки), что есть реальные исследования, говорящие о том, что Web Components быстрее грузятся, нежели популярные сегодня решения, честные исследования, учитывающие кэширования популярных версий из cdn, например, учитывающих минификацию сорсов.
Я вас уверяю, ни по одному из этих пунктов Web Components не выиграют. И именно поэтому они на сегодняшний день не популярны.
Вы так защищаете Web Components, как будто на них кто-то нападает, как будто кто-то спорит с тем, что идеи сами по себе хорошие.
Нет же, всё круто, всё правильно, просто использование этих технологий сегодня не даёт никакого профита.
Вот если бы гугл выкатил хотя бы один свой боевой проект, написанный на собственном Polymer, тогда можно было бы о чём-то говорить, а пока этого нет, разговор этот имеет смысл только в разрезе собственных поделок.i360u Автор
09.09.2018 12:56Вот вы говорите, что необходимо отказаться от популярных фреймворков/библиотек
Действительно? Где? По моему, я написал о том, что веб-компоненты можно использовать В СОЧЕТАНИИ с фреймворками и библиотеками. Ссылку на тесты привел. И это лишь один из интересных кейсов их применения.
Далее, простите, у меня нет сил это прокомментировать: я опять предположу что вы не читали, читали не внимательно или просто не поняли в чем суть. Допускаю, что в последнем случае, в этом есть моя вина, но я, честно, старался.
i360u Автор
09.09.2018 13:10https://github.com/Polymer/polymer/wiki/Who's-using-Polymer%3F — не стал изначально вставлять ссылку в статью, ибо она не о Polymer по большей части, а о стандартах на которых он основан. Но вот, любуйтесь.
SPAHI4
09.09.2018 13:21хотя бы один свой боевой проект, написанный на собственном Polymer
эмм, ютуб? внутренний интерфейс хрома?x-foby
09.09.2018 15:12Внутренний интерфейс хрома — это не в счёт, так как внезапно не нуждается в поддержке ie, edge, safari)
А вот ютюб — это да, проглядел я, мой косяк)Aingis
10.09.2018 09:51И — внезапно! — на Ютюбе все не так радужно: в Firefox или Edge он открывается в 5 раз дольше, чем в Google Chrome.
Lodin
08.09.2018 22:17+2Никак не могу взять в толк, почему в каждой статье про WebComponents обязательно упоминается HTMLImports. Эта спецификация считается deprecated, её отказались имплементировать все браузеры, кроме Chrome. Я понимаю, что на HTMLImports написано подавляющее большинство современных вебкомпонентов, но это всего лишь наследие предыдущих версий Polymer.
i360u Автор
09.09.2018 07:03А можно поинтересоваться, с чего вы взяли, что HTMLImports — deprecated? У них как был статус Working Draft, так и остался. Совершенно верно, что эту часть стандарта отказались внедрять производители браузеров всех кроме Chrome, но они пишут что ПОКА отказались. Поскольку эта спецификация была изначально включена, и реализована в Chrome и его производных — я о ней пишу. Хотя я написал, что сам ее не использую.
justboris
09.09.2018 11:10Надежда, как известно, умирает последней, по пока все идет по тому же пути, как умер Object.observe
- Поддерживается только в Chrome, остальные вендоры отказываются это имплементировать
- Ни один крупный фреймворк ими не пользуется (включая Polymer)
Официальной таблички "deprecated" на фичу пока не навесили, но идет работа по превращению html-модулей в расширение ES-модулей с отказом от синтаксиса
<link rel="import">i360u Автор
09.09.2018 11:18Согласен с этим. Не согласен с позицией, что эту часть уже пора полностью игнорировать. Как ни крути, сама концепция — довольно интересна. Хотя-бы для того, чтобы быть в курсе тенденций, и этапов развития, о ней неплохо бы знать.
justboris
09.09.2018 11:38Синтаксис и семантика импортов абсолютно точно поменяется. Зачем учить то, что будет однозначно переделано?
i360u Автор
09.09.2018 11:50Ну так я и не рекомендую их использовать, тут я согласен с вами и разработчиками Polymer.
Aingis
10.09.2018 22:26В Хроме не включается обсуждаемый Polymer.
i360u Автор
11.09.2018 00:50Простите, а как вы его пытались включить?
Aingis
11.09.2018 15:38Точнее говоря не сам Polymer, а встроенные полифиллы.
i360u Автор
11.09.2018 15:42встроенные полифиллы
Гениально. Вы уверены, что понимаете о чем говорите?
Aingis
11.09.2018 16:59Я-то да, но хз почему ответ на habr.com/post/422499/#comment_19091077 оказался в этой ветке.
justboris
11.09.2018 18:05Полифиллы можно включить для Chrome при помощи get-параметров, например: https://www.example.com/my-application/view1?wc-ce&wc-shadydom&wc-shimcssproperties
Задокументированно это тут, возможно на Youtube эту фичу оторвали, но в моем опыте эта штука помогала отлаживать баги, пользуясь удобными devtools Хрома и не запуская виртуалку.
Yavanosta
08.09.2018 22:32+2HTML imports уже deprecated. Вместо них скорее всего поддержат импорты html в js через стандартный `import`.
Polymer уже тоже не рекомендуется использовать, почитайте их блог или последние доклады. Суть полимера — дать возможность «раннего доступа» к вебкомпонентам до реализации их в платформе, посмотреть как это в дикой природе выживает и лучшее взять в плаиформу. Сейчас на эту роль претендует LitElement
Что-то полетело — кастомные элементы и шедоу рут.
Что-то изменилось — html imports заменят на import в js, css mixins скорее всего сохранятся как идея но вроде будут представлять из себя что-то вроде кастомных предопределенных точек доопределения стилей (по аналогии с ::before и ::after можно будет создать в своем элементе my-element::super-button, но это пока ранний драфт, не ясно что будет в итоге).
Что-то нет — дата биндинги не полетели их в платформе не будет, вместо них предлагается использовать редакс и рендер-функцию для эффективной работы которой предлагается добавить в template поддержку чего-то вроде плейсхолдеров.
В общем статья уже во многом устарела. :-(Lodin
09.09.2018 00:21Дополню ваш комментарий парой ссылок :)
Что-то изменилось — html imports заменят на import в js, css mixins скорее всего сохранятся как идея но вроде будут представлять из себя что-то вроде кастомных предопределенных точек доопределения стилей (по аналогии с ::before и ::after можно будет создать в своем элементе my-element::super-button, но это пока ранний драфт, не ясно что будет в итоге).
Хорошие ссылки по теме — сам CSS Shadow Parts proposal и отличное описание того, как это предполагается использовать, от Monica Dinculescu.
Что-то нет — дата биндинги не полетели их в платформе не будет, вместо них предлагается использовать редакс и рендер-функцию для эффективной работы которой предлагается добавить в template поддержку чего-то вроде плейсхолдеров.
HTML Template Instantiation proposal.
Yavanosta
09.09.2018 07:26Спасибо, я просто в поезде с телефона набирал комментарии, не нашел в себе сил искать ссылки :-)
i360u Автор
09.09.2018 07:56HTML imports уже deprecated
Спрашивал уже у предыдущего комментатора, у вас тоже спрошу: откуда такие новости?
скорее всего поддержат импорты html в js через стандартный
import.В смысле, "скорее всего"? Именно так это и работает в Polymer 3.0, и именно этот подход рекомендую я.
Polymer уже тоже не рекомендуется использовать
If your project has a short development cycle and you're uncomfortable with including pre-release dependencies in your production deployments, you might choose to use Polymer 3.0 instead. This is a safe choice, as we'll continue to support the Polymer 3.x APIs with maintenance releases for the foreseeable future.
Цитата из последнего сообщения в блоге разработчиков. Знаете, я тут пытаюсь заниматься популяризацией новых фишек веб-платформы и вопросы готовности технологий к использованию — самые труднопробиваемые. А вы мне предлагаете писать о вещах, которые in development? В свое время — обязательно напишу, сейчас — явно рано. Статья точно пока не устарела.
Часть про биндинги не буду комментировать, вы видимо, торопились сильно когда писали.
kmmbvnr
09.09.2018 06:08Пробую сейчас использовать custom elements.
Существенный недостаток — на момент вызова connectedCallback нет доступа к child элементам. Как делать вложенные элементы, такие как свой select с options?
Или первая отрисовка будет основана только на основе атрибутов элемента (дублируем selected option атрибутом) или откладывать отрисовку на setTimeout, но это визуально же мерцание.
В итоге сделал перечисление всех options json'ом в аттрибуте. Для серверной генерации удобно, но руками конечно не напишешь.
i360u Автор
09.09.2018 07:34Хм, а вы ничего не путаете? Проверяю, все доступно:
connectedCallback() { console.log(this.children); }
По ссылке на StackOverflow описана какая-то странная вымороченная ситуация и еще код приведен с поиском дочернего элемента внутри Shadow DOM, хотя он лежит внутри обычного DOM как обычный потомок элемента…
Делал и селекты и табы и прочее подобным образом, проблем не было. Лучшим вариантом для подобных случаев считаю что-то типа этого:
<my-select> <my-option icon="some-icon" value="opt-1">Option Text</my-option> </my-select>
Где оба элемента — обычные custom elements (мутации вложенных элементов родительским в момент добавления в DOM — не нужны)
kmmbvnr
10.09.2018 09:57хм, странно. Проверил на чистом hrml все действительно как вы говорите. Но у меня в пайплайне что-то это ломает
zim32
09.09.2018 10:23Скорее всего фреймворки никуда не уйдут, просто view часть у них пкрекдет на веб компоненты. Роутинги, формы, анимации хранение состояния далеко не полный перечень всего что есть во фреймворках и нет в веб компонентах.
i360u Автор
09.09.2018 10:30Скорее всего фреймворки никуда не уйдут, просто view часть у них пкрекдет на веб компоненты.
Полностью согласен. Ну, кроме анимаций =) Никто и не позиционирует веб-компоненты как замену фреймворкам, скорее их стоит рассматривать как основу для фреймворков нового поколения.
zim32
09.09.2018 10:56+1Вот бы они еще запилили Object.observe еще бы пару фреймворков отвалилась.
i360u Автор
09.09.2018 11:02Есть же Proxy
Drag13
09.09.2018 14:03Это не одно и тоже. Prxoy шире, но из-за этого (т.к. нужно поддерживать больше функционала) медленный. До сих пор ни один крупный вендор на него не перешел, хотя намерения озвучены.
Large
11.09.2018 18:14Разница в том, что Object.observe можно было вешать на любой объект (например результат сторонней библиотеки) и при этом слушать события на этом объекте, а Proxy — это обертка которая просто передает вызовы на оригинальный объект. Таким образом если сторонняя библиотека меняет оригинальный объект — Object.observe об этом сообщит, а Proxy сможет сообщить лишь об изменениях над proxy объектом.
urrri
10.09.2018 01:13Есть ещё такая либа slim.js. Проще, меньше и быстрее чем Полимер
i360u Автор
10.09.2018 09:56Я думаю подобные штуки будут появляться все чаще и в во все большем количестве. И это хорошо, пусть цветут тысячи цветов. Главное, мы будем точно знать что у них в основе и куда смотреть в случае проблем.
Large
11.09.2018 18:16Пока больше всего не хватает scoped register, без этого поддержка сложных UI фреймворков становится более сложной.
dblokhin
Читал ваш предыдущий пост про Polymer. Решил попробовать и влюбился :) Все очень радует, горячо поддерживаю переход на LitElement.