Оптимизируем React приложение для отображения списка элементов

shouldComponentUpdate(newProps, newState) {
    // проверяем что порядок и кол-во элементов остались прежними
    // то есть если id остались прежними, значит у нас нет "больших" изменений
    const changed = newState.targets.find((target, i) => {
        return this.state.targets[i].id !== target.id;
    });
    return changed;
}

здесь может вылететь ошибка, если в newState.targets больше элементов, чем в this.state.targets

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

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

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

import Module from './Module';

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

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

Возможно, вы невнимательно прочитали статью.

такой подход пытается решить самораздутую проблему с глобальной областью видимости с CSS это всё

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

При этом, во-первых, нифига её не решает, т.к. единственная разница в конечном CSS, так это названия селекторов в CSS станут короче

Как это? Разница в том, что имена классов будут уникальными. Не «может быть уникальными», а уникальными. При этом исходный код содержит понятные и уместные названия.

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

С чего вдруг? А при импорте .js файлов таких проблем нет? В чем разница?

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

Именно этот вопрос в статье описан и решается просто и удобно для дев-режима. А на проде minified, uglified и concatenated javascript вы легко читаете? :)

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

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

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

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

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

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

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

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

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