Вопросы к UI. Шаблон компонента. Основная часть

Была история, - подавал, мне грамотно обосновали отказ, посоветовали путь решения.

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

Вы попробуйте - в любом случае это не повредит.

Вопросы к UI. Шаблон компонента. Основная часть

Вы спрашиваете - чего не хватает в DOM.

Называю.

Вы - ну этого нет в спецификации!

Ну конечно нет, раз этого нет среди фич)

Ещё разик напишу, если Вам не удалось прочитать с первого захода ;)
- Если Вы считаете что какая-та функциональность необходима, - Вы можете обратиться в группу разработки стандартов.

Придётся обосновать необходимость и сделать внятное предложение.

Работа со стилями - предполагаемое поведение от дом. Он должен давать все возможности необходимые для реализации всех аспектов верстки через js.

Предполагаемое поведение DOM - это работа с нодами, и она вполне адекватно реализована, включая и работу со стилями элементов.

Работа с классами CSS реализована в API CSSOM и там (как Вам уже справедливо указали) можно и классы создавать и псевдо классы к селекторам навешивать.

Здесь опять, если Вы знаете как улучшить API - делайте предложение. Отказ обычно грамотно обосновывают :)

Вопросы к UI. Шаблон компонента. Основная часть

Эта притензия не совсем к DOM.
Насколько я знаю, ожидаемое Вами поведение не является частью спецификации. Попробуйте сформулировать и отправить предложение в группу разработки стандартов.

Но как Вы сами заметили

Тут есть сотни нюансов

Вопросы к UI. Шаблон компонента. Основная часть

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

Вопросы к UI. Шаблон компонента. Основная часть

С DOM в том и проблема, что в него заложено крайне мало возможностей по работе с элементами. Либо сделано это как-то криво, недоработано, не покрывает всех функций.

Хм, крайне спорно, DOM - это такой турбо composite, которого больше нигде нет. Не могли бы Вы привести пример возможности по работе с элементами, которой нет в DOM?

Каких функций не хватает?

Вопросы к UI. Шаблон компонента. Введение

Да думаю многие просекли, просто непонятен результат ваших изысканий, всё-то Вам не нравится: SGML Вам колючий, React душный, CSS слишком отдельный...

Будут конкретные предложения?

Не томите :)

Народный браузер — каким он мог бы быть?

Инструменты разработчика -> вкладка сеть

Вопросы к UI. Шаблон компонента. Введение

Заинтриговали, жду следующего доклада

Вопросы к UI. Шаблон компонента. Введение

Как я понял, вы говорите уже о какой-то конкретной реализации, и вашем опыте с ней.

Ну а был бы смысл говорить о чём-то не конкретном? ;)

Но дьявол в деталях, нужно целиком отсматривать предложенное вами решение, анализировать проекты. активно писать на нем.

Весь дьявол в DOM API, думаю Вы с ним знакомы не понаслышке, библиотека просто даёт возможность масштабировать наиболее очевидное совмещение HTML и JS

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

Здесь нет синтаксиса - его вовсе нет.

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

Субъективщина :)

Вопросы к UI. Шаблон компонента. Введение

Макеты - не шаблоны, клея 2k (с lazy loading модулей 3.7k), работаем прямо с DOM
живых объектов, как в детстве :)

Как не жонглируй троицей технологий, и всеми подобными подходами, в среднем получится что-то вроде ...

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

Вопросы к UI. Шаблон компонента. Введение

Декларативный HTML/XML макет, императивно (ручками :) шатаем из прямо связянного с макетом скрипта

--hello-world component
<div beans-as="hello-world" beans-shadow="mode=closed;delegatesFocus=true">
	<h1 beans-body></h1>
	<input beans-ref="input" placeholder="type your name here">
	<h2>Hello <span beans-ref="name">Anonymous</span>!</h2>
	<script>
		$ref.input.oninput = (e) => {
			this.beanUpdate($ref.input.value)
		}

		this.onBeanUpdate = (data) => {
			$ref.name.innerText = data || 'Anonimous'
		}
	</script>
</div>

--root of app
<div beans-as="double-hello-world">
		<hello-world>Hello first</hello-world>
		<hr>
		<hello-world>Hello second</hello-world>
</div>

• как-то так, здесь два компонента, один использует другого

• всё это заливается в фабрику

• из фабрики берётся скриптом и монтируется туда, куда нужно

Вопросы к UI. Шаблон компонента. Введение

Основной посыл статьи - поставить под сомнение текущие реализации шаблонов.

Поставил бы под сомнение шаблоны как таковые.

Новый фронтенд-фреймворк?

как всегда - хотелось бы увидеть реализацию "стандартного" приложения, чтобы было с чем сравнить https://todomvc.com/

А что, так можно было?

Извиняюсь конечно, но опять скажу - использовать CustomElements как единственную основу для декомпозиции - это приблизительно как использовать js без модулей и closures

А что, так можно было?

W3View ? ванильные компоненты без магии

А что, так можно было?

а ведь можно и

<button onclick="increment()">Click me!</button>

так тоже было можно ;)

А что, так можно было?

ну так-то можно конечно, но придётся добавить пару аргументов и превратить эту красоту в вырвиглазную зубодробильню :)

HTML-теги с искусственным интеллектом

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

HTML-теги с искусственным интеллектом

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

:) "синтаксис кастомных тегов" никогда не проверяется в общем реестре, просто потому, что никогда не попадает в общий скоуп, ну кроме тех случаев, когда это оправданно и делается преднамеренно.

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

Для решения этой проблемы есть такая штука как тег 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 или посмотрит мои публикации на хабре, в любом случае диалог получился приятный и содержательный, спасибо за развёрнутую обратную связь.

HTML-теги с искусственным интеллектом

Эта проблема имеет множество решений, от совсем простых, типа соглашений о нейминге (префиксы, постфиксы), до более сложных, в виде дополнительного контроля регистрации компонентов, на уровне библиотеки. В частности, в Симбиот встроено такое решение.

На мой (возможно избыточно придирчивый и возможно недостаточно компетентный) взгляд - здесь любое решение выглядит как костыль. Лучше избежать проблем, тогда и решать их не придётся.

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

С CustomElements точно так-же приходится ручками инициировать и подчищать хвосты.

И потом, я не предлагаю отказываться от CustomElements как таковых, просто не использовать их для внутренней декомпозиции приложения, можно завернуть ВЕСЬ виджет в один CustomElement и максимально избежать воздействия внешней среды минимально воздействуя на неё в свою очередь.

А потом, когда ваш компонент станет действительно сложным,

Я сделаю декомпозицию, - это почти бесплатно ;)

вы НЕИЗБЕЖНО начнете путаться в этих повторениях.

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

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

Опять-же, предпочитаю не привязывать данные к текстовым нодам а использовать <span ref="key">, ну и собрать строку любым способом мне тоже никто не запрещает.

PS. На виджетах я сам "собаку съел". И даже продолжаю есть. Именно так и появился Симбиот.

А я ушёл таки в бэк, ибо там где я сейчас работаю, на фронте безраздельно свирепствует React :)