CMS для сайта-визитки

Вот-жеж блин. Сколько лет пользуюсь, не знал, что у такого способа описания и название есть. (а узнал про него, подсмотрев в чужом коде)

Имхо - самый логичный, красивый и понятный способ написания легкомасштабируемых структур.

Который разрушает всю идею классов, делая из них по сути идентификаторы.

По сути, кроме Яндекса его никто и не использует.

Большинство популярных CMS - WordPress, VBulletin, Ghost, сайтов - Google, Medium, Wikipedia используют классическую гибкую разметку.

Представим на сайте есть кнопки, которые могут быть тегами label, a, button, input, span.

Классическим выходом будет просто дописывать class="button" в HTML, например, <label class="button">, и задать стили для .button в CSS.

Если нужно дополнительное оформление исходя из элемента, можно уточнить, label.button, a.button и так далее.

Но исходя из Яндекс БЭМ, нужно писать <label class="label__button">, <a class="a__button">.

И даже больше, если нужно оформить определенное состояние элемента, например, :hover, Яндекс предлагает писать .label__button--hover вместо label.button.hover.

А если у вашей кнопки есть родители, тогда вам нужно всех их прописать в название класса.

Вместо .list a - .ul__list__item__link.

Какое из этого удобство?

То, что Internet Explorer 8 обрабатывает селектор .label__button--hover на 2 мс быстрее label.button.hover? Так ведь и растет количество этих самых селекторов!

Стабильность и структурированность? - Возможно, но в ущерб гибкости. Тем-более, те же цепочки классов можно воссоздать и в SASS.

Александр И, когда у вас на поддержке 75 сайтов, отличающихся друг от друга цветом шкурки, и расположением почти однотипных блоков, это реально удобно. поверьте. Это позволяет вносить изменения в какой-либо дефолтный блок или элемент блока, тем самым меняя только его, не трогая, при этом всю остальную обвязку. (мало того, сохраняется и раскраска, которая у нас вынесена в отдельный файл)

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

зы. прочем, мы уже оффтопим

Александр И, вы не поняли что такое БЭМ и с чем его едят, а за код с ваших примеров "я бы уши то пооткрутил" ©

Для сайта-визитки? Устроим гонку: верстальщик предоставил нам архив с файлами index.html, about.html, contact.html, footer.html, header.html. Кто быстрее сделает сайт визитку, я, распаковав архив и залив на хостинг, или ты, разворачивающий свою джангу или что ты там любишь?

Webasyst - это фреймворк, а не движок. Да и не особо то он шестикрыл, уж точно меньше чем Wordpress.

Верстальщик может повлиять на роутинг? На загрузку конфигов к базе? PSR-7? Не смеши.

Прочти это:

Вебасист это такой-же фреймворк как битрикс, или вордпресс. Наличие определенного, весьма скудного и не ахти как задокументированного, АПИ не делает его фреймворком.

Боже, о каком роутинге вообще речь идет. Тут разговор шел о том, что человек сделает верстку вместо 100 килобайт в 10. А вы уже в такие дебри полезли. Просто для него "код" это верстка, а не моторчик.

Прочел. В теории -все круто. На практике - когда из-за "selector--name" приходится прогеру делать на одну а целых 3 страницы (add/updete/index) то ну его к чертям. Может верстальщику проще (хотя хз, я лично верстаю на бустрапе 3 и мне там удобно) но прогеру точно очень усложняет жизнь тот БЕМ. я бы убил того, кто это придумал и добавил мне проблем. Хотя при часовой оплате - я получаю больше)

И тем не менее, вебасист - фреймворк для разработки приложений, какие бы ты тут мысли не высказывал.

Человек все правильно говорит - под сайт визитку незачем использовать CMS.

Щито? Что за "add/update/index"? Можете изложить вашу проблему подробней, в чем она заключается?

Прекрасно, но на практике все-равно получается много кода, мало гибкости и абстракции.

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

Я следую концепту дизайна Material Design.

Каждый блок может быть .card {border-radius: 4px; box-shadow...}...

Каждый блок может быть разной цветовой палитры .red, .red-invert...

Каждый блок может иметь разный цвет текста .primary, .secondary, разный размер шрифта .display-1, .body...

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

(примерно такую разметку я использую)

<div class="card red-invert s-hide">
    <h1 class="display-1 primary"></h1>
</div>

Если вдруг Google обновит рекомендации и скажет не использовать border-radius для карточек, мне нужно будет отредактировать только класс card.

Собственно для этого и предназначены классы, для абстракции.

Как я понимаю, следуя Яндекс БЭМ, мой код бы выглядел как и соответственно, мне нужно будет продублировать оформление конкретно для этой карточки:

(поправьте, если я неверно понял концепцию)

<div class="cardredinvertshide">
    <h1 class="cardredinvertshide__display1primary"></h1>
</div>

А в CSS, вместо .card {}, .cardredinvertshide, .card2redinvertshide, .card3redinvertshide... {}

(что повлияет не только на размер HTML, но и CSS)

Как по мне, это то же самое, что сравнивать ООП (классы) с функциями (БЭМ)?

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

БЭМ практически превращает классы в идентификаторы, которые можно использовать больше одного раза.

А вся идея крутится вокруг изначальной медлительности вложенных селекторов?

Разве это не проблема браузеров?

Разве JS/HTML/CSS это не из области ВЫСОКОархитектурного программирования, где акцент делается на логику, расширяемость и гибкость?

Да, но на сайте визитке есть форма обратной связи, которая шлет на email, имеет валидацию, сохраняет на всякий случай в БД, вдруг письмо реджектниться как спам, отправляет смс для скорой обработки заявки, а так же добавляет заявку в CRM. Иногда там надо менять шапку под праздники, а потом еще каталог товаров или услуг выложить. Посчитаете в общем? :) На разработке жизненный цикл проекта не закончился. Развернуть на той же симфони или yii или любом другом фреймворке ваш архив у меня займет на 15 минут больше времени чем у вас разархивировать, зато потом я буду навешивать функционал с неверойтной скоростью и дешевизной по сравнению с вашими костылями, которые проект превратят в лапшакод с кучей багов/ошибок и etc.

---------- Добавлено 11.01.2017 в 18:38 ----------

БЭМ хорошо дружит с бутстрап, никак не мешает бэкенд программерам, просто вместо <div class='rL Lt center hd of cat item nostok'> появляется вменяемый <div class='products__item products__item_disable'

---------- Добавлено 11.01.2017 в 18:46 ----------

Это прекрасно, пока вы помните что у вас card это именно то что вам надо, а потом прихожу я и мне надо поменять стиль у конкретно этого card конкретно на этой странице, и? думаете я знаю что card это то что вы запланировали? Методология на то и методология, так сказать правила, БЭМ знают многие, ваши - никто. БЭМ хорошо переносится между проектами, вы можете взять с любого БЭМ проекта и выдернуть кусок и он будет ровно таким же и никак не повлияет на новый проект. А знаете сколько в общем экономит реюзабельный код времени? С точки зрения абстракции БЭМ конечно же сложнее, он навязывает, но в дальнейшем он просто делает жизнь легче.