Polymer 3.0 на Google I/O 2018

    Всем привет!


    В данный момент, как многие знают, проходит ежегодная конференция Google I/O, в рамках которой была представлена новая версия библиотеки для работы с интерфейсами веб-приложений Polymer 3.0 (видео на английском):



    Основные нововведения:


    1. Отказ от использования HTML-imports в пользу ES-modules
    2. Отказ от использования Bower в пользу npm
    3. Вынос полифиллов для поддержки новых стандартов (требуются для 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-платформы и многое опробовал в боевых условиях реальных проектов. В течении всего этого времени, я регулярно встречаю различные мнения о данной технологии, как среди отечественных разработчиков, так и среди наших иностранных коллег. И мнения эти, в удручающем большинстве случаев, либо очень поверхностны, либо глубоко ошибочны. Я призываю сообщество к непредвзятому взгляду на данный стек, к пересмотру и обновлению своих знаний. Поверьте, это того стоит.

    Средняя зарплата в IT

    110 000 ₽/мес.
    Средняя зарплата по всем IT-специализациям на основании 8 477 анкет, за 2-ое пол. 2020 года Узнать свою зарплату
    Реклама
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее

    Комментарии 36

      0
      Вторая версия — ничего так, симпатишная.
      А в 3.0 опять совместимость поломали?
        +1

        Дело в том, что почти все части набора спецификаций Web-components прижились и поддерживаются (либо начнут поддерживаться в самом ближайшем будущем, а пока сносно работают с полифиллами) всеми современными браузерами. Кроме — HTML-imports. С этим не задалось. Замена HTML-imports на ES-модули ломает совместимость, да. Но разработчики Polymer-a, сделали тулзу для миграции на новую версию https://github.com/Polymer/polymer-modulizer.

          –4
          Я кажется уже это писал, но не жалко и повторить — для меня замена HTML Imports на ES-модули автоматически означает нежелание пользоваться. О чем они думают — не понимаю.
            0

            Пользоваться чем? Кому? Кто они?

              0
              Нежелание пользоваться полимером с моей стороны. При этом версия 1 мне очень понравилась.

              Они — это разработчики полимера. Им конечно наплевать, и тут уж ничего не поделать.
                +2

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

                  0
                  Я понимаю, что они не свободны и все такое. Тем не менее, первый же полимер работал на основе HTML Imports, и при этом достаточно прилично.

                  А то что полимер стал ближе к основной массе — ну, это не факт, что хорошо. Было некоторое разнообразие, в том числе разнообразие подходов, а будет один ровный ландшафт. HTML Imports, в том числе, обеспечивали некоторые возможности по доставке — т.е. мы импортируем один HTML, а получаем в итоге набор много из чего, не связанный вообще говоря напрямую даже с custom elements.
                    +4

                    А мне html-импорты наоборот сильнее всего не нравились.


                    Я когда-то написал переиспользуемый Polymer компонент. Очень было неудобно работать и их инструментами:


                    • для тестирования — свой велосипед web-component-tester
                    • для сборки — некий vuclanizer
                    • как проверить код компонентов через ESLint, я так и не понял
                    • как подключать не-UI библиотеки, а какую-то логику для работы с данными, например для запросов на сервер, тоже неясно

                    А теперь вроде как обычные ES-модули, которые понимаются webpack или другим современным бандлером. Плюс можно будет запускать эти модули под node.js и тестировать через JSDOM. Это позволит не запускать тяжелый браузер и выполнять тесты быстрее (но это не точно, только если полифиллы заработают).

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

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

                      Таких примеров компонент тьма. У вас же компонет Яндекс карт? Ну так есть же гуглевские похожие, они подключают логику работы с rest сервисами карт, например. Этот пункт я честно говоря не понял.

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

                      И для того чтобы они работали, вообще не нужен javascript (при условии конечно, что это не полифил, а реализовано в браузере). При этом его предлагается заменить на ES-импорт. Ну т.е. я js отключил — импорты отвалились тоже?

                      >Плюс можно будет запускать эти модули под node.js и тестировать через JSDOM.

                      Ну хм. У меня нет и не было никакой nodejs вообще. Я не говорю, что это правильно — я говорю, что это был немного другой подход. Мне он нравился больше. А то что будет — будет как у всех.
                        0
                        Ну, я могу предположить, что причина в том, что для вас webpack родной

                        Мимо. Первый коммит сделан в 2014 году, вебпак тогда только набирал обороты. А актуальными технологиями был gulp с плагинами.


                        Потом, когда пришел вебпак, и все начали использовать require() или import, почувствовалось улучшение в процессах, все стало более упорядоченно. А vulcanize так и остался какой-то примочкой сбоку.


                        И для того чтобы они работали, вообще не нужен javascript

                        А window.customElements.define() у вас без javascript как вызовется?

                          +1
                          >А window.customElements.define()

                          Я напомню — HTML Imports перпендикулярны кастомным элементам. Вы можете использовать первые и не применять вторые. Я говорил тут только про импорты.
                            0

                            А для чего еще можно использовать импорты?


                            Даже документация mdn затрудняется дать пример их использования.


                            Если у вас есть пример, покажите, интересно же.

                              0
                              MDN? Так мозилловцы до сих пор и не реализовывали этот стандарт — у них видимо фантазии недостаточно, чтобы понять, что их use cases — это не все возможные use cases.

                              Мне не очень понятно, что вас смущает? Это именно импорт, только на уровне html — т.е. вы импортируете целиком документ, у которого может быть произвольной сложности структура. И любые ресурсы внутри в дополнение, от скриптов до фонтов. При этом он вполне себе может быть обработан на уровне сервера, т.е. упомянутый вами vulcanizer достаточно легко (я реально этого не делал, но архитектуру прикидывал) реализуется где-то в бэкенде, на чем угодно, потому что все что ему нужно — это парсить html, а не интерпретировать javascript, например, что несколько сложнее.

                              Я не говорю, что у этого решения нет недостатков по сравнению с ES модулями — наверное они есть, но я в данном случае как раз выступал за разнообразие подходов.
                                0

                                MDN пишется не только Мозиллой. Google и Microsoft тоже участвуют. Плюс можно присылать исправления самому. Но несмотря на это, никаких use-case-ов, кроме импорта Polymer-компонентов, так и не нашлось.


                                я в данном случае как раз выступал за разнообразие подходов.

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

                                  0
                                  Понимаете, импорт полимер компонента — это вовсе даже не импорт полимер компонента. Это именно что импорт html, внутри которого разметка и скрипт, который совершенно случайно создает полимер компонент. Но иногда и не создает. Это совершенно реальный способ применения, я его десятки раз встречал внутри компонент. Т.е. оно пакуется в html import, а внутри никаких кастом элементов не содержит.
                                    0

                                    А расскажите об этом поподробнее. Что можно положить в import чтобы там не было никакого упоминания polymer?

                                      0
                                      В спецификации HTML Imports как это ни удивительно, нет ни одного упоминания о полимере :)

                                      Ну вот же, например, что далеко ходить: habr.com/post/230877

                                      Да, компоненты — самое очевидное применение, но стандарт шире, чем оно.
                                        0

                                        Что стандарт, что статья по ссылке отвечают на вопрос "как?" но совсем не рассказывают "зачем?"


                                        Именно из-за того, что они не решают никакой практичкеской задачи (кроме частного случая полимера), импорты и загнулись

                                          0
                                          Импорт — это способ упаковки компонент (любого вида). Зачем компоненты? Это тривиальный вопрос, и его же можно задать и для ES Modules. Зачем какие-то модули, если можно весь скрипт засунуть внутрь страницы, inline?

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

                                          Ну и насчет загнулись… я бы не делал таких выводов. Хром (в том числе андроид и ios) поддерживает по полной программе, а это значит, что поддержка в целом чрезвычайно велика. Собственно, одного примера youtube достаточно.
                                            0

                                            Это какая-то демагогия. Реального примера использования html-импортов тут нет. Ясно-понятно.

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

                                                Ну ладно, будут примеры — дайте знать. Мне интересно выслушивать и собирать разные юз-кейсы.


                                                А пока — спецификация хоронится по причине отсутствия спроса.

        –1
        ИМХО догоняют Реакт. Надо ли? Смогут ли?
        В целом расстроен.
          +3

          Реакт — это огромный, местами буквально монструозный, костыль над DOM. Полимер — это браузер + немного сахара поверх нативных спек. Не думаю что тут речь вообще идет о том, что кто-то кого-то догоняет, потому как Реакт, в данном аспекте — это прошлое, а Полимер и — будущее. Я поддерживаю свою собственную либу для работы с UI, которая концептуально очень похожа на новый Полимер, и я отлично вижу, что здесь главное даже не конкретная реализация, а фундамент на котором она основана — сама веб-платформа. Каждый раз, когда мне приходится сталкиваться с Реактом (а приходится, к сожалению, довольно часто), я испытываю боль. Меня поймет любой, кто продвинулся в разработке чуть дальше среднестатистического хипстера, и для кого "состояние" компонента — это не только "пропсы со стейтом" но и кастомные табиндексы, положения каретки при вводе, тонкая оптимизация, кеширование, танцы с бубном вокруг CSS и многое другое, что требует знаний того, как работать с DOM. Для меня это не вопрос холивара или религии, это вопрос скорости: условно, то, что я сделаю на Реакте за день, без него я сделаю за пару часов.

          0
          Пользуюсь второй версией, но, увы, не очень понимаю, что будет с третьей и стоит ли на неё переходить.
          В Roadmap update они пишут, что начинают работу над библиотекой LitElement, которая является продолжателем идей Polymer и её будущим.

          А в faq они вообще открытым текстом говорят, что стоит пользоваться LitElement и что, несмотря на то, что она всё ещё в разработке, они планируют выпустить её очень скоро.
            +1

            lit-html — это, всего-навсего, тулза для преобразования темплейт-стринг в объекты DOM. Ее внедрение связано с тем, что при необходимости подключения всех зависимостей через ES-модули, разметка также переезжает в js. Мне самому сперва это показалось очень спорным и удручающим решением, но после того, как я в своих проектах вынес определения шаблонов в отдельные js-файлы и настроил синтаксис в VS Code для файлов *.tpl.js как HTML — все стало очень даже няшно. В итоге, у меня есть практически нативный html, отделенный от логики компонента, со всеми плюшками обработки строк в js, без каких-либо трудностей при последующей сборке через Webpack.

              +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}`
                }
              ...
              
                +1

                Да, вы правы, что-то я ерунду сморозил. Lit — это про эффективное обновление DOM, без лишнего парсинга html и без изменения изначальной структуры элементов. Штука очень интересная, ее можно использовать и без Polymer.

                  0

                  Интересно получается. То есть "Реакт — это огромный, местами буквально монструозный, костыль над DOM", а аналогичное решение от авторов Polymer — "штука очень интересная".


                  А в чем именно разница? Что там, что там происходит сравнение и патчинг только изменившихся кусочков DOM. Но в React сравнение происходит в виртуальных JSON-структурах, а в lit-html используются реальные DOM-ноды. Эта идея не новая, но каких-то убер-преимуществ с скорости или чем-то еще не приносит (скорее даже наоборот), поэтому популярности так и не завоевала.

                    0

                    Тут, говоря о "интересности", более или менее корректно будет сравнить lit-html с JSX/VDOM:
                    https://github.com/Polymer/lit-html#benefits-over-jsx И да, то что там (в React) что-то сравнивается "виртуально" никак не отменяет взаимодействия с реальным DOM, что должно наводить на определенную мысль.

                      0

                      Почитал, интерересная информация.


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


                      Еще там есть довод, что не требуется специальных интеграций в редакторы и IDE. Но html внутри template strings не подсвечивается как html. Для более-менее больших шаблонов это может быть проблемой. И тут, внезапно, нужно ставить специальный плагин для lit-html.


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

                      На какую?

                        +1

                        Вы можете вынести строку с шаблоном в отдельный файл (что само по себе уже хорошо), что-то типа *.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. И первое ну никак не может быть быстрее второго, потому как второе — неотъемлемая часть работы первого.

                          0

                          Понятно, но тема костыльности React и не-костыльности lit-html не раскрыта. Это все из-за того, что в lit-html используются DOM-ноды и HTMLTemplateElement, а в React все строится на JS-объектах, так?

                            +1

                            А я ведь и не писал нигде, что сравниваю React с lit-html, я сравнивал React с Polymer, причем именно в плане композиционной механики — организации модульной структуры приложения. В Polymer это реализуется за счет нативных API, в React — это мета-платформа, реализованная на js, поверх того-же DOM, с искаженным синтаксисом в JSX и кучей своих мета-платформенных нюансов, которые, зачастую, только существенно затрудняют работу при необходимости более низкоуровневого вмешательства в работу всей этой кухни.

                              0

                              Понятно, то есть вам важно, чтобы в маркетинге фреймворка звучала фраза "мы нативные". А то что для этой "нативности" там используется наколеночный парсер html, а для дата-байндинга вставляются магические строки, которые потом ищутся регулярками — это неважно, да?


                              Я предпочитаю не принимать маркетинг на конференциях и в readme-файлах, а смотреть, как оно там устроено в самом деле. Чего и вам желаю.

                                +1

                                Послушайте, я уж и не знаю какими словами еще написать, чтобы наконец стало понятно: Polymer != lit-html, я же вроде уже несколько раз уточнил что и с чем я сравниваю. Когда я говорю о нативности, я говорю о Custom Elements прежде всего. Зачем вы мне приводите ссылки на код lit? Эта штука даже не production ready еще, о чем разработчики пишут сразу. И если вы такой молодец, что смотрите как оно там устроено, посмотрите как устроен текущий Polymer, чтобы не плавать так в теме.

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

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