Конец эры глобального CSS

А не так давно все рассчитывали, что эту проблему решит Shadow DOM.

Затем появилась связка virtual dom + es6/browserify imports, и всё, чего ей не хватало, это изолированные стили.
Теперь, возможно, и так неспешное внедрение shadow dom'а затянется ещё сильнее. Посмотрим!

CSSModules круты да, но этого не достаточно против

*{
 //
}

рекомендую еще postcss-initial и postcss-autoreset.

Согласен, что звучит громковато и это тоже способ борьбы с существующей проблемой, а не её устранение. Но подход к решению как раз совсем другой — не такой хрупкий, как у существующих «ручных» методик по именованию классов. И он действительно меняет подход к написанию css.

При разработке, в общем-то, важно, чтобы решение работало. Например, какая разница, используется ли browserify, webpack или нативный браузерный es6 import, если в любом случае мы пишем строчку

import Module from './Module';

и эта строчка работает? Безо всяких поправок на то, как именно обеспечили её работу. Да, абстракции дают протечки, и хорошо знать, что там под капотом, но это не значит, что абстракции плохая концепция. Ими можно и нужно пользоваться.

Веб-компоненты — отличная идея, а <template></template> с собтвенным тэгом <style></style> — офигительно удобно.

Проблема в том, что до их внедрения ещё не скоро. Shadow DOM — штука, под которую практически невозможно сделать полифилл.

А технология, описываемая в статье, будет работать прямо сейчас в любом браузере. Нужна настройка системы сборки? Да. Но ведь и Polymer требует того, чтобы над ним посидеть и всё настроить.

В идее, описанной в статье, нет какого-то дополнительного усложнения. Мы и раньше пользовались системами сборки и css-препроцессорами. Только сверх этого нужно было ещё строго следовать выбранной методике по именованию классов. Теперь же скорее наоборот — руки частично развязаны, можно спокойно писать CSS, которой затронет только тот компонент, который хочется.

А импорт css внутри javascript модуля я бы не назвал «мешаниной». Это идея цельного компонента. Ингредиенты: html, css, javascript. Вполне логично, когда они вместе. Web components ведь о том же говорят :)

Во-вторых отхватите проблемы с кривыми импортами, дублированием импортов или импортом не того и не туда.

Это как вообще? Импорты теперь анти-паттерн и опытные разработчики не используют их, чтобы не огрести проблем с импортом «не туда»? :D

В-третих, как это все замечательно будет смотреться в девтулзах, когда в браузере на проде ты видишь селектор ._1rJwx92-gmbvaLiDdzgXiJ { … } и не понимаешь откуда он.

Source maps

Если верстка не статическая, а шаблон, то в него можно прокинуть стили вместе с остальными данными.

Например, в Marionette:

import {ItemView} from 'backbone.marionette';
import styles from './styles.css';

export default class extends ItemView {

    serilalizeData() {
        // прокидываем стили в шаблон
        return Object.assign(super.serializeData(), {styles});
    }
}

В шаблоне

<div class={{styles.foo}}></div>

А также для тех, кто рендерит нодой на сервере.

Пафоса многовато, может быть, да, но и не то чтобы «из ничего»

На самом деле css-modules отдают вам map оригинальных имен на уникальные. Вы можете сохранить их в json и проводить замену на своем сервере, как вам удобно.

Пускай сначала к единым стандартам придут и решат проблему кроссбраузерности. :)

Зачем намеренно усложнять вещи, которые призваны быть простыми?
Можно понять возможность расширения функционала, или устранения очевидных проблем вроде позиционирования, кроссбраузерности.
Иначе звучит как «Установить библиотеку из 100 строк, что бы 10 строк писать в 5 строк»