Не надо парить, лучше пиарь ;-)

@zxqfox нам мнимым "бывшим" работникам Яндекса аудиторию Хабра не убедить похоже :)

@Guria Чур меня! Я оттуда еще года 4 назад удалился ;-)

Я не понимаю, почему, но, кажется, на хабре есть люди, которые агрятся на все, что связано с БЭМ.

Боюсь такие люди есть не только на Хабре. :) On Вт, 7 апр. 2015 at 22:47, Alexander Savin notifications@github.com wrote:

Я не понимаю, почему, но, кажется, на хабре есть люди, которые агрятся на все, что связано с БЭМ.

— Reply to this email directly or view it on GitHub https://github.com/bem/bem-forum-content-ru/issues/359#issuecomment-90695521 .

@apsavin @Yeti-or Кажется, что просто на Хабре их большинство. И еще кажется, что у них отсутствует понимание смысла происходящего, они ждут, пока кто-то сверху им даст директивы. ;-)

@zxqfox нотки высокомерия в твоем посте зря)

@apsavin Да ну, всегда есть исключения. Но это же факт, что 60% населения пассивны по своему характеру.

@apsavin по моему они блеют перед неизвестным. Сам же хабр запустил тостер на BEM, разве нет?

Я не понимаю, почему, но, кажется, на хабре есть люди, которые агрятся на все, что связано с БЭМ.

@Guria @zxqfox @Yeti-or А вы читали про жестокий holy war , между сектантами (Свидетели БЭМ) vs чуваки которые узают webpack ))) Это было ржачно))В жизни , они бы точно друг друга перестреляли)

@Guria @zxqfox @Yeti-or @Rahnar

Мне лично страшно разговаривать за БЭМ с людми с которыми не работаю. Потому когда начинаешь говорить про БЭМ, ты говоришь не то, чтобы о фронтенде, а о том как построить работу на надпроектном уровне, а тебя понимают за сборку css html и не "как у всех" модульную структуру.

В общем ты им про устройство солнечной системы, а они про орбиту лун юпитера.

Давеча, слышал как архитектор фронта в одному известном банке рассказывал тимлиду про то, что такое БЭМ - все свелось к тому, что "поставил не завелось", будем использовать css нэйминг.

С другой стороны слушать конкретных "адептов" БЭМ, тоже самое, что и адептов "webpack". При детальном разборе подходов, легком тролинге выясняется, что для их текущей работы не важно, что использовать - не столь высока колокольня.

:)))

@pavelpower webpack — это borschik на стероидах done right ;) он умеет разфлетить зависимости с рекурсивным сохранением правильных урлов, но для того, чтобы выразить всю полноту задач фронтенда, его обычно используют в связке с каким-то внешним таск-раннером.

@pavelpower Мне нравится БЭМ, это лучшее что я использовал.Очень удобно все сделано. Я хочу еще пощупать web-components , сейчас есть библиотека от google polymer.js

@tadatuta ну таки да, я о "webpack" говорил в контексте темы - того что на слуху, иначе не возможно, когда говоришь с адептами :)

@Rahnar мне тоже нравится. Но есть то, что не удобно.

К примеру, стандартный набор блоков слишком связанный. К примеру блок page, на тот момент когда я хотел его использовать, из bem-components в обязательном порядке тянул за собой i-bem, который тянет jquery.

А для наших разработок jquery слишком глючный и местами медленная либа. Некоторые браузеры просто падают на ней. По сему, приходится накапливать свою библиотеку блоков.

Еще как пример это bemhtml - глазвырви шаблонизатор. Хорошо, что есть bh - простой и очень легко внедряемый шаблонизатор.

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

Дальше надо было бы написать развернутую статью на тему "куда же развивается БЭМ", "БЭМ это библиотека или вселенная?", "БЭМ для чайников"...

"БЭМ для чайников"...

Неконсистентно. 2 вопроса и одно спорное утверждение. Надо так: «БЭМ — это для чайников?».

Еще как пример это bemhtml - глазвырви шаблонизатор. Хорошо, что есть bh - простой и очень легко внедряемый шаблонизатор.

@veged I'm sorry! :cat:

К примеру, стандартный набор блоков слишком связанный. К примеру блок page, на тот момент когда я хотел его использовать, из bem-components в обязательном порядке тянул за собой i-bem, который тянет jquery.

А для наших разработок jquery слишком глючный и местами медленная либа. Некоторые браузеры просто падают на ней. По сему, приходится накапливать свою библиотеку блоков.

Года 2 бьюсь с зависимостью jquery. Не тем бьюсь, наверное, но оно до сих пор там. Уже бы либо в браузер встроили, либо перестали считать, что js это jquery. Особенно, когда 70% его фукнционала не используется.

@zxqfox, @veged, @tadatuta - посмотрев соседние ветки, оказывается втиснутый jquery - зло для многих. Не та ли это Рында?

@pavelpower

блок page, на тот момент когда я хотел его использовать, из bem-components в обязательном порядке тянул за собой i-bem, который тянет jquery.

Если сам page подходит, всегда можно вычесть лишние зависимости на этапе сборки.

для наших разработок jquery слишком глючный и местами медленная либа

Если уж jQuery слишком глючная, то сложно представить, какие библиотеки для вас считаются надежными :) А если серьезно, то, согласись, на сегодняшний день процент пользователей, для которых скорость jquery является боттлнеком «крайне мала».

bemhtml - глазвырви шаблонизатор. Хорошо, что есть bh - простой и очень легко внедряемый шаблонизатор.

Приведу список типичных действий, которые можно хотеть проделать с помощью шаблонизатора:

Задать блоку тег

block('b1').tag()('span')

VS

bh.match('b1', function(ctx) {
    ctx.tag('span')
}

Для атрибутов, классов, js, контента, флага про bem и миксов все в точности аналогично.

Для проброса данных вглубь по дереву

applyNext({ someKey: 'someValue' });

VS

ctx.tParam('someKey', 'someValue');

Для добавления обертки

block('b1').content()(function() {
    return {
        elem: 'inner',
        content: applyNext()
    };
})

VS

bh.match('b1', function(ctx) {
    ctx.content({
        block: 'inner',
        content: ctx.content()
    }, true);
});

Ты точно уверен, что отличия настолько велики, чтобы одно было «глазвырви», а другое — «простой и очень легко внедряемый шаблонизатор»? ;)

Не всегда людям ясно как работать с графовыми зависимостями [...] как бы не старался делать блоки независимыми, сложно обойтись без разделения функционала на отдельные блоки при сложной реализации

Я соглашусь, что это могло показаться сложным, когда БЭМ только появился. Но на сегодняшний день повсеместного распространения npm- и bower-зависимостей, подключающихся с помощью целой кучи разных модульных систем, кажется, что подход стал вполне себе классическим.

jquery - зло для многих

Во-первых, время от времени мы рассматриваем возможность отказа от jQuery. В частности сам блок i-bem уже не зависит от нее, только i-bem__dom. Если же отрывать jQuery для работы с DOM, придется самим мейнтейнить работу с событиями, включая их нормализацию между браузерами. Пока это все-таки достаточно большая задача и заниматься ей некому. Во-вторых, в тех редких случаях, когда использование jQuery действительно принципиально невозможно, можно реализовать свой собственный модуль jquery или попробовать применить существующие совместимые альтернативы вроде zepto под таким названием. Вхождений не так уж и много, потребуется реализовать достаточно небольшой сабсет методов. В-третьих, как следствие из второго пункта, можно собрать специальную сборку jQuery ровно под нужды i-bem__dom и подключать у себя ее. Другое дело, что это может сбивать с толку пользователей, которые будут ожидать, что доступен весь привычный арсенал и потеряется профит использования версии с яндексового CDN, которая с большой долей вероятности заранее лежит в кэше у пользователей из СНГ.

@tadatuta у них нестандартные девайсы => нестандартные браузеры/окружения, и jquery — лишневатый.

Во-первых, время от времени мы рассматриваем возможность отказа от jQuery. В частности сам блок i-bem уже не зависит от нее, только i-bem__dom. Если же отрывать jQuery для работы с DOM, придется самим мейнтейнить работу с событиями, включая их нормализацию между браузерами.

Еще, насколько я знаю, в v3 должны появится некие сущности, описывающие элементы. Но это не то же самое, что и DOM элементы (типа jQuery-chain).

Кроме того, что верстальщики знают jquery (но не знают javascript), и поэтому jquery лучше — есть какие-то реальные доводы, почему i-bem должен так сильно от него зависеть?

$.each ? $.fn.closest ? parseHTML ?

Чем Sizzle принципиально лучше Slick, например? Почему нельзя одно заменить другим? Или вообще выкинуть (в пользу getElementsByClassName и других простых прокси-методов).

https://github.com/jquery/jquery/blob/master/src/selector-sizzle.js vs https://github.com/mootools/mootools-core/tree/master/Source/Slick

На мой взгляд, тема недостаточно раскрыта и доводы несущественны. Может быть просто это не критично, и поэтому никто этого пока не сделал? Тогда у @pavelpower должны быть шансы запилить PR, в котором он может сделать эту прокси-прослойку, и что его даже примут. Верно?

@zxqfox учитывая, что у нас очень простые селекторы, Sizzle выкинуть можно хоть сейчас. Основная проблема, как я и писал выше, именно в работе с событиями.

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

@tadatuta Речь не о выбрасывании jQuery в пользу Sencha. Речь о возможностях замещения одного другим и модульности => не перевирай мои слова ;-) с порогом входа ничего не произойдет.

Если же отрывать jQuery для работы с DOM, придется самим мейнтейнить работу с событиями, включая их нормализацию между браузерами. Пока это все-таки достаточно большая задача и заниматься ей некому.

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

Чем https://github.com/jquery/jquery/blob/master/src/event.js лучше https://github.com/mootools/mootools-core/blob/master/Source/Types/DOMEvent.js? ;)

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

Как уже во многих топиках, многими людьми здесь говорилось, улучшить можно очень много всего, а ресурсы ограничены. Мне кажется, их есть на что тратить, кроме выпиливания jQuery. Кому сильно нужно ( @pavelpower ? ) - подменит модуль, это не очень сложно.

И да, +1 к словам @tadatuta про bemhtml.

@zxqfox сначала ты пишешь, что с порогом входа ничего не произойдет, а потом — что нужно навернуть дополнительный абстрактный слой над jQuery. Но либо такой слой уже есть в виде ym-модуля jquery (с точно таким же API, как у jQuery ;)), то ли, если предполагается другое API, то это и означает, что для использования потребуется изучать что-то дополнительно.

@tadatuta Пойдем в отдельным трёп. По большому счет — у меня бы кончились аргументы, если бы эта абстракция называлась, скажем, DOMLibrary, и не слепо выкидывала jQuery целиком, а только лишь явно то, что используется. В виде элементов-ли, или как-то еще — не столько важно. Если элементами/модификаторами — то и подгружать можно было бы более тонко (с i-bem не то же самое?). В общем, это мало роляет для 90% задач.

@zxqfox очень таки близок к пониманию моей боли :) @tadatuta - в большинстве проектов, верстаки не работают с jquery, они работают с БЭМ. На другом уровне абстракции.

Если сам page подходит, всегда можно вычесть лишние зависимости на этапе сборки.

Хы, вычитание это сложная операция. А вот сложение простая. По сему, если сделать так, чтобы я мог зависимости складывать, а не вычитать. Было бы лучше. К примеру, при сборке блока page добавлять i-bem в проектах под desktop, а под stb не добавлять.

Приведу список типичных действий, которые можно хотеть проделать с помощью шаблонизатора:

В маленьких примерах все смотрится шикарно, при переходе к работе, голова идет кругом от closurestyle в bemhtml. Куда проще переходить на нормальный JS стиль с JS кода. Опять же, не нужно выдумывать дополнительный styleguide, можно пользоваться тем же JS гайдом.

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

Про события

• В одном из проектов, используем Gator
• В качестве "сахарного заменителя" на проектах еще используем jbone, правда доработали некоторые его медленные функции.

И да, мы заменяем сборку jquery. Опять же с точки зрения системы это вычитание. А вычитание - это сложная операция.

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

В маленьких примерах все смотрится шикарно, при переходе к работе, голова идет кругом от closurestyle в bemhtml. Куда проще переходить на нормальный JS стиль с JS кода. Опять же, не нужно выдумывать дополнительный styleguide, можно пользоваться тем же JS гайдом.

Вот этого я не понял. bemhtml - это же тот же js.

@apsavin как бы не так https://ru.bem.info/technology/bemhtml/v2/bemhtml-js-syntax/