Попалась на глаза серия из двух статей про CSS-in-JS от автора библиотеки JSS Олега Исонена. В первой части рассказывается про причины появления этого подхода.

CSS-in-JS это не какая-то библиотека, а идея, которая получила своё воплощение в целом ворохе библиотек, которые позволяют описывать и использовать CSS прямо в JS-коде. Это позволяет избежать целого класса проблем, присущих обычному CSS: отсутствие ограниченной области видимости, наличие неявных связей между стилями и кодом, накопление старого CSS-кода, недетерминированная специфичность, вызванная порядком загрузки стилей, могущественные селекторы, которые иногда сложно поддерживать, невозможность выразить стили на основе состояния приложения.

При этом в статье есть очень спорный момент. Автор пишет про то, что для решения некоторых описанных проблем были придуманы разные методологии наименования стилей и организации кода. При этом эти методологии очень сложны во внедрении, когда над проектом работает большое количество людей. По-моему личному опыту это не так. Конечно, какое-то недопонимание может быть в самом начале, но когда все участники разработки видят, что та структура, которую даёт BEM, Beavis и подобные методологии, лишает их головной боли, никаких проблем во внедрении быть не должно. Проблема потенциально может возникнуть только на уровне коммуникации, когда она доносится неправильно, и команда не видит в ней объективных преимуществ.


#cssinjs #css #bem

https://medium.com/dailyjs/what-is-actually-css-in-js-f2f529a2757

Вчера я поделился своими мыслями о первой части статьи "What is actually CSS-in-JS". Сейчас хочу рассказать про вторую часть - "The tradeoffs of CSS-in-JS", которая перечисляет существующие недостатки подхода.

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

Хотя в статье есть много полезной информации, она получились какой-то однобокой, но автор честно признался, что его мнение может быть необъективно.

#cssinjs #css

https://medium.com/@oleg008/the-tradeoffs-of-css-in-js-bee5cf926fdb

Аггелос Арванитакис опубликовал статью, посвящённую проблемам производительности популярных CSS-in-JS библиотек — "The unseen performance costs of modern CSS-in-JS libraries in React apps".

Сейчас наиболее популярны CSS-in-JS библиотеки, которые в рантайме внедряют на страницу стили — Styled Components, Emotion. Они несут накладные расходы, которые становятся очень заметны, если в приложении происходит частое обновление большого количества компонентов. Тормоза возникают из-за большого количества Context.Consumer и дополнительной работы на парсинг и подготовку стилей. Для снижения негативного эффекта автор советует не использовать чрезмерную композицию, ещё советует использовать стили, которые не зависят от пропсов, и предлагает поэкспериментировать с zero-runtime CSS-in-JS-решениями, например, linaria (от себя хочу добавить ещё reshadow).

Статья очень интересная. Рекомендую почитать всем, кто работает с CSS-in-JS библиотеками.

#performance #cssinjs #react

https://calendar.perfplanet.com/2019/the-unseen-performance-costs-of-css-in-js-in-react-apps/

Пару дней назад в чате @defrontchat спросили про преимущества Styled Components. Я как фронтендер-пенсионер сказал, что не понимаю хайпа вокруг CSS-in-JS библиотек. И вот сегодня нашёл довольно хороший пост Санил Пая про преимущества CIJ-библиотек.

Стили, написанные с использованием CIJ можно проанализировать статически: если в имени класса есть опечатка TS/Flow про это скажут. При использовании CIJ-библиотек не надо волноваться про append-only стили. Удалил компонент — удалил стили. Контроль над селекторами делает простым извлечение критического CSS. Так как стили в CIJ это код, начинают работать оптимизации, использующиеся для JS (code splitting, dead code elimination). Ещё одно неочевидное преимущество касается того, что в SPA-приложениях, в которых используется асинхронная загрузка стилей и скриптов нельзя гарантировать порядок загрузки ассетов, что приводит к использованию !important.

The facebook codebase has thousands of !important statements, despite being written by competent engineers with solid engineering practices and deep relationships with design teams.

В общем, рекомендую почитать статью всем, у кого есть вопросы к CSS-in-JS. Многое встаёт на свои места.

#cssinjs #musings

https://gist.github.com/threepointone/731b0c47e78d8350ae4e105c1a83867d

Пару недель назад инженеры из facebook опубликовали статью про редизайн главного сайта социальной сети — "Rebuilding our tech stack for the new Facebook".

В прошлом году на конференции f8, когда представили новый сайт, рассказали про использованные технологии. Небольшой обзор можно почитать тут. Статья сильно пересекается с докладами, но в ней есть пара новых деталей.

Для работы с CSS используют своё CSS-in-JS решение, которое на стадии сборки приложения извлекает стили из кода компонентов в CSS-файлы. При извлечении стилей используется подход Atomic CSS, в котором одно правило представляется отдельным классом. Благодаря Atomic CSS удалось уменьшить общий объём стилей на 80% по сравнению со старой версией facebook. Кроме извлечения стилей CIJ-библиотека упрощает работу с относительными размерами шрифтов для улучшения a11y. Разработчики могут использовать в коде компонентов размеры в пикселях, на этапе сборки они автоматически преобразуются в rem'ы.

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

#facebook #cssinjs

https://engineering.fb.com/web/facebook-redesign/

Доминик Тобиас написал статью о подходах к улучшению производительности CSS-in-JS — "How to increase CSS-in-JS performance by 175x".

Заголовок у статьи, конечно, кликбейтный, но написано там всё по делу. В прошлом году на perfplanet было опубликовано исследование с печальными результатами — популярные CSS-in-JS библиотеки, которые в рантайме внедряют на страницу стили (Styled Components, Emotion), могут очень негативно влиять на производительность сложных страниц.

Для улучшения производительности Доминик предлагает использовать CSS-in-JS библиотеки, которые могут извлекать стили из JS на этапе компиляции, также предлагает использовать CSS-переменные для темизации и рекомендует (по возможности) отказаться от динамики в стилях.

Полезная статья. Рекомендую почитать всем, кто использует Styled Components, Emotion и другие подобные библиотеки.

#react #cssinjs #performance

https://dominictobias.medium.com/how-to-increase-css-in-js-performance-by-175x-f30ddeac6bce

Алекс Руденко из команды разработки Chrome DevTools написал статью про добавление поддержки редактирования стилей, создаваемых с помощью CSS-in-JS-библиотек — "CSS-in-JS support in DevTools".

Возможность редактирования CSS-in-JS стилей появилась в Chrome 85. Для поддержки редактирования стили должны быть представлены как статический текст. В случае с CSS-in-JS статического текста нет, так как такие стили размещаются в памяти во внутренней структуре данных CSSOM. Для добавления возможности редактирования их стали преобразовывать в текст. Для синхронизации мутируемых стилей был добавлен новый механизм, который оповещает бэкенд DevTools при изменении стилей с помощью CSSOM API.

Хорошая статья. Рекомендую почитать, если интересуетесь внутренней работой браузеров.

#internals #chrome #cssinjs

https://developers.google.com/web/updates/2021/02/css-in-js