БЭМ — методология развешивания костылей
Впервые я узнал о БЭМ лет 5 назад. В то время все ненавидели IE6, ждали возможности полноценно использовать CSS2 и благополучно забывали табличную верстку. В то время казалось, что когда исчезнет IE6, жизнь верстальщика станет увлекательной и беззаботной. Именно IE6 был основной причиной костылей в верстке. Кто бы мог подумать, что во времена HTML5 и CSS3, когда нет особых проблем с развитием популярных браузеров, ситуация станет еще хуже.
Недавно я обнаружил, что многие существующие проекты уже внедрили БЭМ, а некоторые новые проекты требуют от верстальщика обязательной разработки по БЭМ. То есть профессиональные разработчики уже ставятся перед фактом и не имеют выбора. Раз ситуация складывается таким образом, давайте попробуем разложить все по полочкам без рекламы и приукрашивания.
Сопровождаемость и повторное использование кода
Очень важные показатели для любой разработки, известные нам в основном по языкам программирования. Вся суть и прелести БЭМ сводятся именно к этим показателям. Если программисту долго рассказывать про их важность, а потом предложить купить слона, сделка скорее всего состоится. Чтобы понять, улучшает ли БЭМ что-то в этом направлении, надо сначала определиться по отношению к чему будем проверять улучшения. Если сверстать страничку таблицами, как это было во времена IE6, то улучшения от перехода на БЭМ с такой верстки определенно будут. Но найти проекты, которые все еще страдают от табличной верстки, сейчас уже непросто. Посмотрим лучше на актуальные практики, которые идут из спецификации HTML/CSS.
Таких практик всего одна. Это семантическая верстка с разделением структуры данных и оформления. Много лет разработчики самого HTML развивали язык, подразумевая именно эту практику. В концепции разделения структуры данных и оформления заложена одна очень важная идея на тему сопровождаемости. HTML-разметка создается таким образом, чтобы любые последующие изменения можно было вносить, меняя только CSS-код. Эта концепция очень изящно решает все задачи сопровождаемости. В итоге, если БЭМ что-то и улучшает в плане сопровождаемости, то явно не по отношению к семантической верстке.
БЭМ существенно облегчил жизнь разработчиков в Яндекс
Много раз видел что-то вроде этой фразы в качестве убедительного аргумента в пользу БЭМ. Проверить качество жизни разработчиков в Яндекс после перехода на БЭМ будет непросто. Зато можно посмотреть код их проектов. Так вот, это очень похоже на правду. Ведь в верстке некоторых проектов Яндекса все еще используются некоторые практики табличной верстки. К примеру, чтобы расположить логотип и горизонтальное меню сбоку от него, кто-то из разработчиков Яндекса впендюривает одну общую таблицу. Неудивительно, что БЭМ улучшает жизнь в Яндекс, ведь хуже БЭМ только табличная верстка.
Проблема в том, что свою борьбу с таблицами эта компания разнесла по всему рунету под видом некой эффективной методологии. Сейчас даже новые проекты, разработчики которых даже не знают про табличную верстку, вынуждены использовать эту топорную практику борьбы с таблицами. Бороться с табличной версткой нужно, если проблема еще где-то имеет место. Вот только не надо менять одни костыли на другие. Есть хорошие готовые практики, которые давно решают все задачи сопровождаемости. И уж точно не стоит выгонять с Хабра всех, кто высказывается против использования методологии БЭМ. Если бы БЭМ был так прекрасен, как описывают авторы, не было бы срача.
Что в итоге
БЭМ — это жесткий и очень топорный свод правил, который не несет никакой практической пользы, если не брать в расчет проблемы устаревшей табличной верстки. БЭМ уродует код и разрушает все прекрасное, что есть в процессе верстки. Любое соприкосновение с БЭМ напоминает бессмысленное и утомительное развешивание костылей.
Перед тем как внедрять у себя БЭМ, стоит несколько раз подумать, почитать спецификацию HTML/CSS, изучить другие практики. Только после реального понимания практической полезности разных практик и различий между ними можно принимать решение в пользу использования БЭМ, но лучше в этот момент еще раз подумать. В ином случае можно стать жертвой агрессивного маркетинга и соучастником в распространении говнокода.
