Если вы уже преодолели порог входа (важное условие!), то делать даже простые сайты (ну где есть больше одного блока, а не просто текст в body) проще с БЭМ. Лично я все личные мелкие штуки быстро тяпляпаю с bem-tools/bemhtml/i-bem.js.
я думаю на этом можно считать тред исчерпанным ;-) — ваши аналогии вполне хороши, а дальше каждый сам для себя решает, зубами он провод оголяет или швейцарским ножом
Если отбросить вопрос порога входа и рассматривать только применимость, то у меня вот такие мысли. Есть два типа сложных инструментов (инструментов с высоким порогом входа):
1) узкоспециальные — например, какой-нубудь инструмент для обслуживания велосипеда — сложность там обусловлена предметной областью, т.е. как раз применимы они только для определённых задач
2) универсальные — например, швейцарский нож — сложность обусловлена тем как всё сложно понапихано в одну штуку, но применимость (после того как овладел) вполне универсальная (даже в велике можно будет что-то покрутить)
Мы всю дорогу проектировали БЭМ как раз как более универсальный инструмент и вот есть пример применения его для той же визитки: github.com/mishanga/bem-vcard + mishanga.pro
Но это конечно не означает, что он универсален до абсолюта — продолжая аналогию, для некоторых задач нужен не швейцарский нож, а бутылка воды.
Конечно нижний предел масштабируемости есть. Его тяжело сформулировать точно, т.к. у нас нет никаких едениц измерения для размера и сложности проекта. Если говорить примерно, то, безусловно, если вам сейчас нужно сделать один сайтик и больше их не делать никогда, то не надо тратить время на преодоление порога входа. Если же вы хотите остаться в профессии на долго, то скорее всего (если всё будет складываться) размер и сложность проектов со временем будут только расти (в идеале расти бесконечно ;-) ) — а это значит, что рано или поздно, вы преодолеете любой нижний предел. Так почему бы не начать сразу?! ;-)
Так короче писать. Но так нужно учитывать набор допущений. Например, что первый пункт меню действительно первый в DOM-е, а не второй, потому, что первый скрыт JS-ом или используется под какой-нибудь бордер-разделитель. Или, что вы не поддерживаете IE6, в котором не работают селекторы вида .item.current и :first-child.
Всегда можно вручную собрать элегантное решение под узкую конкретную задачу, но БЭМ он про то, что:
— задачи с течением времени меняются прямо под ногами и решение должно выдерживать это с минимальным переписыванием
— задач много и их надо делать на потоке, срезая углы на придумывании для каждой заковыристых элегантных короткостей (хотя я и сам их так люблю!)
ID обязаны быть уникальными в пределах документа. В основе же БЭМ, одним из принципов, всегда лежала идея о произвольном повторении произвольных блоков на странице. Скорее можно сказать, что БЭМ стоит поперёк горла идее каскадных селекторов, т.к. классы то используются как раз по назначению. Но это тоже не совсем так, про контекстную зависимость уже писал тут выше по треду — habrahabr.ru/post/171437/#comment_5951255 — у неё есть особенности, но БЭМ её никак не запрещает (просто мы подробно рассказываем в чём минусы и получается так, что в реальных проектах она мало используется).
Не боитесь, что к тому моменту, когда вы увидите причины не употреблять звёздочку, у вас на руках будет огромный проект с кучей кода и большим количеством элементов на странице? И его надо будет полностью переписать, т.к. на таких объёмах уже будут глазом видны тормоза (кстати, про измерения не «на глазок» можно посмотреть events.yandex.ru/events/yasubbotnik/kiev-may-2011/talks/232/ ).
Я понимаю, что аргумент звучит в духе «такие проблемы только у Яндекса» и «маленьким проектам это не нужно». Но я просто хочу намекнуть задуматься, а стоит ли проверять на своём опыте, наступите ли вы на эти же грабли.
Именно так. Идея «интерфейсов» или «контрактов» отлично выражается в БЭМ-терминах (мы этим сами пользуемся). Можно это делать не только с помощью модификаторов, но и с помощью дополнительных примиксованных блоков. При этом происходит явное отделение, когда нам нужно заводить интерфейс, а когда нет. Подробнее про миксы можно послушать в докладе events.yandex.ru/events/yasubbotnik/msk-sep-2012/talks/327/
Ваше утверждение немного конфликтует с тем, что к нам на конференциях подходят посторонние люди и говорят, что у них есть необходимость в подобной БЭМ методологии (а также в наборе инструментов и готовых блоков).
Абсурдно спорить с тем, что БЭМ появился как решение конкретных проблем в Яндексе (и продолжает нами развиваться тоже для этого же) — мы не спорим ;-) Вот только это не противоречит никак тому, что всё это применимо в других проектах — нужно всего лишь преодолеть порог входа!
Яндекс достаточно большой, чтобы в нём могли существовать люди, не сумевшие договориться и было бы не честно отрицать наличие «не технологических» причин.
Вы правы, и XJST и YATE появились из общих базовых идей типа «как XSLT, только лучше», нужен JavaScript, декларативность и т.п… Но я могу обобщить технологические отличия.
XJST проектировался и создавался как часть некоторой системы, это ядерная библиотека с узкой специализацией — нахождение шаблонов по предикатам и их рекурсивное применение — и эта узкая специализация максимально проработана (см. подробнее доклад clubs.ya.ru/bem/replies.xml?item_no=899 ). В нём нет ничего про задачу создания HTML, синтаксический сахар, ескейпинг и всякое такое. Подразумевается, что XJST будет использоваться внутри других инструментов, которые будут уже отвечать за свою узкую специализацию, например, удобство генерации HTML (например, BEMHTML) или диспетчеризацию URL-ов.
YATE это инструмент полного стека для задачи написания шаблонов для генерации HTML. Т.е. в нём встроены и какие-то механизмы подбора шаблона (более простые, чем в XJST), и вещи типа автоескейпинга, синтаксического сахара (HTML-литералов), которых совсем нет в XJST.
XJST является по сути небольшим надмножеством JavaScript, т.е. практически всё пишется именно на JavaScript и только на нём, чтобы можно было использовать существующие знания синтаксиса, производительности и т.п… И если разработчику нужно добавить какую-то сложную функциональность он может написать её нативно, внутри XJST-шаблона.
YATE это отдельный язык, который подразумевается для компиляции не только в JavaScript, т.е. в нём, например, свои принципы использования переменных и т.п… Подразумевается, что язык этот достаточно простой, чтобы с одной стороны не создавать проблем для изучения, а с другой, потенциально компилироваться плюс-минус в любой язык типа C, Perl, Java и др… Так же, этот язык такой простой, что любые сложные вещи должны реализовываться не на нём, а отдельно в виде плагинов на том языке куда происходит компиляция (JavaScript, C, Perl и т.п.).
Уже этих отличий достаточно, чтобы могли существовать два проекта. Но в теории, в будущем, можно было бы компилировать YATE в XJST, чтобы использовать и сложный оптимизированный матчинг и синтаксис, если он многим понравится.
до того, как YUICompressor научился обрабатывать по несколько файлов за однин вызов мы делали этот патч сами во внутренней версии YUICompressor иначе было совсем не приемлемо медленно
1) узкоспециальные — например, какой-нубудь инструмент для обслуживания велосипеда — сложность там обусловлена предметной областью, т.е. как раз применимы они только для определённых задач
2) универсальные — например, швейцарский нож — сложность обусловлена тем как всё сложно понапихано в одну штуку, но применимость (после того как овладел) вполне универсальная (даже в велике можно будет что-то покрутить)
Мы всю дорогу проектировали БЭМ как раз как более универсальный инструмент и вот есть пример применения его для той же визитки: github.com/mishanga/bem-vcard + mishanga.pro
Но это конечно не означает, что он универсален до абсолюта — продолжая аналогию, для некоторых задач нужен не швейцарский нож, а бутылка воды.
Всегда можно вручную собрать элегантное решение под узкую конкретную задачу, но БЭМ он про то, что:
— задачи с течением времени меняются прямо под ногами и решение должно выдерживать это с минимальным переписыванием
— задач много и их надо делать на потоке, срезая углы на придумывании для каждой заковыристых элегантных короткостей (хотя я и сам их так люблю!)
Отдельно немного в тему Консорциума — habrahabr.ru/company/yandex/blog/156389/
Я понимаю, что аргумент звучит в духе «такие проблемы только у Яндекса» и «маленьким проектам это не нужно». Но я просто хочу намекнуть задуматься, а стоит ли проверять на своём опыте, наступите ли вы на эти же грабли.
events.yandex.ru/events/yasubbotnik/msk-sep-2012/talks/329/
raw.github.com/bem/bem-bl/master/blocks-common/i-bem/__html/i-bem__html.wiki
Абсурдно спорить с тем, что БЭМ появился как решение конкретных проблем в Яндексе (и продолжает нами развиваться тоже для этого же) — мы не спорим ;-) Вот только это не противоречит никак тому, что всё это применимо в других проектах — нужно всего лишь преодолеть порог входа!
Забирает:
— производительность
— устойчивость к модификациям вида «перенести это в _таком же_ виде в другое место»
Даёт:
— меньше писать, т.к. не надо в каждом месте повторять что-то точечно, а можно модифицировать контекст
Вы правы, и XJST и YATE появились из общих базовых идей типа «как XSLT, только лучше», нужен JavaScript, декларативность и т.п… Но я могу обобщить технологические отличия.
XJST проектировался и создавался как часть некоторой системы, это ядерная библиотека с узкой специализацией — нахождение шаблонов по предикатам и их рекурсивное применение — и эта узкая специализация максимально проработана (см. подробнее доклад clubs.ya.ru/bem/replies.xml?item_no=899 ). В нём нет ничего про задачу создания HTML, синтаксический сахар, ескейпинг и всякое такое. Подразумевается, что XJST будет использоваться внутри других инструментов, которые будут уже отвечать за свою узкую специализацию, например, удобство генерации HTML (например, BEMHTML) или диспетчеризацию URL-ов.
YATE это инструмент полного стека для задачи написания шаблонов для генерации HTML. Т.е. в нём встроены и какие-то механизмы подбора шаблона (более простые, чем в XJST), и вещи типа автоескейпинга, синтаксического сахара (HTML-литералов), которых совсем нет в XJST.
XJST является по сути небольшим надмножеством JavaScript, т.е. практически всё пишется именно на JavaScript и только на нём, чтобы можно было использовать существующие знания синтаксиса, производительности и т.п… И если разработчику нужно добавить какую-то сложную функциональность он может написать её нативно, внутри XJST-шаблона.
YATE это отдельный язык, который подразумевается для компиляции не только в JavaScript, т.е. в нём, например, свои принципы использования переменных и т.п… Подразумевается, что язык этот достаточно простой, чтобы с одной стороны не создавать проблем для изучения, а с другой, потенциально компилироваться плюс-минус в любой язык типа C, Perl, Java и др… Так же, этот язык такой простой, что любые сложные вещи должны реализовываться не на нём, а отдельно в виде плагинов на том языке куда происходит компиляция (JavaScript, C, Perl и т.п.).
Уже этих отличий достаточно, чтобы могли существовать два проекта. Но в теории, в будущем, можно было бы компилировать YATE в XJST, чтобы использовать и сложный оптимизированный матчинг и синтаксис, если он многим понравится.
про скорость Node.js и Java вы правы ;-)
а что такое CSC?