Извиняюсь конечно, но опять скажу - использовать CustomElements как единственную основу для декомпозиции - это приблизительно как использовать js без модулей и closures
Ок, даже если так, вы же понимаете, что ваша либа этих проблем никак НЕ избегает? Вы используете синтаксис кастомных тегов, а они проверяются в общем реестре и могут точно также конфликтовать при наличии в общем скоупе других кастомных тегов.
:) "синтаксис кастомных тегов" никогда не проверяется в общем реестре, просто потому, что никогда не попадает в общий скоуп, ну кроме тех случаев, когда это оправданно и делается преднамеренно.
Пример, приведённый мной - это модуль, - библиотека компонентов, которая может подгружаться со всеми зависимостями по требованию или доставляться в преобразованном виде в составе бандла.
Для решения этой проблемы есть такая штука как тег template, но вы его не используете. Как не используете многих других современных стандартов для избежания проблем.
Ну какие современные стандарты template в продакшене, в 2016 году, ну в самом деле? (Библиотека, способна работать в ИЕ-8 без полифиллов :) )
Вы понимаете разницу между инкапсулированной инициализацией компонента изнутри, по коллбеку, который вызывается браузером автоматически, и поиском DOM-элементов в документе и инициализацией компонента вручную извне? И тоже самое касается очистки памяти.
Компонент - это и есть капсула (DOM + initScript + life cycle handlers), да надо вызвывать component.mount(target, index?) вместо target.appendChild(component) - не большая плата.
Виджеты бывают, условно, распределенными по странице: в одном месте может быть, к примеру, UI для загрузки файла, а в другой - прогресс этой загрузки. Помимо этого, у вас может быть библиотека общих UI-примитивов, которая может использоваться как "внутри" так и "снаружи". Помимо этого, вас кейс подразумевает ваш полный контроль над содержимым виджета, а значит, отсутствие проблем с общей областью для имен кастомных тегов.
Это ВСЁ поддерживается, а про общую видимость имён я уже написал чуть выше :)
И никаких проблем с дебагером при использовании биндингов нет, это такой-же javascript,
Предполагаю - он всё-же немного под капотом, про пограничные случаи недопонял,
Вы можете предпочитать такой подход ровно до того момента, пока он не перестанет работать.
Это справедливо для любого подхода
Доминирование React, на мой скромный взгляд, это очень печальная ситуация. Надеюсь она будет меняться, так как технически и концептуально - React совсем не достоин такой популярности и обладает огромным количеством недостатков.
Здесь поддерживаю абсолютно, но на изменение ситуации не надеюсь
Но в данном случае, мы тут сравниваем production-ready библиотеку, которая активно тестируется и используется другими разработчиками в ЗНАЧИТЕЛЬНОМ количестве очень разных кейсов, и ваш эксперимент. Интересный эксперимент, но не более того пока, уж простите.
Мы тут сравнивали библиотеку, реализующую DSL и практически ванильный HTML+JS с оочень тонкой надстройкой для инкапсуляции разметки и логики работы с ней в переиспользуемых компонентах.
Даже не представляю себе кейсов, с которыми связка HTML+JS не справится.
PS: С моей стороны было наивно полагать, что кто-то воспользуется Google или посмотрит мои публикации на хабре, в любом случае диалог получился приятный и содержательный, спасибо за развёрнутую обратную связь.
Эта проблема имеет множество решений, от совсем простых, типа соглашений о нейминге (префиксы, постфиксы), до более сложных, в виде дополнительного контроля регистрации компонентов, на уровне библиотеки. В частности, в Симбиот встроено такое решение.
На мой (возможно избыточно придирчивый и возможно недостаточно компетентный) взгляд - здесь любое решение выглядит как костыль. Лучше избежать проблем, тогда и решать их не придётся.
А вот без CustomElements, вам придется ручками все постоянно инициализировать и убивать, ручками искать и указывать элементы, где должна происходить инициализация - и вот это уже, проблема куда более серьезная, особенно для виджетов, которые могут использоваться в динамической и неконтролируемой, непосредственно вами, среде.
С CustomElements точно так-же приходится ручками инициировать и подчищать хвосты.
И потом, я не предлагаю отказываться от CustomElements как таковых, просто не использовать их для внутренней декомпозиции приложения, можно завернуть ВЕСЬ виджет в один CustomElement и максимально избежать воздействия внешней среды минимально воздействуя на неё в свою очередь.
А потом, когда ваш компонент станет действительно сложным,
Я сделаю декомпозицию, - это почти бесплатно ;)
вы НЕИЗБЕЖНО начнете путаться в этих повторениях.
Здесь вопрос предпочтений, - я предпочитаю путаться в коде, Вы видимо предпочитаете путаться в binding'ах, я предпочитаю использовать при распутывании дебаггер, Вы очевидно используете что-то другое.
А еще, вам может понадобится привязывать данные напрямую к текстовым нодам, и тут вообще полный караул.
Опять-же, предпочитаю не привязывать данные к текстовым нодам а использовать <span ref="key">, ну и собрать строку любым способом мне тоже никто не запрещает.
PS. На виджетах я сам "собаку съел". И даже продолжаю есть. Именно так и появился Симбиот.
А я ушёл таки в бэк, ибо там где я сейчас работаю, на фронте безраздельно свирепствует React :)
Да, нативное всегда лучшее, согласен, но проблема CustomElements в том, что они регистрируются на глобальном уровне и иногда это мешает. Я некоторое время назад (лет восемь наверное прошло :) ) занимался поставкой достаточно сложных виджетов на клиентские сайты, и было бы очень не православно гадить в глобальную область видимости своими кастомными тегами переключателей, слайдеров и прочей мелочью (которой было достаточно много).
Собственно жизненный цикл это всего шесть хендлеров и требование пользоваться специальными (нестандартными) методами компонентов в пределах приложения, никаких других проблем.
//hello-world component
<div as="hello-world">
<h1 ref="content"></h1>
<input ref="input" placeholder="type your name here">
<h2>Hello <span ref="name">Anonimous</span>!</h2>
<script type="javascript">
var me=this;
this.ref.input.oninput = function(e){
me.setData(me.ref.input.value);
};
this.onSetData = function(data){
me.ref.name.innerText = data || 'Anonimous';
};
</script>
</div>
//root of app
<div as="double-hello-world">
<hello-world>Hello first</hello-world>
<hr>
<hello-world>Hello second</hello-world>
</div>
И никакого повторяющегося кода :)
А CustomElements очень хороши для изоляции стилей и красивой установки виджета, тогда приходилось с этим приседать и наклоняться ;).
Прочёл все Ваши статьи и заметил что с каждой итерацией Symbiote становится всё больше похож на W3View, который существует уже с 2016 года практически без изменений.
Осталось только отказаться от использования CustomElements в качестве основы для внутренней компоновки, ну и пройтись бритвой Оккама по всяким модным двусторонним связываниям - this.ref - вполне достаточен.
В целом этот тренд всецело поддерживаю - HTML, CSS и JS - это всё что нужно для построения приложений любой сложности.
Хотите сказать что Virtual DOM чудесным образом уменьшает это все при добавлении одной ноды в дерево?
Я открывал профилировщик и сравнивал React с одной мало известной библиотекой - результат время на рендеринг без изменений, процессор и память в разы больше утилизируются при использовании Virtual DOM
Virtual DOM был придуман не для оптимизации перерисовки, а для того чтобы натянуть сову на глобус - заменить innerHTML и продолжать генерить страницы как привыкли.
И пусть REACT, на мой взгляд, не шибко хорошо демонстрирует эту идеологию, зато, в своё время, он был одним из первых, кто решил вернуть программистов сайтов с императивного пути массового внедрения JavaScript на путь декларативного программирования
коллеги опять перепутали декларативное программирование и декларативный язык разметки :)
:) я придумал — w3view, он обходится без темплет. HTML и JS разделены но код связный, компоненты настоящие, работает быстрее чем react, покрывает 100% потребностей и провоцирует декомпозицию, куда прийти за миллиардом?
Мы может быть и разные, но тараканы у нас одинаковые, универсального решения на все случаи жизни нет и быть не может.
Чем больше на себя берёт библиотека или фреймворк, тем уже скоуп решаемых задач и больше навязываемых ограничений.
как всегда - хотелось бы увидеть реализацию "стандартного" приложения, чтобы было с чем сравнить https://todomvc.com/
Извиняюсь конечно, но опять скажу - использовать CustomElements как единственную основу для декомпозиции - это приблизительно как использовать js без модулей и closures
W3View ? ванильные компоненты без магии
а ведь можно и
так тоже было можно ;)
ну так-то можно конечно, но придётся добавить пару аргументов и превратить эту красоту в вырвиглазную зубодробильню :)
хм, не нашёл такого в спецификации, в принципе вводить кастомные атрибуты без префикса было ошибкой
:) "синтаксис кастомных тегов" никогда не проверяется в общем реестре, просто потому, что никогда не попадает в общий скоуп, ну кроме тех случаев, когда это оправданно и делается преднамеренно.
Пример, приведённый мной - это модуль, - библиотека компонентов, которая может подгружаться со всеми зависимостями по требованию или доставляться в преобразованном виде в составе бандла.
Ну какие современные стандарты template в продакшене, в 2016 году, ну в самом деле? (Библиотека, способна работать в ИЕ-8 без полифиллов :) )
Компонент - это и есть капсула (DOM + initScript + life cycle handlers), да надо вызвывать component.mount(target, index?) вместо target.appendChild(component) - не большая плата.
Это ВСЁ поддерживается, а про общую видимость имён я уже написал чуть выше :)
Предполагаю - он всё-же немного под капотом, про пограничные случаи недопонял,
Это справедливо для любого подхода
Здесь поддерживаю абсолютно, но на изменение ситуации не надеюсь
Мы тут сравнивали библиотеку, реализующую DSL и практически ванильный HTML+JS с оочень тонкой надстройкой для инкапсуляции разметки и логики работы с ней в переиспользуемых компонентах.
Даже не представляю себе кейсов, с которыми связка HTML+JS не справится.
PS: С моей стороны было наивно полагать, что кто-то воспользуется Google или посмотрит мои публикации на хабре, в любом случае диалог получился приятный и содержательный, спасибо за развёрнутую обратную связь.
На мой (возможно избыточно придирчивый и возможно недостаточно компетентный) взгляд - здесь любое решение выглядит как костыль. Лучше избежать проблем, тогда и решать их не придётся.
С CustomElements точно так-же приходится ручками инициировать и подчищать хвосты.
И потом, я не предлагаю отказываться от CustomElements как таковых, просто не использовать их для внутренней декомпозиции приложения, можно завернуть ВЕСЬ виджет в один CustomElement и максимально избежать воздействия внешней среды минимально воздействуя на неё в свою очередь.
Я сделаю декомпозицию, - это почти бесплатно ;)
Здесь вопрос предпочтений, - я предпочитаю путаться в коде, Вы видимо предпочитаете путаться в binding'ах, я предпочитаю использовать при распутывании дебаггер, Вы очевидно используете что-то другое.
Опять-же, предпочитаю не привязывать данные к текстовым нодам а использовать <span ref="key">, ну и собрать строку любым способом мне тоже никто не запрещает.
А я ушёл таки в бэк, ибо там где я сейчас работаю, на фронте безраздельно свирепствует React :)
Да, нативное всегда лучшее, согласен, но проблема CustomElements в том, что они регистрируются на глобальном уровне и иногда это мешает.
Я некоторое время назад (лет восемь наверное прошло :) ) занимался поставкой достаточно сложных виджетов на клиентские сайты, и было бы очень не православно гадить в глобальную область видимости своими кастомными тегами переключателей, слайдеров и прочей мелочью (которой было достаточно много).
Собственно жизненный цикл это всего шесть хендлеров и требование пользоваться специальными (нестандартными) методами компонентов в пределах приложения, никаких других проблем.
И никакого повторяющегося кода :)
А CustomElements очень хороши для изоляции стилей и красивой установки виджета, тогда приходилось с этим приседать и наклоняться ;).
Прочёл все Ваши статьи и заметил что с каждой итерацией Symbiote становится всё больше похож на W3View, который существует уже с 2016 года практически без изменений.
Осталось только отказаться от использования CustomElements в качестве основы для внутренней компоновки, ну и пройтись бритвой Оккама по всяким модным двусторонним связываниям - this.ref - вполне достаточен.
В целом этот тренд всецело поддерживаю - HTML, CSS и JS - это всё что нужно для построения приложений любой сложности.
Успехов
Вообще-то виртуал дом это оптимизация innerHTML и с ним заведомо медленнее чем с натуральным DOM
Маленькое уточнение - JS начинает работать не после загрузки страницы а в процессе
Хотите сказать что Virtual DOM чудесным образом уменьшает это все при добавлении одной ноды в дерево?
Я открывал профилировщик и сравнивал React с одной мало известной библиотекой - результат время на рендеринг без изменений, процессор и память в разы больше утилизируются при использовании Virtual DOM
Virtual DOM был придуман не для оптимизации перерисовки, а для того чтобы натянуть сову на глобус - заменить innerHTML и продолжать генерить страницы как привыкли.
которой нет
Отличная была практика, отказ от нее привел к тому, что верстальщики решили что они стали программистами.
коллеги опять перепутали декларативное программирование и декларативный язык разметки :)
Чем больше на себя берёт библиотека или фреймворк, тем уже скоуп решаемых задач и больше навязываемых ограничений.