Карго-культ HTML в современном фронтенде

Практика показывает, что набор императивных правил почти всегда удобнее и проще для понимания, чем увесистое декларативное дерево. Сравните, к примеру, императивный Gulp c декларативным Grunt или монструозный декларативный конфиг Webpack, особенно ранних версий с симфоневской оберткой вокруг него — Encore. А самое веселье, когда декларативное дерево содержит явно выраженные итерации или рекурсию и разработчики пытаются соблюдать DRY без применения декомпозиции.
Оптимальным же, на мой взгляд, является комбинирование подходов, когда минимальные фрагменты остаются декларативными шаблонами, а все какие-либо структуры формируются императивным кодом.

Он мало того, что в несколько раз меньше эквивалентного JSX кода, так из него ещё и легко

Как минимум для меня он не меньше. Он может быть короче, но не меньше. У такого кода огромная когнитивная нагрузка. Хотя возможно это частично связано с отсутствие подсветки, но чтение вот этого куска

$my_example $mol_view
    sub /
        <= Panel $my_bipanel
            left <= input /
                <= Editable $mol_check_box
                    checked?val <=> editable?val true
                    title @ \Editable

У меня вызвало кучу вопросов:
1) Что делают прямые и обратные слэши? Когда они нужны? Почему после sub есть прямой слэш, а перед Editable — обратный? А после $my_bipanel вообще ничего нет
2) checked?val — это одна переменная или две переменные и оператор?
3) Что делают < = и <= >? Это передача параметров компонента? Но тогда почему слева от <=> один параметр checked?val, а справа два параметра editable?val и true? Или Всё таки слева два параметра, а справа — 4?
4) В строке <= Panel $my_bipanel Panel — это компонент, а $my_bipanel параметры? Или Panel — это слот у sub, а $my_bipanel — компонент?
5) Почему оператор? пишется слитно спараметрами, а @ — раздельно.
Итого 5/7 WTF/line. Весьма дофига.

Кстати, насчет JSX и его карго-культа HTML, который хоть и не нужен, но оказался полезен. У JSX есть фундаментальное достоинстве в сравнении с типичными языками шаблонов. JSX предствавляет собой фактически JavaScript (ну или TypeScript) код, записанный в чуть другой нотации. Он не требует никакого контекста для однозначной трансляции в JS. Более того он взаимооднозначно транслируется в JS. Код JS, бывший до этого JSX, всегда можно гарантировано и однозначно перегнать обратно в JSX (ну за мелким исключение в виде короткой записи для булевых параметров со значением true). А из этого следуют некоторые его дополнительные свойства:
— Добавлять JSX в транслятор языка достаточно один раз, вам не придётся портировать в JSX новый синтакстис скажет ES2020 вроде "?." и "??", как приходится делать разработчикам Angular с его языком шаблонов.
— Для JSX кода автоматически будут нормально работать линтеры и большинство правил, касающихся JS.
При всем при этом JSX всё ещё синтаксически похож на HTML. Сочетание всех этих факторов позволет JSX'у постепенно доносить до разработчиков простую мысль: «Отдельный язык шаблонов не особо и нужен.» Просто описывайте иерархию ваших компонентов на том же языке, что и всё остальное. Быстрее всего это как не странно дошло до мобильных и десктоп разработчиков с KotlinUI, SwiftUI и Flutter'ом. При том что сама идея не особо нова и Java код писался внутри JSP ещё хрен знает когда, а PHP вообще изначально был именно языком шаблонов. Но у большинства популярных языков из 90-х было всё очень плохо с декларативным синтаксисом, и специально написанные шаблонизаторы оказались вроде бы короче. Только это было лечением симптомов, а не болезни.

А карго-культ HTML и правда не нужен. По крайней мере синтаксически.

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

html`<div style=${{transform: `translate(${x}px, ${y}px)`}}>
     ${users.filter(u => u.IsActive).map((user,index) => html(user.Id)`
           <user user=${user}/>
     `}
</div>`

HyperHTML
Учить 1 день, скорость хорошая, памяти требует мало. Никакой магии внутри, код библиотеки понять довольно быстро.

Весьма похоже на HTML, но только это не HTML, чтобы там ни говорили Angular-евангелисты.

Ваш HTML-валидатор, похоже, имеет мнение, отличное от стандартного валидатора. Стандартный валидатор не возражает против ангулярских атрибутов, хотя пишет предупреждения, что эти атрибуты не будут сериализоваться в XML. Вставка кода шаблона в HTML документ в браузере никаких проблем не вызывает, он парсится в DOM без ошибок. Так что ангуляровцы правы: синтаксически это валидный HTML. Семантически же — это расширение, использующее допустимые синтаксические возможности (все эти префиксы и скобочки в именах атрибутов). Так как эти возможности никем до этого не использовались, то и неоднозначности не возникает.

То есть это мало того, что не HTML, так это ещё и вовсе не шаблон.

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

И это таки HTML, поэтому шаблонизаторы/трансформеры/конфигураторы вполне могут десериализовать его текстовое представление в DOM-фрагмент, трансформировать его и, если надо, десериализовать обратно без потерь.

Это — язык для компоновки компонент, мимикрирующий под HTML.

Следом, после ранта про недекларативность реакта, вы пишете:

Чтобы добиться гибкости, но не потерять декларативность, нужно разбивать код компонента на 2 части:

• Декларативная, где происходит компоновка компонент друг с другом.
• Императивная, где описывается логика работы.

Так что не так? Шаблоны ангуляра — это первая часть. Т.е. главная претензия — это не то, что он "язык компоновки", а лишь "мимикрия"? Но, как выясняется, это не мимикрия, а расширение, и использование всем известного синтаксиса — это большой плюс, так как снижается когнитивная нагрузка. Вдобавок, использование именно валидного декларативного HTML — это путь к созданию желаемых вами "конфигураторов". Впрочем, к полезности последних у меня крайне скептическое отношение — все визуальные конструкторы UI/code/database, которые я использовал, в конце концов шли в помойку из-за своей ограниченности и слабой расширяемости, и всё возвращалось к "code first" (где есть декларативность через FP или через fluent-style) и, максимум, превью результата.