BEM с человеческим лицом

[nerv]

В статье BEM с человеческим лицом есть комментарий:

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

кто что думает по этому поводу?

[lexxcode]

58 минут назад, nerv сказал:

кто что думает по этому поводу?

Мое мнение не поменялось. БЭМ - шлак

Точнее, как почти всегда у яндекса, идея была неплохая, но реализация шлак. 

[wwt]

1 час назад, nerv сказал:

кто что думает по этому поводу?

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

[nerv]

1 час назад, alexriz сказал:

Мое мнение не поменялось. БЭМ - шлак

тогда, какой подход ты используешь? Например, согласной моей ссылке под альтернативой BEM понимаются css modules

http://www.sitepoint.com/understanding-css-modules-methodology/

http://glenmaddern.com/articles/css-modules

https://github.com/css-modules/css-modules

https://habrahabr.ru/post/270103/

[lexxcode]

Я отделил тему про БЭМ, а то к теме что читают форумчане, это как-то не очень относится.

2 часа назад, nerv сказал:

тогда, какой подход ты используешь? Например, согласной моей ссылке под альтернативой BEM понимаются css modules

Скажем так, модульность появляется в любой методологии, сама собой. Просто потому, что это логично и естественно. Ну правда. Тот же БЭМ элементарно разбивается на модули, более того они прямо к этому призывают. 
Другой вопрос в самом подходе организации имен селекторов для компонентов. Хоть они упорно пытаются навязать, что это прям не так уж важно, и писать нечто подобное .block--element__mod - это норм, хотя это нифига не норм. Ну да черт с ним с самим синтакисом, это не так принципиально, при том, что по тому же БЭМ можно прикрутить и менее адовое именование. Да в статье правильно написано все, вцелом. Потому что в БЭМ и правда слишком много жести, надо быть гибче. Но в статье не описан один важный момент, как и во всех про БЭМ. Не нужно в понятие модификатора пихать все подряд. Я искренне считаю, что это слишком очевидно. По БЭМ модификатор это чуть ли не все, начиная от просто чуть другого цвета фона в элементе, заканчивая какими-то опциональными вещами, вроде отображения элемента. А всего-то нужно разделить понятия модификатора на модификатор (mod) и состояине (state). Так жить становится на много проще.
Это что касается моего отношения к БЭМ.

Что касается меня, то у меня тут свой подход в организации css. Кстати, похож на OPoR. Но свой вариант я вывел намного раньше чем узнал об OPoR, честно
У меня есть следующие понятия:
block, element, mod, state и js-*

Никаких лишних префиксов не нужно. Использую только .js-*, для навешивания js функционала, но это как отдельный слой. 
В частности тот же SASS позволяет избавиться от необходимости писать в HTML всякого рода дублирования вроде
class="block-element block-element_mod", а просто class="block-element_mod". Потому что всей компановкой занимается SASS и мне не нужно об этом задумываться вообще.
В SASS это выглядет примерно так:

.block {
    $root: &;
    some: css;
    &-element {
        some: css;
        &_mod {
            @extend #{$root}-element;
            some: css;
        }
        &.state {
            somestate: css;
        }
    }
}

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

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

Так же в статье есть речь о том, что нужно под каждый компонент выделять свою ноду в html. В общем я с этим согласен. Кроме ситуаций с иконками. К ним я отношусь по разному, в большинстве случаев, я стараюсь вешать их на ПЭ, а не как отдельную ноду. Ну если уж другого выхода нет, то тогда это отдельная нода, хотя меня это невероятно бесит
Для иконок у меня есть отдельный компонент, например .icon. И чтобы добавить к чему-то иконку просто достаточно добавить .icon_iconame

<div class="block-element icon_iconame">Some Text</div>

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

.block {
    $root: &;
    some: css;
    &-element {
        some: css;
        &_mod {
            @extend #{$root}-element;
            some: css;
        }
        &.state {
            somestate: css;
        }
        &[class^="icon_"], &[class*=" icon_"] {
            somechange: forelem;
            &:before {
                somechange: foricons;
                change: size;
              	some: color;
            }
        }
    }
}

Да это несколько нарушает понятие инкапсуляции, но все таки: "Сейчас к людям надо помягше. А на вопросы смотреть ширше."

Вот в общем-то мои мысли по поводу БЭМ, модульности и вообще подходу к css. Для меня это работает, вероятно для кого-то нет, по каким-то причинам. Но тут уж я ничего поделать не могу

[wwt]

40 минуты назад, alexriz сказал:

Никаких лишних префиксов не нужно.

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

[lexxcode]

2 минуты назад, wwt сказал:

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

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

[andrey7287]

18 час назад, alexriz сказал:

и писать нечто подобное .block--element__mod - это норм

Так это ересь какая то а не БЭМ )))

18 час назад, alexriz сказал:

В SASS это выглядет примерно так:

Хорошо, а в чём принципиальное отличие от БЭМ подхода, кроме неосмысленного именования (block)? И что мешает использовать модификатор d БЭМ, аналогичным образом ? Собственно &--mod  и &--state .

 

[lexxcode]

55 минут назад, andrey7287 сказал:

Так это ересь какая то а не БЭМ )))

Ну открой соглашение по именованию в БЭМ и посмотри...
Модификатор элемента: .block-name__elem-name_mod-name
 

55 минут назад, andrey7287 сказал:

кроме неосмысленного именования (block)?

Неосмысленное именование. Это пример вообще-то 

55 минут назад, andrey7287 сказал:

И что мешает использовать модификатор d БЭМ, аналогичным образом ? Собственно &--mod  и &--state .

ничего не мешает, в БЭМ так и есть да. Но это неудобно.

И потом, я не собираюсь навязывать что-то, все равно это неблагодарное занятие и никому не интересно. Используйте что хотите, мне то какое дело, в общем-то  @nerv задал мне вопрос, я ответил как я к этому подхожу. Все.

[andrey7287]

1 час назад, alexriz сказал:

Ну открой соглашение по именованию в БЭМ и посмотри...
Модификатор элемента: .block-name__elem-name_mod-name

Да, только модификатор сейчас через "--" делается, по этому приведённая запись и вызвала недоумение. 

2 часа назад, alexriz сказал:

И потом, я не собираюсь навязывать что-то, все равно это неблагодарное занятие и никому не интересно.

Мне интересно. По сути у тебя тот же БЭМ, только в профиль. Хотя идеи возможно и полезные, возьму на заметку.

[Great Rash]

Я согласен с этим утверждением на все сто. БЭМ дал главное - научил людей избавляться от мусорной свалки в CSS. А ещё я считаю, что все эти ваши SASS, SCSS и т.п. вместе с переменными должны умереть. Как только везде заюзают Web Components всё это станет ненужно. Вот тогда и наступит верстальческий рай

[lexxcode]

3 минуты назад, Great Rash сказал:

А ещё я считаю, что все эти ваши SASS, SCSS и т.п. вместе с переменными должны умереть.

Согласен. Я сам люблю css таким какой он есть. SASS начал использовать больше для внесения разнообразия в работу) Я его использую минимально, только то что позволяет компоновать селекторы в стак, где нужно. Мне об этом просто думать не нужно и тратить на это время. А большую часть того что предлагается, я не использую, по факту, просто нет надобности.

7 минут назад, Great Rash сказал:

БЭМ дал главное - научил людей избавляться от мусорной свалки в CSS.

только добавил свалки в html xD

[wwt]

55 минут назад, andrey7287 сказал:

Да, только модификатор сейчас через "--" делается, по этому приведённая запись и вызвала недоумение. 

модификатор ваще то через одно подчеркивае, а елемент либо __, либо --. Так в доках написано. А как кто делает это уже его личное дело.

[Great Rash]

1 час назад, alexriz сказал:

только добавил свалки в html xD

На самом деле нет. Просто надо уметь его готовить  Товарищи из яндекса писали, что у них иногда по дню уходило просто на проектирование разметки (без написания кода). Т.е. наверное треть времени уходит на то чтобы просто понять как разбить макет на БЭМ-элементы.

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

[lexxcode]

9 минут назад, Great Rash сказал:

На самом деле нет. Просто надо уметь его готовить

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

<div class="block-name__elem-name block-name__elem-name_mod-name block-name__elem-name_mod-state">Some Text</div>

То есть прописать целых три класса вместо одного.
В итоге на выходе в коде получается какая-то нечитабельная помойка

[Great Rash]

21 минуты назад, alexriz сказал:

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

<div class="block-name__elem-name block-name__elem-name_mod-name block-name__elem-name_mod-state">Some Text</div>

То есть прописать целых три класса вместо одного.
В итоге на выходе в коде получается какая-то нечитабельная помойка

Ты так пишешь будто длинные названия классов - это что-то плохое. Ну и что, что их три? Главное ведь не длина атрибута class, а понятность чтения кода. Не понимаю чем это хуже той лапши на SASS, которую ты привёл в пример. Особенно забавно получается если приходится разбираться в таком коде, не имея исходников (был у меня такой случай).

UPD:

Дополню справедливости ради, что я тоже не в восторге от системы модификаторов, предложенной яндексом. Сам то я примерно так пишу:

<div class="block-name__elem-name _mod-1 _mod-2"></div>

философия БЭМ сохраняется, но код при этом читабельней. Однако это только потому, что ИЕ6 помер наконец. А ведь БЭМ придумывали ещё в эпоху актуальности ИЕ6, в котором (сюрприз-сюрприз) в CSS не работала запись такого вида:

.block-name__elem-name._mod-1 {
  /* ... */
}

Именно оттуда растут ноги такого длинного объявления модификаторов.

[lexxcode]

33 минуты назад, Great Rash сказал:

Ты так пишешь будто длинные названия классов - это что-то плохое. Ну и что, что их три? Главное ведь не длина атрибута class, а понятность чтения кода.

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

33 минуты назад, Great Rash сказал:

Не понимаю чем это хуже той лапши на SASS, которую ты привёл в пример. Особенно забавно получается если приходится разбираться в таком коде, не имея исходников (был у меня такой случай).

У меня как раз лапши и не получается, в html подобный пример я бы записал максимум так:

<div class="block-elem_mod state">Some Text</div>

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

.block {
   padding: 10px;
}
.block-elem,
.block-elem_mod {
    margin: 5px;
}
.block-elem_mod {
    color: #800;
}
.block-elem.state {
    background: #080;
}

Так примерно css будет выглядеть. .block-elem_mod стакается вместе с базовым block-elem, т.к. расширяется от него, дальше уточняется индивидуально mod версия. .state может быть как глобальным, так и индивидуальным, как в данном случае. 

Все вполне понятно.

На sass это вообще будет выглядить цельным блоком

.block {
    $root: &;
    padding: 10px;
    &-elem {
        margin: 5px;
        &_mod {
            @extend #{$root}-elem;
            color: #800;
        }
        &.state {
            background: #080;
        }
    }
}

На чем писать это уже выбор каждого (конечно на css)

33 минуты назад, Great Rash сказал:

Особенно забавно получается если приходится разбираться в таком коде, не имея исходников (был у меня такой случай).

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

[Great Rash]

Ну собственно твоя реализация ничем не отличается от классического БЭМ. Вопрос вкуса как писать модификаторы, через 2 подчёркивания или через одно. Например в твоей реализации элементов придётся в CSS использовать camel case, про который тоже куча народу скажет своё "фи". Так что вкусовщина всё это.

Почему в яндексе твой подход не прокатил бы я уже написал собственно.

[Svatov]

Я очень часто замечаю, что многие фукают на БЭМ, но по сути используют его принципы в какой-либо интерпретации. 

БЭМ не умер и никуда не денется, даже после появления CSS Modules с его неймспейсами. Он позволяет писать css стили модульно и в этом его преимущество, особенно для внедрения в различные стеки по типу Angular 2 или React based архитектуры.

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

Edited March 24, 2016 by Svatov

[by chris]

15 минут назад, Svatov сказал:

БЭМ не умер и никуда не денется

Целый mdl на бэме. В гугле, вроде как не глупые ребята.

[nerv]

В 3/24/2016 в 15:09, Great Rash сказал:

Я согласен с этим утверждением на все сто. БЭМ дал главное - научил людей избавляться от мусорной свалки в CSS. А ещё я считаю, что все эти ваши SASS, SCSS и т.п. вместе с переменными должны умереть. Как только везде заюзают Web Components всё это станет ненужно. Вот тогда и наступит верстальческий рай

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

а) с одной стороны очень прохоже на то, что с приходом неймспейсов в css (css_modules/web_conponents) БЕМ станет не нужен

б) с другой, неймспейсы требуют javascript, без которого можно обойтись в ряде случаев

[Great Rash]

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

[wwt]

12 часа назад, Great Rash сказал:

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

даже разработчики браузеров уходят от практики "выключения js", к примеру в Firefox убрали из настроек отключение скриптов, оно осталось только через about:config,

[CyberX]

 

26.03.2016 в 12:33, Great Rash сказал:

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

Как минимум JS необходим, но для аналитики не обязателен, Можно чисто на PHP написать аналитику, которая даже время пребывания на странице будет показывать и ни какая метрика не нужна станет. 

Я вот большой не сторонник транспайлеров и препроцессоров(пусть сдохнет еще и TS с React и VUE). БЕМ мне начал нравится года два назад. Раньше я на OOCSS работал обычно, но на форуме даже ни одной темы. БЕМ реально хороший.