Pull to refresh

Comments 55

UFO just landed and posted this here

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


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

Какая плохая Майкрософт, проталкивала полезные фичи, которыми сейчас все пользуются.
Или вы не хотите вспомнить, что тогда никаких комитетов по стандартизации не было, а сейчас есть? А в статье как раз о чем говориться?
UFO just landed and posted this here
UFO just landed and posted this here
недавно пролетала статья. мелкософт добавляла в IE кучу технологий (архитектура которых хромала), которые нужны были ей самой, например для outlook, ни с кем не советовавшись, а потом пыталась пропихнуть это как стандарт. теперь вот похожим занимается google — запилила WC для youtube (кстати, сайт тоже фактически монополист).
Стоп, AJAX ненужная вещь? к примеру.

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

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

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

не стоит так обобщать. :) кое-что взлетело и позже таки было стандартизировано. кстати, по этой причине в XHR есть странноватые решения.
UFO just landed and posted this here
например нет состояния sended. после opened идет headers_received.

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

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

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

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

В первом тикете из конструктивного фидбека есть только два комментария



Во втором тикете эти же моменты никак не адресованы. Так почему же он остался открытым?

Во втором тикете эти же моменты никак не адресованы.

Кстати да, это очень хороший вопрос. Не в связи с закрытостью, а вообще.
UFO just landed and posted this here
Аргументы выглядят логичными и справедливыми в обычной ситуации, но в случае веб-компонентов есть нюансы, которые я попробую раскрыть в этой статье.

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

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

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

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


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

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


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

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

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

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

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

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

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

Это не так:

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

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


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

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


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

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


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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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


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

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


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


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

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

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

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


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

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

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

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


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

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

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

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

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

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

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


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


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

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

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


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

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

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

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


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


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

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

Нет, не так:


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

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


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

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



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

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


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

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


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

Sign up to leave a comment.

Articles