Действительно, такая изоляция может работать, но только для атомарных компонентов: когда мы уверены, что внутри ничего не появится (того, что мы не задумывали).
Во всех остальных случаях необходимо обеспечить, чтобы селекторы элементов одного блока не мачились на вложенный, потому что сам по себе селектор .cool-module .button не обеспечивает этого (будет мачится на все .button внутри, даже если это уже кнопка из другого, вложенного, блока)
БЭМ — появился не на пустом месте, а для решения конкретных задач. Если есть инструменты, которые могут решить эти задачи иначе: надо обязательно на них смотреть (как минимум, чтобы свой собственный взгляд в этом вопросе расширять).
Уникальные имена классов для каждого элемента избавляют от таких казусов. В БЭМ это решается неймингом, а в CCS-модулях — автоматически, за счет локального скоупа.
«Жесткие» компоненты с максимальным приоритетом собственных стилей — это круто, когда пишется нечто, что будет использоваться на разных сайтах
На любом сайте, который живет и развивается, компонентый подход оправдан.
Завтра приходит менеджер и просит переставить вот эту штуку сюда, а этот блок вложить вот в этот — не круто говорить в таких случаях «Я так не задумывал! Мне нужно неделю, чтобы все переверстать».
В Яндексе компонентый подход приняли задолго до того, как это стало популярно и все к этому пришли. Виталий Харисов первый раз рассказывал про БЭМ, кажется, еще в лохматом 2007 году.
Что случится если внутри my-mega-widget появится my-another-mega-widget внутри которого будет button?
На button уже будут мачится два селектора: .my-mega-widget .button и .my-another-mega-widget .button, а это не то, чего ожидаешь от композиции компонентов.
Бэкбон это все-таки про одностраничные приложения, а это скорее reactjs, только очень простой — не для веб-приложений, которые живут годами, а для простых сайтов, например, лендингов
Предлагаете отказываться от jQuery как зависимости и поддержать нормальную модульность?
Изначальная идея была в том, чтобы сделать штуку для, грубо говоря, простого верстальщика, который привык работать с jQuery и на простом сайте он уже подключен.
Во всех остальных случаях необходимо обеспечить, чтобы селекторы элементов одного блока не мачились на вложенный, потому что сам по себе селектор .cool-module .button не обеспечивает этого (будет мачится на все .button внутри, даже если это уже кнопка из другого, вложенного, блока)
Я «адепт БЭМ» и, тем не менее написал обзор CSS-модулей :)
БЭМ — появился не на пустом месте, а для решения конкретных задач. Если есть инструменты, которые могут решить эти задачи иначе: надо обязательно на них смотреть (как минимум, чтобы свой собственный взгляд в этом вопросе расширять).
Уникальные имена классов для каждого элемента избавляют от таких казусов. В БЭМ это решается неймингом, а в CCS-модулях — автоматически, за счет локального скоупа.
Как верно отметил Iskin, плюс CSS-модулей в том, что «не надо ни о чем думать».
А послезавтра потребуется добавить обертку для кнопки и селектор непосредственного потомка перестанет работать.
На любом сайте, который живет и развивается, компонентый подход оправдан.
Завтра приходит менеджер и просит переставить вот эту штуку сюда, а этот блок вложить вот в этот — не круто говорить в таких случаях «Я так не задумывал! Мне нужно неделю, чтобы все переверстать».
На button уже будут мачится два селектора: .my-mega-widget .button и .my-another-mega-widget .button, а это не то, чего ожидаешь от композиции компонентов.
Или disabled — это вложенный элемент, а не модификатор для самого компонента?
Предлагаете отказываться от jQuery как зависимости и поддержать нормальную модульность?
Изначальная идея была в том, чтобы сделать штуку для, грубо говоря, простого верстальщика, который привык работать с jQuery и на простом сайте он уже подключен.
либо, т.к. в данном случае метод inc синхронный, можно вызвать где-то в коде приложения сперва inc у блока, а затем updateOnServer