Scriptc и Typescript без рантайма

Представьте: ваш TypeScript-код запускается за 1 миллисекунду. Без Node.js. Без V8. Без рантайма.

ЗАПУСК NODE.JS ПРИЛОЖЕНИЯ
─────────────────────────
Исходный код
(TypeScript/JS)
     │
     ▼
┌─────────────────┐
│  Сборка/бандлинг │  ← долго
│   (webpack,     │     (упаковка кода
│    esbuild)     │     в один файл)
└────────┬────────┘
         │
         ▼
┌─────────────────┐
│  Node.js runtime│  ← тяжёлый
│  (включает V8)  │     (среда выполнения
│                 │     для работы кода)
└────────┬────────┘
         │
         ▼
     Холодный старт
     ~100-500ms
     (запуск с нуля)

ЗАПУСК SCRIPTC БИНАРНИКА
─────────────────────────
Исходный код
(TypeScript)
     │
     ▼
┌─────────────────┐
│  Scriptc build   │  ← компиляция
│  (транспиляция   │     (преобразование
│   в нативный код)│     кода в машинный)
└────────┬────────┘
         │
         ▼
┌─────────────────┐
│  Готовый         │  ← без JS-движка
│  бинарник        │
└────────┬────────┘
         │
         ▼
     Холодный старт
     ~1-10ms
     (запуск с нуля)

Что такое scriptc и почему об этом стоит знать

Когда я впервые увидел заголовок «Scriptc by Vercel: TypeScript-to-Native compiler, no JavaScript engine in binary», меня это зацепило. Не потому, что я фанат всего от Vercel — скорее наоборот, я давно научился скептически относиться к хайповым проектам. Но сама идея убрать JavaScript-движок из продакшен-бинарника выглядит настолько логично, что удивительно, почему это не сделали раньше.

Scriptc — это экспериментальный компилятор, который превращает TypeScript напрямую в нативный бинарник. Без Node.js, без V8, без необходимости устанавливать среду выполнения на целевой машине. Скачал бинарник — запустил.

Vercel, кстати, не первый год экспериментируют с компиляцией JavaScript в нативный код. Вспомните попытки с WebAssembly или проекты вроде Neon для Rust. Но Scriptc идёт дальше — он не просто компилирует код, а полностью убирает необходимость в JS-движке.

Чем это отличается от обычного подхода

Классический пайплайн для TypeScript-проекта выглядит так: код → сборка → бандл → запуск в Node.js. Node.js — это, по сути, прослойка, которая интерпретирует JavaScript и исполняет его через движок V8. На холодном старте это может занимать от 100 до 500 миллисекунд, а иногда и больше.

Scriptc ломает эту цепочку. Компилятор трансформирует TypeScript в машинный код, который процессор понимает напрямую. Никакого V8, никакого интерпретатора.

Результат: бинарник запускается за миллисекунды, а не за сотни. Предсказуемость — на уровне любого Go- или Rust-проекта.

Как это устроено внутри

Если заглянуть в репозиторий, становится понятно, что Scriptc — это пока ранний проект. Но базовая механика интересная:

• Парсинг TypeScript — компилятор понимает типы и синтаксис TS
• Транспиляция в промежуточное представление — код переводится в упрощённый формат перед финальной компиляцией
• Компиляция в нативный бинарник — итоговый файл, который можно запустить напрямую

При этом в бинарнике действительно нет JavaScript-движка. Это не WebAssembly и не бандл с мини-JS-интерпретатором. Это честный нативный код.

Для edge-задач и CLI-утилит это особенно ценно. Меньше зависимостей — проще деплой, меньше головной боли с совместимостью версий Node.js.

Плюсы для продакшена

Давайте честно. Преимущества такие:

• Быстрый холодный старт — миллисекунды вместо сотен миллисекунд
• Предсказуемость — бинарник работает одинаково везде, где есть нужная архитектура процессора
• Простой деплой — один файл, без npm-пакетов и версий Node.js
• Меньше поверхности атаки — без движка меньше уязвимостей в рантайме

Звучит прекрасно. Но есть нюанс: это экспериментальный проект. Vercel сами предупреждают, что Scriptc не готов для продакшена. Нет поддержки всей стандартной библиотеки JavaScript, отладка нетривиальна, а размер бинарника может быть больше, чем аналогичного Go-проекта.

Ограничения и риски

Вот что меня смущает:

• Зрелость — проект только начинает жизнь. API может поменяться, баги неизбежны.
• Стандартная библиотека — не всё из привычного Node.js будет работать.
• Отладка — как отлаживать нативный бинарник? Это уже не привычная консоль Chrome DevTools.
• Размер — для больших проектов бинарник может быть внушительным.

Для CLI это уже сейчас может быть ок — утилиты часто проще по структуре. Для сервисов с интенсивной бизнес-логикой — лучше подождать.

Когда это имеет смысл использовать

Идеальные сценарии для Scriptc сейчас:

• CLI-утилиты — быстрый запуск, один файл для распространения
• Edge-функции и serverless-функции — где критичен холодный старт
• Простые скрипты автоматизации — если не нужна вся мощь npm-экосистемы
• Образовательные проекты — чтобы понять, как работает компиляция

Не стоит смотреть в сторону Scriptc, если проект активно использует npm-пакеты, нужна полная совместимость с Node.js API или команда не готова к экспериментам в продакшене.

Моя оценка

Scriptc — это не революция, но интересный шаг. Vercel показывает направление: TypeScript может выйти за рамки JavaScript-рантайма. Это в духе времени, когда Bun и Deno уже бросают вызов Node.js, а компиляция в нативный код становится нормой для высоконагруженных систем.

Лично мне интересно следить за развитием проекта. Не потому, что я брошу TypeScript-разработку и побегу переписывать всё на нативные бинарники. А потому, что подобные эксперименты двигают индустрию вперёд.

Но прямо сейчас — не спешите внедрять. Поиграйте, посмотрите, оцените сценарии. Экспериментальный проект — это про обучение и подготовку к будущему, а не про надёжный продакшен.

Выводы

• Scriptc убирает JS-движок из цепочки запуска и резко сокращает холодный старт.
• Проект интересен для CLI, edge и простых автоматизаций.
• Для продакшена пока рано: проект экспериментальный и с ограничениями.
• Следить за ним стоит, но внедрять — только осторожно.

Ссылки

• Scriptc на GitHub — экспериментальный репозиторий проекта
• Bun — альтернативный JavaScript-рантайм