Comments 36
А в 3.0 опять совместимость поломали?
Дело в том, что почти все части набора спецификаций Web-components прижились и поддерживаются (либо начнут поддерживаться в самом ближайшем будущем, а пока сносно работают с полифиллами) всеми современными браузерами. Кроме — HTML-imports. С этим не задалось. Замена HTML-imports на ES-модули ломает совместимость, да. Но разработчики Polymer-a, сделали тулзу для миграции на новую версию https://github.com/Polymer/polymer-modulizer.
Пользоваться чем? Кому? Кто они?
Они — это разработчики полимера. Им конечно наплевать, и тут уж ничего не поделать.
А причем тут разработчики полимера? Тут дело в разработчиках браузеров, и в одной из спек, которую не удалось удалось пока продвинуть. Разработчики Полимера имеют дело с тем, что имеют, не смотря на свою крепкую дружбу с Chrome, стандарты им не подконтрольны. Не смотря на это, полимер ничего не теряет от этой замены, скорее наоборот становится ближе для основной массы разработчиков.
А то что полимер стал ближе к основной массе — ну, это не факт, что хорошо. Было некоторое разнообразие, в том числе разнообразие подходов, а будет один ровный ландшафт. HTML Imports, в том числе, обеспечивали некоторые возможности по доставке — т.е. мы импортируем один HTML, а получаем в итоге набор много из чего, не связанный вообще говоря напрямую даже с custom elements.
А мне html-импорты наоборот сильнее всего не нравились.
Я когда-то написал переиспользуемый Polymer компонент. Очень было неудобно работать и их инструментами:
- для тестирования — свой велосипед web-component-tester
- для сборки — некий vuclanizer
- как проверить код компонентов через ESLint, я так и не понял
- как подключать не-UI библиотеки, а какую-то логику для работы с данными, например для запросов на сервер, тоже неясно
А теперь вроде как обычные ES-модули, которые понимаются webpack или другим современным бандлером. Плюс можно будет запускать эти модули под node.js и тестировать через JSDOM. Это позволит не запускать тяжелый браузер и выполнять тесты быстрее (но это не точно, только если полифиллы заработают).
>как подключать не-UI библиотеки, а какую-то логику для работы с данными, например для запросов на сервер, тоже неясно
Таких примеров компонент тьма. У вас же компонет Яндекс карт? Ну так есть же гуглевские похожие, они подключают логику работы с rest сервисами карт, например. Этот пункт я честно говоря не понял.
Ну т.е., другими словами — через HTML Imports можно импортировать именно что голый HTML, содержащий внутри все что угодно, например статику, CSS, скрипты, фонты, в общем все, что бывает внутри. UI там необязателен.
И для того чтобы они работали, вообще не нужен javascript (при условии конечно, что это не полифил, а реализовано в браузере). При этом его предлагается заменить на ES-импорт. Ну т.е. я js отключил — импорты отвалились тоже?
>Плюс можно будет запускать эти модули под node.js и тестировать через JSDOM.
Ну хм. У меня нет и не было никакой nodejs вообще. Я не говорю, что это правильно — я говорю, что это был немного другой подход. Мне он нравился больше. А то что будет — будет как у всех.
Ну, я могу предположить, что причина в том, что для вас webpack родной
Мимо. Первый коммит сделан в 2014 году, вебпак тогда только набирал обороты. А актуальными технологиями был gulp с плагинами.
Потом, когда пришел вебпак, и все начали использовать require() или import, почувствовалось улучшение в процессах, все стало более упорядоченно. А vulcanize так и остался какой-то примочкой сбоку.
И для того чтобы они работали, вообще не нужен javascript
А window.customElements.define() у вас без javascript как вызовется?
Я напомню — HTML Imports перпендикулярны кастомным элементам. Вы можете использовать первые и не применять вторые. Я говорил тут только про импорты.
А для чего еще можно использовать импорты?
Даже документация mdn затрудняется дать пример их использования.
Если у вас есть пример, покажите, интересно же.
Мне не очень понятно, что вас смущает? Это именно импорт, только на уровне html — т.е. вы импортируете целиком документ, у которого может быть произвольной сложности структура. И любые ресурсы внутри в дополнение, от скриптов до фонтов. При этом он вполне себе может быть обработан на уровне сервера, т.е. упомянутый вами vulcanizer достаточно легко (я реально этого не делал, но архитектуру прикидывал) реализуется где-то в бэкенде, на чем угодно, потому что все что ему нужно — это парсить html, а не интерпретировать javascript, например, что несколько сложнее.
Я не говорю, что у этого решения нет недостатков по сравнению с ES модулями — наверное они есть, но я в данном случае как раз выступал за разнообразие подходов.
MDN пишется не только Мозиллой. Google и Microsoft тоже участвуют. Плюс можно присылать исправления самому. Но несмотря на это, никаких use-case-ов, кроме импорта Polymer-компонентов, так и не нашлось.
я в данном случае как раз выступал за разнообразие подходов.
Разнообразие должно быть осмысленным. Нет смысла делать возможность, которая будет использоваться одним-единственным фреймворком, да и то не самым популярным.
А расскажите об этом поподробнее. Что можно положить в import чтобы там не было никакого упоминания polymer?
Ну вот же, например, что далеко ходить: habr.com/post/230877
Да, компоненты — самое очевидное применение, но стандарт шире, чем оно.
Что стандарт, что статья по ссылке отвечают на вопрос "как?" но совсем не рассказывают "зачем?"
Именно из-за того, что они не решают никакой практичкеской задачи (кроме частного случая полимера), импорты и загнулись
Кстати говоря, все фреймворки типа commonjs почти всегда вынуждены решать задачу импорта шаблонов, изображений, стилей и пр. «не скриптов». При этом решают они ее намного более криво, нежели данная технология. Просто все привыкли.
Ну и насчет загнулись… я бы не делал таких выводов. Хром (в том числе андроид и ios) поддерживает по полной программе, а это значит, что поддержка в целом чрезвычайно велика. Собственно, одного примера youtube достаточно.
Это какая-то демагогия. Реального примера использования html-импортов тут нет. Ясно-понятно.
В целом расстроен.
Реакт — это огромный, местами буквально монструозный, костыль над DOM. Полимер — это браузер + немного сахара поверх нативных спек. Не думаю что тут речь вообще идет о том, что кто-то кого-то догоняет, потому как Реакт, в данном аспекте — это прошлое, а Полимер и — будущее. Я поддерживаю свою собственную либу для работы с UI, которая концептуально очень похожа на новый Полимер, и я отлично вижу, что здесь главное даже не конкретная реализация, а фундамент на котором она основана — сама веб-платформа. Каждый раз, когда мне приходится сталкиваться с Реактом (а приходится, к сожалению, довольно часто), я испытываю боль. Меня поймет любой, кто продвинулся в разработке чуть дальше среднестатистического хипстера, и для кого "состояние" компонента — это не только "пропсы со стейтом" но и кастомные табиндексы, положения каретки при вводе, тонкая оптимизация, кеширование, танцы с бубном вокруг CSS и многое другое, что требует знаний того, как работать с DOM. Для меня это не вопрос холивара или религии, это вопрос скорости: условно, то, что я сделаю на Реакте за день, без него я сделаю за пару часов.
В Roadmap update они пишут, что начинают работу над библиотекой LitElement, которая является продолжателем идей Polymer и её будущим.
А в faq они вообще открытым текстом говорят, что стоит пользоваться LitElement и что, несмотря на то, что она всё ещё в разработке, они планируют выпустить её очень скоро.
lit-html — это, всего-навсего, тулза для преобразования темплейт-стринг в объекты DOM. Ее внедрение связано с тем, что при необходимости подключения всех зависимостей через ES-модули, разметка также переезжает в js. Мне самому сперва это показалось очень спорным и удручающим решением, но после того, как я в своих проектах вынес определения шаблонов в отдельные js-файлы и настроил синтаксис в VS Code для файлов *.tpl.js как HTML — все стало очень даже няшно. В итоге, у меня есть практически нативный html, отделенный от логики компонента, со всеми плюшками обработки строк в js, без каких-либо трудностей при последующей сборке через Webpack.
Создавать элементы с разметкой в 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}`
}
...
Да, вы правы, что-то я ерунду сморозил. Lit — это про эффективное обновление DOM, без лишнего парсинга html и без изменения изначальной структуры элементов. Штука очень интересная, ее можно использовать и без Polymer.
Интересно получается. То есть "Реакт — это огромный, местами буквально монструозный, костыль над DOM", а аналогичное решение от авторов Polymer — "штука очень интересная".
А в чем именно разница? Что там, что там происходит сравнение и патчинг только изменившихся кусочков DOM. Но в React сравнение происходит в виртуальных JSON-структурах, а в lit-html используются реальные DOM-ноды. Эта идея не новая, но каких-то убер-преимуществ с скорости или чем-то еще не приносит (скорее даже наоборот), поэтому популярности так и не завоевала.
Тут, говоря о "интересности", более или менее корректно будет сравнить lit-html с JSX/VDOM:
https://github.com/Polymer/lit-html#benefits-over-jsx И да, то что там (в React) что-то сравнивается "виртуально" никак не отменяет взаимодействия с реальным DOM, что должно наводить на определенную мысль.
Почитал, интерересная информация.
Основным достоинством ставится то, что такой подход не требует предварительной компиляции, все производится в рантайме. Однако, очевидно, что лишние операции скажутся на скорости работы. Не все так однозначно.
Еще там есть довод, что не требуется специальных интеграций в редакторы и IDE. Но html внутри template strings не подсвечивается как html. Для более-менее больших шаблонов это может быть проблемой. И тут, внезапно, нужно ставить специальный плагин для lit-html.
никак не отменяет взаимодействия с реальным DOM, что должно наводить на определенную мысль.
На какую?
Вы можете вынести строку с шаблоном в отдельный файл (что само по себе уже хорошо), что-то типа *.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. И первое ну никак не может быть быстрее второго, потому как второе — неотъемлемая часть работы первого.
Понятно, но тема костыльности React и не-костыльности lit-html не раскрыта. Это все из-за того, что в lit-html используются DOM-ноды и HTMLTemplateElement, а в React все строится на JS-объектах, так?
А я ведь и не писал нигде, что сравниваю React с lit-html, я сравнивал React с Polymer, причем именно в плане композиционной механики — организации модульной структуры приложения. В Polymer это реализуется за счет нативных API, в React — это мета-платформа, реализованная на js, поверх того-же DOM, с искаженным синтаксисом в JSX и кучей своих мета-платформенных нюансов, которые, зачастую, только существенно затрудняют работу при необходимости более низкоуровневого вмешательства в работу всей этой кухни.
Понятно, то есть вам важно, чтобы в маркетинге фреймворка звучала фраза "мы нативные". А то что для этой "нативности" там используется наколеночный парсер html, а для дата-байндинга вставляются магические строки, которые потом ищутся регулярками — это неважно, да?
Я предпочитаю не принимать маркетинг на конференциях и в readme-файлах, а смотреть, как оно там устроено в самом деле. Чего и вам желаю.
Послушайте, я уж и не знаю какими словами еще написать, чтобы наконец стало понятно: Polymer != lit-html, я же вроде уже несколько раз уточнил что и с чем я сравниваю. Когда я говорю о нативности, я говорю о Custom Elements прежде всего. Зачем вы мне приводите ссылки на код lit? Эта штука даже не production ready еще, о чем разработчики пишут сразу. И если вы такой молодец, что смотрите как оно там устроено, посмотрите как устроен текущий Polymer, чтобы не плавать так в теме.
Polymer 3.0 на Google I/O 2018