Фронтенд без сборки: реальное состояние концепции No-Build в 2026 году

Фронтенд без сборки: реальное состояние концепции No-Build в 2026 году

В последние несколько лет в веб-разработке активно обсуждается концепция No-Build — подход, при котором разработчик полностью отказывается от компиляции, бандлинга и транспиляции кода, отправляя в браузер чистые, нативные файлы HTML, CSS и JavaScript. Популяризации этого движения способствовало быстрое развитие веб-стандартов: появление нативных ES-модулей (ESM), карт импорта (import maps), нативной вложенности в CSS (nesting) и современных протоколов HTTP/2 и HTTP/3, которые теоретически нивелировали накладные расходы на загрузку большого количества мелких файлов.

Известный веб-технолог Олли Уильямс (Ollie Williams) опубликовал подробный разбор реального состояния концепции No-Build в 2026 году. Он детально проанализировал, действительно ли современные стандарты позволяют полностью избавиться от инструментов сборки и с какими непреодолимыми ограничениями сталкиваются проекты при масштабировании.

Нативный CSS против препроцессоров: где сборщики больше не нужны

В области работы со стилями концепция No-Build продвинулась дальше всего. Многие задачи, для решения которых раньше требовались препроцессоры (прежде всего Sass), сегодня решаются браузерами нативно:

• Вложенность (Nesting): Стандартный CSS теперь поддерживает вложенные правила из коробки, делая синтаксис Sass избыточным.
• Пользовательские свойства (CSS Variables): Нативные переменные динамичны и могут изменяться в рантайме с помощью JavaScript, что намного мощнее статических переменных препроцессоров.
• Современные цветовые пространства: Работа с цветами в пространствах oklch(), lab(), lch() и относительными цветами поддерживается всеми современными браузерами (категория Baseline).

Тем не менее, полная автоматизация без сборки натыкается на проблемы совместимости со старыми браузерами. Для поддержки устаревших платформ инструменты вроде PostCSS или Lightning CSS выполняют «снижение синтаксиса» (syntax lowering) — например, переводят цвета oklch() в стандартные rgb(). Без сборки разработчику приходится отказываться от этих возможностей ради совместимости либо ограничивать круг поддерживаемых пользователей.

Вторая проблема CSS в No-Build — это организация файлов. Если проект разбит на множество мелких компонентов, каждый CSS-файл должен импортироваться через директиву @import или отдельные теги <link>. В проектах без сборки (таких как ONCE от Basecamp) это приводит к тому, что браузер вынужден последовательно запрашивать десятки мелких файлов. С точки зрения сжатия (Gzip/Brotli) это крайне неэффективно: алгоритмы сжатия работают намного лучше на едином крупном файле, где они могут использовать обратные ссылки на повторяющиеся фрагменты кода (как показал в своих исследованиях Джейк Арчибальд). Без минификации и склеивания CSS-файлов проект неизбежно теряет в производительности.

JavaScript без сборки: водопады запросов и npm-зависимости

Если в CSS без сборки еще можно жить, то в JavaScript отказ от бандлеров (таких как Vite, esbuild, Webpack или новый Rolldown) создает серьезные проблемы для любого приложения сложнее простого лендинга.

1. Сетевые водопады (Waterfalls)

Главный миф No-Build заключался в том, что мультиплексирование в HTTP/2 и HTTP/3 позволяет быстро загружать сотни мелких JS-файлов параллельно по одному соединению. Однако на практике возникает проблема глубоких цепочек импорта (водопадов).

Если файл main.js импортирует app.js, который импортирует router.js, который, в свою очередь, импортирует auth.js, браузер не может начать загрузку auth.js, пока не скачает и не распарсит все предыдущие файлы в цепочке. Это создает последовательную цепочку сетевых запросов, критически увеличивая время до интерактивности страницы (Time to Interactive). Частично проблему решает механизм <link rel="modulepreload">, но прописывать предзагрузку для каждого файла вручную в большом проекте невозможно.

2. Разрешение транзитивных зависимостей

Современная разработка строится на использовании пакетов из реестра npm. Большинство библиотек (например, Lit, React или Lodash) состоят из десятков внутренних модулей и имеют собственные зависимости.

Чтобы браузер мог импортировать npm-пакет без сборки, разработчик должен настроить карту импортов (import maps), указав точные пути к каждому файлу:

{
  "imports": {
    "lit": "/node_modules/lit/index.js",
    "@lit/reactive-element": "/node_modules/@lit/reactive-element/reactive-element.js"
  }
}

Для крупного проекта с десятками библиотек ручное ведение и обновление карт импорта для всех транзитивных (вложенных) зависимостей превращается в неразрешимый кошмар. Бандлеры решают эту задачу автоматически на этапе сборки, собирая всё дерево зависимостей в плоскую структуру.

3. Отсутствие оптимизаций (Tree-Shaking и минификация)

Бандлеры выполняют важнейшую оптимизацию — удаление мертвого кода (Tree-Shaking). Если вы импортируете только одну функцию из огромной библиотеки, сборщик вырежет все неиспользуемые части. В концепции No-Build браузер будет вынужден скачать весь файл библиотеки целиком. Отсутствие минификации (удаления пробелов, комментариев и сокращения имен переменных) дополнительно раздувает размер передаваемого трафика.

Сравнительный анализ подходов

Выводы

Концепция No-Build в 2026 году является отличным выбором для:

• Простых сайтов-визиток и лендингов с минимумом интерактивности.
• Внутренних административных панелей, где скорость первой загрузки не критична.
• Прототипов, демонстрационных стендов и образовательных проектов.

Однако для масштабных публичных веб-приложений, где важна каждая миллисекунда времени загрузки у конечного пользователя, сборщики кода остаются обязательным инструментом. Современные быстрые бандлеры на Rust (такие как Rolldown и Rspack) минимизируют накладные расходы на этапе разработки, предоставляя преимущества No-Build (мгновенный запуск) при сохранении максимальной оптимизации кода для продакшена.