спасибо! я пытался соорудить что-то типа:

block('link')

   .attrs()(function() { return { href: this.ctx.url; } } )

   .tag()('a');

Можно писать .bemhtml и .bemhtml.xjst.

В .bemhtml можно писать и старый и новый синтаксис.

В .bemhtml.xjst только новый.

А по скорости такой синтаксис будет работать быстрее?

Значительно быстрее (если компилить в продакшен режиме). Dev-режимы сравнить нельзя, т.к. раньше не было такого режима.

Если да, то по скорости должен сравняться с BH?

Не факт Смотри ответы выше.

Но в целом цифры стали намного ближе.

хорошее желание )

*.js

В общем случае:

def()(function() { return ... })

для этого делались "вставки" в bemjson.

{

  block: 'b-page',

  content: [

    @include четотам,

    ... содержимое страницы ...

    @include footer

  ]

}

точный синтаксис надо уточнить.

еще можно наследовать свою страницу от b-page и в bemhtml и прохардкодить там шапку/футер. но вставки удобнее и логичнее.

че-то меня совсем запутали.  я считал, что bemjson это сугубо формат данных для преставления страницы. а всякая логика по его сборке (включая инклуды, наследование и что там еще бывает) реализуется в технологиях, предназначенных для его сборки, типа priv.js. или есть что-то еще?

http://clubs.ya.ru/bem/replies.xml?item_no=1967 — штука, которая для priv.js помогает работать с bemjson как с xpath с xml (или около того).

https://github.com/veged/borschik/pull/16 — позволяет с помощью борщика делать вставки статических кусков в bemjson. не @include, но почти, и суть та же.
https://github.com/alexeyten/borschik/blob/63903a219e32e245a2e9223cf656e63827cce329/docs/js-include/js-include.en.md — инфа про последнее

К сожалению, оно до сих пор в подвешенном виде

http://clubs.ya.ru/bem/2508/2524 — ваша же тема, ищите в самом низу "bemjson.raw" — писать придется руками, но писать там не много.

Почему я считаю, что это должно быть в release-1.0.0

bemjson сейчас является представлением на более высоком уровне содержимого страницы. т.е. это как C, когда как HTML это assembler. В html есть ssi и иногда (не часто) бывает очень полезным. В C есть макросы (#include) — та же история. В bemjson ничего такого пока нет, и раз от раза все на это натыкаются.

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

о, спасибо за подборку. тогда мои 5 копеек. 

классическая схема сборки в bem-tools выглядит следующим образом: 

bemjson -> bemdecl -> 'deps -> {css, js, bemhtml.js } -> {(bemjson + bemhtml.js) -> html}

где стрелками обозначен порядок сборки зависимостей. все, что в фигурных скобках собирается независимо друг от друга. html получается наложением bemhtml на исходный bemjson. 

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

второй вариант - что-то мудрить в хвосте. так появисля https://github.com/generalov/project-stub/tree/stas.js  . 

bemdecl -> deps -> { css, js, bemhtml.js, stas.js} ->  { (stas.js -> bemjson) + bemhtml.js -> html }

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

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

Если вы будете куда-то таскать файлы — таскайте собранные версии.

SSI тоже много кто не любит . Для него есть отдельный модуль в apache и nginx. Но есть же? Нельзя отбирать саму возможность. Не нравится — не используй, но возможность быть должна.

я не отрицаю, что инклуды могут принести определенную локальную пользу (у нас некоторые еще об extends в стиле django мечтают). просто мне кажется, что этот вопрос не нужно решать в рамках формата.. ssi ведь ни когда не был частью html. или там django-templates. так же и здесь.

Что-то я потерял нить спора

Немного похвалю enb

Там есть родной нодовский require в bemjson технологии, обычно этого хватает.