спасибо

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

тогда это __top, а не --top

Элемент, а не модификатор

Не совсем понятно, что конкретно имеется в виду "ничего лишнего".
Если нужен ТОЛЬКО серверный рендер - bemxjst с этим отлично справляется.
Но я очень сомневаюсь, что только это нужно.
У нас интернет-магазин на классическом стеке, всё никак не начнём переход на BRC.

На счёт всяких вещей типа "ничего лишнего", код сплиттинг в мире React намного проще реализовать.

Для нас выбор в сторону React сейчас из-за следующих факторов:
- Только ОДИН шаблонизатор (а не 3, как сейчас... bemtree, bemhtml и... i-bem)
- Code Splitting
- TypeScript
- Fiber (приятный бонус)
- Возможность использовать одни хэлперы как в шаблонах, так и в сторах (без всяких костылей)
- импорты (правда когда их мгого... Вспоминаешь про deps :) )

Почему пока не перешли на BRP:
- Есть поток приоритетных бизнес-задач
- Много кода / мало людей
- Любим bemxjst

Поглядываем ещё на Vue 3.0. Может к моменту релиза мы уже начнём таки переход и глянем, сможет ли Vue порадовать или нет.

Всем привет.  У меня node js никак не установится и выдает ошибку. Может кто нибудь знает,  как ее решить.
В гугле искал,  но ответа так и не нашел.  
Смотрел как lts так и текущую версию.
Жопа какая-то.

1. Оффтоп. Не о bem вопрос.
2. Для разработки лучше Linux/MacOS (хотя у windows вроде какие-то костыли с подсистемой есть)

💪

Чатик whitepaper https://t.me/whitepapertools — футболки можно спрашивать там

Посмотрел видео с конференции и появилось пару вопросов. Сразу добавлю, что документацию не всю прочитал.
1. При описании элемента реально возможно по 7-15 классов (описание всех можификаторов, состояний)?
2. Нужно/можно ли использовать css значения у элементов по умолчанию или все решают модификаторы?
3. Я так понял, что при создании шаблона не используют обычную вёрстку страницу и прописывание классов, а используют инструменты для описания структуры страницы и ее автоматической генерации со всеми классами. Это так?

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

1. У элементов не часто много модификаторов, но иногда бывает. Обычно это повод подумать, как выделить его в самостоятельный блок

попробуй описать состояние блока,  тогда состояние элемент, модификатор используй для js или типа конечного состояния *_padding_top

станет короче

2. Удобнее все опционалтное выносить в модификаторы, а уже их задавать по умолчанию при желании

3. Да. Например, шаблоны bem-xjst из bemjson. Опять же чтобы проще описывать и делать меньше ошибок

1) Возможно, но действительно редкость. Чаще бывает, что да, получилось много модификаторов, проходит пару дней и замечаешь, что некоторые модификаторы можно «схлопнуть» вместе.
2) можно. модификатор именно модифицирует дефолтное значение
3) в БЭМ-стеке — да.

дайте ссылку на видео пожалуйста

https://youtu.be/QArmhI33zwY?t=6667

Один из свежих докладов по BEM (с 1:50) и почему его постоянно хоронят.

О, да, буду признателен за фидбек — помог ли мой доклад кому-то разобраться с БЭМ и согласны ли вы с тезисами, почему БЭМ «хоронят».

+ тем более буду благодарен за критику

Вопрос по XJST — как получить рантайм-контекст «родительской» сущности? Например, блоку — узнать, какое значение модификатора theme  у внешнего элемента?