Новый компилятор TypeScript на Go собирает код быстрее, но не делает его быстрее

Microsoft переписывает компилятор TypeScript с JavaScript на Go и обещает 10-кратный прирост производительности.

Новость быстро разлетелась по сообществам, но на деле всё не так однозначно, пишет разработчик Оскар Дудич в рамках Architecture Weekly.

Речь идёт о скорости компиляции, а не исполнения кода. Ваши приложения не станут работать быстрее — только собираться. Это как если бы производитель автомобилей сказал, что «машина стала в 10 раз быстрее», а потом уточнил, что речь о производстве, а не скорости на трассе.

Почему решили переписать и причём тут Go

Компилятор — это CPU-bound задача. Он не ждёт ответа от базы данных и не занимается сетевыми запросами. Он грузит процессор на полную, разбирая дерево типов, анализируя код и генерируя выходной файл.

Node.js с его однопоточной моделью и event loop плохо подходит для таких задач. Он отлично работает в веб-серверах — там важна скорость отклика и работа с I/O, но не тяжёлые вычисления. Компилятор TypeScript вырос, стал сложнее, и старая архитектура начала тормозить.

Go здесь оказался подходящим выбором:

• у него есть легковесные потоки (goroutines);
• параллельное выполнение встроено на уровне языка;
• нет нужды в трюках с worker threads, как в Node.js;
• проще работать с памятью и сложными структурами.

Почему просто не использовать worker threads в Node.js?

Это возможно, и они действительно дают параллельность. Но:

• переписывать старый код с учётом многопоточности — больно;
• обмен данными между потоками в Node.js идёт через сериализацию;
• каждый поток создаёт свой V8-инстанс, что дорого по ресурсам.

Команда решила не латать старое, а начать с чистого листа. И, как показали первые тесты, даже однопоточный Go-компилятор оказался быстрее, чем старый на Node.js.

А что с браузерами и плагинами?

Это пока не ясно. В браузерах Go не работает нативно, и придётся либо компилировать его в WebAssembly, либо сохранить JS-версию для playground'ов. Вопросов больше, чем ответов:

• как сохранить совместимость с TypeScript-плагинами;
• будет ли 100% повторяемость в поведении компилятора;
• изменятся ли ошибки, предупреждения и тонкости типов.

Зачем вообще об этом думать

Это кейс о масштабировании и выборе инструментов. То, что хорошо работало в 2012 году, перестаёт тянуть в 2025-м. Переписывание проекта — не всегда трагедия. Иногда это необходимость, если фундамент начал мешать росту.

Важно не повестись на «10x быстрее». Такие цифры всегда требуют контекста. Но и отрицать ценность изменений не стоит — особенно если вы работаете с большими кодовыми базами и каждый процент ускорения важен.