Веб-компоненты и открытые стандарты


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


    • Это веб-стандарт, сделанный открытым сообществом, а не какой-то частной компанией
    • Веб-стандарты не ломают обратную совместимость, не придется переживать за свой код в будущем
    • Все современные браузеры придерживаются стандарта в своем поведении, меньше сюрпризов на кросс-браузерном тестировании

    Аргументы выглядят логичными и справедливыми в обычной ситуации, но в случае веб-компонентов есть нюансы, которые я попробую раскрыть в этой статье.


    Открытый стандарт


    Открытость стандарта подразумевает то, что он написан с привлечением разных заинтересованных сторон. В результате получается удовлетворяющий всех результат. Что же произошло в этом случае? Открываем документ и видим его авторов


    • Dimitri Glazkov, Google
    • Hayato Ito, Google
    • Dominic Cooney, Google

    Все они работают в Гугле. Аналогичная ситуация и в истории коммитов в этот репозиторий. Попробуйте на графике контрибьюторов найти человека не из Гугла. В первой пятерке таких точно нет.


    Получается, что этот стандарт написан почти на 100% в Гугле. Но, может быть, у сообщества была возможность высказать свои пожелания и они были услышаны? Давайте рассмотрим несколько примеров.


    Глобальный реестр компонентов


    Избегание глобальных сущностей является одним из важных аспектов дизайна масштабируемых систем. На эти грабли веб-разработка уже наступала в CSS, где любой класс применяется глобально ко всей странице. Веб-компоненты попытались починить это через Shadow DOM, но тут же сломали в другом месте, добавив глобальный реестр компонентов. Каждый компонент должен иметь уникальное имя, а если встретится дубликат, то выбросится исключение, и весь Javascript перестанет работать, если его не завернуть в try/catch.


    Эту проблему зарепортил пользователь, но один из авторов стандарта ответил что проблемы никакой нет и закрыл тикет.


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


    Таким образом, спустя 6 лет после первоначальной публикации стандарта, мы все еще имеем проблему, которая должна была бы выявиться еще на первоначальном ревью. Хотя какое тут ревью, сотрудникам Гугла виднее, как именно нам будет хорошо.


    Расширение нативных элементов


    Возможно, Гугл игнорирует пожелания рядовых разработчиков, но прислушивается к разработчикам других браузерных движков? Они же все на общее дело работают. Но здесь тоже не все гладко.


    Веб-компоненты предусматривают возможность расширения нативных элементов. Например, вы можете навесить дополнительную функциональность на тэг <button> при помощи такого кода:


    customElements.define('cool-button', CoolButton, { extends: 'button' });

    Этот код работает во всех современных браузерах, но не в Safari. Вот заявление разработчика webkit что они считают эту фичу хаком, вредящим будущему веба, и отказываются его поддерживать. В качестве альтернативы они выступают за поддержку custom-attributes по аналогии с custom-elements, но до стандарта этому предложению еще далеко.


    Firefox тоже упоминает эту фичу в своем обзоре веб-компонентов (секция is=””) и показывает что у этой фичи больше минусов, чем плюсов


    Тем не менее этот синтаксис все-таки попал в финальный стандарт, хоть не работает и никогда не будет в одном из трех основных браузеров, и тем самым опровергает правило "то что есть в стандарте, будет поддержано браузерами, рано или поздно"


    Стабильность стандартов


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


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


    Однако разработчики Firefox выступили против этой фичи. По их мнению, в это время уже были на подходе Javascript-модули и ещё один лишний механизм импорта в стандартах ни к чему.


    В результате фича так и не дошла до финального стандарта, но ее реализация уже была добавлена в Chrome, и Google уже выпустил фреймворк Polymer, который на этот потенциальный стандарт опирался. В результате создатели Polymer были вынуждены переписать свой фреймворк без использования HTML-импортов, а пользователям этого фреймворка пришлось столкнуться с уникальным событием – необходимостью съезжать с устаревшего веб-стандарта.


    Здесь еще можно вспомнить значительное переписывание стандарта Shadow DOM, когда внезапно оказалось, что написанная Гуглом версия стандарта не устраивает остальных вендоров.


    Таким образом, и принцип "стандарт – гарант стабильности" с веб-компонентами не сработал.


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


    Псевдо-стандарты


    К сожалению, Гугл так и не вынес ничего полезного из урока переписывания ранних стандартов Shadow DOM v0 и наступает на те же грабли еще раз.


    В этот раз речь об adoptedStylesheets. Маркетинговая статья красиво рассказывает о пользе этой новой фичи. При этом там умалчивается, что это никакой не стандарт, и поведение этой функциональности ни с кем не обсуждалось. Есть ссылка на псевдо-спецификацию, но при внимательном взгляде можно заметить, что никакая это не спецификация, а "Collection of Interesting Ideas" – то есть этот документ даже не дошел до Editor Draft – начальной стадии на пути в веб-стандарт.


    Закономерным образом, при обсуждении этой спецификации с сообществом, вылезли недостатки дизайна. Но гуглеры не сдаются и призывают оставить поведение как есть, мотивируя это тем, что пользователи уже пользуются фичей в продакшене. В итоге получается такая ситуация:


    1. Гугл выкатывает в свой браузер фичу, ни с кем не посоветовавшись
    2. Затем выпускает фреймворк с использованием этой фичи и рекламирует его как production-ready
    3. Наивные пользователи начали пользоваться этим фреймворком, и теперь Гугл использует их в качестве аргумента чтобы оставить косячный стандарт как есть.

    Это не было бы так плохо, будь это единичный случай, но у Гугла есть целая организация с подобными псевдо-стандартами на Github: https://github.com/wicg. Неопытные пользователи могут подумать, что это еще одна организация наподобие WHATWG или W3C, но нет, WCIG это такой своеобразный клуб по интересам:


    Community Groups are proposed and run by the community. Although W3C hosts these conversations, the groups do not necessarily represent the views of the W3C Membership or staff.

    Вольный перевод:


    Эта группа управляется сообществом. Несмотря на то что эти дискуссии проходят в рамках W3C, они не обязательно представляют взгляды членов W3C.

    Таким образом, если вы видите очередной анонс нового "стандарта" от Гугла, советую проверять, откуда он исходит, и был ли там фидбек от других разработчиков браузеров.


    Гугл оказывает очень большое давление на стандарты и вносит туда много разных фич. Не все браузеры способны поспевать за этим темпом и выбывают из борьбы. Сначала сошла с дистанции Opera и перешла на Chromium, теперь Edge. Эта ситуация развязывает руки Гуглу и позволяет добавлять в браузеры фичи, не советуясь ни с кем. В результате мы видим красивую картинку на caniuse, где 3 из 6 браузеров поддерживают некоторую фичу, в то время как Mozilla отмечает ее как вредную, поскольку она открывает возможность утечки данных пользователей.


    Выводы


    Надеюсь, эта статья позволит принять вам информированное решение об использовании веб-технологий. Статья выражает исключительно мое личное мнение, но содержит достаточно ссылок на источники, чтобы каждый смог их прочесть и составить своё собственное.


    Если после всего этого вы все еще считаете веб-компоненты хорошим решением для вашего проекта, это замечательно. Но если единственным аргументом "за" был "ну это же веб-стандарт, они не могут ошибаться", то лучше пересмотреть свои выводы и перестать кушать этот кактус.

    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

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

      +28

      Гугл делает то же самое, что делал Майкрософт во времена доминирования IE. Ничего нового.

        +4

        Все так, не первый раз такая ситуация случается. Но это же не значит, что по-другому быть не может.


        Например, в WebAssembly или TC39 более сбалансированный состав участников, и там обходится без таких масштабных драм

          +3
          Какая плохая Майкрософт, проталкивала полезные фичи, которыми сейчас все пользуются.
          Или вы не хотите вспомнить, что тогда никаких комитетов по стандартизации не было, а сейчас есть? А в статье как раз о чем говориться?
            +6

            А решение, когда NodeList — это «живая» коллекция, то есть реагирует на изменения DOM?


            Кстати, W3C был основан в 1994 году. IE 1 вышел в 1995 году. HTML был стандартизован W3C в 1995 году. Так что утверждение, что тогда никаких комитетов не было — ложно.

              +6

              Я слишком хорошо помню, как Microsoft плевала на все стандарты. В случае с тем же IE6 (а это не единственный пример), это стоило человечеству миллионы человеко-часов по всему миру. Все веб-разработчики десятилетие рвали волосы на всех частях тела, пока это поделие не сгинуло. С тех пор для меня Internet Explorer — синоним софта ужасающе низкого качества.

              +13
              недавно пролетала статья. мелкософт добавляла в IE кучу технологий (архитектура которых хромала), которые нужны были ей самой, например для outlook, ни с кем не советовавшись, а потом пыталась пропихнуть это как стандарт. теперь вот похожим занимается google — запилила WC для youtube (кстати, сайт тоже фактически монополист).
                0
                Стоп, AJAX ненужная вещь? к примеру.
                  +2

                  Вещь нужная, как и векторная графика (VML/SVG), как и css-градиенты, но реализация хромает. Поэтому веб-браузеры все реализуют все эти нужные фичи, но уже более человечески.

                    +12

                    var xhr = new ActiveXObject("Microsoft.XMLHTTP");
                    Как-то, не кроссбраузерно в реализации Microsoft.

                      0
                      Стоп, AJAX ненужная вещь? к примеру.

                      не стоит так обобщать. :) кое-что взлетело и позже таки было стандартизировано. кстати, по этой причине в XHR есть странноватые решения.
                        +1

                        Тут бы список этих странностей. Ибо большинство годами не используют xhr на прямую.

                          0
                          например нет состояния sended. после opened идет headers_received.

                          про странное название и так все знают.
                  +3
                  Открытость стандарта подразумевает то, что он написан с привлечением разных заинтересованных сторон.

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

                    +4

                    Предположу, что имелась ввиду не только иметь доступ на чтение, но и возможность вносить предложения, которая фактически доступна только сотрудникам Гугла.

                      0
                      Пример автора о глобальном регистре, например, не выдерживает никакой критики. Предложение о не-глобальном регистре от стороннего человека было закрыто не потому, что он не из гугла, а потому, что предложенная идея не реализуема на практике. И в issue есть подробное описание, почему именно.
                      Равно как и второе предложение (от гугла) не было закрыто потому, что оно гораздо проще и вполне реализуемо.
                    0

                    Тут главным словом всё же является «стандарт». Имеется в виду, что стандарт называется открытым, когда он доступен для всех (открытый) и все заинтересованные стороны договорились об его использовании (стандарт). Собственно, именно за это идёт борьба последние 20 лет, и так развивается веб.

                    +1
                    Аргументы выглядят логичными и справедливыми в обычной ситуации, но в случае веб-компонентов есть нюансы, которые я попробую раскрыть в этой статье.

                    На всякий случай, эти «нюансы» сопровождают практически все стандарты W3C, не важно, проталкивает ли их гугл, майкрософт, или вообще никто (потому что неидеальность идей, которые поначалу кажутся здравыми — никто не отменял).
                    И придираться конкретно к веб-компонентам и к гуглу тут бессмысленно. Примерно такой же толщины статью можно накатать, например, про svg, про новые версии css, и вообще практически про любой нужный стандарт.

                    Ах бедные разработчики и пользователи polymer, подло подбитые коварными бизнес-практиками гугля. Ах, им пришлось выкашивать не прижившийся bleeding edge из кода. А когда люди в поздних нулевых бегали между неоднозначностями имплементации svg, или же слезали с флеша, потому что дальше терпеть это уже было нельзя — это древняя история и никогда такого не было.
                    Когда речь идёт об открытых стандартах, затрагивающих интересы многих участников — так будет всегда. И у вас всегда есть выбор — можно просто не использовать ничего из новых стандартов. jQuery и штуки типа ExtJS работают прекрасно по сей день, примерно в любом браузере, и очень эффективно.
                      +4
                      Хм, ситуация c HTML-imports, как раз, ярко показывает, что Гугл далеко не всесилен в вопросе стандартов и сообщество еще как влияет на то, что мы получаем в итоге. Черновики и версия v0 долго обсуждались сообществом, и если авторы предложений из Гугла, это совсем не значит, что принимали стандарт тоже они самолично. Также, алармистская позиция по поводу того, что все браузеры переезжают на Chromium, имхо, не очень крепкие основания под собой имеет, так как Chromium — это open source (в отличие от IE), и тот же Microsoft, принимая теперь активное участие в его разработке (как и еще куча народа), уже вносит свое альтернативное видение в общее дело. Я не буду утверждать, что все гладко, но лучше такой путь вперед, чем застой для платформы, перед которой время ставит новые требования.

                      Над неймспейсами для веб-компонентов, кстати, ведется работа.
                        +5
                        Черновики и версия v0 долго обсуждались сообществом, и если авторы предложений из Гугла, это совсем не значит, что принимали стандарт тоже они самолично

                        Shadow DOM v0 не был реализован ни в одном браузере за пределами Blink (Chromium). В этом и проблема, Гугл сначала релизит сырую версию стандарта в своем браузере, а потом уже занимается её согласованием. Свежий пример с adoptedStylesheets это еще раз подтверждает. Хотя в нормальном мире это происходит наоборот (смотрим на TC39, где до браузеров добираются только stage-3 фичи).


                        Также, алармистская позиция по поводу того, что все браузеры переезжают на Chromium, имхо, не очень крепкие основания под собой имеет.

                        Opera уже 7 лет как живет на Chromium и как-то особо себя никак не проявила. Разве что в помощи Гуглу в виде аппруверов для фичи, по которой у Mozilla было еще много вопросов. Возможно, у Microsoft получится лучше, но изначально ситуация не очень позитивная. Хотя бы потому что они не смогут больше сыграть карту "мы отказываемся это поддерживать", которой воспользовались в Webkit в истории с element is=""


                        Над неймспейсами для веб-компонентов, кстати, ведется работа.

                        Интересно, а где об этом можно узнать побольше?

                          +1
                          Shadow DOM v0 не был реализован ни в одном браузере за пределами Blink

                          Это не так, была реализация в Firefox. Причем они пытались сделать это по своему, и один и тот-же код работал в FF и Chrome сильно по разному.

                          В этом и проблема, Гугл сначала релизит сырую версию стандарта в своем браузере, а потом уже занимается её согласованием.

                          Это не проблема, это фича: она позволяет бОльшему количеству разработчиков все попробовать и вернуть фидбэк ДО окончательного принятия стандарта.

                          Opera уже 7 лет как живет на Chromium и как-то особо себя никак не проявила.

                          Это не так:

                          Интересно, а где об этом можно узнать побольше?

                            +2

                            По информации на caniuse, v0 спецификация в Firefox была за флагом, как и подобает не стандартизованной технологии.


                            Это не проблема, это фича: она позволяет бОльшему количеству разработчиков все попробовать и вернуть фидбэк ДО окончательного принятия стандарта.

                            Для этой фичи придумали флаги и canary браузеры. Добавление несогласованной фичи в стабильный релиз браузера, да еще и выпуск фреймворка на ее основе (Polymer и lit-element) – это уже авантюра


                            Opera уже 7 лет как живет на Chromium и как-то особо себя никак не проявила.
                            Это не так

                            Я там вижу только улучшения производительности и рефакторинги. А добавления чего-то значительного, сравнимого по масштабу, например, с shadow-dom или service-workers там нет, Гугл держит ключевые фичи под своим контролем.


                            Над неймспейсами для веб-компонентов, кстати, ведется работа.
                            github.com/w3c/webcomponents/issues/716

                            Ссылка на этот тикет у меня есть в статье. "Ведется работа" – это громко сказано, скорее там рефлексируют на тему, что они наделали со стандартом, и как теперь в него добавить эту фичу и ничего при этом не сломать.

                              0
                              То есть проблема не в самих фактах, а Вашем личном к ним отношении. Вы даете оценку технологии на основе субъективного восприятия того, как правильно и насколько чей вклад значимый и какая активность достаточна. А я вот считаю, что флаги — это зло, и что лучше двигаться вперед в отношении важных нововведений, чем вечно обсуждать что-то в закрытом клубе для избранных. Гугл вытащили этот вопрос из тени, и многое сделали для внедрения полезных фич. Я не фанат Гугла, и не готов выступать адвокатом за все их косяки, но вот именно за веб-компоненты — я им очень благодарен.
                                +3

                                Если вам зашли веб-компоненты, очень рад за вас. Я тоже всё жду задачи, для которой они идеально подойдут, но как-то пока не случилось.


                                Основная цель статьи – разрушить миф о том, что веб-компоненты являются стандартом в смысле консенсуса веб-разработчиков и создателей браузера. Это еще один фреймворк, для которого Гугл смог пролоббировать предустановку в браузеры.

                                  0
                                  Вы ничего не разрушили, ибо разрушать было нечего. Позвольте мне ретроспективно резюмировать:

                                  — Вы делаете утверждение в статье, о том, что Гугл, пользуясь доминирующим положением на рынке, протолкнул в стандарты выгодную им фичу, проигнорировав сообщество

                                  — Я вам пишу, что часть предложенной спецификации так и не была принята (HTML imports), именно из-за противодействия сообщества. То есть, принятая в стандарт спецификация не является, априори, единоличным вкладом Гугл и у Mozilla вполне хватило влияния, чтобы выкинуть то, что им не нравилось. То есть, Гугл не всесилен и сообщество не бессильно.

                                  — Вы пишите, что работу над стандартом вели исключительно разработчики Гугл, потому как они являлись авторами предложений и первые версии внедрялись только в подконтрольном Chromium

                                  — Я пишу что это не так, ибо работа велась и разработчиками Firefox, которые запилили свою имплементацию (а значит, видели в этом смысл) и также активно участвовали в обсуждении

                                  — Вы говорите, что в FF реализация была за флагом (как будто это что-то меняет), и потом утверждаете, что это правильно

                                  — Ок, вот вам и пример того, как соперничают разные подходы. Очередной аргумент в пользу того, что «не Гуглом единым»

                                  Я ничего не напутал? Потому, что главный финальный тезис Вашей статьи, о том, что «не все стандарты хороши, потому, что некоторые навязаны кровавым Гуглом», вроде как не очень подтверждается…

                                  Это еще один фреймворк, для которого Гугл смог пролоббировать предустановку в браузеры.

                                  И веб-компоненты — это не фреймворк, а часть DOM API, которая позволяет часть задач выполнять эффективнее. Почему-то все сравнивают компоненты с фреймворками, хотя это вещи слегка ортогональные, и прежде всего, веб-компоненты — это мощное средство композиции, и интеграции.
                                    +3

                                    Все-таки есть большая разница между подходом "работаем с сообществом, собираем пожелания, долго обсуждаем, выпускаем MVP, последовательно его улучшаем" (как это происходит у WebAssemby сейчас) и ситуацией с веб-компонентами "выкатываем почти финальную версию на суд публики, даем возможность отклонить только самую откровенную дичь".


                                    И веб-компоненты — это не фреймворк, а часть DOM API

                                    Одно другому не противоречит. Это фреймворк, который запихнули в DOM API.


                                    И насчет его мощности у меня есть сомнения, которые я раскрыл в своей статье, и потом ещё одну перевёл.


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

                                      0
                                      вряд ли в гугле все считали HTML импорты дичью, кроме того, я читал что в развитии стандартов для веб компонентов активно участвовали и Microsoft и в эдже все относительно быстро реализовывали.
                                        +1

                                        По ссылкам в статье можно восстановить хронологию событий. Первая презентация веб-компонентов произошла в 2011 году. Процесс стандартизации и работа с фидбеком от других браузеров началась только 2014 году. Возникает вопрос, что делал Гугл эти три года, и почему не обратился за фидбеком раньше?

                                          0
                                          Процесс стандартизации и работа с фидбеком от других браузеров началась только 2014 году.

                                          www.w3.org/TR/2012/WD-components-intro-20120522 — А это тогда что?
                                            0

                                            Спасибо за ссылки, теперь стало понятно, чем они занимались в это время.


                                            Однако вопрос, почему они зарелизили несогласованное API в браузере и подорвали доверие к браузерному API как оплоту стабильности, остаётся открытым.

                                              0
                                              Браузернные API никогда и не были оплотом стабильности, сегментация веб-платформы — это ее основная проблема еще со времен IE… А добавленное API ничего не ломало, ибо не было никакого легаси. Не вижу большой проблемы.
                                            0
                                              0
                                              касательно именно импортов, возможно некоторым потребовался удар масштабными граблями. Сейчас много отрицателей ООП, MVC и прочих полезных паттернов, произошел видимо разрыв поколений из-за ухода разработки в аутсорс и дрейфа технологий, да и есть лобби с евангелистами которые постоянно призывают от чего-нибудь отказаться или наоборот что-то поставить во главу угла и как-будто обеспечить этим узко-специализированную эффективность.
                                            0
                                            И насчет его мощности у меня есть сомнения, которые я раскрыл

                                            Да, нюансов масса. Часть из них действительно выглядит как проблема. Но, во первых, эти проблемы, в подавляющем большинстве своем, имеют вполне изящные решения, а во вторых — покажите мне «беспроблемную» технологию. Вся эта история началась ведь не на пустом месте, она выросла из «проблем» которые были до нее. И когда мне начинают рассказывать про недостатки веб-компонентов те, кто пишут на ЛЮБОМ из популярных фреймворков — я делаю смачный такой фейспалм, потому, что на каждый из этих фреймворков можно написать статью о «проблемах» раз в 10 длиннее. Я бы тоже не стал рекламировать веб-компоненты как универсальное решение на все случаи жизни. Но и хейтить их я бы тоже не стал.
                                              +1

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


                                              Стандарт же обновлять намного сложнее, нужно аккуратно вносить изменения ничего не сломав на существующих сайтах. Нужно семь раз отмерить и только потом релизить. А Гугл же бежит впереди всех и подставляет своих пользователей.

                                                0
                                                можно всегда все бросить и написать с нуля

                                                Ничего нельзя бросить и написать с нуля, если оно становится мета-платформой. То есть можно конечно, но тогда это тоже можно смело записывать в список жирных недостатков. Контракты важнее реализаций, и в этом аспекте никакой существенной разницы нет, вам все равно придется выполнять условия контрактов. Но в одном случае, вы будете писать на условном С++ а в другом — на JS.
                                          0
                                          да, существенная разница как раз в том что не надо бустрапить и транспилять, что-бы заиметь некоторый минимум и точку входа, это дает более простую реализацию динамически добавляемых компонентов и вообще взаимодействия на странице. Веб компоненты достаточно органичны и при том мощны, раньше была такая технология Flesh/Flex и многие делали на нее ставку из-за всяких удобных и крутых возможностей и производительности, но она была блобом закрывающим приложения в свой черный ящик, таким же как популярные фреймворки сейчас. Тогда вы писали на флеше и только на нем используя эту технологию, сейчас точно также закрываетесь во внутреннем джаваскрипт рантайме приложения на фреймворке. Да, можно все таки делать мостики, но будет ли это эффективнее использования фреймворков на веб компонентах и нативном джаваскрипте (с модулями и пр.) — большой вопрос.
                                +2

                                развитие веб компонентов проходило не безболезненно, однако нынешняя реальность из засилия совершенно несовместимых между собой и порой противоречащих инженерной науке фреймворков реакт, вуе и ангуляр гораздо хуже

                                  +1

                                  Веб-компоненты не заменяют ни один из этих фрэймворков. Главная фича этих фрэймворков — декларативность, веб-компоненты никак не реализуют её. Веб-компоненты только приносят боль дебага стилей.

                                    0

                                    полностью может и нет, но фреймворк использующий веб компоненты заменит. Насчёт декларативности можете привести пример чего нельзя сделать с ними? Я вот прикручивал инжектор от ангуляра и это было декларативно вполне. Слоты и гетеры тоже позволяют это все обеспечивать. Ну а теневое дерево как раз призвано решать проблемы со стилями.

                                      +1

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


                                      Например, в вашем компоненте есть иконка, которая показывается при определённой комбинации атрибутов компонента. В веб компонентах в сеттере каждого атрибута нужно поместить логику, которая проверяет комбинацию и скрывает/показывает иконку. Можно вынести эту логику в отдельный метод. Если подобных этой иконке особенностей много, то в классе будет много таких методов, и его понимание станет сложнее, чем понимание простого HTML-шаблона. Ещё один пример: вывод списка, содержимое которого изменяется — императивных подход требует ручной обработки каждого элемента списка для применения изменений. При декларативном подходе это реализуется на раз-два. Я не рассматриваю всерьёз реализацию декларативности через innerHTML = ..., потому что это заставляет браузер удалять и создавать содержимое элемента заново, что долго и приводит к потере внутреннего состояния элементов в содержимом.


                                      Декларативность не противоречит веб-компонентам, можно сочетать оба подхода. Пока её нет в веб-компонентах, фрэймворки типо React и Vue будут востребованы. Инкапсуляция CSS — это другой вопрос, веб-компоненты решают эту проблему.

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

                                        При декларативном подходе это реализуется на раз-два. Я не рассматриваю всерьёз реализацию декларативности через innerHTML


                                        innerHTML это вообще не про веб компоненты, потому что customElements работает только с appendChild и insertAdjacentHtml, и если от конечного разработчика какую-то магию спрятали за подсистемами это не значит, что такого же нельзя реализовать для веб-компонентов. Даже я бы сказал наоборот: в популярных фреймворках делают специальные погремушки для live биндинга и шаблонизации, которые в компонентах просто работают из коробки или после некоторых изящных доработок, например с attributeChangedCallback не нужны специальные обзерверы и реакторы потоков данных.
                                          0
                                          innerHTML это вообще не про веб компоненты, потому что customElements работает только с appendChild и insertAdjacentHtml

                                          Это еще почему? Custom Elements прекрасно создаются через innerHTML, и это одна из их важных фишек.
                                            0
                                            возможно это было у меня только в отдельных легаси браузерах, но факт в том что кастомные элементы у меня то ли не раздиспатчивались совсем, то ли как-то не совсем корректно при использовании innerHTML, в тоже время через другие перечисленные методы все работало
                                              0
                                              Думаю дело было в этапах жизненного цикла. Браузер может распарсить разметку и создать фрагмент DOM дерева таким образом, что кастомный элемент появляется в DOM до вызова своего конструктора. В этом случае, бразузер создает узел HTMLUnknownElement и только потом заменяет его на ваш компонент. В этом случае, если вы присвоите данному узлу какое-либо свойство, оно будет потеряно после срабатывания «правильного» конструктора. Эта проблема решена здесь с помощью метода «defineAccessor».
                                                0
                                                да, скорее всего речь шла о невызывающемся в таком случае connectedCallback или некорректном с точки зрения кастомного элемента его контексте
                                          +1
                                          кстати именно с Custom Elements гораздо более доступным оказывается прямое взаимодействие с элементами дерева, вот в реакте у вас обязательно такие приколы будут сбоить от перерендеров, а тут перерендер это дело «добровольное», осмысленное, сопровождаемое вызовом колбеков с разбиндивающим кодом
                                        0
                                        Главная фича этих фрэймворков — декларативность

                                        Разумеется нет. Декларативность достигается в разы меньшей ценой, простые инструменты шаблонизации в десятки раз меньше фреймворков «целиком».
                                      –1

                                      Борис, спасибо за интересную статью.


                                      Это из тех случаев когда «безнаказанность порождает вседозволенность». Но что делать в подобных ситуациях с такого рода монополистами как Гугл с его Хром пока не понятно. Силы которая могла бы повлиять на Гугл нет. Разве что ИТ-сообщество организуется и будет игнорировать криво сделанные фичи и не будет поддерживать их и браузеры, которые их используют. Но, имхо, всем лень в этом разбираться, всем проще ориентироваться на Хром.


                                      Вспоминается ситуация с Adobe Flash. Тогда такой силой официально стала Apple, когда отказалась от поддержки Flash.

                                        +1
                                        ну это же веб-стандарт, они не могут ошибаться

                                        Нет, не так:


                                        ну это же веб-стандарт, он встроен в браузеры и на него можно рассчитывать, как на DOM API или методы JS, а не вздрагивать каждый раз от мажорного релиза библиотеки и не прислушиваться нервно к тишине, когда релизов не было
                                          0

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


                                          А выход новой версии фреймворков хоть и сопровождается большим шумом в интернете, спешить обновляться необязательно, однажды написанный и протестированный код вряд ли сломается, если его не менять.

                                            0

                                            Проиллюстрирую ситуацию примером. В 2015 году я сделал два компонента для Яндекс-Карт:



                                            Версия на AngularJS работает как ни в чем не бывало, а версия на Polymer сломалась, потому что API для нее уже удалили из браузеров. Вот и все что нужно знать о стабильности веб-компонентов.

                                              0

                                              Я кажется понял, откуда боль и злость: вы почему-то решили, что веб-компоненты v0 были стандартом. Нет, это был черновик, который неосмотрительно зашипили в Chrome. Всё, что я говорил, относится к v1, да и вам бы принять, простить и пережить травму.


                                              Повторюсь: веб-компоненты стали реальностью не когда смельчаки начали писать компоненты на v0, а когда Apple, Mozilla и кто-то там ещё договорились про v1. Хватит пугать публику старыми страшилками.

                                                0

                                                v0 к спецификации приделали уже задним числом, изначально это продавалось как без пяти минут стандарт (ссылка на документацию Polymer из 2014 года).


                                                Точно так же ничто не мешает сейчас найти фатальный недостаток в текущей версии, и начать готовить Custom Elements v2. И судя по тому, с каким скрипом решаются такие важные моменты, как де-глобализация реестра компонентов, шансы на v2 спецификацию не такие уж и маленькие.

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

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