@Rahnar если присмотреться к Web Components подробнее, то речь идет о нескольких вещах:

1. Custom elements
2. HTML imports
3. Templates
4. Shadow DOM

Если сравнивать с тем, что предлагает БЭМ, то Custom elements решает ту же задачу, что и BEM-дерево — он предоставляет абстракцию над крайне ограниченным DOM деревом.

HTML imports в любом случае требует сборки («вулканизации» в терминах Web Components).

В качестве Templates у нас BEMHTML и BH. Решают те же задачи, но декларативно.

Shadow DOM по сути призван решить ту же проблему, что у нас решают элементы блоков.

Нам ничего не мешает в какой-то момент изменить шаблоны так, что генерировать БЭМ блоки в виде веб-компонентов. Это можно попробовать сделать даже просто на уровне своего проекта. Но какую практическую пользу это принесет? Где именно ожидается прирост в скорости?

@tadatuta @Rahnar наверное имеет ввиду скорость генерации html. Т.к. этим будет заниматься именно браузер, а не js

@belozyorcev Да , именно об этом и речь. Собственно , интересно было послушать мысли людей по этому поводу. У нас на работе массовые дискуссии идут )

@belozyorcev Вот как выглядят Templates из Web Components:

<template id="template">
  <style>
    ...
  </style>
  <div>
    <h1>Web Components</h1>
    <img src="http://webcomponents.org/img/logo.svg">
  </div>
</template>

<script>
  var template = document.querySelector('#template');
  var clone = document.importNode(template.content, true);
  var host = document.querySelector('#host');
  host.appendChild(clone);
</script>
<div id="host"></div>

1. Сначала хардкодим весь код на страницу в перемешку со стилями, вставляя плейсхолдеры в тех местах, где нужно вывести переменные.
2. Потом пишем JS, чтобы шаблоны заработали.
3. До того, как JS выполнится, получаем проблемы с индексацией поисковиками.

На то, чтобы распарсить шаблоны, заполнить их данными, сгенерировать финальный HTML и вставить его в DOM по-прежнему нужно время. Принципиальный выигрыш по скорости возможен только за счет того, что шаблонизация по принципу интерполяции строк гораздо проще, но и выразить на таких шаблонах мало что можно.

А главное — это то, что из BEMHTML/BH можно сгенерировать такие шаблоны на этапе разработки и задеплоить в продакшен результат, а вот обратное неверно.

@tadatuta ты немного лукавишь. в общем случае из декларативных «шаблонов» можно всегда получить интерполируемые, а обратное неверно, да. Но это именно потому, что шаблоны в приложенном тобой примере интерполируемые, и нет возможности сгенерировать из них BEMHTML/BH. Если бы шаблоны были, скажем, в виде XSL (наиболее близкое и понятное из того, что можно в каком-то виде применить к сырому HTML), то теоретическая возможность сгенерировать BEMHTML/BH уже появилась бы. Кстати, сейчас у нас есть теоретическая возможность из BH генерировать BEMHTML, а обратное неверно. Хотя, даже интерполируемые шаблоны теоретически можно разложить на склейку строк со вставками, хоть это и не даст всей гибкости, но что-то уже появится.

В остальном, впрочем, согласен полностью.

upd Имеется ввиду, естественно, поиск плюсов от использования шаблонов в web components. Минусы там явно перевешивают, да.

@zxqfox

Но это именно потому, что шаблоны в приложенном тобой примере интерполируемые, и нет возможности сгенерировать из них BEMHTML/BH. Если бы шаблоны были, скажем, в виде XSL...

Так я же говорю о том, что предлагают Web Components как стандарт. XSL там, к сожалению, нет и напротив, его совсем недавно выпилили из blink. А то, что там есть убого чуть менее, чем полностью.

@tadatuta Аминь! :+1: