1) Сходить куда? Например в базу данных или к HTTP API?

На самом деле куда угодно: в БД, по HTTP, на файловую систему или агрегировать данные из нескольких источников. Идея в том, что блоки могут сами ходить за своими данными. Но важно понимать, что это не обязательное требование, а лишь потенциальная возможность. При желании можно готовить данные с помощью любого бекенда, а в BEMTREE только превращать их в BEMJSON.

2) Можно ли где-нибудь почитать код, примеры как это лучше применять на практике?

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

Есть статья про это дело. Кажется, ее до сих пор можно использовать как вводную и все будет работать. Мне можно задавать вопросы про подход или про код bnsf.

@apsavin, кстати, не хочешь перенести bnsf в bem-incubator ?

@vithar Зачем?

@apsavin Ну мне бы хотелось лучшие решения комьюнити собрать в одном месте.

Инкубатор звучит как что-то, предназначенное для экспериментов и проб. "Поместим вот это в bem-incubator и попробуем вырастить, если получится - переместим в bem" - вот как-то так я это воспринимаю. Я скорее создам отдельную организацию для bnsf, в которую смогут переехать так же генератор проектов, project-stub и реализации различных плагинов, которые не хочется включать в основной репозиторий - например, подключенный и настроенный winston в качестве основного логгера. Вообще, организация на гитхабе как способ объединения проектов сообщества мне не кажется хорошей идеей. Почему бы просто не вести список вроде такого? Oh, wait, вот же)

Да, есть смысл в твои словах, буду думать.

Список есть такой https://github.com/sturobson/BEM-resources/blob/master/README.md

Почему бы не сделать кейворд bem или b_ или bem-library, bem-something и по ним искать в npm/bower ?

@zxqfox +1