За три десятилетия своего существования JavaScript успел пережить десятки попыток собственного уничтожения. В девяностые Microsoft пыталась вытеснить его с помощью VBScript. В нулевые сеть заполонили интерактивные Flash-анимации на ActionScript. Позже Google разработала язык Dart специально для того, чтобы заменить JS внутри Chrome, а сообщество разработчиков экспериментировало с элегантным CoffeeScript.
Однако JavaScript пережил всех конкурентов. Появление TypeScript лишь зацементировало его победу, признав прагматичную истину: избавиться от JavaScript невозможно, его можно лишь дополнять. И вот, разменяв четвертый десяток, главный язык интернета вступил в классический кризис среднего возраста.
В широко обсуждаемом эссе инженера Маруна Байдуна препарируется тектонический сдвиг: вся инфраструктура разработки фронтенда — сборщики, компиляторы, линтеры и даже сами среды исполнения — стремительно переписывается на системные языки программирования: Rust, Go и Zig.
Утраченная суперсила: когда все говорили на одном языке
Взрывной расцвет экосистемы начался с появлением Node.js. Скрытым преимуществом веб-разработки на долгие годы стала однородность среды. Инженеры использовали один и тот же язык для отрисовки кнопок в браузере, написания логики микросервисов и создания вспомогательных инструментов.
Транспилятор Babel, сборщики Webpack и Rollup, линтер ESLint и тестовый фреймворк Jest были написаны на чистом JavaScript. В индустрии это называли практикой «dogfooding» — создатели инструментов пользовались тем же продуктом, что и их пользователи.
У этой однородности была колоссальная практическая ценность: если в сборщике что-то ломалось, любой сеньор или даже мидл-разработчик мог открыть папку node_modules, поставить привычный console.log, локализовать проблему и отправить pull request авторам библиотеки. Миллионы инженеров по всему миру могли контрибьютить в свои повседневные devtools, не покидая уютных границ родного синтаксиса.
Странный парадокс нативной инфраструктуры
Но по мере роста корпоративных кодовых баз JavaScript-инструменты начали задыхаться. Сборка многостраничного приложения в Webpack стала занимать минуты, превращая рабочий день в бесконечное ожидание.
Ответом стало «Великое нативное переписывание». Сначала появился esbuild на Go, доказавший, что бандлер может работать в 50 раз быстрее. Следом поднялась мощная волна проектов на Rust: SWC, Biome, Turbopack, Oxc и Rolldown, а рантайм Bun показал невероятную прыть на языке Zig. Скорость горячей перезагрузки модулей сократилась до миллисекунд, а шильдик «Written in Rust» превратился в главный маркетинговый козырь любого нового проекта.
Однако эта гонка привела к забавному архитектурному парадоксу: мы компилируем код на JavaScript с помощью утилит на Rust, чтобы на выходе получить файл на JavaScript, который затем передается на исполнение браузерному движку V8, написанному преимущественно на C++. Мы выстроили сверхскоростные нативные рельсы для вагончика, который никуда особо не спешит.
Черный ящик и отчуждение сообщества
За победные графики бенчмарков сообществу приходится платить неявную, но высокую цену. Прежде всего, инструменты превратились в непроницаемый «черный ящик». Когда нативный сборщик неожиданно падает с системной ошибкой паники (panic!) или искажает дерево абстрактного синтаксиса (AST), абсолютное большинство фронтендеров бессильны. Для отладки такой проблемы больше недостаточно знаний промисов и прототипов: требуются глубокие системные навыки управления памятью, лайфтаймов и понимания ассемблерных вызовов.
В результате резко сузился круг тех, кто способен развивать и поддерживать инструменты открытого исходного кода. Пул контрибьюторов в ключевые проекты инфраструктуры сократился до узкой когорты системных программистов. Пострадала и экосистема плагинов: создание расширений теперь требует либо возни со сложным интерфейсом N-API, либо компиляции в WebAssembly с неизбежными потерями на передачу данных между средами.
Марун Байдун задает резонный вопрос: насколько далеко веб-сообщество готово зайти в усложнении надстроек вокруг JavaScript, прежде чем признать, что язык перестал справляться с собственным окружением? Скорость сборки — бесспорное благо, но техническим лидерам стоит помнить, что потеря открытости и простоты тулчейна может обойтись индустрии дороже сэкономленных секунд компиляции.