Есть альтернативы БЭМ?

Question

[Rrooom]

По хорошему, я не нашел ни единой другой методологии для фронтэнда. Неужели только ЯНдекс делают по уму, а остальные как придется?

Есть ли альтернативы? Как-то он мне нравится, уродливые классы, избыточность кода. Категорически непонятно, как использовать, если работа начинается с уже готовой верстки.темы - писать заново. Но таки хочется, что бы всё было чистенько и понятно, а то в любом проекте со временем всё превращается в выгребную кучу.

Answer 1

[Владислав Килин]

Странное ощущение, что это троловопрос. Тем не менее.

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

Если вы собрались переводить ваш сайт с одного подхода на другой, вы так или иначе встанете перед дилеммой: переписывать все или переписывать не все. Другой вопрос, что двойственный подход может стоить вам куда больше полной переписки.

Исключительно в ваших силах не превращать все в выгребную кучу. Я, например, пользуюсь совершенно тривиальным подходом в верстке, который на достаточно серьезных проектах так и не скатился в тартарары.
1. Побольше частичных представлений данных. Конечно, не на каждый чих, но на каждую более-менее абстрактную часть модели.
2. На каждое частичное представление - свой css-файл.
3. Каждый элемент взаимодействия с пользователем - свой js-компонент.

Обычный todo-mvc превращается с таким подходом вот в такую структуру:

todo/
todo.view
todo.css
todo.js
todo_test.js
todoitem/
todoitem.partial
todoitem.css
todoitem.js
todoitem_test.js

Каждое представление состоит из маленького куска верстки, редко больше 50 строк. Каждый css- и js-файл - аналогично. Последний проект, который я делал по такой схеме пережил два года, примерно 10000 коммитов верстки, представлял собой мастер оплаты, веб-приложение и три админки к нему, и до сих пор адекватно функционирует и изменяется.

Answer 2

[memba]

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

А так же можете перемещать свои элементы не залезая в CSS файл и не переписывая наследование.

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

Если вам не нравятся длинные префиксы можно использовать старый подход к БЭМ. В простых проектах я делаю так:

Все глобальные классы начинаются с префикса "b-".

.b-topic { }
.b-topic .title { }
.b-topic .text { }
.b-topic .text a { }

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

Например, если бы я использовал в коде ".title { }" для задания стиля основных заголовков, то ".b-topic .title { }" наследовал бы этот стиль. Что бы этого не произошло, для глобальных классов нужно ставить префикс... ".b-title { }".

Answer 3

[Сергей Виноградов]

Есть ли альтернативы?

Если дело касается CSS, то например operatino.github.io/MCSS или https://smacss.com/

Потом, никто вас не заставляет писать всё по БЭМ'у, испольуя все инструменты, которые предлагает Яндекс.

Вы можете определить для себя свои требования, и им следовать, использую при этом какие-то моменты из БЭМ'а, которые вам нравятся.