Отказ от ответственности: эта статья очень самоуверенна. Пожалуйста, используйте все, что хотите. Я настоятельно рекомендую вам использовать разные методы для разных приложений, чтобы вы могли сравнить их с реальными вариантами использования ваших проектов. Все следующие моменты касаются «математической точки зрения», т.е. я просто пытаюсь описать идеальный мир веб-разработки.

Не так давно использование React вызвало широкое обсуждение CIJ в компонентной разработке. Эта тема все еще очень актуальна. Этой теме были посвящены две презентации из 11 на последней конференции CSS в Берлине. Я уже не говорю о многочисленных статьях и проектах, которые пытаются конкурировать за аудиторию разработчиков.

Но CSS-in-JS касается не только опыта разработчика; он также пытается решить проблему UX и продвинуть вперед компонентную разработку. Вдобавок ко всему, CIJ запутывает и сбивает с толку многие аспекты разработки внешнего интерфейса, тем самым противореча принципу KISS и принципу разработки UNIX для создания одноцелевых инструментов (программ). Позже я расскажу о деталях, позвольте мне сначала подчеркнуть, почему вышеупомянутые принципы полезны. Разные поколения разработчиков начинают с разных языков / фреймворков (и, конечно, рыночной ситуации), поэтому они не могут просто устанавливать правила для следующих разработчиков. Это жизнь. Тем не менее, по-прежнему крайне важно извлекать из своего опыта и распространять его дальше: принципы UNIX являются частью таких точных и лаконичных знаний, необходимых для беспрепятственной разработки. Мы можем следовать за ними и быть счастливыми.

Что не так с CIJ? Краткий ответ будет заключаться в том, что он позиционирует себя как замену CSS. Более того: несмотря на то, что CIJ - это только подмножество / надмножество CSS, сторонники CIJ, такие как Марк Далглиш, говорят нам, что этот подход решит проблемы на разных платформах, а не только в Интернете. Давайте обсудим появление этих новых библиотек в веб-разработке. До CIJ у нас были проекты для встроенного управления стилями внутри компонентов React. Они решают проблему селекторов CSS с ограниченной областью видимости, используя максимальную специфичность CSS. Таким образом, разработчик может быть уверен, что компонент будет иметь определенную презентацию на веб-странице. Для зрелых разработчиков это, конечно, не было серебряной пулей; они использовали препроцессоры для управления кодом и соглашение об именах для удобства обслуживания. Затем появились модули CSS с решением для определения области видимости CSS. Люди начали использовать его в основном из-за простоты. Я бы сказал, что стиль Shadow DOM намного более перспективен, но веб-компоненты никогда не вызывали столько шума. Таким образом, модули CSS устанавливают бессмысленные имена классов для элементов DOM только для того, чтобы решить проблему определения области видимости. CIJ сочетает эту концепцию с парадигмой встроенного стиля, в которой все правила CSS вместе с их логикой помещаются прямо в файл javascript. Защитники CIJ утверждают, что это больше не встраиваемый подход и что мы можем решить множество проблем одновременно. Это сильное заявление. Но, пожалуйста, не пытайтесь решить все проблемы одновременно! Особенно нет необходимости повторно реализовывать спецификацию CSS в javascript, чтобы поддерживать один и тот же набор правил на разных платформах (я говорю о гибкой реализации, в частности, для react-native).

На этом этапе я хотел бы быть более конкретным и привести больше примеров. Следя за темой CIJ в течение нескольких последних месяцев и прочитав несколько статей за и против, я могу порекомендовать вам нескольких авторов. Они приведут вам множество причин, по которым установка CSS в JS, как правило, не является хорошей идеей.
http://keithjgrant.com/posts/2015/05/against-css-in-js/ < br /> http://jamesknelson.com/why-you-shouldnt-style-with-javascript/
https://medium.com/@gajus/stop-using-css-in-javascript -for-web-development-fa32fb873dcc

Эти парни действительно хороши с точки зрения своего влияния на сообщество, я имею в виду, они не просто болтают и жалуются, как я. Им можно доверять) Некоторые из упомянутых в статьях проблем CIJ стоит здесь повторить.

  • CIJ не означает, что вам не нужно изучать CSS. В любом случае, как фронтенд-разработчик, вы должны знать о блочной модели CSS, специфике селекторов и многих других аспектах. Некоторые предпочитают ограничиваться заранее определенным набором правил для создания пользовательского интерфейса. Это может быть использование только flexbox или привязка к определенной сеточной системе, такой как Bootstrap. Тем не менее, знание всех возможностей CSS дает вам гибкость и свободу.
  • CIJ - это дополнительный уровень абстракции в вашем проекте. Это звучит как обычное дело в инженерии. Я имею в виду, что мы всегда складываем разные слои вместе для идеального результата. Но в случае CJS этот слой не является необходимым и потенциально дорогостоящим. Если в коде CSS есть проблема, будет сложно определить, на каком уровне содержится проблема. CIJ все еще находится на начальном этапе, и процесс отладки (а также широкая поддержка в IDE) далек от совершенства.
  • CIJ не помогает общаться внутри команды. Для такого общения должен быть общий язык. Многие дизайнеры могут понимать и писать файлы CSS. А есть люди, которые профессионально занимаются только созданием разметки. Каким вы видите их общение с миром CIJ? Вы хотите, чтобы они понимали систему компонентов, написанную на javascript? Я так не думаю.
  • Подход CIJ делает ваш код еще более запутанным. Некоторым разработчикам нравится помещать правила CSS прямо в файл javascript, но это явно нарушает принцип разделения ответственности. CSS был создан для визуального представления. Это мощная концепция, заключающаяся в том, что, если мы захотим изменить это представление, мы сможем изменить только файл CSS. В таких случаях хорошо спроектированные компоненты не требуют модификации разметки.
  • CSS - чисто декларативный язык; именно поэтому он такой мощный. Но CIJ имеет тенденцию быть императивным. Мы проигрываем здесь.

Это философия Unix. Пишите программы, которые делают одно и делают это хорошо. Напишите программы для совместной работы. Напишите программы для обработки текстовых потоков, потому что это универсальный интерфейс.

Дуг Макилрой

Давайте продолжим приносить извинения по поводу StyledComponent. На последней конференции CSS в Берлине Глен Мэддерн назвал несколько причин, по которым он написал эту библиотеку. Он сказал, что нет необходимости использовать дополнительные библиотеки, такие как PostCSS, для объединения стилей. Вместо этого вы можете использовать обычные JS-модули. Он утверждал, что преобразования файлов не так прозрачны по сравнению с набором программных правил. Вроде пока все хорошо. Затем он упомянул, что синтаксис библиотеки вдохновлен SASS. Давай остановимся здесь. Если они изменили синтаксис, это больше не классический CSS, верно? Это надмножество или подмножество, разница такая же. Но комбинируя инструмент построения, такой как PostCSS, и синтаксический сахар, такой как SASS, вы нарушаете разделение задач. Я бы сравнил такой подход с очень неожиданной ситуацией, когда повар начинает печь сладкий пирог с мясом внутри, предлагая его вместо обычного обеда из основного блюда и десерта. То же самое произошло с автором JSS Олегом Слободским, который связывает воедино очень разные цели JSS. Некоторые из этих функций ориентированы на производительность, другие - на обслуживание кода. Итак, теперь все теряют цель инструмента и его основной вариант использования.

Кроме того, аргументы в пользу производительности особенно умозрительны. Некоторое время я занимался темой веб-оптимизации, и с тех пор считаю, что это действительно отдельная часть процесса разработки. Когда Глен говорит нам, что критическая проблема CSS волшебным образом решена CIJ, я начинаю думать, что эта конкретная проблема - лишь небольшой кусочек огромной головоломки, называемой производительностью сети. И когда хорошие парни сравнивают разные библиотеки CIJ в поисках наиболее эффективного размера пакета, я действительно обеспокоен тем, что это не может иметь никакого отношения к моему проекту SPA, потому что проблема большого пакета должна быть решена в другом измерении.

Если вы все оптимизируете, вы всегда будете недовольны.
Дональд Кнут

Для ясности, начните с самого начала: с пользователя. Да, производительность - это метрика, ориентированная на пользователя, и у нас есть очень хорошая методика, которую можно применить здесь, которая называется RAIL-модель, разработанная Google. Это поможет вам понять критерии, а затем вы сможете использовать инструмент Lighthouse для повышения производительности вашего конкретного приложения. CIJ не может быть инструментом повышения производительности, потому что у него уже есть другая цель: обслуживание кода. И, чтобы быть последовательным, некоторые из хороших примеров инструментов инфраструктуры CSS - это CSSO и Autoprefixer.

Давайте представим, что может случиться в будущем. Похоже, у нас не так много вариантов для CIJ. Некоторые считают, что он заменит CSS. Но я в этом сомневаюсь. CSS активно развивается, нужно лишь обращать внимание на правильные источники. Особенно важен проект Houdini. Конечно, CIJ может быть заменой CSS на не-веб-платформах, но он подчеркивает в основном проблему этих конкретных систем. Возможно, я ошибаюсь насчет назначения многочисленных библиотек CIJ, и они являются предварительными решениями перед появлением нового стандарта в Интернете. Тем не менее, текущий статус CIJ для меня неясен, что заставляет меня очень скептически относиться к его светлому будущему.