Когда дедлайн «горит», а редкая библиотека из npm внезапно падает с ошибкой в модном рантайме (ведь на моей машине всё работало идеально), романтика быстро сменяется холодным расчетом — и этот момент наступает в карьере каждого разработчика, рискнувшего уйти за хайпом. Мир серверного JavaScript за последние несколько лет пережил настоящий бум альтернативных рантаймов. Появление Deno, а затем и Bun, всколыхнуло сообщество разработчиков. На волне критики устаревших подходов Node.js многие инженеры, включая автора этой статьи, поспешили объявить Node «устаревшим легаси» и перенесли свои новые проекты на современные платформы «из коробки». Обещания безопасности по умолчанию, встроенной поддержки TypeScript без костылей вроде ts-node и современных стандартов Web API казались билетом в светлое будущее.

Однако индустрия разработки устроена интереснее, чем бесконечная погоня за хайпом. Недавняя работа над клиентским проектом на SvelteKit заставила меня вернуться к тому, от чего я так усердно пытался уйти — к Node.js. Каково же было мое удивление, когда я обнаружил, что за время моего отсутствия экосистема Node совершила колоссальный скачок вперед. Тот Node.js, который мы ругали за громоздкие модули и отсутствие базовых удобств пять лет назад, и современный Node — это две совершенно разные платформы. Так родилась мысль, ставшая заголовком этой статьи: дружба с Deno окончена, теперь Node — мой лучший друг.

В этой статье мы подробно разберем, почему разработчики, долгое время очарованные Deno, снова обращают внимание на Node.js, насколько далеко продвинулась его экосистема и с какими минимальными трудностями на самом деле сталкиваешься при обратной миграции кодовой базы.

Почему разработчики уходили на Deno и что заставило нас вернуться

Чтобы понять причину камбэка, нужно вспомнить контекст. Deno создавался как работа над ошибками Node.js. Райан Даль учел свои главные сожаления по поводу Node: отказ от централизованного менеджера пакетов (npm) в пользу импорта по URL, строгая песочница безопасности (доступ к сети и файловой системе только по флагам) и нативная поддержка TypeScript. Для разработчика, уставшего настраивать tsconfig.json, webpack, babel и бороться с хрупкими обертками, Deno выглядел глотком свежего воздуха.

Но практика коммерческой разработки вносит свои коррективы. Когда вы берете проект на поддержку или работаете в жестких рамках дедлайнов клиентского заказа, экосистемный фактор начинает играть ключевую роль. Представьте: вам срочно нужно подключить специфический SDK для работы с платежным шлюзом или устаревшую, но критически важную криптографическую библиотеку (как тот самый древний скрипт на jQuery, который держит на плаву полные доходы компании). В Deno интеграция таких модулей через npm-совместимость часто превращается в рулетку с неожиданными ошибками сборки. Тема миграции с Deno обратно на Node.js все чаще вспыхивает в дискуссиях на таких площадках, как Hacker News и Lobsters. Разработчики отмечают, что несмотря на всю элегантность Deno, его нишевость иногда превращается в проблему, когда вам нужна редкая интеграция или строго определенная библиотека из npm, которая капризничает в чужеродном рантайме.

Эволюция Node.js: как экосистема догнала тренды

Осознав тупиковость некоторых архитектурных тупиков, мы неизбежно смотрим по сторонам в поисках стабильности. Главный вопрос, который волнует индустрию сегодня: насколько далеко продвинулась экосистема Node.js за время популярности альтернативных рантаймов? Оказалось, что пока сообщество обсуждало новые фичи Deno и Bun, команда Node.js не сидела сложа руки. Они тихо, но методично закрывали те самые потребности, на которые жаловались разработчики.

1. Нативная поддержка TypeScript

Больше не нужно городить сложные конфигурации с ts-node или предварительной сборкой в JS для простых скриптов. Современный Node.js поддерживает экспериментальный флаг для выполнения TypeScript "из коробки":

node --experimental-strip-types app.ts

Это избавляет от лишней головной бо