Напишу свои пять копеек на правах ментейнера пакета bem-xjst, и входящего в его состав движка bemhtml (с JavaScript-синтаксисом шаблонов).

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

Во-вторых, тут на форуме, уже есть некоторые мнения.

Я своё мнение писать не могу, иначе будет выглядеть как будто я за bemhtml. Что очевидно.

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

В bh никогда не нравились обвязки типа module.exports = function(bh) {} Ну и работа с ним выгладит как работа с чем-то написанным на коленке, например приходится писать __ в матчерах и подобное. Глаз не цепляется за конструкции "это про шаблон", а "это про пользовательские функции" потому что все функции) В bemhtml с этим всем лучше как мне кажется. Он и выразительнее. Ну и опять же... есть очень нужный bemtree

• bh проще для понимания новому человеку, т.к. синтаксис ближе к css
• bh меньше весит
• bh проще в отладке шаблонов

у bh можно прочитать исходники и понять как там всё устроено

@Yeti-or я более-менее осилил контрибьютить в bem-xjst, там совсем не та омета, что была раньше, берешь и читаешь ;)

@kompolom Попробую поспорить.

bh проще для понимания новому человеку, т.к. синтаксис ближе к css

можешь привести примеры шаблонов на BH и BEMHTML, где BH ближе к CSS?

bh меньше весит

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

bh проще в отладке шаблонов

Можно попробовать даже просто http://bem.github.io/bem-xjst/ — вроде все сообщения об ошибках вполне внятные, но @miripiruni активно продолжает улучшать. Кроме того, висит PR с поддержкой source maps.

Дебагабилити есть в планах bem-xjst, да и он развивается, а bh уже нет. По остальному, кроме семантики и API, там паритет. Шаблоны bh можно реквайрить и иметь несколько экземпляров, bemhtml несколько инстансов только через generate + eval. Ну и соглашусь, хоть не до конца, про BEMTREE, но в bh есть метод processBemjson и с натяжкой (используя 2 набора шаблонов) можно иметь аналог. Первый, конечно, сильно выразительнее и вообще, но если напрячся и писать только матчеры на BEM-сущности (кроме, скажем, корневых), то это возможно и в BH.

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

У нас на проектах верстальщики (не особо умеющие js) въезжают в bemhtml/bemtree без проблем.

В bem-xjst не контрибьютил, но в bemtree баги правил, вроде не rocket science.

@apsavin см. https://github.com/awinogradov/bem-xjst/pull/1/files

@tadatuta Спасибо, подписался на тред. Выглядит интересно.

@apsavin а зачем тебе virtualdom ? Какая в нем необходимость?

@uradvd запилили проект на BH сделали целенаправленно т.к. объяснить людям как работает БЭМ на нем было куда проще. Да и online редактор сыграл не мало (спасибо Роману - правильно, Рома его пилил?)

Из текущих траблем были следующие:

1. Либы из стандартных набором типа bem-components на запускались без тюнинга на bh
2. Обязательно писать exports, но при серверном рендеринге даже плюс - можем тащить переменные окружения и использовать в хитростях (что с точки зрения архитектуры плохо, но упрощает жизнь в сложных ситуациях сборок)
3. Проблема горячей замены шаблона - приходится драться с кешем require

Коллеги тут пишут, что у BH будущего не видно. Это так, но если смотреть в сторону функционального подхода, может быть там можно, что-то раскопать.

online редактор сыграл не мало

Теперь есть и песочница для BEMHTML: http://bem.github.io/bem-xjst/ (by @mishanga и @miripiruni).

Либы из стандартных набором типа bem-components на запускались без тюнинга на bh

На текущий момент проблем с bem-components не должно быть с любым из шаблонизаторов — мы гоняем тесты на разных версиях обоих.

Обязательно писать exports

На самом деле нет. См. https://github.com/bem/bem-components/issues/1286

Проблема горячей замены шаблона

Без require сервер тоже приходится перезапускать, так что это скорее фича ;)

Да, bemhtml сейчас более динамичен в развитии.

bemhtml сложнее портировать на другие языки. Например php. А как мне кажется есть огромное количество фронтендеров, которые пишут шаблоны для всевозможных php cms-ок. Пока есть bh и bh.php есть шанс, что кто то из них начнет использовать бэм в своих проектах.

@pavelpower чтобы не дублировать код.

@pavelpower мы тоже реализовали проект на bh.php все классно, работает отлично, но много логики в шаблонах получилось. Чего бы небыло если использовать bh(bemhtml)+bemtree что в php сложно реализовать(красиво :))