Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 17
У css-modules есть досадный минус: из коробки они плохо типизированы. Если написать import styles from './Comp.module.css'; , то styles оказывается просто Record<string, string>. Есть какие-то дополнительные нашлепки, которые генерят *.d.ts, но это так себе.
На текущем проекте используем vanilla-extract, вполне устраивает.
https://marketplace.visualstudio.com/items?itemName=clinyong.vscode-css-modules не решает проблему проверки наименований классов на уровне тайпскрипта(да и с чего бы), но в IDE позволяет парсить модули и обращаться к классам уверенно через styles.**** с автокомплитом
Блин, интересно, веб когда нибудь вернётся в просто нормальным стилям? Бесит же, когда стили на сайте весят мегабайт просто потому что для каждой из сотен button сгенерился свой .buttin_uf5gj8h класс, хотя они все почти одинаковые.
Почему-то на бэке сильнее задумываются об оптимизации, а на фронте все просто обмазывают очередной абстракцией и новым слоем проблем.
turbopack в next вообще не позволяет изменять стили от css модулей, при этом генерируя их максимально больными для глаз. Вот пример из production бандла - 'FullNavbar-module-scss-module__DJfi9G__full-navbar'.
Решается это всё доступом к настройке генерируемых классов, но большинство решений почему-то это не предоставляет
В идеале бы какой-то сборщик, который сможет собрать классы, что есть цвет фона и шрифта, есть скругления, есть тени и их разное сочетание даёт кнопки, карточки, модалки...
Хотя я знаю такой сборщик. Называется "человек разумный")))
Не, вообще ИИ с этим тоже справится, но приходится его прям гонять "нет, ты сделал лишние классы, когда такие уже были, переиспользуй" и "а теперь отрефакторь, чтобы убрать лишнее и соблюдать dry принцип"
Блин, интересно, веб когда нибудь вернётся в просто нормальным стилям?
У меня такая же мысль возникла после прочтения статьи. За последнее время веб очень усложнился, оброс новыми проблемами которые как-то решать надо, а том числе огромный вес.
Честно говоря я даже не уверен, что их надо именно решать, а не создать просто все заново. Ванильный html, ванильный js и простой css сейчас решает кучу проблем, но большинство разработчиков (особенно джун/мидл) сегодня уже просто не умеют что делать без react. Сеньеры кто постарше ещё умеют. Пока...
Это боль. Они на полном серьёзе сравнивают css-in-js с модулями, а вариант что вообще можно просто руками написать style.css который будет весить 5кб - этого тупо нет в картине мира...
Авторитетное мнение бэкенда по поводу фронта) идите сделайте пожалуйста авито или вк на html и ванильном js, а мы посмотрим. Вы вот даже не понимаете, чем css-in-js плох с точки зрения взаимодействия с ним - вам и не надо, не сталкиваетесь же. Но мнение есть, и уверенное) как-то знаете, жидко что ли, непрофессионально
Я фуллстэк, делал достаточно крупные решения в направлении обучения в Сбере, Райфе и МТС. Ваше жиденькие можете оставить себе.
На ванильных решениях я с командой делал в том числе решения которые дальше продавались на рынок корп.клиентам, на десятки экранов.
Рецепт очень простой: на собеседовании проверять, что кандидат умеет вообще в фронтенд, а не только в реакт. Правда для этого надо самому шарить.
Фуллстек, на моём опыте, в 100% случаев значит "я знаю бэк и чё-то там щупал пару раз во фронте". В билайн при мне фуллстэк-тимлид делал отступы между блоками белыми бордерами на белом фоне - это всё, что нужно знать о компетенции фуллстека относительно фронтенд-разработки и вёрстки в частности) нет, если вам нравится рассуждать, мало разбираясь в теме - пожалуйста, кто ж запретит. Только стоит понимать, что у этих рассуждений мало общего с реальностью
Рецепт очень простой: на собеседовании проверять, что кандидат умеет вообще в фронтенд, а не только в реакт. Правда для этого надо самому шарить.
Здесь у нас одна позиция: достойный фронтенд это в первую очередь знание основ и умение их использовать, а потом уже фреймворки и прочие навороты
Не, это не про меня. Я как раз чаще решаю вопрос только фронтом. Сейчас сделал себе приложение для презентации (вместо поверпионт, верстать слайды по одному, они собираются в презу), есть интерактивная часть типа таймеров, заданий, спойлеров подсказок к заданиям и прочим - бэка нет вообще. Приложение для запоминания английских слов сыну - аналогичная фигня, все происходит на фронте, включая логику выбора слов из списка, где больше всего ошибок было, из бэка там только гугл скрипт на 50 строк для хранения словаря в таблице.
Так что нет. Я фуллстэк который вырос из старого пэхапэ где фронт и бэк вообще были переплетены и неделимы.
Тот же больной вопрос.
для каждой из сотен button сгенерился свой .buttin_uf5gj8h класс, хотя они все почти одинаковые
Решается созданием своей дизайн-системы/использованием существующей. Честно не представляю, где вы нашли файл со стилями на мегабайт. Уж столько неиспользуемого css мне приходилось вычищать - сам итоговый файл со стилями редко превышал хотя бы 100 кб. И это будет огрооомный файл)
Не одним реактом едины https://habr.com/ru/articles/523646/
Есть ещё подход css in TS где не только селекторы но и сама структура типизируется
можно написать
{ Details: { Body: { overflow: ‘overlay’ } } } а TS проверит что у компонента есть элемент Details и что Details содержит Body и что Body компонент, а не строка
Плюс человекочитаемые имена вместо хэшей, что гораздо удобнее
Пример того что генериться : [my_profile_details_body]
Ещё плюс: всё селекторы специфичны, но легко перебиваются откуда угодно, очень гибко
если статью не читать то впринципе ии справился с заданием.
если читать там одни и теже выводы по несколько раз встречаются это еще я половину прочитал.
любой современный ии намного лучше иныормацию выдаст если просто title статьи ему отправить.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
CSS-in-JS vs CSS Modules: что выбрать в 2026?