x10 до продуктивності TypeScript: Microsoft розробляє нативний компілятор

💡 Усі статті, обговорення, новини про Front-end — в одному місці. Приєднуйтесь до Front-end спільноти!

Сьогодні Microsoft оголосили, що розробляє нативну версію компілятора TypeScript на Go. Під час тестування ця версія показала 10-кратне прискорення в деяких репозиторіях — і до 15-кратного в інших.

Очікується, що до середини 2025 року з’явиться попередня версія нативного tsc, здатного виконувати перевірку типів у командному рядку, а повнофункціональне рішення для збірки проєктів і мовної служби буде готове до кінця року.

Go-код із нового робочого репозиторію доступний для збірки та запуску під тією ж ліцензією, що й існуюча кодова база TypeScript. У файлі README містяться інструкції щодо збірки та запуску tsc і мовного сервера, а також огляд уже реалізованих можливостей. Розробники планують регулярно публікувати оновлення з новими функціями для тестування.

Наскільки швидше

Нативна реалізація вже підтримує завантаження багатьох популярних проєктів на TypeScript, включно з самим компілятором TypeScript, і забезпечує значне прискорення роботи. Наведені нижче показники відображають час виконання tsc на кількох відомих репозиторіях GitHub різного розміру:

Кодова база

Розмір (LOC)

Поточний час

Нативний час

Прискорення

VS Code

1,505,000

77.8s

7.5s

10.4x

Playwright

356,000

11.1s

1.1s

10.1x

TypeORM

270,000

17.5s

1.3s

13.5x

date-fns

104,000

6.5s

0.7s

9.5x

tRPC (server + client)

18,000

5.5s

0.6s

9.1x

rxjs (observable)

2,100

1.1s

0.1s

11.0x

Хоча нативна реалізація TypeScript ще не є повністю завершеною, вже зараз вона демонструє суттєве покращення продуктивності під час перевірки коду. Очікується, що більшість проєктів відчують значне прискорення роботи компілятора, що позитивно вплине на весь процес розробки.

Покращення швидкості роботи редактора

Оскільки розробники проводять більшість часу в редакторах, їх продуктивність тут має вирішальне значення. Новий TypeScript забезпечить швидке завантаження великих проєктів і миттєву реакцію на дії користувача. Сучасні редактори, такі як Visual Studio та Visual Studio Code, вже демонструють високу продуктивність, але значною мірою вона залежить від мовних сервісів. Завдяки нативному порту ці сервіси працюватимуть значно швидше.

Наприклад, кодова база Visual Studio Code завантажується в редакторі за 9,6 секунди, тоді як із нативною мовною службою цей час скорочується до 1,2 секунди — у 8 разів швидше. Це означає, що розробники зможуть одразу працювати після відкриття редактора.

Використання пам’яті також зменшилося приблизно вдвічі, а швидкість операцій мовної служби (автодоповнення, пошук визначень, навігація) значно зросла. Також планується перехід на Language Server Protocol (LSP) для кращої інтеграції з іншими мовами програмування.

Що далі чекає на TypeScript

Нещодавно вийшла версія TypeScript 5.8, а незабаром з’явиться TypeScript 5.9. Кодова база на JavaScript продовжить розвиватися в серії 6.x, а версія TypeScript 6.0 підготує ґрунт для майбутнього переходу на нативну реалізацію.

Як тільки нативна версія досягне достатньої функціональності, її випустять під номером TypeScript 7.0. Щоб уникнути плутанини, розробники вирішили чітко розмежувати версії: TypeScript 6 (JS) залишиться у традиційному вигляді, а TypeScript 7 (native) буде повністю нативним. У внутрішній документації можуть також зустрічатися кодові назви: «Strada» (оригінальне ім’я TypeScript) та «Corsa» (назва нового порту).

Чи потрібно переходити на нову версію одразу? Це залежить від проєкту. Деякі зможуть перейти на TypeScript 7 без проблем, інші ж можуть залежати від застарілих API чи конфігурацій, які поки не підтримуються в нативному TypeScript. Тому розробники продовжать підтримувати серію 6.x, поки TypeScript 7 не стане повністю стабільним.

👍ПодобаєтьсяСподобалось9
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

дивне рішення
якби вони спочатку зробили кастомний компілятор Go на Java, спеціально для цього діла — я б залайкав

Не зрозумів, чому для цього не використали більш адекватні та популярні мови типу С++ чи, хоча (www.tiobe.com/tiobe-index) б .net, який вже вміє у native.

Пишут, что сначала пытались сделать на расте, но не асилили и пришлось делать на го.

я вже подивився відосики перед сном, так, проблема у строгих типах у всих інших.

Хороше питання. В репі є цілий тред «Why Go?»

Я так розумію, вони хотіли напівавтоматизований (і максимально близький до оригінала) перевод з тайпскрипта, і гоу підійшов найбільше, бо дозволяє писати у тому самому стилі, який вже використовується для компілятора тайпскрипта

Так, вони на першому кроці використовували чи то скріпт, чи то AI для трансформування коду у GO, майже 1-1 вийшло. З іншими МП довелось би все ручками з нуля вигадувати конструкції аби обійти все це.

Заголовки як завжди...

... The native implementation will drastically improve editor startup, reduce most build times by 10x, and substantially reduce memory usage.

Те, що для цієї задачі використали Go, — це, звісно, плюс для самого Go, враховуючи, що на Go написаний esbuild.

Але я очікував, що використають Rust за прикладом Deno або Zig за прикладом Bun.

Більшість сучасних трансляторів написані або на С/С++ або розкручені, тобто транслятор може транслювати сам себе. Чому Go lang, і справді велике питання.

Тут якраз пояснюють чому саме Go замість Rust

www.youtube.com/watch?v=10qowKUW82U

Вони не переписували його з нуля, а транслювали на Го, намагаючись максимально зберегти структуру оригіналу. На Расті (і на Сшарпі або плюсах) так не вийшло б

--- По оригіналу статті і коду в Github, ам тільки реалізація самого траслятора із TypeScript зроблена на Go lang, і це усе. Він не генерує CPU кода як Go lang або D

Offtopic
Цікаво звідки взялось оце

фреймверками

Вони ж фреймворки, ну нехай фреймвоки, але звідки оте верк(вьорк)?
PS
Середа != середовище

Сорі, передивився оригінал англійською та репозіторії коду. Йдеться лише про сам транслятор із TypeScript, який розкрутили в Go lang. Про трансляцію в нативний CPU код не йдеться рівно як WebASM (хоча є такі транслятори), як і раніше на виході — JavaScript.

Та воно однаково не по темі було :)
То більше про дивну транскрипцію/транслітерацію work -> верк(вьорк)
Хоч там найбільш натуральний варіант це
work -> ворк(вок)

Але, ніби зрозумів. То якщо хтось німецьку вчив, то у них отой дивний варіант зявляється

хоча є такі транслятори

Це які?
Ніби не має.
Є AssemblyScript але це все таки не Typescript, і то він в WebAssembly компілюється.

Javy це ні не компілятор, ні не транслятор. Це QuickJS— JavaScript інтерпретатор —на WebAssembly + доданий JavaScript код на вході як strings.
Javy не має відношення до TS це інтерпретатор JS — тобто інформації про TS типи нема і компіляції/транспайлінгу нема.

porffor.dev — найближче що знайшов.
Використовує інформацію про типи з TS для AOT оптимізацій. Обіцяють транспайлінг в С.
Pre-alpha! 57.19% EcmaScript conformance test не говорячи про TS.

Ніби не має.

Підписатись на коментарі