Про БЭМ (методология написания CSS от Яндекс — Блок__Элемент_Модификатор ← наиболее правильная запись расшифровки) нынче можно услышать на каждом шагу. Дело оказалось благим и покатилось по миру. Яндекс даже полез в W3C (связано это или нет — не знаю, но надеюсь, что да — [на самом деле нет]).Подробности — по ссылке.
Думаю многие, кто ещё не пробовал, но прочитал описание БЭМ, задаются справедливым вопросом: «какая практическая польза от всего этого действа?» На самом деле, не смотря на то самое развёрнутое описание, конкретно уловить основную «фишку» довольно сложно. Описано конечно много плюсов и общее ощущение от методологии положительное, и кажется, что вроде как и не плохо бы попробовать, но нехватает чего-то конкретного. Прямо вот примера на живом что ли. Вот у меня сайт, вот вёрстка не по БЭМ, почему я должен всё менять? Особенно, если учесть тот факт, что БЭМ в принципе отметает все селекторы кроме классов, неужто за это время столько умных мужей в W3C не осознали, что всё настолько неправильно?
За сим возьму на себя смелость привести несколько примеров с которыми вы (конечно если вы каким-то образом связаны с вёрсткой) сталкиваетесь, не побоюсь этого слова, ежедневно. И что изменится в таких ситуациях если бы вёрстка была изначально выполнена в БЭМ.
Форум /
Прочел "Войну и Мир" пост с комментариями.
Основные проблемы возникают из-за недопонимания целесообразности использования БЭМ-а. Возможно это является следствием малого количества примеров и есть вероятность что требуется предложение градации для малых и средне-крупных проектов. При этом готовых тем для проработки примеров можно набрать из тех же комментариев, так же стоит обратить внимание на "неудобные" примеры - если в этих случаях отсутствует целесообразность применения БЭМ-а, стоит это признать, либо предложить достойный вариант решения. Неудобные варианты это первое о чем будут спрашивать.
Думаю что интересным будут ежедневные мини-статьи/записки в сообщество как раз по простым примерам, это инициирует дискуссию и вычитку для последующего включения примеров в будущий How-to.
Еще один момент, было бы здорово запастись красивыми примерами рефакторинга сайтов "до" и "после", если надо с краткими комментариями.
Вообще, исходя из моего незачительного опыта работы с БЭМ — методология крайне гибкая, может использоваться как для прототипирования, разработки web интерфейсов, так и для разработки мобильных приложений или... да мало ли чего еще. Фактически, любых графических интерфейсов. Да и не только графических... В общем, она действительно очень гибкая).
Неделю назад я думал о том, как было бы удобно описать интерфейс мобильного приложения блоками, создать блоки с необходимыми для сборки технологиями, под андроид своя реализация, под ios своя, при сборке будут собираться нужные, общий код, естественно, тоже будет использоваться. И главное, что даже bem make пригодится. Правда, после него все таки надо будет руками еще и каком-нибудь xcode запустить сборку, но можно и bem make настроить так, чтобы он сразу собирал, или в xcode вызывался — это детали, главное, что это возможно, и это удобнее и быстрее, чем пилить код на бесконечные #ifdefы или абстрактные прокси объекты, которые будут в рантайме что-то там разруливать.
С рефакторингами — сложнее, но на последнем Я.Субботнике делились таким опытом. И это были не докладчики.
Хабрасрач больше похож на закидывание какашками в сторону БЭМа, чем на холивар... печалька.
Думаю, ноги растут от плохого понимания БЭМ-методологии автором статьи (больше на уровне вёрстки, что-ли), а вследствии, и запутывания всего сообщества, а так же открытия дороги товарищам тролям к тем самым пресловутым оружейным какашкам.
Как то раньше было приятнее читать про БЭМ когда про него никто не знал. А сейчас по моему еще хуже))) Ну несколько правильных комментариев уже есть - это хорошо) За них можно и зацепиться разработчикам которые ищют что-то подобное.
Как по мне все круто. Радует что js. Радует что очень гибко и удобно. ) С инструментами правда нужно еще доразобраться
Дисклеймер: автор комента не застал становление ООП, так что любые совпадения случайны
Когда-то люди и в сторону ООП плевались
потом ещё плевались
даже сейчас есть те, кто продолжает плевать в эту сторону, но разве ООП когда-то было плохим?
P.S. Думаю, глупо было бы ожидать, что все с радостью накинуться на БЭМ. Людям нужно время, нужно увидеть ряд очень клёвых проектов, нужно чтобы большие дядечки в которых они верили сказали что это круто.
просто на мой взгляд, у комментаторов на хабре слабо получалось узреть реальный профит(хотя он был). И мне кажется это большей частью из-за отсутсвия красивых примеров и lifestory.
По мне приятнее самому докапаться до крутоты, а не жадать пока кто-то или что-то тебя толкнет к этому
Не скажу, что наследование в ООП — гениальная штука. По большей части это связывание кода, и лучше наследованием пользоваться как можно реже и в идеале не более чем на 1 уровень.
С другой стороны, полиморфизм и инкапсуляция — наше все.
Так что, тут как повернуть.
П.с. Кстати, и реализации ООП в разных языках по-разному удобны. Взять сравнить smalltalk/java с javascript/ruby — земля и небо...
Дорогу осилит идущий
Ваши слова, подтверждают мою мысль: любая парадигма (как мифический артефакт) способна создать великое благо в достойных руках, и, соответственно, великое зло, в руках недостойных. Поэтому её можно хаить вечно, для каких-то задач она, скорее всего, будет подходить лучше, для других - хуже.
Так что, нельзя просто так взять и поверить в БЭМ - нужно много, много аргументов.
А где вы нашли ООП в прототипно-ориентированном JavaScript?
ну пассивный народ тоже может быть/стать пользователями, к ним стоит искать подходы и устанавливать диалог.
а еще — лень двигатель прогресса.
это да