Web Components — это единственное светлое будущее веба. Смиритесь


    Вчера вышла [весьма достойная статья про Web Components, и я понял, что не могу не поделиться тем опытом, что я накопил за последние восемь месяцев. Я не буду рассказывать о том, как работать с Веб Компонентами, я расскажу, почему. Поэтому тем, кто не знает об этом стеке технологий, стоит прочитать статью по ссылке выше.
    Дело в том, что в июне вышла первая стабильная версия моей библиотеки CornerJS. Начавшись как автономная реализация директив из AngularJS, она постепенно превратилась в более простой — как в использовании, так и в реализации — аналог (неточный, да, я знаю) Пользовательских Элементов из спецификации Веба Компонентов.

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

    Это замечательная, на мой взгляд, в реализации библиотека — я действительно считал ее основным инструментом в разработке, и в последнем проекте (видеопортале) она оказалась важнее jQuery: от него я мог бы отказаться, а от нее нет.

    Но я, как человек, внедривший ее в нашу команду, и отказываюсь от нее — мы переходим на Mozilla X-tags для IE9+ сайтов и Polymer для IE10+ сайтов. К счастью, на моей памяти у нас был всего один или два проекта IE8+.

    И в этом посте я расскажу, почему веб-компоненты — это не просто будущее веба. А единственное будущее веба.



    Как все началось



    Предпосылки к подобной архитектуре появлись четыре года назад в Google и Яндекс, при этом сохранился национальный колорит.

    Так, в Google появился AngularJS — фреймворк, в котором большая часть логики опиралась на директивы. Почему это так важно? Потому что директивы представляли из себя модули, которые привязывались к html-тэгам, и выполнялись в изолированном окружении этой ноды. Колорит тут заключался именно в том, что Google сохранил верность Java-подобному подходу, и построил все вокруг не-нативных сеттеров и геттеров. С одной стороны это правильно, это был единственный способ сделать «почти честный» колбэк для изменения Представлений, с другой — это привнесло некое неудобство в использовании библиотеки. Впрочем, о чем это мы, мы уже ко всему привыкли, можно сказать. Но в итоге появилось главное: автономные визуальные и не очень элементы, которые можно легко переносить из проекта в проект. Кстати, говорят — я, к сожалению, последние несколько месяцев не отслеживаю прогресс AngularJS — что они уже переехали на почти нативный Object.observe.

    А в Яндексе появился БЭМ, Национальная русская идея с JSON и верстальщицами. Я где-то в комментариях выразил мою позицию по отношению к нему: «БЭМ это попытка влететь в светлое будущее, размахивая костылями. С одной стороны, это действительно получилось, с другой — смотреть без смеха или слез невозможно». Впрочем, неделя рОзжыга на тему БЭМ уже прошла, так что не надо в комментариях обсуждать эту тему, прошу. Я просто хотел сказать то, что сам по себе подход действительно достоин восхищения: понять и сделать механику, которая обеспечивает инкапсуляцию и стилей, и скриптов (да, а в ангуляре только скрипты инкапсулируются) — это гениально, а то, как именно это сделано — это дело второе, и те, кому это действительно нужно, давно смирились и пользуются.

    В итоге...


    … мы имеем то, что имеем: большие команды пришли к осознанию того, что инкапсулироваться и подключаться должны не только библиотеки (привет, requireJS и мой личный фаворит browserify), но в первую очередь — визуальные компоненты на каждой из страниц сайта.
    Почему? Да потому что они не относятся к основному потоку программы. Если у вас веб-приложение, как к нему должен относиться рендеринг диаграммы на главной странице? Никак, идеальный для вас вариант это продекларировать в шаблоне, в нужном HTML-тэге входные данные, а дальше оно пусть само работает. Вы правда не хотите думать о том, когда запустить рендер данных, а если вам внезапно захочется динамически обновлять эти данные — тем более не хотите, вам куда удобнее просто добавить какой-нибудь

    <value at=100 is=500>
    

    Вы уже пользуетесь таким подходом, смотрите:
    <video width="320" height="240" poster="poster.jpg" controls="controls" preload="none">
        <source type="video/mp4" src="myvideo.mp4" />
        <source type="video/webm" src="myvideo.webm" />
        <source type="video/ogg" src="myvideo.ogv" />
    </video>
    


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

    Модульный веб


    Со временем, когда ты начинаешь активно пользоваться библиотеками для веб-компонентов (или БЭМ, с чем согласятся сторонники этого подхода, хотя я чувствую, что они меня уже возненавидели) внезапно приходит осознание того, что единое приложение, как таковое, почти никогда не нужно. Каждая веб-страница — автономная сущность, изолированная от внешнего мира, ей хорошо самой по себе, а приложение — это та сущность, которая остается при переходе между страницами, и ее почти никогда нет. Дело в том, что переходы между страницами могут быть частичными, и часть Пользовательских Элементов может легко и непринужденно остаться на ней, например, плеер или чат.

    В итоге получается очень простая вещь: 90-95% веб-сайтов может быть построено только из автономных компонентов, представляющих из себя модули, сочетающие в себе визуальное представление, логику, а так же внешние методы и свойства. Ну и, конечно, они могут содержать в себе другие модули.

    Те реализации этого подхода, которые есть сейчас, на самом деле ужасны в части визуальной составляющей. Если в плане логики вы можете спокойно создать комбинированный AMD/npm/безмодульный компонент с неплохим в общем-то набором инструментов, то с визуальным представлением все сложнее: приходится иметь внутри модуля шаблонизатор, пользоваться inline-стилями или вписываться в document.styleSheets, и все равно не можете быть уверенным, что веб-разработчик не заденет своими стилями модуль. Вдруг у него есть какой-нибудь footer a, и он вставляет туда ваш блок лайков?

    Привет, компоненты


    На базе опыта команд google, mozilla и многих других у них совместно возникло понимание того, что нужно создать возможность реализовать изолированные логиковизуальные модули. Опыт же подсказал им, что действительно очень важно:

    Инкапсуляция css

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

    Пользовательские методы и свойства

    Это возможность создавать внешние интерфейсы, как методы, так и значения. К счастью, в js это довольно просто сделать, а геттеры и сеттеры уже сравнительно давно появились. Спасибо Object.defineProperty. Это важно, потому что у кастомных элементов должны быть новые интерфейсы. Как бы вы реализовывали тэг video без
    HTMLVideoElement.prototype.play()
    ?

    Куча колбэков на каждый чих

    конструкторы, деструкторы, и колбэки для изменения атрибутов. Неочевидный момент: есть два колбэка «конструктора». Первый из них отвечает за создание элемента (document.createElement('x-tag')), а второй — за добавление его в DOM-дерево. В случае, если вы просто добавили элемент в верстку — выстрелят оба. Зачем это нужно? Затем, что некоторые действия (например, запуск событий) должны выполняться по добавлению элемента в DOM-дерево. Более того, они должны выполняться по каждому добавлению элемента в DOM-дерево, в том числе если вы перенесете элемент, передав его через appendChild другому родителю.

    Шаблоны без выполнения содержимого

    Их важность не очень очевидна на первый взгляд, вроде бы «да, все круто, теперь картиночки не будут подгружаться», но идет отрыв от контекста Пользовательских Элементов: люди забывают о том, что они тоже запускаются по добавлению в DOM, и если раньше в каком-нибудь MVVM фреймворке можно было спокойно вставить что-то в качестве шаблона и забыть — с ним ничего не случится, то теперь же нужно учитывать то, что элементы, объявленные в шаблоне, имеют свойство инициироваться, и какой-нибудь
    <x-video-with-subtitle source="{{video.source}}">
    

    будет запущен с {{video.source}} в качестве source, что совершенно не устраивает никого.

    Инкапсуляция верстки

    Это тоже не полностью очевидный момент. Дело в том, что точно так же стили, на верстку Пользовательского Элемента не должно быть никакого влияния: она должна быть абсолютно автономной, к ней можно «достучаться» только особой, уличной магией — именно для того, чтобы стандартные библиотеки не умели работать с ним.
    Однако зачастую атрибутов для конфигурирования элемента бывает недостаточно, и для какой-нибудь диаграммы самым правильным решением будет создать что-нибудь вроде
    <x-diagram type="histogram">
        <value at=100 is=500>
        <value at=200 is=300>
        <value at=300 is=200>
        <value at=300 is=700>
    </x-diagram>
    


    Поэтому нужно было сделать две вещи: инкапсуляцию реальной верстки и поддержку простейшей (на уровне тэгов) ее шаблонизации. Обе вещи неплохо удались: Shadow DOM представляет собой одновременно как способ инкапсуляции одновременно стилей и структурной верстки, так и простой, но довольно удобный в некоторых местах шаблонизатор.

    В той статье не объяснялось, но я попытаюсь прояснить про шаблонизацию: в действительности шаблонизатор Shadow DOM не ограничивается применением тэга
    <content>
    
    в лоб. У него есть атрибут select, и с ним он выглядит примерно так:
    <content select=".first">
    
    Этот тэг «вынимает» из host DOM компонента все элементы, попадающие под действие тэга. Соответственно, второй раз этот поиск уже ничего не найдет. Таким образом, написание
    <content></content><content></content>
    
    в реальности просто перенесет содержимое host DOM в composed DOM, а второй тэг уже ничего не сможет перенести, потому что элементов уже нет.
    Если кто-то по-прежнему ничего не понял — попробуйте это замечательное демо, которое показывает, как же все-таки работает Shadow DOM.

    Во многих публикациях он подвергался резкой критике из-за того, что не обладал какими-либо сверхспособностями вроде итераторов или фильтров, или даже просто возможности вставить элемент дважды. К сожалению, никто особо не тратил на оппонентов время, а надо было бы. Дело в том, что shadow DOM не шаблонизатор в привычном смысле слова: он не создает элементы из шаблонов. Он занимается прямым пробросом элементов. Если вы поместили элемент в host DOM, и изменили его атрибуты, они будут доступны и изменены и в shadow DOM. Если вы поместили один Пользовательский Элемент в другой Пользовательский Элемент, конструктор для вложенного элемента будет вызван всего один раз, и у него не случится внезапного осознания того, что его куда-то перенесли, и надо заново запускать конструктор. Это был единственный возможный разумный вариант для реализации.

    Объявление Пользовательского Элемента


    Для декларирования подобных элементов не подходил тэг script: фактически, большая часть тэга представляла из себя все же верстку. В некоторых — я бы даже сказал, многих — случаях скриптинга можно в принципе избежать. Поэтому самым разумным решением было расширить спецификацию самого HTML еще одним элементом с немного «особенным» синтаксисом.
    Но тут возникает потребность в еще одном решении: как эти элементы кэшировать? Мы не можем подключить их через script, потому что это не тэг script, а значит, нужно создавать спецификацию для другого способа подключения элементов. Так появились HTML Imports.
    Подробнее о них я рассказывать не буду, это, конечно, интересно, но статья и так выходит довольно большой.

    Сам же выбор подхода с созданием новых тэгов появился по ряду причин, но одной из основных я бы назвал невозможность привязки двух конструкторов к одному и тому же тэгу. В свое время я потратил полдня на то, чтобы отладить директиву лицензионного соглашения. Выглядел тэг как-то так:
    <div class="directive-agreement directive-scrollbox"> Текст соглашения по умолчанию, который бы заменялся в случае, если для данного конкурса задан другой текст </div>
    


    Я долго не мог понять, почему у меня не появляется скроллбокс. Причем дебаггер показывал, что он создается… а потом пропадает.
    Дело оказалось именно в том, что directive-scrollbox отрабатывает первой. А directive-agreement — второй, и тоже преобразовывает innerHTML.

    В итоге


    Спецификация Веб Компонентов очень хорошо продумана, и построена из отдельных модулей, которые вместе направлены на одну простую задачу: предоставить действительно удобный способ создания новых HTML-тэгов, в которых инкапсулированы визуальная часть и логика. Это способно в разы ускорить создание веб-сайтов за счет того, что их становится легче подключить, и во многих случаях это можно выполнять верстальщику самостоятельно, без привлечения фронтэнд-разработчиков. Фронтэнд-разработчикам жизнь тоже облегчается, их работа разделяется фактически на две составных части: создание автономных модулей с логикой и большим удобным набором внешних интерфейсом, и создание ядра веб-приложения. При этом вторая деятельность больше относится к senior разработчикам, которые уже устали от создания «клевых анимированных эффектов», а первая гораздо легче парралелится, и гораздо легче тестируется: тестирование переходит от BDD, который довольно долго был основным для веба, к модульному тестированию, в котором тестируется по отдельности каждый компонент.

    Механика HTML Imports особенно важна для развития веба, так как почти гарантированно приведет к созданию онлайн-репозитория/CDN с большим количеством библиотек веб-компонентов, а, как мы знаем, централизованные репозитории положительно влияют на качество кода, создаваемое сообществом: все стараются поднять свою репутацию, выдавая качественный код, само сообщество активно развивается, а необходимые модули и библиотеки становится проще найти и подключить. Централизованный же CDN способен обеспечить и более быструю загрузку веб-страниц (это бич наших дней, размер страниц увеличивается быстрее, чем увеличивается пропускная скорость интернета у конечного пользователя).

    В итоге почти наверняка через буквально 2-3 года большая часть того, что сейчас представлено библиотеками, будет реализовано в качестве Пользовательских Элементов, потому что это банально удобнее в использовании и поддержки. Слайдеры, responsive изображения, WYSIWYG и Markdown-редакторы, видео с поддержкой караоке, генератор мурлыкающих котиков на canvas, в общем почти все, что есть в вебе, может быть обернуто в Пользовательский Элемент.

    Самое смешное, что элемент не обязательно должен быть визуальным: почему бы не сделать что-то вроде такого?
    
    var $ = document.createElement('x-library-jQuery')
    


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

    Начните использовать их сегодня.
    Попробуйте, вам понравится.

    Если вы разрабатываете для IE9+ — вы можете использовать Mozilla X-tags (сейчас у них УПС, пользуйтесь репозиторием)

    Если для IE10+ — подключите Polymer и используйте честные Пользовательские Элементы или пользуйтесь более легким синтаксисом и расширением возможностей Веба Компонентов в polymer.js. Искреннее спасибо Google за то, что они очень сильно вложились в Polymer и создали ie10+ (а некоторые даже IE9+) полифиллы для всех составных частей Веб Компонентов.

    Я надеюсь, мне удалось рассказать вам, почему все было сделано именно так: я прошел это на своем опыте, с каждой версией библиотеки все больше приближаясь к X-tags, потому что подобный синтаксис является единственно возможной реализацией «реактивного» подхода к работе с визуальными компонентами, и приближаясь к осознанию причин некоторых странных и сложных на первый взгляд вещей.

    Послесловие


    В последнее время ведется все больше разговоров о том, что веб становится все более фрагментирован. Если вам нужно подключить browserify-модуль и AMD модуль, это вызовет… некоторые проблемы. Некоторые библиотеки адаптированы для TypeScript, некоторые для CoffeeScript (ну ладно, ладно, я знаю, с ними можно работать, но многих CoffeeScript легко может напугать, если нужно будет исправить небольшие баги в какой-нибудь маленькой библиотеке или добавить свои методы). Dart — это вообще отдельный язык, который далеко не идеально взаимодействует с обычным JS. Веб Компоненты могут убрать эту фрагментированность: все компоненты будут совместимы друг с другом, потому что это будет просто HTML. Пусть и с новыми элемнтами. Google может спокойно создавать компоненты на их Dart, вы сможете пользовать icedCoffee, в Facebook продолжат пугать всех своим JSX, а в Одессе таки будут развивать модули на liveScript и дальше.
    Вы все равно сможете пользоваться этими библиотеками, потому что у всех их будет один и тот же способ взаимодействовать.
    Пожалуйста, начните использовать их сегодня, и вы сделаете веб лучше: любой разработчик сможет использовать вашу библиотеку, вне зависимости, пишет ли он на чистом JS, или на любом из препроцессоров, или вообще не пишет — задумайтесь о том, что слайдер, например, не нужно инициализировать из JS, ему достаточно того, что он будет сконфигурирован через атрибуты и внутреннее содержимое. В конце концов, две трети, наверное, библиотек для jQuery — это просто что-то вроде $().mediaelement(config) и все.

    P.S. Предлагаю объявить неделю Веб Компонентов открытой
    Поделиться публикацией
    Похожие публикации
    Ой, у вас баннер убежал!

    Ну. И что?
    Реклама
    Комментарии 23
      0
      Кстати, AngularDart использует Shadow DOM вместо ngTransclude для шаблонов компонентов, и есть подтвержденные планы о переносе этого же подхода в AngularJS в следующих версиях. Что вы об этом думаете?
        0
        Использовать Shadow DOM само по себе похвально, но вопрос во-первых в том, что это все сведется до ie10+, так как верстать(точнее применять стили) одновременно под shadow dom и не под shadow dom — смерти подобно. А во-вторых возникнет довольно неприятный диссонанс: web components нацелены на то, чтобы объединить различные варианты исполнения библиотек под одним стандартом, а библиотеки ангуляра вряд ли с ним точно совместимы, и визуальные компоненты для ангуляра будут развиваться парралельно.
        Я сам все хочу перейти на dart — одни только строковая интерполяция и честные Maps чего стоят. И веб-компоненты, я надеюсь, позволят это сделать в ближайшее время (планируем несколько ie10+ проектов). Но на мой взгляд — лучше одновременно использовать polymer в качестве движка компонентов и анимаций, и angular для именно что логики приложения. Субьективно — им стоит в первую очередь подключить поддержку тэга template (я не знаю, возможно, они уже сделали, я честно не успеваю за всем развитием следить), чтобы Пользовательские Тэги могли безболезненно держаться в шаблонах. А сам по себе shadow DOM, насколько помню, убыстряет работу рендера (за счет того что тэги внутри теневого DOM не учитываются в querySelector, а внутри себя их хранится совсем немного), так что да, начинание замечательное. По моей опять же субьективной оценке — доля старых ie в большинстве сегментов снизится до 1-2% суммарно приблизительно к лету, если судить по динамике, и большинство команд будет иметь возможность работать со всем стеком Веб Компонентов.
        –6
        Вот сколько я смотрю на вэбкомпонетны, все эти shadow dom и иже с ними, ну это же просто нормально реализованный asp.net на javascript.
          +8
          Все развивается по спирали.
          ASP.NET был громоздким, не гибким, медленным, но у него был отличный фреймворк. Все его хаяли. И поэтому родился ASP.NET MVC.
          JS был легким, быстрым, гибким, но все надо было писать самому и с нуля. Все его хаяли. И поэтому рождалось все больше фреймворков.
          Чувствую скоро будет та точка, где они пересекутся.
          И обнимутся все, и заплачут.
          +1
          Я может быть чего-то не понимаю про эти компоненты, но W3C получается додумалась до .htc?
            +1
            Ну, в vbscript геттеры и сеттеры тоже появились раньше чем в хроме :) Но мы же не используем их, верно?
            +6
            Сегодня WebComponents это buzzword как раньше был HTML5. Это прекрасная идея кастомного HTML элемента (которая существовала с эпохи Web 2.0) и несколько API, которые делают жизнь чуть-чуть проще. Я думаю, что для вас не секрет, что каждый первый web-UI-движок так или иначе позволяет создавать такой элемент, что BEM Tools, что React, что jQueryUI. Совсем другое дело это какой интерфейс будет на выходе и на сколько сложно в него вникнуть.

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

            Я считаю, что утверждение «стандарт построения кастомного HTML элемента спасет мир» — это миф. Опять будет тасяча галерей, просто написанных на WebComponents API. И, я уверен, что вы напишете свою потому как чужие галереи несут такой невероятные оверхэд по количеству поддерживаемых фичей из-за того, что их создатель не понимает KISS.

            «Прописал импорт компоненты с CDN и вуаля» — так не будет. Мы и через 10 лет будем пытаться сокращать количество запросов. Как обычно скачаем все компоненты и будем использовать инструменты для сборки этих компонент.

            Shadow DOM и Scoped CSS поможет избежать конфликтов «Встраиваемым приложениям» (Disqus например). В прочем, мы можем и так можем свести количество конфликтов к 0, используя кастомные теги (как делают API Яндекс Карт) и методологию BEM.

            W3C молодцы, что выделили эту часть HTML5 в отдельное понятие Web Components. По крайней мере теперь разработчики будут копаться в этом слове (Components) и начнут осознавать, что жирные библиотеки вроде jQuery нужно заменять маленькими компонентами(модулями), которые будут использоваться на 100%.

            Начните пользоваться Компонентами (без Web-) и начните забывать слово Библиотека, например, попробуйте выкинуть jQuery и заменить его на что-то более изящное.
              +1
              Понимаете, дело именно в том, что я отказался от собственного аналогичного решения, поняв, что оно идет к x-tags. Причем об x-tags я узнал тогда, когда не только api обоих библиотек совпадало процентов на 70, но и общий внутренний поток выполнения (там есть много спорных интересных моментов, я изучал именно из-за этого) был приближен настолько, насколько он может быть приближен у библиотек с разными механиками. И в общем-то за те несколько месяцев, что знаком с x-tags, испытал определенные, пусть и не очень значительные, проблемы с оставшимися 30%.

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

              Консорциум молодцы именно в том плане, что для создания единой спецификации регистрирования зависимых изолированных объектов, привязываемых к DOM, учли все ошибки предыдущих подобных архитектур, и то, что есть сейчас в этой спецификации, в общем-то можно сказать что выстрадано.
              Я хотел рассказать именно о том, почему были приняты именно такие решения в спецификации, почему они важны для компонентов, и почему это лучшее из того, что есть среди множества вариантов. Ну и, конечно, ответить на кучу еще не заданных вопросов.

              Shadow DOM и Scoped CSS поможет избежать конфликтов «Встраиваемым приложениям» (Disqus например). В прочем, мы можем и так можем свести количество конфликтов к 0, используя кастомные теги (как делают API Яндекс Карт) и методологию BEM.

              Не можем. Какой-нибудь шибанутый (простите) вебмастер может залихватски сделать что-нибудь вроде footer :last-child {margin-right: 20px}, потому что ему надо у всех конечных элементов отступы делать, и все полетит к чертям. Да, это проблема вебмастера, а не разработчика компонента, но лучше бы этой проблемы не было вообще. Мы все делаем решения для людей, а люди могут ошибаться. Поэтому в любом случае нужно подключать shadow DOM, если есть возможность. Вам дают возможность подстелить соломку, так воспользуйтесь ей.

              Начните пользоваться Компонентами (без Web-) и начните забывать слово Библиотека, например, попробуйте выкинуть jQuery и заменить его на что-то более изящное.

              Если честно, я вообще обычно 90% времени на vanilla пишу, если это работа с DOM. Ну это так, лирическое отступление.

              Честно говоря, я не могу точно определить, какую вы мысль хотели сказать, но в общем и целом — я скорее склонен согласиться. Нет, Веб Компоненты — это не buzzword, потому что он достаточно сильно ограничен по спецификации, вы не можете взять и воткнуть его куда-то (хотя я верю в то, что продажники в веб-студиях и с этим справятся), в отличии от HTML5, который охватывает такое количество стандартов, что куда не плюнь — всюду он. Анимации, новые интерфейсы, css3, es5, кастомные тэги, канвас, вебгл, сокеты — это все подпадает, и трудно понять, о чем ведет диалог человек. Веб Компоненты же это новый вариант создания модулей, который позовляет получить (почти) гарантированную инкапсуляцию кода, верстки, и стилей, и получить действительно удобный и стандартизированный интерфейс к ним. Именно об этом я и говорю — можно пользоваться БЭМ, React, но в итоге все действительно сведется к нативным вещам, потому что они действительно одновременно более удобные, безопасные, быстрые, и наиболее легкопереносимые. Это факт, и с ним придется мириться тем же фанатам БЭМ, например.
                0
                > Какой-нибудь шибанутый (простите) вебмастер может залихватски сделать что-нибудь вроде footer :last-child

                Вот именно, что всегда говорят о разных уровнях вэба. Есть сайт портфолио, или gmail подобное приложение. В последнем я очень сомневаюсь, что будет ситуация когда `шибанутый вэбмастер`, потому что это совсем разного уровня приложения и зачастую разного уровня люди их делают.
                И разумеется, я с вами о shadow dom согласен — это здорово. Но подобный аргумент удивил :)
              +1
              Веб Компоненты могут убрать эту фрагментированность: все компоненты будут совместимы друг с другом, потому что это будет просто HTML.
              Я согласен, что они будут работать. Однако вы не будете использовать компоненты написанные на «чужом языке» и сделанные «чужим инструментом» потому как эти компоненты могут тянуть какие-то тяжелые зависимости (платформу), вы не будете понимать как они устроены и напишете свой. Да они будут скомпилированы в CSS, HTML и JS но сорцы их будут на Stylus, Jade и например TypеScript с примесью React.
                0
                А вам правда часто нужно править чужую библиотеку? Воспринимайте это не как часть сайта, но как его изолированный блок. Как… ну, лайки фейсбука. Или Disqus. Вполне возможно, что Disqus сделан на JSX+stylus или Dart+less. Вы ведь не думаете об этом, правда? Ну, вот и тут то же самое. Оно просто работает. Ну, еще надо добавить конфигурацию.
                  +1
                  Вэб компоненты крутые, в силу того, что шаблон проектирования `Компонент` очень классный и никак не наоборот. И для построения большого вэб приложения им одним «сыт» не будешь. В этой шумихе все, как и вы — огромный акцент делают на `third-party components` — как бы — «подключил и забыл». Но имея также огромный опыт работы с компонентами я пришел к выводу, что очень сложно сделать универсальный компонент. Поэтому мы будем все равно преимущественно иметь «локальные» компоненты, и только несколько вендорных. В силу этого и разговор нужно вести в этом направлении. Как Вэб компоненты помогают структурировать приложение, как выглядит сборка приложения, какие паттерны скрыты в Компоненте (инкапсуляция html, css конечно же одна из самых классных, что я вижу) и прочее.
                    0
                    очень простой пример. Просто посмотрите на то количество библиотек для jQuery, которое используют люди. Тот же jQuery UI. Фактически любой из них можно просто и непринужденно превратить в автономный компонент, который можно будет подключать даже верстальщику.
                    И это действительно очень важно. Визуальная составляющая вновь отходит в ведование верстальщиков, а фронтэнд-разработчики становятся именно разработчиками.
                    Я бы вел весь диалог скорее вот в этом направлении.
                      0
                      Как-то сильно идеалистично. Как вы вообще пришли к концепции описанного в статье? Каков размер команды? Насколько сильное разделение труда в ней? Какие сайты вы делаете? Каков размер проектов? Насколько тяжело дается использование концепции компонентов другим разработчикам?

                      Соглашусь с мнением выше — визуальные виджеты из разных библиотек часто приходится подпиливать. А базовые вещи, нужные всем, думаю со временем будут включены в html6 или что там будет.
                        +1
                        можете посмотреть, библиотека CornerJS. Я начал ее вести от директив ангуляра, там был похожий синктаксис: имя директивы — колбэк.
                        Директива — тэг, стиль или атрибут (с префиксом directive или data). Со временем (где-то полгода) это преобразилось в реально подобие x-tags: колбэк на добавление директивы в дом-дерево (оох я намучался с добавлением или удалением класса к существующему элементу), колбэк на деструктор, колбэк на смену атрибута. На создание тэга это было нереально в силу особенностей реализации: если конструктор-колбэк для HTMLCustomElement может быть создан, то на добавление класса или атрибута это слабореализуемо.

                        К моей радости, у нас появилось достаточно большое количество джуниоров, которые открыты к новым концепциям. Особенности и механики CornerJS они освоили за часа четыре, после этого появился небольшой внутренний репозиторий директив: удобный скроллбокс, несколько дропдаунов, обертка для mediaelement.js, слайдер, попапы, в общем стандартный базовый набор.
                        На x-tags мы перешли на днях, у ребят по первому проекту на них. Говорят, даже удобнее, правда немного путаются с колбеками на инициализацию. Думаю, следующий проект у каждого из них будет ie10+, и можно будет дать нативные тэги и немножко полимер.

                        Относительно «какие сайты делаем» — разброс большой. В портфолио много промо-проектов, но вот конкретно сейчас я отвечаю за разработку видеопортала/социальной сети для видеомейкеров (не знаю как это правильно назвать). Сейчас где-то на две трети уже все готово, запущено, работает. Если посмотреть по распределению количества кода на фронтэнде: 10% ядро приложения, 40% скомпилированные шаблоны, 40% — директивы. 10% — вендорные либы. Больше кода нет. Суммарно это весит где-то 800кб, в гзипнутом состоянии — 220кб. Там, к сожалению, шаблоны не жмутся даже через простейший компрессор, просто перестают отрабатывать, поэтому так хорошо жмется. Пока не успеваю сесть и разобраться в чем дело, а так — в сжатом состоянии оно выходило около 400кб, ну и жалось до 150.
                        Ладно, это долгая история, и ей тоже место на хабре, но когда во-первых ядро выползет в опенсорс (я сейчас этим занимаюсь, будет простейший изоморфный express-мимикрирующий фреймрорк), а во-вторых мы закончим этот проект. Сейчас он по скорости работает быстрее чем ютуб, и это уже с учетом того, что мы при запуске немного накосячили, и теперь ориентированный на русскую команду сайт хостится в ДЦ амазона Северной Вирджинии. Думаем перевести в Ирландию в следующем месяце. Ладно, это долгая история, куда-то меня не туда понесло.

                        В общем, я хотел сказать, что на опыте нескольких команд, работающих с совершенно разными как по контенту, так и по формату сайтами, и работая на немного разных языках (треть команды пишет на coffeeScript, это считается ок, плюс лично я заигрываю с TypeScript и Dart), мы используем 20-40% написанных в прошлых проектах директив. Правда, они не считаются за компоненты, и они могут играть вполне прикладную роль, в том числе роль «костыля» — например, есть директива, которая закрывает попап через n секунд после появления, соответственно в попап добавляется эта директива, и по его появлению начинает работать.
                        К тэгам сразу же заложено более аккуратное отношение инициативой сверху.
                          0
                          Спасибо за ответ. Просто мне кажется, что компоненты будут нужны только там, где очень жесткие требования к стилю оформления сайта, а сам сайт крупный, с постоянным добавлением нового фунционала, полностью динамический — в смысле абсолютно никакого рендеринга на стороне сервера. И кроме vk.com, last.fm да интернет-банкингов, других таких назвать сходу не могу. И я не могу сказать, что таких сайтов большинство, несмотря на то, что средства для создания таковых появились уже лет 5 назад.
                            +1
                            нет, почему? рендеринг может быть на обоих сторонах: это может быть полностью-фронтэнд сайт (ангуляр без модуля для express,), правда в этом случае будут некоторые небольшие тонкости в связи с шаблонами, классический с перезагрузкой между страницами, и stateless (не знаю как правильно назвать) с первоначальной загрузкой уже отрендеренной страницы и дальнейшими динамическими переходами.
                0
                Спасибо за отличную статью, с ее помощью в голове все уложилось лучше чем от прошлой. Даже понял, что был не совсем корректен сравнивая Dojo Widgets и Web Components.

                Но JavaScript API работы с компонентами так и не понял. Если JS внутри компонента изолирован, то как компонент общается с внешним миром? Выставляет set/get/watch? Судя по статье на html5rocks он вообще ничего не предоставляет и set/get и методы работы с дочерними компонентами нужно описывать самому. Polymer позволяет регистрировать созданные виджеты и выставлять их свойства в качестве атрибутов, но в описании Web Components я ничего такого не нашел.

                Абсолютная самостоятельность компонентов может быть очень вредна. Без механизма наследования и зависимостей мы рискуем получить сайты, которые подключают десятки надерганных из разных мест компонентов, которые на 90% имеют дублирующий код. Собственно как сейчас часто происходит с JQuery плагинами.
                  0
                  ну, я просто не понаслышке знаком с этими механизмами, и хотел попытаться объяснить, почему все сделано именно так — в меру моего понимания. Это не официальная точка зрения, просто я самостоятельно ко всему этому пришел с другой стороны вообще, и вижу теперь причины сложных решений.
                  Статья вообще начиналась про то, что писать свои костыли для запуска кода на появление элемента в dom-дереве моветон, и хотел рассказать о том, какие косяки всплывут. В статье $.whenLive я начал, хотел расписать поподробнее, и вот что вышло)

                  Насчет инкапсуляции JS — гхм, ну тут не совсем корректно говорить именно про инкапсуляцию. Суть в том, что все сводится к HTMLCustomElement.prototype. Вы можете создавать любые элементы, при этом у них будет общий интерфейс: новые методы и свойства нативных элементов, это будет ожидаемо, и будет нормально работать умная IDE, подсказывая методы.

                  Относительно механизма наследования и зависимостей — вопрос решается CDN и централизованным репозиторием, не пакетным менеджером даже.
                  Подход простой: 1 тэг == 1 html import до него. Все зависимости так же подключаются импортами. Дальше в дело вступают нативные механизмы кэширования браузера, и в итоге подсасывается минимум библиотек. В идеале — на таком CDN должно быть выставлено «вечное» кэширование, и единожды загруженный элемент будет загружаться всегда из кэша. Это немного замедлит загрузку одиночных сайтов, но значительно ускорит веб в целом.
                    0
                    Статья вообще начиналась про то, что писать свои костыли для запуска кода на появление элемента в dom-дереве моветон, и хотел рассказать о том, какие косяки всплывут

                    Никогда не понимал зачем такое может понадобится. Даже с появлением mutationobserver это лишняя нагрузка на браузер и выглядит как ошибка в логике приложения.

                    нормально работать умная IDE, подсказывая методы

                    умные IDE это и сейчас умеют. Для сторонних фреймворков проблема решается созданием словаря API виджетов во время сборки проекта и скармливанием его движку autocomplete-a IDE. В нашем фреймворке так и делаем.

                    Про импорты не понял. Например, сейчас у меня есть миксин _FormValue от которого наследуются все инпут-виджеты. Кто-то из них оставляет отнаследованный метод, кто-то его оверрайдит. Как такой же механизм может быть реализован в компонентах?

                    «вечное» кэширование, и единожды загруженный элемент будет загружаться всегда из кэша

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

                      Я тоже, но за последнюю неделю видел две таких библиотеки, одна в посте тут с пятидесятью с лишним плюсами, другую — в trending гитхаба. Потому и хотел обьяснить неправильность.

                      С наследованием — там все проще некуда, по сути это «почти-честные-классы». У элемента обьявляются методы и свойства. Если другой элемент его расширяет — методы-свойства родителя наследуются. Ну как всегда, все довольно предсказуемо.
                      Там же вроде бы достаточно сильный акцент был сделан на расширение встроенных классов, чтобы можно было буквально в двадцать строк сделать свой x-form и x-input.

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


                      Вы с google hosted libraries разве не работали?
                      Посмотрите на пример пути и все сами поймете

                      //ajax.googleapis.com/ajax/libs/angularjs/1.2.10/angular.min.js
                  0
                  Как то всё очень сложно. Мне кажется веб всё дальше превращают в крайне сложную и наслоеную архитектуру. По моему в рамках HTML/CSS/JS не надо ничего придумывать, надо найти замену для этого зоопарка.
                    0
                    Правильно ли я понял, что Web Components это очередной клей между различными подсистемами где часть из этих подсистем реализованы нативно в браузере? Мне это напоминает:
                    image

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

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