Всем привет!
В данный момент, как многие знают, проходит ежегодная конференция Google I/O, в рамках которой была представлена новая версия библиотеки для работы с интерфейсами веб-приложений Polymer 3.0 (видео на английском):
Основные нововведения:
- Отказ от использования HTML-imports в пользу ES-modules
- Отказ от использования Bower в пользу npm
- Вынос полифиллов для поддержки новых стандартов (требуются для FF, Edge и IE11) из состава самой библиотеки
Почему это может быть интересно?
Ключевой особенностью Polymer является то, что данная библиотека построена на основе современной группы стандартов Web-components. Это означает, что ее композиционные возможности (во многом аналогичные React или Vue) реализованы не с помощью мета-платформы и js-абстракций поверх обычного DOM, а на уровне самого браузера, что открывает ряд поистине замечательных возможностей и рождает целый спектр новых подходов. Например, практически стирается граница между SPA и классической веб-страницей, существенно упрощается работа с окружением разработки и существенно повышается универсальность ваших решений: вы можете использовать свою UI-библиотеку и реализацию вашей дизайн-системы в сочетании с практически любым популярным фреймворком или библиотекой, без необходимости какой-либо серьезной адаптации (https://custom-elements-everywhere.com/). И это далеко не все.
P.S.
Так получилось, что лично я работаю с набором стандартов Web Components и непосредственно с Polymer в течении уже нескольких лет, еще с версии 0.5. Я очень внимательно слежу за развитием данного сектора Web-платформы и многое опробовал в боевых условиях реальных проектов. В течении всего этого времени, я регулярно встречаю различные мнения о данной технологии, как среди отечественных разработчиков, так и среди наших иностранных коллег. И мнения эти, в удручающем большинстве случаев, либо очень поверхностны, либо глубоко ошибочны. Я призываю сообщество к непредвзятому взгляду на данный стек, к пересмотру и обновлению своих знаний. Поверьте, это того стоит.
Комментарии (33)
vdonich
10.05.2018 21:50ИМХО догоняют Реакт. Надо ли? Смогут ли?
В целом расстроен.i360u Автор
11.05.2018 09:51Реакт — это огромный, местами буквально монструозный, костыль над DOM. Полимер — это браузер + немного сахара поверх нативных спек. Не думаю что тут речь вообще идет о том, что кто-то кого-то догоняет, потому как Реакт, в данном аспекте — это прошлое, а Полимер и — будущее. Я поддерживаю свою собственную либу для работы с UI, которая концептуально очень похожа на новый Полимер, и я отлично вижу, что здесь главное даже не конкретная реализация, а фундамент на котором она основана — сама веб-платформа. Каждый раз, когда мне приходится сталкиваться с Реактом (а приходится, к сожалению, довольно часто), я испытываю боль. Меня поймет любой, кто продвинулся в разработке чуть дальше среднестатистического хипстера, и для кого "состояние" компонента — это не только "пропсы со стейтом" но и кастомные табиндексы, положения каретки при вводе, тонкая оптимизация, кеширование, танцы с бубном вокруг CSS и многое другое, что требует знаний того, как работать с DOM. Для меня это не вопрос холивара или религии, это вопрос скорости: условно, то, что я сделаю на Реакте за день, без него я сделаю за пару часов.
SomeoneToIgnore
11.05.2018 09:21Пользуюсь второй версией, но, увы, не очень понимаю, что будет с третьей и стоит ли на неё переходить.
В Roadmap update они пишут, что начинают работу над библиотекой LitElement, которая является продолжателем идей Polymer и её будущим.
А в faq они вообще открытым текстом говорят, что стоит пользоваться LitElement и что, несмотря на то, что она всё ещё в разработке, они планируют выпустить её очень скоро.i360u Автор
11.05.2018 10:39+1lit-html — это, всего-навсего, тулза для преобразования темплейт-стринг в объекты DOM. Ее внедрение связано с тем, что при необходимости подключения всех зависимостей через ES-модули, разметка также переезжает в js. Мне самому сперва это показалось очень спорным и удручающим решением, но после того, как я в своих проектах вынес определения шаблонов в отдельные js-файлы и настроил синтаксис в VS Code для файлов *.tpl.js как HTML — все стало очень даже няшно. В итоге, у меня есть практически нативный html, отделенный от логики компонента, со всеми плюшками обработки строк в js, без каких-либо трудностей при последующей сборке через Webpack.
web_devel
11.05.2018 17:48+2Это не «всего-навсего тулза» и её внедрение связано не с этим.
Создавать элементы с разметкой в js в Polymer3 вы можете и без lit-html (собственно modulizer так и делает):
import {PolymerElement, html} from '@polymer/polymer/polymer-element.js' ... static get template() { return html`<p>You can use polymer binding here: [[someProp]]` } ...
Это JSX-like подход к перерендеру дома (без VDOM, основанный на template literals), в нём не работает стандартный биндинг:
import { LitElement, html } from '@polymer/lit-element'; ... _render({someProp}) { return html`<p>You cannot use polymer binding here, it's just template literal ${someProp}` } ...i360u Автор
11.05.2018 18:34Да, вы правы, что-то я ерунду сморозил. Lit — это про эффективное обновление DOM, без лишнего парсинга html и без изменения изначальной структуры элементов. Штука очень интересная, ее можно использовать и без Polymer.
justboris
12.05.2018 14:48Интересно получается. То есть "Реакт — это огромный, местами буквально монструозный, костыль над DOM", а аналогичное решение от авторов Polymer — "штука очень интересная".
А в чем именно разница? Что там, что там происходит сравнение и патчинг только изменившихся кусочков DOM. Но в React сравнение происходит в виртуальных JSON-структурах, а в lit-html используются реальные DOM-ноды. Эта идея не новая, но каких-то убер-преимуществ с скорости или чем-то еще не приносит (скорее даже наоборот), поэтому популярности так и не завоевала.
i360u Автор
12.05.2018 19:59Тут, говоря о "интересности", более или менее корректно будет сравнить lit-html с JSX/VDOM:
https://github.com/Polymer/lit-html#benefits-over-jsx И да, то что там (в React) что-то сравнивается "виртуально" никак не отменяет взаимодействия с реальным DOM, что должно наводить на определенную мысль.justboris
12.05.2018 21:12Почитал, интерересная информация.
Основным достоинством ставится то, что такой подход не требует предварительной компиляции, все производится в рантайме. Однако, очевидно, что лишние операции скажутся на скорости работы. Не все так однозначно.
Еще там есть довод, что не требуется специальных интеграций в редакторы и IDE. Но html внутри template strings не подсвечивается как html. Для более-менее больших шаблонов это может быть проблемой. И тут, внезапно, нужно ставить специальный плагин для lit-html.
никак не отменяет взаимодействия с реальным DOM, что должно наводить на определенную мысль.
На какую?
i360u Автор
13.05.2018 04:38Вы можете вынести строку с шаблоном в отдельный файл (что само по себе уже хорошо), что-то типа *.html.js и настроить стандартную подсветку HTML-синтаксиса для такого типа файлов: у вас будет все работать в вашей IDE, включая синтаксис CSS. В VS Code, к примеру, это делается так:
"files.associations": { "*.html.js": "html" },
На какую?
На такую, что все изменения в реальном DOM делаются через обычный DOM API, независимо от того, сколько слоев "магии" вы накрутите поверх и как вы это назовете в маркетинговых целях. Если ваш компонент при смене состояния либо входных данных будет изменять свою часть DOM эффективно (а это значит не вызывать каждый раз парсинг через innerHTML, не менять структуру и состав элементов, а взаимодействовать только со свойствами, атрибутами и стилями уже существующих, как и делает Lit) — то вам вообще не нужны никакие VDOM и lit-html, все и так будет быстро и красиво. Никаких "лишних" операций при этом вы не произведете (если, конечно, специально не постараетесь). Вера некоторых адептов React, в то, что VDOM — быстрее чем DOM, вызывает у меня приступы истерического хохота, потому как сравнивают они, на самом деле, VDOM + DOM с чистым DOM. И первое ну никак не может быть быстрее второго, потому как второе — неотъемлемая часть работы первого.
justboris
13.05.2018 12:21Понятно, но тема костыльности React и не-костыльности lit-html не раскрыта. Это все из-за того, что в lit-html используются DOM-ноды и HTMLTemplateElement, а в React все строится на JS-объектах, так?
i360u Автор
13.05.2018 12:39А я ведь и не писал нигде, что сравниваю React с lit-html, я сравнивал React с Polymer, причем именно в плане композиционной механики — организации модульной структуры приложения. В Polymer это реализуется за счет нативных API, в React — это мета-платформа, реализованная на js, поверх того-же DOM, с искаженным синтаксисом в JSX и кучей своих мета-платформенных нюансов, которые, зачастую, только существенно затрудняют работу при необходимости более низкоуровневого вмешательства в работу всей этой кухни.
fukkit
Вторая версия — ничего так, симпатишная.
А в 3.0 опять совместимость поломали?
i360u Автор
Дело в том, что почти все части набора спецификаций Web-components прижились и поддерживаются (либо начнут поддерживаться в самом ближайшем будущем, а пока сносно работают с полифиллами) всеми современными браузерами. Кроме — HTML-imports. С этим не задалось. Замена HTML-imports на ES-модули ломает совместимость, да. Но разработчики Polymer-a, сделали тулзу для миграции на новую версию https://github.com/Polymer/polymer-modulizer.
sshikov
Я кажется уже это писал, но не жалко и повторить — для меня замена HTML Imports на ES-модули автоматически означает нежелание пользоваться. О чем они думают — не понимаю.
i360u Автор
Пользоваться чем? Кому? Кто они?
sshikov
Нежелание пользоваться полимером с моей стороны. При этом версия 1 мне очень понравилась.
Они — это разработчики полимера. Им конечно наплевать, и тут уж ничего не поделать.
i360u Автор
А причем тут разработчики полимера? Тут дело в разработчиках браузеров, и в одной из спек, которую не удалось удалось пока продвинуть. Разработчики Полимера имеют дело с тем, что имеют, не смотря на свою крепкую дружбу с Chrome, стандарты им не подконтрольны. Не смотря на это, полимер ничего не теряет от этой замены, скорее наоборот становится ближе для основной массы разработчиков.
sshikov
Я понимаю, что они не свободны и все такое. Тем не менее, первый же полимер работал на основе HTML Imports, и при этом достаточно прилично.
А то что полимер стал ближе к основной массе — ну, это не факт, что хорошо. Было некоторое разнообразие, в том числе разнообразие подходов, а будет один ровный ландшафт. HTML Imports, в том числе, обеспечивали некоторые возможности по доставке — т.е. мы импортируем один HTML, а получаем в итоге набор много из чего, не связанный вообще говоря напрямую даже с custom elements.
justboris
А мне html-импорты наоборот сильнее всего не нравились.
Я когда-то написал переиспользуемый Polymer компонент. Очень было неудобно работать и их инструментами:
А теперь вроде как обычные ES-модули, которые понимаются webpack или другим современным бандлером. Плюс можно будет запускать эти модули под node.js и тестировать через JSDOM. Это позволит не запускать тяжелый браузер и выполнять тесты быстрее (но это не точно, только если полифиллы заработают).
sshikov
Ну, я могу предположить, что причина в том, что для вас webpack родной, и вам именно эти инструменты непривычны. У меня же база — скорее JavaEE, и для меня webpack такой же непривычный. При этом я написал несколько десятков полимер компонентов, вообще не пользуясь ни одним из перечисленных вами инструментов от гугля. А тот факт, что компонентов уже понаписали тьму, говорит в целом о том, что инструменты всех более-менее устраивали. Ну и судя по вашему комментарию, у вас претензии не к импортам, а больше к инструментам.
>как подключать не-UI библиотеки, а какую-то логику для работы с данными, например для запросов на сервер, тоже неясно
Таких примеров компонент тьма. У вас же компонет Яндекс карт? Ну так есть же гуглевские похожие, они подключают логику работы с rest сервисами карт, например. Этот пункт я честно говоря не понял.
Ну т.е., другими словами — через HTML Imports можно импортировать именно что голый HTML, содержащий внутри все что угодно, например статику, CSS, скрипты, фонты, в общем все, что бывает внутри. UI там необязателен.
И для того чтобы они работали, вообще не нужен javascript (при условии конечно, что это не полифил, а реализовано в браузере). При этом его предлагается заменить на ES-импорт. Ну т.е. я js отключил — импорты отвалились тоже?
>Плюс можно будет запускать эти модули под node.js и тестировать через JSDOM.
Ну хм. У меня нет и не было никакой nodejs вообще. Я не говорю, что это правильно — я говорю, что это был немного другой подход. Мне он нравился больше. А то что будет — будет как у всех.
justboris
Мимо. Первый коммит сделан в 2014 году, вебпак тогда только набирал обороты. А актуальными технологиями был gulp с плагинами.
Потом, когда пришел вебпак, и все начали использовать
require()илиimport, почувствовалось улучшение в процессах, все стало более упорядоченно. А vulcanize так и остался какой-то примочкой сбоку.А
window.customElements.define()у вас без javascript как вызовется?sshikov
>А window.customElements.define()
Я напомню — HTML Imports перпендикулярны кастомным элементам. Вы можете использовать первые и не применять вторые. Я говорил тут только про импорты.
justboris
А для чего еще можно использовать импорты?
Даже документация mdn затрудняется дать пример их использования.
Если у вас есть пример, покажите, интересно же.
sshikov
MDN? Так мозилловцы до сих пор и не реализовывали этот стандарт — у них видимо фантазии недостаточно, чтобы понять, что их use cases — это не все возможные use cases.
Мне не очень понятно, что вас смущает? Это именно импорт, только на уровне html — т.е. вы импортируете целиком документ, у которого может быть произвольной сложности структура. И любые ресурсы внутри в дополнение, от скриптов до фонтов. При этом он вполне себе может быть обработан на уровне сервера, т.е. упомянутый вами vulcanizer достаточно легко (я реально этого не делал, но архитектуру прикидывал) реализуется где-то в бэкенде, на чем угодно, потому что все что ему нужно — это парсить html, а не интерпретировать javascript, например, что несколько сложнее.
Я не говорю, что у этого решения нет недостатков по сравнению с ES модулями — наверное они есть, но я в данном случае как раз выступал за разнообразие подходов.
justboris
MDN пишется не только Мозиллой. Google и Microsoft тоже участвуют. Плюс можно присылать исправления самому. Но несмотря на это, никаких use-case-ов, кроме импорта Polymer-компонентов, так и не нашлось.
Разнообразие должно быть осмысленным. Нет смысла делать возможность, которая будет использоваться одним-единственным фреймворком, да и то не самым популярным.
sshikov
Понимаете, импорт полимер компонента — это вовсе даже не импорт полимер компонента. Это именно что импорт html, внутри которого разметка и скрипт, который совершенно случайно создает полимер компонент. Но иногда и не создает. Это совершенно реальный способ применения, я его десятки раз встречал внутри компонент. Т.е. оно пакуется в html import, а внутри никаких кастом элементов не содержит.
justboris
А расскажите об этом поподробнее. Что можно положить в import чтобы там не было никакого упоминания polymer?
sshikov
В спецификации HTML Imports как это ни удивительно, нет ни одного упоминания о полимере :)
Ну вот же, например, что далеко ходить: habr.com/post/230877
Да, компоненты — самое очевидное применение, но стандарт шире, чем оно.
justboris
Что стандарт, что статья по ссылке отвечают на вопрос "как?" но совсем не рассказывают "зачем?"
Именно из-за того, что они не решают никакой практичкеской задачи (кроме частного случая полимера), импорты и загнулись
sshikov
Импорт — это способ упаковки компонент (любого вида). Зачем компоненты? Это тривиальный вопрос, и его же можно задать и для ES Modules. Зачем какие-то модули, если можно весь скрипт засунуть внутрь страницы, inline?
Кстати говоря, все фреймворки типа commonjs почти всегда вынуждены решать задачу импорта шаблонов, изображений, стилей и пр. «не скриптов». При этом решают они ее намного более криво, нежели данная технология. Просто все привыкли.
Ну и насчет загнулись… я бы не делал таких выводов. Хром (в том числе андроид и ios) поддерживает по полной программе, а это значит, что поддержка в целом чрезвычайно велика. Собственно, одного примера youtube достаточно.
justboris
Это какая-то демагогия. Реального примера использования html-импортов тут нет. Ясно-понятно.
sshikov
Во-первых, я ничего и не обещал, ибо свои я вам показать не могу. И да, с самого начала это было высказано исключительно как мое собственное мнение, ничего больше. Пусть и подкрепленное большим опытом — но опытом достаточно далеким от современного веб мейнстрима. Если вы мнение от демагогии не отличаете — ничем не могу помочь.