TypeScript 10x Lebih Cepat
(devblogs.microsoft.com)- Microsoft mengumumkan peningkatan performa TypeScript hingga 10x melalui porting native pada compiler dan alatnya
- Waktu startup editor meningkat drastis, waktu build dipangkas hingga 10x, dan penggunaan memori berkurang signifikan
- Versi pratinjau
tscakan dirilis pada pertengahan 2025, dan pada akhir 2025 dukungan build proyek penuh serta language service akan tersedia
Latar belakang peningkatan performa TypeScript
- Nilai utama TypeScript adalah pengalaman pengembang yang sangat baik
- Semakin besar codebase, semakin tinggi nilai TypeScript, tetapi pada proyek skala besar muncul masalah performa
- Terjadi masalah waktu pemuatan dan pemeriksaan yang lama
- Diperlukan keseimbangan antara startup editor yang cepat dan analisis seluruh codebase
- Fitur berbasis AI membutuhkan informasi semantik yang cepat dan akurat
- Kebutuhan untuk memverifikasi status codebase melalui build command-line juga meningkat
Rencana port native
- Pekerjaan port native untuk compiler dan alat TypeScript telah dimulai
- Target peningkatan performa:
- Mempercepat waktu startup editor secara signifikan
- Memangkas waktu build hingga 10x
- Mengurangi penggunaan memori
- Pertengahan 2025: versi pratinjau
tscdengan pemeriksaan tipe via command-line dijadwalkan rilis - Akhir 2025: dukungan build proyek penuh dan language service dijadwalkan tersedia
Menjalankan kode dan pengujian
- Kode dapat di-build dan dijalankan dari repositori kode TypeScript Go
- Repositori tersebut menyediakan panduan untuk build dan menjalankan
tscserta language server - Pembaruan rutin untuk fitur baru akan terus diberikan
Seberapa cepat peningkatannya?
- Hasil pengujian waktu build proyek TypeScript saat ini pada beberapa codebase populer menunjukkan peningkatan berikut:
- Proyek VS Code dengan sekitar 1,5 juta baris kode meningkat dari 77,8 detik menjadi 7,5 detik, sekitar 10,4x lebih cepat
- Proyek Playwright dengan sekitar 350 ribu baris kode meningkat dari 11,1 detik menjadi 1,1 detik, sekitar 10,1x lebih baik
- Proyek TypeORM dengan sekitar 270 ribu baris kode meningkat dari 17,5 detik menjadi 1,3 detik, sekitar 13,5x lebih baik
- Proyek date-fns dengan sekitar 100 ribu baris kode meningkat dari 6,5 detik menjadi 0,7 detik, sekitar 9,5x lebih baik
- Proyek tRPC dengan sekitar 18 ribu baris kode meningkat dari 5,5 detik menjadi 0,6 detik, sekitar 9,1x lebih baik
- Proyek rxjs dengan sekitar 2 ribu baris kode meningkat dari 1,1 detik menjadi 0,1 detik, sekitar 11x lebih baik
- Meski fiturnya belum sepenuhnya lengkap, peningkatan performa lebih dari 10x diperkirakan terjadi pada sebagian besar codebase
- Pemeriksaan tipe dan penelusuran kode menjadi jauh lebih cepat
- Integrasi alat AI dan dukungan refactoring tingkat lanjut pun dimungkinkan
Peningkatan performa editor
- Kecepatan pemuatan dan respons editor meningkat
- Berdasarkan codebase Visual Studio Code, waktu muat berubah dari:
- Saat ini: 9,6 detik → versi native: 1,2 detik (sekitar 8x lebih baik)
- Penggunaan memori juga berkurang sekitar 50%
- Performa tugas language service seperti autocomplete, quick info, dan go to definition diperkirakan ikut meningkat
- Pekerjaan migrasi sedang dilakukan berbasis Language Server Protocol (LSP)
Roadmap versi
- TypeScript 5.8 sudah dirilis, dan TypeScript 5.9 akan segera hadir
- Codebase TypeScript berbasis JS akan terus dikembangkan pada versi 6.x
- Setelah codebase native stabil, rilis akan dilakukan sebagai TypeScript 7.0
- TypeScript 6 → versi berbasis JS
- TypeScript 7 → versi berbasis native
- Setelah TypeScript 7 dirilis, versi 6.x juga akan tetap dipelihara untuk jangka waktu tertentu
Langkah berikutnya
- Informasi tambahan tentang performa, compiler API, LSP, dan lainnya akan diumumkan
- Pertanyaan umum dapat dilihat di GitHub FAQ
- AMA akan diadakan di Discord komunitas TypeScript pada 13 Maret 2025 (10:00 PDT | 17:00 UTC)
24 komentar
Saya merasa banyak orang melemparkannya tanpa benar-benar memikirkan
structural typing.Kalau ingin menulis ulang ke bahasa dengan
nominal typingseperti C# atau Rust, pasti tidak mudah karena harus mengubah terlalu banyak struktur fundamental proyek.Di antara bahasa yang mengadopsi
structural typing, yang bisa memberi performa lebih tinggi daripada basis JS yang sudah ada mungkin hanya C++ atau Go, dan kalau produktivitas juga diperhitungkan, tidak ada alternatif lain.Sejak suatu titik, saya jadi makin jarang menyentuh TS, tapi melihat kabar seperti ini rasanya jadi tertarik lagi, ya?
Kalau di ts
anydipakai sembarangan kecuali benar-benar tidak terhindarkan, ya jadinya tidak beda dengan pakai vanilla.. hehSepertinya perdebatan soal ini cukup panas sampai Anders Hejlsberg sendiri meninggalkan komentar.
https://github.com/microsoft/typescript-go/…
Saya termasuk orang yang berharap hasil kompilasi dari TypeScript bisa langsung keluar sebagai biner.
Saya kurang paham soal frontend.. apakah ini berbeda dengan swc?
SWC berfokus pada pembuatan kode JavaScript yang kompatibel seperti Babel serta hingga proses bundling, sedangkan ini berfokus pada mengonversi kode TypeScript menjadi JavaScript atau memeriksa error.
Ada istilah dogfooding, yaitu menggunakan sendiri apa yang kita buat. Tetapi untuk bahasa pemrograman, rasanya ini memang sedikit mengundang pertimbangan.
Menurut saya pribadi, runtime JS yang menjadi fondasi ts (mis. spidermonkey, v8) sebagian besar ditulis dengan C++, dan tidak ada runtime yang diimplementasikan dengan JS.
Kalau melihat kompilasi js -> js juga terlalu lambat bila memakai pure JS sehingga semua beralih ke esbuild dan semacamnya,
jadi saya merasa di ts pun tidak perlu ngotot mempertahankan dogfooding.
Saya khawatir nantinya pengelolaan codebase TypeScript yang sudah ada akan terabaikan.
Kabar yang menggembirakan! Menariknya, bahasa TypeScript dari MS tampaknya benar-benar banyak mengambil pilihan yang tidak terduga, berbeda dari perkiraan. Dari sudut pandang MS, ini bisa dibilang hampir proyek open source pertamanya, dan tidak seperti Dart dari Google yang dulu ingin menggantikan JS, pilihan untuk melengkapi JS terasa sangat bijak. Kali ini pun, meski mereka punya banyak bahasa sendiri untuk dipakai dalam porting native ini, tetap mengejutkan bahwa mereka memilih Go dari Google.
Lho, bukannya di kubu Deno sudah ada toolchain berbasis Rust yang dibuat... kenapa tiba-tiba Go?
Sepertinya yang dimaksud itu runtime seperti Node, sedangkan yang dibicarakan di sini adalah compiler untuk bahasa TS itu sendiri.
Ah, setelah membaca artikelnya sedikit lebih jauh, sepertinya saya bingung karena ada pembahasan bahwa editornya menjadi lebih cepat.
tscmenjadi 10 kali lebih cepat. Artinya, waktu transpiling darits->jsberkurang sangat banyak.tsseperti VSCode, kecepatannya menjadi jauh lebih tinggi. Artinya, logika yang berbagi fungsitsc, seperti pemeriksaan sintaksts, juga menjadi lebih cepat.Jadi ternyata isinya seperti itu.
Saya pernah mengalami saat menggunakan tipe generik yang disusun secara rekursif, performanya jadi lambat sehingga terpaksa memakai alternatif lain. Kalau memang 10 kali lebih cepat, saya berharap bagian seperti ini juga bisa membaik.
Thread diskusi tentang kenapa Go cukup menarik.
https://github.com/microsoft/typescript-go/discussions/411
Ada banyak hal yang perlu dipertimbangkan juga...
Begitulah, tapi saya juga bisa memahami perasaan para developer .NET...
Para pengembang .NET dan Rust tampaknya sangat marah.
Saya paham soal .NET, tapi menurut saya Rust posisinya sama seperti Go. Bagaimanapun juga, proyek dan library Go terkait JS yang sudah ada tampaknya ikut memengaruhi keputusan tersebut.
Pengembangan untuk bahasa C# memang tidak berhenti, tetapi terlalu sering terasa seperti framework yang menggunakan C# dibiarkan terbengkalai.
Tulis dalam Go~
Sangat dinantikan.
Pendapat Hacker News
tsccepat dengan Ruststc: dihentikanezno: masih dikembangkan aktif, dan tidak bertujuan menjadi padanan 1:1 untuktsc