Да, это можно сделать, но загвоздка в том, что тот же lit-html накладывает правила на написание темплейтов (к примеру, html`<div ?disabled=...  или html`<my-list .listItems=...) в итоге мы опять начинаем учить и использовать что-то про инструмент (неважно библиотека или фреймворк). Получается для конечного разработчика что lit-html, что react, что angular - разницы нет. Т.е. мы не можем просто взять и заменить lit-html на что-то другое.

Я пробовал делать следующую штуку, писал компонент на hyperHTML, потом пытался его использовать в lit-html компоненте (и наоборот). И по факту это не работает, у них есть проблемы взаимодействия при обновлении и при передаче параметров.

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

есть одна проблема - scheduling рендеринга
она пока не решена на уровне платформы, поэтому различным библиотекам для WC может быть сложно синхронизировать ререндеринг
может быть у тебя было что-то на этом уровне

Возможно. Про сахар, я тоже за, в этом плане мне очень нравится как работает typescript, т.е. по факту мы получим тот же js (на выходе нет никакого ts). В идеале я бы наверное хотел что-то вроде этого для wc. Чтобы была либа или фреймворк, и этот инструмент даст возможность писать быстро и безопасно, но на выходе самого этого инструмента не будет - только платформа, только хардкор). Таким образом не будет завязки на дополнительный уровень абстракции в скомпилированном компоненте.

Stencil компилирует как раз в vanilla wc.

LitElement это все таки фреймворк на основе веб-компонентов и шаблонизатора lit-html

ну да Stencil

да, Stencil близок к этому, но у него есть VDOM

Stencil больше фреймворк, чем LitElement, как по мне

считай что VDOM это просто либа)

на мой взгляд, код для lit-element можно по максимуму выносить в миксины и стараться не завязываться на рендер

при таком раскладе технически lit-html можно и заменить (UpdatingElement это позволяет)

методы lifecycle, такие как update / updated, все равно останутся, но основной lock-in все же не в них заключается

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

lit-html внутри основан на драфте стандартного шаблонизатора Template Instantiation, так хоть есть надежда, что по мере стандартизации он станет тоньше

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

еще новость про Scoped Custom Elements registries

https://github.com/w3c/webcomponents/pull/865

Вроде еще не было? Declarative Shadow DOM

https://github.com/mfreed7/declarative-shadow-dom/blob/master/README.md

было, обсуждали