Хабр Курсы для фронтендеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Фронтенд доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 19
несмотря на растущую популярность Tailwind и CSS‑in‑JS решений
Это моё личное и наверняка ошибочное мнение, но я думаю что CSS‑in‑JS уже устарел. Это какой‑то ад с точки зрения отладки и производительности. Плюс это лишний слой абстракции. Просто нормально организованный CSS — это такой кайф после CSS‑in‑JS
Насчёт Tailwind, это вкусовщина, но я тоже не фанат. Для меня это выглядит примерно как использование inline‑стилей
Насчёт SASS/SCSS. Я не вижу достаточно количества плюсов, которые перевешивают минусы в виде добавления ещё одного слоя абстракций, усложнения сборки
Спасибо за ваше мнение. А чем в вашем случае SASS/SCSS усложняет процесс сборки?
1) У меня в целом достаточно ортодоксальный взгляд на это. Например, есть мнение, что для библиотек вообще не нужна сборка и я с этим согласен. Потому что в конечном приложении, которое эту библиотеку будет использовать, наверняка уже будет какой‑то бандлер. Т.е. я просто пишу TypeScript и CSS код и не заморачиваюсь со сборкой, а для SCSS мне придётся что‑то тянуть в проект.
Или даже если я использую сборщик, всё равно это дополнительное время на каждую сборку. При обновлении версий сборщиков наверняка будет что‑то ломаться. Я хз, транспилировать SCSS отдельно или для vite есть плагин, а если решу отказаться от vite и какой‑нибудь bun возьмет на себя полностью сборку или ещё какой‑то очередной мегасборщик, то мне придётся адаптировать и сборку SCSS? У меня сейчас настроен Stylelint для CSS, а для SCSS мне нужно будет тянуть дополнительный плагин? Потом я обновлю версию Stylint, а для SCSS новой версии плагина не будет. У меня просто болит голова, когда я начинаю думать о сборке проектов в вебе. Поэтому чем оно тупее и проще, тем лучше, а лучше вообще без сборки.
2) Но даже это не основной стопер от использования SCSS. На мой взгляд это просто лишняя абстракция. Если я использую CSS, то в браузере и в исходном коде у меня идентичные стили, мне это проще отлаживать, мне проще поправить стиль в браузере, скопировать его обратно в код, или даже не копировать, а просто прямо в браузере и сохранить в файл если это настроено.
3) CSS в отличие от SCSS — это стандарт. Он более распространен. Зачем мне забивать свой мозг тем как в SCSS например переменные объявляются? И зачем мне заставлять остальных людей на проекте делать это? Изучили CSS и этого достаточно.
4) Если в стилях хочется сделать что‑то сложное, то есть два пути: а) усложнить CSS (используя SCSS или CSS‑in‑JS) или б) переформулировать задачу, чтобы в стилях не требовалось делать ничего на столько сложного. Мне ближе вариант б). Когда‑то давно когда CSS был очень ограниченным, когда были сложности с кросс‑браузерной вёрсткой препроцессоры имели смысл. Сейчас я просто не вижу в них смысла. Я не понимаю какой профит мне даст SCSS, чего я не могу сделать на обычном CSS.
Благодарю за развернутый ответ, есть над чем подумать.
А как вы используете ts без сборщика?
Использую tsc в библиотеках, хотя в теории это не обязательно. А в самом приложении уже tsc+vite. Всё равно в конечном приложении будет какой-то бандлер.
Если сайт совсем простой типа лендинга, то там и TypeScript не особо нужен.
Наверное я преувеличил уровень сложностей при добавлении в эту схему SCSS, но я столько намучился со сборкой, что мне нужны очень веские причины, чтобы хоть на чуть-чуть её усложнять.
При компиляции SCSS по умолчанию создаётся map-файл, ссылка на который попадает в готовый CSS-файл. Браузерный отладчик (как минимум, в Хроме) видит такое и показывает именно исходный SCSS-код.
Ну и вы можете дописывать CSS непосредственно в SCSS-файл, это будет нормально восприниматься компилятором.
Согласен, но для меня это дополнительный источник проблем. Схема без дополнительного шага сборки, без map-файлов, без дополнительных языковых конструкций в любом случае проще.
Так конечно можно далеко зайти, например, зачем нужна Java, если всё можно писать на ассемблере. Но SCSS добавляет уж слишком мало на мой взгляд к CSS.
кстати, если верить State of CSS 2024
SASS/SCSS все еще максимально используется в 70% случаях +-
Да, видел этот отчёт. Интересно, что при росте популярности Tailwind, SASS/SCSS все еще уверенно держит позиции.
Спасибо за ссылку! Я забыл про эту статистику. Меня удивляют эти цифры, я их объясняю для себя только legacy проектами. Странно, что в 2022 году Sass/SCSS использовался 57%, в 2023 - 52%, а в 2024 - 67%. Вряд ли он так начал набирать популярность...
Но вообще, я думаю, что не всегда стоит слушать других. Вполне возможно, что у меня очень специфический взгляд на веб-разработку. Я считаю, что с чистым CSS лучше, но не факт, что такой подход работает на любых проектах
ну, почему только легаси? Если посмотреть онлайн школы, крупные и маленькие - в большинстве своём там Sass/SCSS. То есть используют не только динозавры, но и современные разработчики и будущие тоже.
Это спекуляция с моей стороны, я не знаю точно почему там учат Sass/SCSS. Я думаю по инерции или потому что он всё ещё много где используется.
Кстати у Kevin Powell есть видео от 2023 года, где он говорит, что ему больше нравится как реализована вложенность стилей в SCSS, чем в CSS, нужны миксины, циклы и условия. В целом как и у автора этой статьи. Лично я вполне могу обойтись без этих вещей. И я даже не уверен, что мне хотелось бы чтобы они появились в CSS, потому что это выглядит дополнительным усложнением. Есть вещи, которые очень нужны: разные селекторы, анкоры, флексбоксы, гриды, разные улучшения связанные с анимацией и т.д. Это реально упрощает разработку, но насчет тех же миксинов я вообще никогда не переживал
Я разделяю ваш взгляд. Для себя тоже отказался от SCSS и предпочитаю минимум или полное отсутствие инструментов сборки. С таким подходом всё просто работает ©
В большинстве может быть и нет, но много где хотелось бы один бандл CSS, ну и возможность из кучи файлов собрать единое при обычном CSS тоже та ещё задача.
Мы используем SCSS для контроля кода, во первых мы на базе Figma генерируем набор взаимосвязанных переменных с именованием от дизайн токенов, соответственно потом разработчик не пишет напрямую в коде var(--name), а использует наш модуль как
@use '@app/theme' as theme;
.class {
color: theme.$some-var;
}
Что дает во первых контроль, что никто не будет использовать несуществующие переменные, во вторых никто не ошибется в наименовании переменных сделав таким образом ошибку, в третьих не надо полагаться на автодополнение IDE, которая не совсем может понимать ваш код, а к переменным можно и добавить всякую мета информацию типа SassDOC, что удобно подсвечивает deprecated и в принципе описание переменных
Бандл CSS в итоговом приложении будет сгенерен с помощью vite.
Мы не используем на столько активно переменные.
Наверное у нас более примитивная схема. Создаётся React‑компонент, например, ModelExplorer, этот tsx‑файл импортирует ModelExplorer.css, в котором определяются классы model‑explorer, model‑explorer‑title, model‑explorer‑item и так далее. Схема именования классов похожа на Яндекс БЭМ, только проще. В разных компонентах имена классов не пересекаются, потому что мы строго подходим к именованию компонентов, плюс их не на столько много.
Плюс у нас нет нужды генерить рандомные имена классов. Скорее наоборот, фиксированные имена классов упрощают тесты, нет необходимости добавлять дополнительные атрибуты в верстку типа data‑testid.
И собственно это и есть весь подход. Для каждого компонента tsx‑файл, css‑файл, возможно файл с тестами. Строгая схема именования компонентов и CSS‑классов. По возможности отсутствие зависимостей между компонентами. Есть файл, задающий цвета и общие стили. Точно нет нужды в миксинах или большом количестве переменных, потому что это добавляет зависимостей между CSS-файлами. Точно нет нужды в циклах или условиях, потому что это усложняет CSS.
Для меня такой подход максимально простой и удобный. Но я понимаю, что это не one‑size‑fits‑all solution.
У tailwind проблемы если проект большой. Как по мне вообще нет смысла использовать т.к. если проект вырастет все равно придется менять.
Css-in-js сложно поддерживать и проблемы с северным рендерингом.
Модули CSS лучшее как по мне, что мы имеем на данный момент.
Так же нравится postcss
О каких проблемах Tailwind вы говорите? В случае большого проекта можно использовать и комбинированный подход.
С CSS-in-JS пожалуй соглашусь, все таки использовался он не часто, упомянул о нем скорее вскольз. (может попросить если хочешь)
CSS модули хороши, но в случае если вам необходимо разметить сетку или отступы какое-либо, тут на мой взгляд лучше использовать утилити классы либо самописные, либо того же Tailwind.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Почему мы все еще используем SASS в 2025 году