Нам обещали элегантность. Что мы получили, так это синтаксический анализ CSS во время выполнения, нечитаемые имена классов и ошибки гидратации прямо из ада. CSS-in-JS должен был освободить нас от кошмаров глобального пространства имен и стилизации спагетти.
Вместо этого он окутал нас в новый блестящий слой хаоса — тот, который хуже работает, хуже читается и каким-то образом требует больше циклов процессора для выполнения того, что простая таблица стилей прекрасно справлялась два десятилетия назад. Это не эволюция; Я бы назвал это чрезмерной инженерией, замаскированной под прогресс.
От освобождения к привязке к производительности
Когда CSS-in-JS впервые появился, это казалось революционным. Больше никаких глобальных утечек, никаких беспокойств по поводу войн за специфичность, никаких загадочных классовых столкновений. Мы могли бы совмещать стили с компонентами, делая все модульным и «автономным».
Но медовый месяц быстро закончился. Разработчики быстро поняли, что создание стилей во время выполнения — это не маленький компромисс, а бомба замедленного действия. То, что началось как способ упростить стилизацию, превратилось в одну из самых дорогих абстракций, когда-либо применявшихся во фронтенд-разработке.
Связав генерацию CSS с выполнением JavaScript, мы эффективно соединили представление с логикой — именно этого мы пытались избежать, когда изначально изобрели CSS.
Идея динамического вычисления CSS на стороне клиента кажется умной, пока вы не отладите несоответствие гидратации в 3 часа ночи, потому что какой-то этап SSR решил по-разному хешировать имена классов на сервере и в браузере. Это тот тип проблемы, который больше похож не на ошибку, а на наказание за доверие к маркетинговому тексту. Библиотеки CSS-in-JS сделали простой процесс стилизации кнопки таким же сложным, как внедрение зависимостей. И давайте даже не будем говорить о том, насколько увеличился размер пакета только для того, чтобы сделать границы синими.
Связав генерацию CSS с выполнением JavaScript, мы эффективно соединили представление с логикой — именно этого мы пытались избежать, когда изначально изобрели CSS. На смену элегантности разделения пришел встроенный хаос, завернутый в хуки и поставщики контекста.
Скрытый налог на удобство
Разработчики часто защищают CSS-in-JS, утверждая, что «накладные расходы незначительны». Это не. Стилизация во время выполнения приводит к измеримому снижению производительности — от потери миллисекунд при синтаксическом анализе строк до затрат памяти на перерасчеты стилей. Все, что связано с торговлей в цифровой форме, находится под угрозой.
Каждый раз, когда монтируется компонент, системе приходится создавать, внедрять, а иногда даже дедуплицировать теги стиля. Умножьте это на сотни компонентов, и вы превратите свой цикл рендеринга в бюрократический беспорядок.
То, что когда-то было самым большим преимуществом Интернета — упрощенный рендеринг — теперь саботируется чрезмерной абстракцией.
Это не гипотетически. Аудит производительности неизменно показывает, что фреймворки CSS-in-JS увеличивают затраты как на сеть, так и на время выполнения. Вы можете не заметить этого на своей 16-ядерной машине разработки, но ваши пользователи на устройствах низкого уровня наверняка это заметят. То, что когда-то было самым большим преимуществом Интернета — упрощенный рендеринг — теперь саботируется чрезмерной абстракцией.
Трагедия здесь в том, что в браузере уже есть проверенная, оптимизированная система обработки стилей: CSS. Мы заменили его имитацией JavaScript, которая работает медленнее, ее сложнее отлаживать и которая иногда исчезает при обновлении страницы. CSS-in-JS не ускорил стилизацию: он просто замедлил отладку.
И тем не менее, цикл продолжается. Разработчики фреймворка создают патч за патчем, пытаясь сделать динамические стили «чувствующими себя родными». Но вы не можете переоптимизировать собственный механизм стилей браузера. Это похоже на перестройку колеса внутри колеса — за исключением того, что здесь происходит утечка памяти и требуется обновление npm каждую неделю.
Опыт разработчика (DX) Mirage
Сторонники часто утверждают, что CSS-in-JS улучшает работу разработчиков. Они правы — до тех пор, пока вам действительно не придется его поддерживать. На первый взгляд он кажется современным и эргономичным. Стили находятся в вашем файле компонента. Классы с ограниченной областью кажутся чистыми. Переменные доступны.
Но как только кодовая база масштабируется, иллюзия рушится. Вы начинаете искать недостающие интерполяции свойств, манипулировать поставщиками контекста и переписывать логику — и все потому, что ваши стили не могут обрабатывать простые переопределения без переписывания половины дерева компонентов.
Отладка CSS-in-JS напоминает игру в «Сапер» с хэшами классов. DevTools превращается в загадочную пустошь запутанных селекторов. Осмотрите элемент, и вы обнаружите что-то вроде .css-4kq0lj{margin:0 auto} — не совсем читаемое. Удачи в поиске его источника, когда у вас есть дюжина стилизованных компонентов, наследуемых друг от друга, как неблагополучное генеалогическое древо.
Эта одержимость «DX» — опытом разработчиков — стала дымовой завесой для архитектурного долга.
Хуже того, CSS-in-JS поощряет чрезмерное проектирование. Зачем писать простой медиа-запрос, если можно импортировать перехватчик и динамически переключать контекст темы? Разработчики, которые когда-то спорили, стоит ли использовать Flexbox, теперь спорят о том, какой вариант стиля среды выполнения обеспечивает гидратацию на 2 % лучше. Умственная нагрузка колоссальная. Расплата? В лучшем случае маргинал.
Эта одержимость «DX» — опытом разработчиков — стала дымовой завесой для архитектурного долга. Конечно, приятно импортировать стилизованные компоненты и писать CSS в обратных кавычках. Но этот дофамин быстро угасает, когда производительность вашего приложения падает, а время сборки удваивается. Удобство – это не мастерство. А CSS-in-JS удобен за счет ясности.
Возвращение к здравомыслию: будущее после CSS-в-JS
К счастью, ситуация меняется. Даже самые убежденные сторонники CSS-in-JS начинают признавать, что это неустойчиво в масштабе. Такие фреймворки, как Remix, Astro и Next.js 13, подталкивают разработчиков к простоте — использованию традиционных CSS, модулей CSS или статического извлечения вместо генерации во время выполнения. Идея ясна: разделение интересов по-прежнему имеет значение.
Рост числа CSS-переменных и контейнерных запросов, а также стилей с ограниченной областью означает, что современный CSS теперь обрабатывает большую часть того, что пытался исправить CSS-in-JS — но нативно, эффективно и предсказуемо. Никаких штрафов за время выполнения. Никаких хэш-коллизий. Никаких невидимых тегов стиля, засоряющих ваш DOM. Просто стили, которые загружаются мгновенно и ведут себя стабильно.
CSS не сломан; наша дисциплина такая.
Нам не нужно изобретать заново стиль. Нам просто нужно в первую очередь уважать границы, благодаря которым сеть работает. CSS не сломан; наша дисциплина такая. Ответ не в большей абстракции, а в лучшем понимании. Будущее не за встраиванием CSS в JavaScript, а за созданием поддерживаемых стилей, которые естественным образом масштабируются по мере развития Интернета.
Возвращение к основам — это просто зрелость и нормальный сдвиг в сторону практичности. Это понимание того, что добавление уровней абстракции для решения проблем, которые мы создали сами, не является инновацией. Это просто чистое отрицание.
Современный CSS решает исходную проблему
CSS-in-JS родился из благих намерений — модульность, предсказуемость и компонентизация. Но мы получили сложность, замаскированную под прогресс. Чтобы оставаться современным, Интернету не нужны механизмы стилизации во время выполнения или загадочные хэши. Требовалась сдержанность. Нужны были разработчики, готовые признать, что не для каждой задачи требуется библиотека.
Мы вступаем в новую главу, где простота снова становится изощренностью, где глобальные таблицы стилей мирно сосуществуют с правилами с ограниченной областью действия. Там, где браузер выполняет тяжелую работу, как это всегда было задумано, пришло время перестать поклоняться абстракциям, которые нас замедляют, и начать доверять платформе, на улучшение которой мы потратили десятилетия. Готовы сделать шаг?
ТЕНДЕНЦИОННЫЕ ИСТОРИИ YOUTUBE.COM/THENEWSTACK Технологии развиваются быстро, не пропустите ни одной серии. Подпишитесь на наш канал YouTube, чтобы смотреть все наши подкасты, интервью, демонстрации и многое другое. ПОДПИСАТЬСЯ Группа, созданная в Sketch. Александр Уильямс — полнофункциональный разработчик и технический писатель, имеющий опыт работы независимым ИТ-консультантом и помогающий новым владельцам бизнеса настраивать свои веб-сайты. Узнайте больше от Александра Т. Уильямса
