Содержание
Microsoft переписала компилятор TypeScript на Go: сборка быстрее в 10 раз, но код работает так же. Что это меняет для разработчиков
Microsoft переписывает компилятор TypeScript с JavaScript на Go и обещает 10-кратный прирост производительности.
Новость быстро разлетелась по сообществам, но на деле всё не так однозначно, пишет разработчик Оскар Дудич в рамках Architecture Weekly.
Речь идёт о скорости компиляции, а не исполнения кода. Ваши приложения не станут работать быстрее — только собираться. Это как если бы производитель автомобилей сказал, что «машина стала в 10 раз быстрее», а потом уточнил, что речь о производстве, а не скорости на трассе.
Почему решили переписать и причём тут Go
Компилятор — это CPU-bound задача. Он не ждёт ответа от базы данных и не занимается сетевыми запросами. Он грузит процессор на полную, разбирая дерево типов, анализируя код и генерируя выходной файл.
🔥 DOOM запустили внутри… TypeScript-компилятора. Да, это реальноtproger.ru
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 быстрее». Такие цифры всегда требуют контекста. Но и отрицать ценность изменений не стоит — особенно если вы работаете с большими кодовыми базами и каждый процент ускорения важен.