Посмотрите в сторону shadow dom и вообще веб-компонентов, полимер тут в самый раз.
Вы-то это можете, у вас все под вебкит тут заточено последний.
Если рассказывать кратко — та же изоляция на уровне дом-дерева, но при этом гораздо более удобный интерфейс.
нет, почему? рендеринг может быть на обоих сторонах: это может быть полностью-фронтэнд сайт (ангуляр без модуля для express,), правда в этом случае будут некоторые небольшие тонкости в связи с шаблонами, классический с перезагрузкой между страницами, и stateless (не знаю как правильно назвать) с первоначальной загрузкой уже отрендеренной страницы и дальнейшими динамическими переходами.
можете посмотреть, библиотека 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 секунд после появления, соответственно в попап добавляется эта директива, и по его появлению начинает работать.
К тэгам сразу же заложено более аккуратное отношение инициативой сверху.
Никогда не понимал зачем такое может понадобится. Даже с появлением mutationobserver это лишняя нагрузка на браузер и выглядит как ошибка в логике приложения.
Я тоже, но за последнюю неделю видел две таких библиотеки, одна в посте тут с пятидесятью с лишним плюсами, другую — в trending гитхаба. Потому и хотел обьяснить неправильность.
С наследованием — там все проще некуда, по сути это «почти-честные-классы». У элемента обьявляются методы и свойства. Если другой элемент его расширяет — методы-свойства родителя наследуются. Ну как всегда, все довольно предсказуемо.
Там же вроде бы достаточно сильный акцент был сделан на расширение встроенных классов, чтобы можно было буквально в двадцать строк сделать свой x-form и x-input.
веб постоянно меняется. Если компонент не брошен своим автором, то в нем постоянно будет что-то меняться. И жесткий кеш будет только мешать.
Вы с google hosted libraries разве не работали?
Посмотрите на пример пути и все сами поймете
ну, я просто не понаслышке знаком с этими механизмами, и хотел попытаться объяснить, почему все сделано именно так — в меру моего понимания. Это не официальная точка зрения, просто я самостоятельно ко всему этому пришел с другой стороны вообще, и вижу теперь причины сложных решений.
Статья вообще начиналась про то, что писать свои костыли для запуска кода на появление элемента в dom-дереве моветон, и хотел рассказать о том, какие косяки всплывут. В статье $.whenLive я начал, хотел расписать поподробнее, и вот что вышло)
Насчет инкапсуляции JS — гхм, ну тут не совсем корректно говорить именно про инкапсуляцию. Суть в том, что все сводится к HTMLCustomElement.prototype. Вы можете создавать любые элементы, при этом у них будет общий интерфейс: новые методы и свойства нативных элементов, это будет ожидаемо, и будет нормально работать умная IDE, подсказывая методы.
Относительно механизма наследования и зависимостей — вопрос решается CDN и централизованным репозиторием, не пакетным менеджером даже.
Подход простой: 1 тэг == 1 html import до него. Все зависимости так же подключаются импортами. Дальше в дело вступают нативные механизмы кэширования браузера, и в итоге подсасывается минимум библиотек. В идеале — на таком CDN должно быть выставлено «вечное» кэширование, и единожды загруженный элемент будет загружаться всегда из кэша. Это немного замедлит загрузку одиночных сайтов, но значительно ускорит веб в целом.
очень простой пример. Просто посмотрите на то количество библиотек для jQuery, которое используют люди. Тот же jQuery UI. Фактически любой из них можно просто и непринужденно превратить в автономный компонент, который можно будет подключать даже верстальщику.
И это действительно очень важно. Визуальная составляющая вновь отходит в ведование верстальщиков, а фронтэнд-разработчики становятся именно разработчиками.
Я бы вел весь диалог скорее вот в этом направлении.
А вам правда часто нужно править чужую библиотеку? Воспринимайте это не как часть сайта, но как его изолированный блок. Как… ну, лайки фейсбука. Или Disqus. Вполне возможно, что Disqus сделан на JSX+stylus или Dart+less. Вы ведь не думаете об этом, правда? Ну, вот и тут то же самое. Оно просто работает. Ну, еще надо добавить конфигурацию.
Понимаете, дело именно в том, что я отказался от собственного аналогичного решения, поняв, что оно идет к 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, но в итоге все действительно сведется к нативным вещам, потому что они действительно одновременно более удобные, безопасные, быстрые, и наиболее легкопереносимые. Это факт, и с ним придется мириться тем же фанатам БЭМ, например.
Использовать Shadow DOM само по себе похвально, но вопрос во-первых в том, что это все сведется до ie10+, так как верстать(точнее применять стили) одновременно под shadow dom и не под shadow dom — смерти подобно. А во-вторых возникнет довольно неприятный диссонанс: web components нацелены на то, чтобы объединить различные варианты исполнения библиотек под одним стандартом, а библиотеки ангуляра вряд ли с ним точно совместимы, и визуальные компоненты для ангуляра будут развиваться парралельно.
Я сам все хочу перейти на dart — одни только строковая интерполяция и честные Maps чего стоят. И веб-компоненты, я надеюсь, позволят это сделать в ближайшее время (планируем несколько ie10+ проектов). Но на мой взгляд — лучше одновременно использовать polymer в качестве движка компонентов и анимаций, и angular для именно что логики приложения. Субьективно — им стоит в первую очередь подключить поддержку тэга template (я не знаю, возможно, они уже сделали, я честно не успеваю за всем развитием следить), чтобы Пользовательские Тэги могли безболезненно держаться в шаблонах. А сам по себе shadow DOM, насколько помню, убыстряет работу рендера (за счет того что тэги внутри теневого DOM не учитываются в querySelector, а внутри себя их хранится совсем немного), так что да, начинание замечательное. По моей опять же субьективной оценке — доля старых ie в большинстве сегментов снизится до 1-2% суммарно приблизительно к лету, если судить по динамике, и большинство команд будет иметь возможность работать со всем стеком Веб Компонентов.
Это не заблуждения, это опыт, который я реально получил от создания аналогичной библиотеки и использования ее в течении приблизительно с июля этого года внутри собственной команды и в нескольких дружественных.
Подход «один тэг — один инициализатор» верен и в таких условиях единственно правилен, так как ты никогда не знаешь, какая из команд отработает первой. Собственный недавний горький пример научил меня этому: на один селектор были навешаны подгрузка контента (естественно, с заменой innerHTML) и создание скроллбокса. В итоге скроллбокс заменялся контентом, и отладить это было практически нереально.
То же самое с порядком выполнения: если внутри шаблона объявлен видео-инициализатор, вполне возможно, что он отработает первым, и на выходе будет некорректно сформированный тэг video, который уже в дальнейшем не сможет корректно отшаблонизироваться. Подход с @keyframes может казаться удобным, но он лишает вас возможности управлять этим сценарием.
Передавать элемент в качестве this в подобных условиях неразумно: можно создать два совпадающих инициализатора, в которых будет подменяться onMouseOver, например. В итоге будет работать только одно из событий. В моем случае это разруливалось через создание constructor.call(node[directiveName] = Object.freeze(constructor), node, arguments).
Кстати, совсем забыл: у вас нет деструкторов. Это окажется большой проблемой для всех тех элементов, где используется setInterval или requestAnimationFrame. О просторе полета в элементах с window.onresize я молчу.
Еще раз — мне продолжать тыкать в ваши ошибки, которые в итоге затруднят отладку и сделают использование библиотеки сложным или невозможным в многих сложных случаях, или вы задумаетесь, наконец, о том, что не просто так именно к элементам, а не к селекторам присматриваются Mozilla и Google?
Мне весь этот подход, который наблюдается в better-dom, напоминает завывания начинающих разработчиков, которые искренне убеждены, что краткость и чистота кода куда важнее, чем статическая типизация, например, и в панике убегают при виде что Dart или TypeScript, которые на самом деле js с обвесом, что Scala.
ну, вы настойчиво хотите мыслить категориями прежними, даже с новыми технологиями. Не думаю, что кому-то нужно регистрировать события на '.users .userPreview .dropdown:nth-child(5)', например.
Не говоря о том, что сама архитектура достаточно некомфортна для использования.
Во-первых, не стоит завязывать части системы друг на друга. Даже jQuery передает в this нативные элементы — как из-за быстродействия, так и из-за совместимости с библиотеками. Обернуть в $() не составляет проблем, а ресурсы и читаемость значительно выше.
Во-вторых, если вы будете использовать this, указывающий на сам элемент внутри конструктора — вы можете столкнуться с рядом проблем, например — в случае, если совпадет несколько элементов, конструктор будет указывать непонятно на что.
В-третьих — не глядя — вы не знаете вертикальный порядок выполнения и не способны управлять им. Что произойдет, если, например, у вас будет
MutationObserver корректно разруливает подобные ситуации, так как добавляется всегда одна или более нод в списке, одновременного добавления нод с большей и меньшей вложенностью не бывает.
В-четвертых, у вас явно проблемы с событиями, вы их делали «под себя».
Нет и не предусмотрено получения чего-то вроде event.target.className, например.
Ну и в-пятых, идея далеко не нова. X-tags, Polymer. Да и директивы AngularJS (которому уже не первый год) работают по тому же принципу.
Мне продолжать?
тогда в сторону x-tags. там ie9+ за счет того, что нет shadow DOM. Работает оно по крайней мере честнее чем трюки с keyframes. Особенно с учетом того, что mutation events и MutationObserver нацелены на то, чтобы отлавливать события изменения дом-дерева. А @keyframes — нет.
До сих пор не понимаю, почему так много идет акцента на канву. Если у тимлаба тесно интегрирован механизм парсинга док-файлов и вывод на канвас — это повод грустить, а не хвастаться.
это зовется попыткой усидеть на двух стульях — и ноу-хау в рамках заданных стран сохранить, и продавать направо-налево. С точки зрения геополитики — идея хорошая (как я понял из контекста — код предоставляют без проблем, вопрос только в том как бы не продать северной корее и так далее). А со всех остальных — неэтично, да.
это лайки. А шейры довольно прилично себя видут в силу того что это просто ссылка. В этом плане приятнее всего модуль addthis — он показывает исходя из geoIP наиболее популярные кнопки, остальное ныкает. В айфрейм не прячется, большие скрипты не делает (там только работа со счетчиками и колбэки, иногда это необходимо), практически не тормозит систему. Если бы еще вконтакт нормально поддерживал — было бы совсем идеально, а так там только кнопка сейчас, без счетчика
Вы-то это можете, у вас все под вебкит тут заточено последний.
Если рассказывать кратко — та же изоляция на уровне дом-дерева, но при этом гораздо более удобный интерфейс.
Директива — тэг, стиль или атрибут (с префиксом 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 секунд после появления, соответственно в попап добавляется эта директива, и по его появлению начинает работать.
К тэгам сразу же заложено более аккуратное отношение инициативой сверху.
Я тоже, но за последнюю неделю видел две таких библиотеки, одна в посте тут с пятидесятью с лишним плюсами, другую — в trending гитхаба. Потому и хотел обьяснить неправильность.
С наследованием — там все проще некуда, по сути это «почти-честные-классы». У элемента обьявляются методы и свойства. Если другой элемент его расширяет — методы-свойства родителя наследуются. Ну как всегда, все довольно предсказуемо.
Там же вроде бы достаточно сильный акцент был сделан на расширение встроенных классов, чтобы можно было буквально в двадцать строк сделать свой x-form и x-input.
Вы с google hosted libraries разве не работали?
Посмотрите на пример пути и все сами поймете
//ajax.googleapis.com/ajax/libs/angularjs/1.2.10/angular.min.js
Статья вообще начиналась про то, что писать свои костыли для запуска кода на появление элемента в dom-дереве моветон, и хотел рассказать о том, какие косяки всплывут. В статье $.whenLive я начал, хотел расписать поподробнее, и вот что вышло)
Насчет инкапсуляции JS — гхм, ну тут не совсем корректно говорить именно про инкапсуляцию. Суть в том, что все сводится к HTMLCustomElement.prototype. Вы можете создавать любые элементы, при этом у них будет общий интерфейс: новые методы и свойства нативных элементов, это будет ожидаемо, и будет нормально работать умная IDE, подсказывая методы.
Относительно механизма наследования и зависимостей — вопрос решается CDN и централизованным репозиторием, не пакетным менеджером даже.
Подход простой: 1 тэг == 1 html import до него. Все зависимости так же подключаются импортами. Дальше в дело вступают нативные механизмы кэширования браузера, и в итоге подсасывается минимум библиотек. В идеале — на таком CDN должно быть выставлено «вечное» кэширование, и единожды загруженный элемент будет загружаться всегда из кэша. Это немного замедлит загрузку одиночных сайтов, но значительно ускорит веб в целом.
И это действительно очень важно. Визуальная составляющая вновь отходит в ведование верстальщиков, а фронтэнд-разработчики становятся именно разработчиками.
Я бы вел весь диалог скорее вот в этом направлении.
Все те решения, которые сделаны в рамках спеки Веба Компонентов, я прочувствовал на своей личной шкуре в ходе разработки реальных проектов, и получил тот опыт, который нельзя получить, просто сидя и рассуждая об этом всем.
Консорциум молодцы именно в том плане, что для создания единой спецификации регистрирования зависимых изолированных объектов, привязываемых к DOM, учли все ошибки предыдущих подобных архитектур, и то, что есть сейчас в этой спецификации, в общем-то можно сказать что выстрадано.
Я хотел рассказать именно о том, почему были приняты именно такие решения в спецификации, почему они важны для компонентов, и почему это лучшее из того, что есть среди множества вариантов. Ну и, конечно, ответить на кучу еще не заданных вопросов.
Не можем. Какой-нибудь шибанутый (простите) вебмастер может залихватски сделать что-нибудь вроде footer :last-child {margin-right: 20px}, потому что ему надо у всех конечных элементов отступы делать, и все полетит к чертям. Да, это проблема вебмастера, а не разработчика компонента, но лучше бы этой проблемы не было вообще. Мы все делаем решения для людей, а люди могут ошибаться. Поэтому в любом случае нужно подключать shadow DOM, если есть возможность. Вам дают возможность подстелить соломку, так воспользуйтесь ей.
Если честно, я вообще обычно 90% времени на vanilla пишу, если это работа с DOM. Ну это так, лирическое отступление.
Честно говоря, я не могу точно определить, какую вы мысль хотели сказать, но в общем и целом — я скорее склонен согласиться. Нет, Веб Компоненты — это не buzzword, потому что он достаточно сильно ограничен по спецификации, вы не можете взять и воткнуть его куда-то (хотя я верю в то, что продажники в веб-студиях и с этим справятся), в отличии от HTML5, который охватывает такое количество стандартов, что куда не плюнь — всюду он. Анимации, новые интерфейсы, css3, es5, кастомные тэги, канвас, вебгл, сокеты — это все подпадает, и трудно понять, о чем ведет диалог человек. Веб Компоненты же это новый вариант создания модулей, который позовляет получить (почти) гарантированную инкапсуляцию кода, верстки, и стилей, и получить действительно удобный и стандартизированный интерфейс к ним. Именно об этом я и говорю — можно пользоваться БЭМ, React, но в итоге все действительно сведется к нативным вещам, потому что они действительно одновременно более удобные, безопасные, быстрые, и наиболее легкопереносимые. Это факт, и с ним придется мириться тем же фанатам БЭМ, например.
Я сам все хочу перейти на dart — одни только строковая интерполяция и честные Maps чего стоят. И веб-компоненты, я надеюсь, позволят это сделать в ближайшее время (планируем несколько ie10+ проектов). Но на мой взгляд — лучше одновременно использовать polymer в качестве движка компонентов и анимаций, и angular для именно что логики приложения. Субьективно — им стоит в первую очередь подключить поддержку тэга template (я не знаю, возможно, они уже сделали, я честно не успеваю за всем развитием следить), чтобы Пользовательские Тэги могли безболезненно держаться в шаблонах. А сам по себе shadow DOM, насколько помню, убыстряет работу рендера (за счет того что тэги внутри теневого DOM не учитываются в querySelector, а внутри себя их хранится совсем немного), так что да, начинание замечательное. По моей опять же субьективной оценке — доля старых ie в большинстве сегментов снизится до 1-2% суммарно приблизительно к лету, если судить по динамике, и большинство команд будет иметь возможность работать со всем стеком Веб Компонентов.
Подход «один тэг — один инициализатор» верен и в таких условиях единственно правилен, так как ты никогда не знаешь, какая из команд отработает первой. Собственный недавний горький пример научил меня этому: на один селектор были навешаны подгрузка контента (естественно, с заменой innerHTML) и создание скроллбокса. В итоге скроллбокс заменялся контентом, и отладить это было практически нереально.
То же самое с порядком выполнения: если внутри шаблона объявлен видео-инициализатор, вполне возможно, что он отработает первым, и на выходе будет некорректно сформированный тэг video, который уже в дальнейшем не сможет корректно отшаблонизироваться. Подход с @keyframes может казаться удобным, но он лишает вас возможности управлять этим сценарием.
Передавать элемент в качестве this в подобных условиях неразумно: можно создать два совпадающих инициализатора, в которых будет подменяться onMouseOver, например. В итоге будет работать только одно из событий. В моем случае это разруливалось через создание constructor.call(node[directiveName] = Object.freeze(constructor), node, arguments).
Кстати, совсем забыл: у вас нет деструкторов. Это окажется большой проблемой для всех тех элементов, где используется setInterval или requestAnimationFrame. О просторе полета в элементах с window.onresize я молчу.
Еще раз — мне продолжать тыкать в ваши ошибки, которые в итоге затруднят отладку и сделают использование библиотеки сложным или невозможным в многих сложных случаях, или вы задумаетесь, наконец, о том, что не просто так именно к элементам, а не к селекторам присматриваются Mozilla и Google?
Мне весь этот подход, который наблюдается в better-dom, напоминает завывания начинающих разработчиков, которые искренне убеждены, что краткость и чистота кода куда важнее, чем статическая типизация, например, и в панике убегают при виде что Dart или TypeScript, которые на самом деле js с обвесом, что Scala.
Не говоря о том, что сама архитектура достаточно некомфортна для использования.
Во-первых, не стоит завязывать части системы друг на друга. Даже jQuery передает в this нативные элементы — как из-за быстродействия, так и из-за совместимости с библиотеками. Обернуть в $() не составляет проблем, а ресурсы и читаемость значительно выше.
Во-вторых, если вы будете использовать this, указывающий на сам элемент внутри конструктора — вы можете столкнуться с рядом проблем, например — в случае, если совпадет несколько элементов, конструктор будет указывать непонятно на что.
В-третьих — не глядя — вы не знаете вертикальный порядок выполнения и не способны управлять им. Что произойдет, если, например, у вас будет
MutationObserver корректно разруливает подобные ситуации, так как добавляется всегда одна или более нод в списке, одновременного добавления нод с большей и меньшей вложенностью не бывает.
В-четвертых, у вас явно проблемы с событиями, вы их делали «под себя».
Нет и не предусмотрено получения чего-то вроде event.target.className, например.
Ну и в-пятых, идея далеко не нова. X-tags, Polymer. Да и директивы AngularJS (которому уже не первый год) работают по тому же принципу.
Мне продолжать?