Microsoft ускоряет TypeScript: зачем меняется архитектура компилятора и что это значит для разработчиков

Вчера я открыл проект, над которым работал полгода назад.

И забыл, что там 12 тысяч файлов.

IDE подвисла на пару секунд. Потом ещё на пару. Автодополнение приезжало с задержкой, как почтальон в дождливый день. Я нажал сохранить - и пошёл налить кофе, потому что проверка типов, судя по всему, решила взять выходной.

Знакомо?

TypeScript давно перестал быть просто инструментом. Он стал стандартом. Миллионы разработчиков включают его в каждый новый проект, даже не задумываясь.

Но у стандартов есть одна неприятная черта.

Они начинают тормозить ровно в тот момент, когда ты перестаёшь замечать их присутствие.

В небольших приложениях TypeScript летает. Мгновенные подсказки, быстрая проверка, никаких задержек. Ты даже не думаешь о том, что там внутри происходит.

А потом проект вырастает. Подтягиваются зависимости. Появляются общие библиотеки, монорепозитории, сотни разработчиков.

И в один прекрасный день ты замечаешь, что IDE думает дольше, чем ты.

Не намного. Секунда-две. Но когда это происходит по сто раз за день - складывается в часы. В недели. В раздражение.

Я не знаю, как у вас, но у меня есть лимит на ожидание. Когда я нажимаю "перейти к определению" и жду больше трёх секунд - я успеваю забыть, зачем туда шёл.

Это не проблема синтаксиса. Это проблема архитектуры.

TypeScript появился в 2012 году. Тогда никто не думал, что он будет обрабатывать проекты с десятками тысяч файлов. Его писали на самом TypeScript - логичное решение для команды, которая хотела быстро развивать язык.

И это работало. Годы.

Но мир не стоял на месте. Проекты стали больше. Команды - больше. Ожидания - выше.

А компилятор остался тем же.

Он пытается, честно. У него есть инкрементальная сборка, кеширование, хитрые оптимизации. Но если ты работаешь в компании, где общая библиотека компонентов используется двадцатью приложениями - ты знаешь, что даже эти механизмы не всегда спасают.

Ты меняешь один интерфейс.

И компилятор уходит в глубокую медитацию, пытаясь понять, кто от этого зависит.

Microsoft, кажется, это поняла.

Поэтому сейчас развивают Native TypeScript - новую реализацию инструментов языка. Не новый синтаксис, не новый язык, не "TypeScript 2.0". Просто другой движок. Более эффективный.

И тут самое интересное - они выбрали Go.

Спорить можно долго. C++ - быстрее, Rust - безопаснее. Но Go - компромисс. Быстрый, простой в поддержке, хорошо работает с конкурентностью. Для компилятора, которому нужно анализировать тысячи файлов параллельно - это важно.

Но, честно говоря, мне всё равно, на чём это написано. Мне важно, чтобы работало.

Осторожно: не ждите, что старый проект начнёт компилироваться в десять раз быстрее.

Производительность зависит от кучи факторов: размер кодовой базы, количество зависимостей, настройки сборки. Где-то ускорение будет заметным, где-то - почти незаметным.

Главное не в этом.

Главное - снимаются ограничения старой архитектуры. Та, что была спроектирована для других масштабов, в которых мы уже не живём.

Native TypeScript - это не про то, чтобы сделать TypeScript быстрее прямо сейчас.

Это про то, чтобы он мог развиваться дальше.

Есть, конечно, риски.

Экосистема вокруг TypeScript огромна. Плагины, трансформеры, инструменты сборки - многие из них используют внутренние механизмы компилятора не по документации, а по наитию. Когда поменяется архитектура - часть из них сломается.

Это неизбежно.

Microsoft обещает постепенный переход, тестирование на реальных проектах, обратную совместимость. Но я в этом деле достаточно давно, чтобы знать: переход всегда больно. Вопрос только в том, насколько.

Что делать обычному разработчику?

Пока - ничего. Твой код не изменится. Твои проекты не потребуют переписывания.

Но если ты работаешь в крупной команде, со сложными зависимостями и нестандартными настройками - уже сейчас стоит присмотреться. Как только новая архитектура станет стабильной, такие проекты почувствуют разницу первыми.

Имей в виду: через год-два проверка типов в твоём IDE может стать заметно быстрее. Или не стать - если ты работаешь в маленьком стартапе с тремя файлами.

Тогда ты вообще не заметишь.

И это нормально.

Знаете, есть в этой истории одна вещь, которая мне нравится больше всего.

Не то, что TypeScript стал быстрее.

А то, что Microsoft признала: инструменты должны меняться вместе с задачами. То, что работало для проектов 2012 года, не обязано работать для проектов 2026-го.

И если ты перестаёшь развивать свою архитектуру - ты начинаешь тормозить разработчиков.

Даже если твой язык самый популярный в мире.

Я не знаю, когда именно Native TypeScript станет стандартом. Может, через год. Может, через два.

Но я точно знаю, что буду ждать тот день, когда IDE перестанет задумываться перед тем, как показать мне подсказку.

И, возможно, перестану заваривать кофе на время проверки типов.

Хотя привычка уже осталась.