Возможно, @veged смог бы что-то про это сказать точно. Но, насколько я могу судить - если это и возможно, то очень не просто. Посмотрите на эту конкатенацию строк.

Ну вот я долго смотрел на все эти трансформации, пытался разобраться сам, но понял, что нужна помощь сообщества :) Хотелось бы понять как это все работает под капотом, чтобы иметь представление на сколько сложно реализовать эту идею.

Виртуальный дом (как в React) дает преимущества в том, что избавляет от необходимости вручную заниматься обновлениями этого самого DOM, он берет на себя работу по отслеживанию изменившихся фрагментов. Если БЕМ пойдет в сторону виртуального DOM, то ему придется полностью сменить парадигму написания JS-кода, что приведет к необходимости переписать все существующие компоненты.

Чтобы понять, как работает это все - нужно читать код https://github.com/bem/bem-xjst и https://github.com/veged/xjst Я просил написать пост, чтобы было проще разбираться, но @veged сказал, что все слишком сложно и написать подобный пост будет слишком трудозатратно.

@apsavin Думаю, что @veged будет непротив помочь писать такой пост, т.е. можно, например, в каком-то cloud сервисе завести документ, там все это описывать и после позвать @veged поревьюить. Либо же, завести HOWITWORKS.md прямо в репозитории, и постепенно описывать все там, но тогда нужен ответственный за PR, который готов потратить часть своего времени и сделать это.

добавлю в тредик и @narqo

Возможно ли допилить BEMHTML так, чтобы он вместо функции по генерации html строки, выдал функцию по генерации виртуального DOM дерева?

Сам по себе «виртуальное DOM-дерево» — это просто JS-объект, не сильно (по смыслу) отличающийся от развернутого (конечного) BEMJSON.

Думаю, куда интереснее иметь (в дополнение) возможность получить конечный BEMJSON из html-строки; вычислить diff, между двумя BEMJSON-деревьями и наложить на html-узел «патч».

Как заметили выше, чтобы этим пользоваться, одним BEMHTML (шаблонизатором) не обойтись. Нужно пересмотреть событийную модель в i-bem__dom, сильно подумать про возможность реализации поиска по такому дереву (в react не зря нет аналогов find, кроме явных указаний через ref) и еще много чего на самом деле.

Нечто похожее, по масштабам (на сколько я могу судить), сейчас пилят в Ember https://github.com/emberjs/ember.js/pull/10501

@narqo

сильно подумать про возможность реализации поиска по такому дереву (в react не зря нет аналогов find, кроме явных указаний через ref) и еще много чего на самом деле.

Дело как раз в том, что там это все не нужно, так как по его идеологии не нужно вообще трогать DOM-представление императивно. Вместо этого нужно трогать данные, их которых потом построится новое дерево и diff-алгоритм дальше сделает всю грязную работу по обновлению DOM. Существует ряд исключительных ситуаций, когда может хотеться получить элементы дерева, но их очень немного.

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