Comments 55
Все так, не первый раз такая ситуация случается. Но это же не значит, что по-другому быть не может.
Например, в WebAssembly или TC39 более сбалансированный состав участников, и там обходится без таких масштабных драм
Или вы не хотите вспомнить, что тогда никаких комитетов по стандартизации не было, а сейчас есть? А в статье как раз о чем говориться?
Вещь нужная, как и векторная графика (VML/SVG), как и css-градиенты, но реализация хромает. Поэтому веб-браузеры все реализуют все эти нужные фичи, но уже более человечески.
var xhr = new ActiveXObject("Microsoft.XMLHTTP");
Как-то, не кроссбраузерно в реализации Microsoft.
Стоп, AJAX ненужная вещь? к примеру.
не стоит так обобщать. :) кое-что взлетело и позже таки было стандартизировано. кстати, по этой причине в XHR есть странноватые решения.
Открытость стандарта подразумевает то, что он написан с привлечением разных заинтересованных сторон.
Не улавливаю логики этого высказывания. Открытость подразумевает, то что полное описание стандарта можно найти в свободном доступе, не больше и не меньше.
Предположу, что имелась ввиду не только иметь доступ на чтение, но и возможность вносить предложения, которая фактически доступна только сотрудникам Гугла.
Равно как и второе предложение (от гугла) не было закрыто потому, что оно гораздо проще и вполне реализуемо.
В первом тикете из конструктивного фидбека есть только два комментария
- суперкласс HTMLElement должен знать, к какому тэгу он прикреплен
CSS-селектор element-name
глобальный и не понятно как его применять в этой ситуации
Во втором тикете эти же моменты никак не адресованы. Так почему же он остался открытым?
Аргументы выглядят логичными и справедливыми в обычной ситуации, но в случае веб-компонентов есть нюансы, которые я попробую раскрыть в этой статье.
На всякий случай, эти «нюансы» сопровождают практически все стандарты W3C, не важно, проталкивает ли их гугл, майкрософт, или вообще никто (потому что неидеальность идей, которые поначалу кажутся здравыми — никто не отменял).
И придираться конкретно к веб-компонентам и к гуглу тут бессмысленно. Примерно такой же толщины статью можно накатать, например, про svg, про новые версии css, и вообще практически про любой нужный стандарт.
Ах бедные разработчики и пользователи polymer, подло подбитые коварными бизнес-практиками гугля. Ах, им пришлось выкашивать не прижившийся bleeding edge из кода. А когда люди в поздних нулевых бегали между неоднозначностями имплементации svg, или же слезали с флеша, потому что дальше терпеть это уже было нельзя — это древняя история и никогда такого не было.
Когда речь идёт об открытых стандартах, затрагивающих интересы многих участников — так будет всегда. И у вас всегда есть выбор — можно просто не использовать ничего из новых стандартов. jQuery и штуки типа ExtJS работают прекрасно по сей день, примерно в любом браузере, и очень эффективно.
Над неймспейсами для веб-компонентов, кстати, ведется работа.
Черновики и версия 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 и как-то особо себя никак не проявила.
Это не так:
- blogs.opera.com/desktop/2015/10/opera-33-our-contribution-to-chromium
- operasoftware.github.io/upstreamtools
Интересно, а где об этом можно узнать побольше?
По информации на 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.
И насчет его мощности у меня есть сомнения, которые я раскрыл в своей статье, и потом ещё одну перевёл.
И повторюсь – если ваши задачи эта технология решает, чудесно. Но рекламировать её как универсальное решение для всех, я бы не стал.
По ссылкам в статье можно восстановить хронологию событий. Первая презентация веб-компонентов произошла в 2011 году. Процесс стандартизации и работа с фидбеком от других браузеров началась только 2014 году. Возникает вопрос, что делал Гугл эти три года, и почему не обратился за фидбеком раньше?
Процесс стандартизации и работа с фидбеком от других браузеров началась только 2014 году.
www.w3.org/TR/2012/WD-components-intro-20120522 — А это тогда что?
Спасибо за ссылки, теперь стало понятно, чем они занимались в это время.
Однако вопрос, почему они зарелизили несогласованное API в браузере и подорвали доверие к браузерному API как оплоту стабильности, остаётся открытым.
И насчет его мощности у меня есть сомнения, которые я раскрыл
Да, нюансов масса. Часть из них действительно выглядит как проблема. Но, во первых, эти проблемы, в подавляющем большинстве своем, имеют вполне изящные решения, а во вторых — покажите мне «беспроблемную» технологию. Вся эта история началась ведь не на пустом месте, она выросла из «проблем» которые были до нее. И когда мне начинают рассказывать про недостатки веб-компонентов те, кто пишут на ЛЮБОМ из популярных фреймворков — я делаю смачный такой фейспалм, потому, что на каждый из этих фреймворков можно написать статью о «проблемах» раз в 10 длиннее. Я бы тоже не стал рекламировать веб-компоненты как универсальное решение на все случаи жизни. Но и хейтить их я бы тоже не стал.
Достоинство классических фреймворков – они опциональные и каждый сайт волен загружать любую версию, можно делать любые несовместимые изменения. Поэтому ошибки и косяки там исправлять намного проще, можно всегда все бросить и написать с нуля.
Стандарт же обновлять намного сложнее, нужно аккуратно вносить изменения ничего не сломав на существующих сайтах. Нужно семь раз отмерить и только потом релизить. А Гугл же бежит впереди всех и подставляет своих пользователей.
можно всегда все бросить и написать с нуля
Ничего нельзя бросить и написать с нуля, если оно становится мета-платформой. То есть можно конечно, но тогда это тоже можно смело записывать в список жирных недостатков. Контракты важнее реализаций, и в этом аспекте никакой существенной разницы нет, вам все равно придется выполнять условия контрактов. Но в одном случае, вы будете писать на условном С++ а в другом — на JS.
развитие веб компонентов проходило не безболезненно, однако нынешняя реальность из засилия совершенно несовместимых между собой и порой противоречащих инженерной науке фреймворков реакт, вуе и ангуляр гораздо хуже
Веб-компоненты не заменяют ни один из этих фрэймворков. Главная фича этих фрэймворков — декларативность, веб-компоненты никак не реализуют её. Веб-компоненты только приносят боль дебага стилей.
полностью может и нет, но фреймворк использующий веб компоненты заменит. Насчёт декларативности можете привести пример чего нельзя сделать с ними? Я вот прикручивал инжектор от ангуляра и это было декларативно вполне. Слоты и гетеры тоже позволяют это все обеспечивать. Ну а теневое дерево как раз призвано решать проблемы со стилями.
Декларативность — это когда говоришь желаемый результат, а система определяет и делает минимально необходимые изменения в DOM-дереве, чтобы прийти к результату. Всё можно сделать кастомными компонентами, но вопрос, какими усилиями.
Например, в вашем компоненте есть иконка, которая показывается при определённой комбинации атрибутов компонента. В веб компонентах в сеттере каждого атрибута нужно поместить логику, которая проверяет комбинацию и скрывает/показывает иконку. Можно вынести эту логику в отдельный метод. Если подобных этой иконке особенностей много, то в классе будет много таких методов, и его понимание станет сложнее, чем понимание простого HTML-шаблона. Ещё один пример: вывод списка, содержимое которого изменяется — императивных подход требует ручной обработки каждого элемента списка для применения изменений. При декларативном подходе это реализуется на раз-два. Я не рассматриваю всерьёз реализацию декларативности через innerHTML = ...
, потому что это заставляет браузер удалять и создавать содержимое элемента заново, что долго и приводит к потере внутреннего состояния элементов в содержимом.
Декларативность не противоречит веб-компонентам, можно сочетать оба подхода. Пока её нет в веб-компонентах, фрэймворки типо React и Vue будут востребованы. Инкапсуляция CSS — это другой вопрос, веб-компоненты решают эту проблему.
При декларативном подходе это реализуется на раз-два. Я не рассматриваю всерьёз реализацию декларативности через innerHTML
innerHTML это вообще не про веб компоненты, потому что customElements работает только с appendChild и insertAdjacentHtml, и если от конечного разработчика какую-то магию спрятали за подсистемами это не значит, что такого же нельзя реализовать для веб-компонентов. Даже я бы сказал наоборот: в популярных фреймворках делают специальные погремушки для live биндинга и шаблонизации, которые в компонентах просто работают из коробки или после некоторых изящных доработок, например с attributeChangedCallback не нужны специальные обзерверы и реакторы потоков данных.
innerHTML это вообще не про веб компоненты, потому что customElements работает только с appendChild и insertAdjacentHtml
Это еще почему? Custom Elements прекрасно создаются через innerHTML, и это одна из их важных фишек.
Главная фича этих фрэймворков — декларативность
Разумеется нет. Декларативность достигается в разы меньшей ценой, простые инструменты шаблонизации в десятки раз меньше фреймворков «целиком».
Борис, спасибо за интересную статью.
Это из тех случаев когда «безнаказанность порождает вседозволенность». Но что делать в подобных ситуациях с такого рода монополистами как Гугл с его Хром пока не понятно. Силы которая могла бы повлиять на Гугл нет. Разве что ИТ-сообщество организуется и будет игнорировать криво сделанные фичи и не будет поддерживать их и браузеры, которые их используют. Но, имхо, всем лень в этом разбираться, всем проще ориентироваться на Хром.
Вспоминается ситуация с Adobe Flash. Тогда такой силой официально стала Apple, когда отказалась от поддержки Flash.
ну это же веб-стандарт, они не могут ошибаться
Нет, не так:
ну это же веб-стандарт, он встроен в браузеры и на него можно рассчитывать, как на DOM API или методы JS, а не вздрагивать каждый раз от мажорного релиза библиотеки и не прислушиваться нервно к тишине, когда релизов не было
Если что-то и заставляет вздрагивать, так это релизы веб-компонентов, после которых сайт использующий старый стандарт превращается в тыкву.
А выход новой версии фреймворков хоть и сопровождается большим шумом в интернете, спешить обновляться необязательно, однажды написанный и протестированный код вряд ли сломается, если его не менять.
Проиллюстрирую ситуацию примером. В 2015 году я сделал два компонента для Яндекс-Карт:
- AngularJS: http://catatron.com/angular-ymaps/
- Polymer: http://catatron.com/polymer-ymaps/
Версия на AngularJS работает как ни в чем не бывало, а версия на Polymer сломалась, потому что API для нее уже удалили из браузеров. Вот и все что нужно знать о стабильности веб-компонентов.
Я кажется понял, откуда боль и злость: вы почему-то решили, что веб-компоненты v0 были стандартом. Нет, это был черновик, который неосмотрительно зашипили в Chrome. Всё, что я говорил, относится к v1, да и вам бы принять, простить и пережить травму.
Повторюсь: веб-компоненты стали реальностью не когда смельчаки начали писать компоненты на v0, а когда Apple, Mozilla и кто-то там ещё договорились про v1. Хватит пугать публику старыми страшилками.
v0 к спецификации приделали уже задним числом, изначально это продавалось как без пяти минут стандарт (ссылка на документацию Polymer из 2014 года).
Точно так же ничто не мешает сейчас найти фатальный недостаток в текущей версии, и начать готовить Custom Elements v2. И судя по тому, с каким скрипом решаются такие важные моменты, как де-глобализация реестра компонентов, шансы на v2 спецификацию не такие уж и маленькие.
Веб-компоненты и открытые стандарты