Cовсем не скрещивание, но метод “._elem”, аналог “.elem” из i-bem, я в Backbone добавлял, не вижу проблемы добавить и шаблоны. У Backbone ведь то, что называется View -  очень тонкое, шаблонизатор можно использовать любой.

Если full stack bem, то на ум приходит тот же bem-node, в котором роутинг уже есть, остается только bem-mvc добавить. Но это вы и без меня знаете)

P.S. интересно было посмотреть на расписание. В какой-то момент подумал, что в открытый доступ выложены библиотеки из папки ya-libs, а я этого события не заметил, но это быстро прошло)

Нет, они не в открытом доступе пока. Я их изнутри скопировала, тк ничего секретного там нет. Но официально они не оупенсорсились.

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

как встроить всамделешний mvc, чтобы от этого была какая-то практическая польза, пока не понял. в моем понимании i-bem реализации блоков это и view и model, и порой даже controller-mediator одновременно. пока эксперименты приводят к тому, что появляется еще какая-то дополнительная ерунда в духе mvvm. может не так смотрю?

Как прикрутить BEMHTML к Backbone.View — более менее понятно. Но есть же еще события на bem-объектах, которые компонент генерирует и на которые приложение должно реагировать. С ними что делать?

А можно где-нибудь посмотреть код?

// i-router/i-router.js

var AppRouter = Backbone.Router.extend({

        routes: {

            "cats/:name": "cats",

            "": "index"

        }

}) ;

BEM.router = new AppRouter() ;

// b-cats/b-cats.js

BEM.DOM.decl('b-cats', {

        onSetMod: {

            'js': {

                'inited': function() {

                    BEM.router.on('route:cats', this.showCat, this) ;

                }

            }

       }, 

      showCat: function(name) {

      }

}) ;

Спасибо!

Так. Попробую объяснить, почему это сложно сливаемое.

Что дает БЭМ: функциональность распиливается по визуальным и служебным частям. Если накладывать на сервер-сайд — Блоки — это хранилища/модули для технологий (контроллеры, модели, библиотеки и view).

MVC, как таковой, и HMVC в частности — так же позволяет иметь несколько уровней вложенности, наследование, но контроллеры, модели, вьюхи там хранятся и управляются группируясь не по смысловому наполнению, а по типу.

Фактически, математически идеальной будет архитектура, которая позволяет на базе структуры бэм иметь технологии для контроллеров, моделей, но блоки будут расфасованы не по страницам/бандлам, а по уровням переопределения, и иметь возможность наследоваться в любых последовательностях. Правда, в таком случае структура получается слишком сложная для восприятия, и очень высокий порог входа. Технологии bemtree и priv.js вполне вписываются в эту архитектуру. До таких фреймворков мы пока не доросли, слишком молод бэм еще.

Еще вариант, использовать что-то вроде HMVC ­минус View плюс Block (HMBC). Т.е. полностью отказаться от View в пользу Block. Таким образом останутся контроллеры, модели, наследование контроллеров и моделей, но вместо отрисовки View будет функционал по сборке бэм-дерева (bemjson). В данном случае, есть сложности со сборкой правильного бандла — без исполнения кода множество всех зависимостей, элементов и модификаторов недетерменированно, в следствие чего разработчику придется ручками описывать то, что должно войти в сборку бандла в целом и bemhtml.js в частности. Когда на сайте страницы содержать разные зависимости — сложно собирать их 

Мне более близка именно последняя архитектура, но все они, как и фреймворки, которые на них основаны, сильно зависит от возможностей языка, и способа её реализации. Чтоб огурцы солить — тоже нужно уметь.

Как-то так

Можно же подойти так, что блоки — это потенциально реиспользуемые элементы: кнопки, селекторы. А все остальное, само приложение, делается уже по выбранному MVC фреймворку, а не по БЭМ.

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

сложилось мнение, что архитектурные подходы БЭМ являются реакцией на модели наследования и переопределений в CSS. профит в том, что они позволяют верстке быть консистентной не только в плане css, но и на всем стеке версточных технологий, благодаря реализации схожих механизмов для js и html. т.е. как способ организации View с браузером во главе угла - БЭМ вполне себе понятен. но имхо, сея архитектура скорее частное неизбежное зло, нежели пример для подражания вообще, т.к. граблей в ней тоже масса.

похоже, что технически, БЭМ вырос из классической 3-tier архитектуры, как инструментарий для реализации отделимого html-представления. в этой архитектуре логика управления и источники данных живут настолько отдельно, что следов их в бэм-библиотеках практически не видно даже.

естественно, при использовании БЭМ часто хочется чего-то, типа классических активных View (widgets), которые сами знают как сходить за данными и как их показать. priv.js / bemtree решают вопрос. но чем ближе мы приближаемся к бизнес-логике тем связи компонентов "через View" становятся все более длинными и запутанными, а потому менее практичеными.

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

в общем, согласен с toivonens@. но если речь заходит о моделях и взаимодействиях, то вместо разрозненных связок backbone/express.js хочется чего-то более консистентного (типа derby.js). все же 3-tier архитектура предполагает написание одного приложения, а не двух разных.

В целом, я со всем согласен, кроме widgets (да и с  не спорил).

priv.js/bemtree.js — не до конца решают задачи, которые в mvc рулит контроллер. А могли бы.

Скажем, блок "погодный информер" может сам ходить за погодой через апи: BLOCK.api.getWheater(params). На морде будет ходить в xhr, на сервере куда-то еще, но эта логика будет храниться здесь же рядом. Пусть это будет не priv.js, а api.js или common.js. Главное — что рядом.

Или классический контроллер, у которого нет отображения — вставляем эту же технологию в блок — получаем блок-контроллер.

Модели, схемы БД — тоже можно описывать технологиями, но вопрос как их пилить. Например, один блок, несколько моделей — значит технология может содержать сразу набор схем, как мигрировать, то-сё, может выйдет, может нет — сразу не скажешь.

priv.js/bemtree.js — не до конца решают задачи, которые в mvc рулит контроллер. А могли бы.

стандартная технология priv.js пишет за программиста лишь одну строчку: var blocks = {} ; -- что не накладывает ни каких ограничений. т.е. чисто технически, под ней можно дописывать какой угодно код, и за это ничего не будет, правда и помогает она слабо. до сих пор не понимаю, это зарядка для ума такая, или какое-то издевательство? 

концепуально все контроллеры чем-то похожи. но технически контроллер-контроллеру рознь. и контроллеры уровня блоков сильно отличаются от котроллеров уровня страниц. в bem-yana реализовано что-то похожее, но выглядит замороченным сильно.

БЭМ делает очень многое, чтобы притащить подобие модульности в CSS, упираясь практически лишь в его основы-основ - модель белого ящика, здоровый общий контекст и неявные зависимости. такие трюки рулят в верстке, но в целом от нормального ООП больше пользы.

Расскажу почему я думаю, что это не только "а если".

Лет 5 назад я писал проекты и встала необходимость выделить общий код в ядро, которое подтягивалось через svn externals. Я вынес ядро в отдельную папку, спустя какое-то время, я понял, что логично и код проекта засунуть в папку, чтобы унифицировать структуру, затем появились модули, в общем, вышло так:
  ./
    core/
    module1/
    module2/
    app/
Внутри каждой из них обычный MVC — набор контроллеров, модулей. Через какое-то время я наткнулся на термин HMVC.

Бесспорно движки типа joomla, drupal, wp несколько популярнее, чем kohana. Но именно HMVC дает ресурс очень похожий на уровни переопределения в БЭМ. Я бы сказал 1-в-1.

Так вот если взять структуру вида:
  ./
    level1/
      blocks/
      bundles/ ← view
      controllers/
      models/
    ...
    app/
      bundles/
      controllers/
      ... 

То все прекрасно ложится и должно работать.

Вот такая вот история решаема технологиями? Имхо, это лучшее, что можно сделать, и весьма несложно.

p.s. Может технологиями controller.js, model.js, или еще какими-то можно решить. Но в любом случае хранить их лучше отдельно.

кстати, да. еще в django используются похожие штуки. мне кажется, тут главное не смешивать вопросы архитекутуры и технологии сборки: отдельно HMVC, отдельно сборка (с переопределениями или без) - все будет ок. по отдельности они выглядят прекрасно.

трюки со сборкой и переопределениями исходников на файловой системе - тема популярная, но это приемы одного порядка с monkey patch и соответствующими заморочками. удобно в отдельных случаях, но строить архитектуру на базе этого и мечтать, что не попадешься ни в одну из известных ловушек - сликом оптимистично, имхо. 

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

Точно так же может менятся логика или интерфейс апи какой-то библиотеки, потому что депрекейтед, и все ломается Экстраполируя — зачем жить тогда?.. Волков боятся — в лес не ходить, грибов-ягод не есть.

все распадается конечно, но не с периодом полураспада в pi-месяцев. поэтому давай не путать божий дар с яичнецей).

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

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

для стороннего наблюдателя, же, - это код шредингера, вероятность распада которого с течением времени увеличивается по экспоненте. (ну или считайте, что это стоимость поддержки так увеличивается - полгода после релиза и поправить баг стоит как написать с нуля).

Не могу согласится с тем, что разработчик сторонней библиотеки никому ничего не должен. Если он не может предоставить апи — с его библиотекой, какой бы прекрасной она не была, никто не захочет работать.

Любая библиотека, в том числе и блоков, которая вываливается в доступ — уже дает интерфейс, через который её и используют, а это и есть api.