Polymer 3.0 на Google I/O 2018 +6



Всем привет!


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

Вы можете помочь и перевести немного средств на развитие сайта



Комментарии (33):

  1. fukkit
    /#11346762

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

    • i360u
      /#11346832 / +1

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

      • sshikov
        /#11347044 / -3

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

        • i360u
          /#11347084

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

          • sshikov
            /#11347090

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

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

            • i360u
              /#11347102 / +1

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

              • sshikov
                /#11347124

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

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

                • justboris
                  /#11347152

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


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


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

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

                  • sshikov
                    /#11347168

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

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

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

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

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

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

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

                    • justboris
                      /#11347182

                      Ну, я могу предположить, что причина в том, что для вас webpack родной

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


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


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

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

                      • sshikov
                        /#11351302 / +1

                        >А window.customElements.define()

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

                        • justboris
                          /#11352624

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


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


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

                          • sshikov
                            /#11352866

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

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

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

                            • justboris
                              /#11352894

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


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

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

                              • sshikov
                                /#11352902

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

                                • justboris
                                  /#11352942

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

                                  • sshikov
                                    /#11352952

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

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

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

                                    • justboris
                                      /#11353008

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


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

                                      • sshikov
                                        /#11353132

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

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

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

                                        • justboris
                                          /#11353234

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

                                          • sshikov
                                            /#11353762

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

  2. vdonich
    /#11347160

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

    • i360u
      /#11347590

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

  3. SomeoneToIgnore
    /#11347544

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

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

    • i360u
      /#11347698 / +1

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

      • web_devel
        /#11351082 / +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
          /#11351180

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

          • justboris
            /#11352652

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


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

            • i360u
              /#11352944

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

              • justboris
                /#11353032

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


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


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


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

                На какую?

                • i360u
                  /#11353278

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

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

                    • i360u
                      /#11353472

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