# Можно ли отказаться от SCSS в production в 2026? **Коротко: в большинстве проектов — да.** Нативный CSS в 2025–2026 закрывает то, ради чего раньше ставили SCSS: вложенность, переменные, управление каскадом, адаптивность компонентов. Ниже — один реальный layout-пример, сравнение сборки с SCSS и без, когда SCSS всё ещё нужен и в чём разница по перфомансу. --- ## Реальный layout: страница без SCSS Один пример страницы с шапкой, основным блоком и карточками. Всё на нативном CSS: переменные, nesting, `@layer`, container queries. **HTML:** ```html

Заголовок

Карточка 1

Текст карточки.

Карточка 2

Текст карточки.

``` **CSS (один файл, без препроцессора):** ```css /* ========== Слои: порядок задаёт приоритет ========== */ @layer reset, base, layout, components; @layer reset { *, *::before, *::after { box-sizing: border-box; } body { margin: 0; } } @layer base { :root { --space-xs: 0.25rem; --space-sm: 0.5rem; --space-md: 1rem; --space-lg: 1.5rem; --radius: 8px; --clr-bg: #0f1115; --clr-surface: #161a21; --clr-text: #e4e6eb; --clr-muted: #8b9199; } body { font-family: system-ui, sans-serif; background: var(--clr-bg); color: var(--clr-text); min-height: 100dvh; display: flex; flex-direction: column; } } @layer layout { .page { min-height: 100dvh; display: flex; flex-direction: column; } .header { padding: var(--space-md); background: var(--clr-surface); border-bottom: 1px solid rgba(255,255,255,0.06); } .nav { display: flex; align-items: center; justify-content: space-between; max-width: 1200px; margin: 0 auto; } .nav__logo { font-weight: 700; color: inherit; text-decoration: none; } .nav__menu { display: flex; gap: var(--space-lg); list-style: none; margin: 0; padding: 0; } .main { flex: 1; padding: var(--space-lg); max-width: 1200px; margin: 0 auto; width: 100%; } .main__title { margin: 0 0 var(--space-lg); font-size: 1.75rem; } .footer { padding: var(--space-md); background: var(--clr-surface); color: var(--clr-muted); font-size: 0.875rem; text-align: center; } } @layer components { .cards { display: grid; grid-template-columns: repeat(auto-fill, minmax(280px, 1fr)); gap: var(--space-lg); } .card { container-type: inline-size; background: var(--clr-surface); border-radius: var(--radius); overflow: hidden; border: 1px solid rgba(255,255,255,0.06); display: grid; grid-template-columns: 1fr; } .card__media { height: 140px; background: linear-gradient(135deg, #2a3f5f 0%, #1a2838 100%); } .card__body { padding: var(--space-md); } .card__title { margin: 0 0 var(--space-sm); font-size: 1.125rem; } .card__text { margin: 0; color: var(--clr-muted); font-size: 0.9375rem; } @container (min-width: 360px) { .card { grid-template-columns: 120px 1fr; align-items: stretch; } .card__media { height: auto; min-height: 100%; } } } ``` Здесь используются: - **CSS variables** — отступы, цвета, радиус в `:root`, переиспользование в слоях. - **@layer** — reset → base → layout → components; каскад предсказуемый, перебивать компоненты легко. - **CSS nesting** — не показан явно в этом фрагменте; ниже отдельный пример. - **Container queries** — `.card` меняет раскладку по ширине контейнера (узкая колонка — вертикально, шире 360px — медиа слева, текст справа). Один CSS-файл, без компиляции SCSS — достаточно современного браузера и при необходимости PostCSS (autoprefixer). --- ## CSS Nesting Вложенность как в SCSS, но нативно. Удобно для компонентов и BEM-подобных блоков. ```css .card { padding: var(--space-md); border-radius: var(--radius); .card__title { font-size: 1.25rem; margin-bottom: var(--space-sm); } .card__text { color: var(--clr-muted); } &:hover { border-color: rgba(255,255,255,0.12); } @media (min-width: 600px) { padding: var(--space-lg); } } ``` Раньше такое делали через SCSS; сейчас поддерживают Chrome, Firefox, Safari 17+. Отдельный шаг компиляции не нужен. --- ## CSS Variables (как замена SCSS-переменных) В layout-примере выше переменные уже использованы. Объявление в `:root`, использование везде. ```css :root { --space-sm: 0.5rem; --space-md: 1rem; --radius: 8px; --clr-primary: #3b82f6; --clr-bg: #0f1115; } .header { padding: var(--space-md); border-radius: var(--radius); background: var(--clr-bg); } .btn { padding: var(--space-sm) var(--space-md); background: var(--clr-primary); } ``` Плюс: можно менять значения по медиа или по классу (например, тема), без пересборки. В типичном проекте этого хватает вместо SCSS-переменных. --- ## @layer — порядок каскада без гонки специфичности Слои задают приоритет раз и навсегда: что объявлено позже в списке `@layer`, то сильнее. Удобно подмешивать свои стили поверх reset/базы и не зависеть от порядка подключения файлов. ```css @layer reset, base, components, utilities; @layer reset { * { box-sizing: border-box; } } @layer base { body { font-family: system-ui; } } @layer components { .card { padding: 1rem; } } @layer utilities { .mt-1 { margin-top: 0.25rem; } } ``` В layout-примере выше та же схема: reset → base → layout → components. Утилиты (если появятся) можно вынести в отдельный слой и подключать последним. --- ## Container Queries — адаптивность компонента, а не экрана Карточка ведёт себя по ширине своего контейнера, а не окна. Один и тот же класс в сайдбаре и в широкой сетке — без дублирования медиа-запросов по `(min-width: ...px)` для всего экрана. ```css .card { container-type: inline-size; } @container (min-width: 360px) { .card { display: grid; grid-template-columns: 120px 1fr; } } ``` В реальном layout выше это уже использовано для `.card`. Поддержка: Chrome, Firefox, Safari 17+. --- ## Сравнение сборки: SCSS vs нативный CSS | Аспект | Со SCSS | Без SCSS (нативный CSS) | |--------|---------|---------------------------| | Зависимости | `sass` (или `node-sass`/`dart-sass`) | Нет (или только PostCSS для autoprefixer) | | Шаги сборки | Компиляция `.scss` → CSS, затем минификация/постобработка | Минификация/постобработка (при необходимости) | | Конфиг | Настройка путей импорта, source maps, иногда совместимость с фреймворком | Обычно только PostCSS config | | Время сборки | Дольше при большом числе partials | Меньше (нет компиляции Sass) | | Исходники | `.scss` | `.css` (можно писать современный CSS сразу) | Минимальный pipeline без SCSS (например, Vite): ```bash npm i -D autoprefixer postcss ``` `postcss.config.js`: ```js export default { plugins: { autoprefixer: {}, }, }; ``` Стили подключаются как обычные `.css`; nesting, переменные и `@layer` браузер понимает сам. Со SCSS в том же проекте пришлось бы добавить препроцессор и следить за версией Sass. --- ## Когда SCSS всё ещё нужен Отказаться от SCSS не всегда разумно. Он по-прежнему полезен, когда: - **Миксины и функции** — сложные расчёты (например, типографическая шкала, сетка), повторяющиеся куски с параметрами. В CSS есть `calc()` и переменные, но без циклов и функций. - **Циклы** — генерация утилитарных классов или отступов (например, `.mt-1` … `.mt-12`) массой. В нативном CSS такого нет; если нужна большая сетка утилит, проще сгенерировать её в SCSS или использовать Tailwind. - **Импорт и разбиение на много partials** — в CSS есть `@import`, но без объединения в один бандл через сборщик порядок и дублирование контролировать сложнее. В больших командах структура из десятков SCSS-partials может быть осознанным выбором. - **Легаси** — проект уже на SCSS, много готовых миксинов и переменных; миграция на чистый CSS не окупается в ближайшее время. - **Очень старые браузеры** — если нужна поддержка браузеров без nesting/container queries/variables, SCSS даёт «плоский» CSS без этих фич; но в 2026 таргет обычно уже современный. Итог: если не нужны миксины, циклы и сложная генерация стилей, в новом проекте можно спокойно обходиться без SCSS. --- ## Перфоманс: в чём разница - **Размер бандла:** итоговый CSS при одинаковой функциональности сопоставим. SCSS компилируется в обычный CSS; нативный CSS не «тяжелее». Разница может быть только из-за того, что с SCSS часто подключают больше partials или генерируют много утилит. - **Парсинг в браузере:** браузер парсит один и тот же CSS. Nesting, переменные, `@layer`, container queries обрабатываются нативно; дополнительной нагрузки по сравнению со скомпилированным SCSS нет. - **Сборка:** без шага компиляции Sass сборка быстрее и проще. Меньше зависимостей — меньше обновлений и потенциальных конфликтов. То есть с точки зрения рантайм-перфоманса отказ от SCSS не ухудшает страницу; часто сборка и поддержка только выигрывают. --- ## Краткий вывод - **Можно ли отказаться от SCSS в production в 2026?** Да, в большинстве проектов — можно. Достаточно нативного CSS: переменные, nesting, `@layer`, container queries и при необходимости PostCSS (autoprefixer). - **Реальный layout** — один полный пример страницы (header, main, cards, footer) с переменными, слоями и container queries показывает, что типичный макет собирается без SCSS. - **Когда SCSS всё ещё уместен** — миксины, циклы, сложная генерация стилей, большой легаси-проект или жёсткая структура из множества partials. - **Перфоманс** — размер и парсинг CSS сопоставимы; сборка без Sass обычно быстрее и проще. Практический совет: в новых проектах пробуй обходиться без SCSS; подключай его только если появятся задачи, которые на чистом CSS решать неудобно (циклы, сложные миксины).