tsrs: TypeScript Compiler Di-port ke Rust, 8x Lebih Cepat

Cloudflare memperkenalkan tsrs, port compiler TypeScript ke Rust, dengan klaim benchmark awal hingga 8 kali lebih cepat dan pemakaian memori sekitar 70 persen lebih rendah dibanding TypeScript 7.0 pada jumlah type check worker yang sama. Angka tersebut berasal dari pengukuran Cloudflare sendiri yang dipublikasikan 20 Oktober 2026, dan dikerjakan bersama tim TypeScript, bukan sebagai fork independen.

TL;DR

• tsrs adalah port compiler TypeScript ke Rust yang diinkubasi Cloudflare bersama tim TypeScript, bukan fork bahasa baru.
• Benchmark awal Cloudflare: sampai 8 kali lebih cepat dan sekitar 70 persen lebih hemat memori dibanding TypeScript 7.0.
• TypeScript 7.1 beta sendiri sudah sampai 2.5 kali lebih cepat dari 7.0 karena optimasi yang di-upstream dari pekerjaan port ke Go.
• Alasan memilih Rust bukan cuma kecepatan: model memori Rust lebih cocok untuk WebAssembly dan memungkinkan toolchain utuh jalan di browser.
• Statusnya masih eksperimental, jadi belum layak jadi pengganti default di pipeline produksi tim.

Apa Itu tsrs dan Kenapa Cloudflare Membuatnya?

tsrs adalah port compiler TypeScript ke Rust yang dikerjakan Cloudflare bersama tim TypeScript dan diinkubasi sebagai bagian dari proyek mereka. Tujuannya memangkas waktu tunggu type checking dan memori yang dipakai proses itu, tanpa mengubah bahasa TypeScript itu sendiri. Cloudflare menyatakan secara eksplisit bahwa mereka tidak mem-fork TypeScript: tim TypeScript tetap memegang kendali penuh atas desain bahasa, dan port Rust wajib mengikuti implementasi asli supaya tidak melenceng dari semantik yang berlaku.

Alasan di balik keputusan itu praktis. Type checking adalah tahap yang paling sering membuat loop pengembangan terasa lambat, terutama di codebase besar dengan ribuan file dan tipe generik berlapis. Menambah worker memang bisa mempercepat, tapi biayanya memori naik linear. Kalau compiler-nya sendiri bisa lebih cepat dengan jejak memori lebih kecil, maka kecepatan bisa didapat tanpa harus menambah mesin atau RAM.

Yang menarik, Cloudflare tidak menjual ini sebagai bahasa baru atau superset. Mereka menyebut tsrs sebagai port yang setia, dan menempatkan diri sebagai pihak yang menginkubasi eksperimen, bukan pihak yang menentukan arah TypeScript. Detail teknis lengkapnya ada di pengumuman resmi Cloudflare.

Seberapa Besar Selisih Performanya?

Cloudflare merilis perbandingan pada jumlah type check worker yang sama, sehingga angka 8 kali lipat dan 70 persen lebih hemat memori dibanding TypeScript 7.0 bukan hasil menambah core. Mereka juga mencatat bahwa TypeScript 7.1 beta sudah membawa banyak peningkatan, sebagian di-upstream dari pekerjaan port ke Go, dan versi beta itu disebut sampai 2.5 kali lebih cepat dari 7.0.

Implementasi	Kecepatan relatif	Memori	Catatan
TypeScript 7.0	Baseline	Baseline	Pembanding utama di benchmark Cloudflare
TypeScript 7.1 beta	Sampai 2.5 kali lebih cepat	Tidak disebut terpisah	Optimasi dari pekerjaan port Go
tsrs	Sampai 8 kali lebih cepat	Sekitar 70 persen lebih rendah	Jumlah worker sama dengan baseline
tsrs, konfigurasi adaptive	Lebih cepat lagi	Lebih tinggi dari mode default	Menyesuaikan tipe mesin yang dipakai

Ada satu catatan penting soal membaca benchmark seperti ini. Cloudflare sendiri menyoroti bahwa banyak klaim performa port TypeScript di luar sana memakai mesin lebih besar dan opsi yang berbeda dari default TypeScript. Karena itu mereka menyebut sudah menyamakan konfigurasi dengan tim TypeScript sebelum mengukur. Meski begitu, benchmark vendor tetap benchmark vendor: angka 8 kali lipat itu konteksnya type checking, bukan waktu build atau waktu startup editor secara keseluruhan.

Kenapa Rust dan Bukan Go?

Jawaban singkatnya: WebAssembly dan model memori. Rust tidak membawa garbage collector ke dalam binary, sehingga saat dikompilasi ke Wasm, interaksi memori antara guest dan host jauh lebih sederhana. Cloudflare menyebut ini sebagai salah satu alasan fundamental kenapa Rust lebih cocok untuk kasus WebAssembly, dan mereka sudah lama menjalankan Wasm di Workers.

Implikasi praktisnya cukup besar. Kalau compiler TypeScript bisa berjalan sebagai modul Wasm dengan jejak memori kecil, maka type checking bisa dijalankan di tempat yang sebelumnya tidak mungkin: di dalam browser, di dalam sandbox di edge, atau di perangkat kecil. Untuk pekerjaan yang berjalan dalam loop ketat di Workers, selisih memori beberapa puluh megabyte per instance berubah jadi biaya nyata saat dikalikan ribuan eksekusi.

Cloudflare juga menyebut target paket yang mencakup seluruh fitur TypeScript, termasuk Language Server Protocol dan content mappers, dalam satu paket. Itu penting untuk tooling: kalau compiler dan language server berasal dari basis kode yang sama, perilaku editor dan hasil build tidak gampang berbeda.

Apa Hubungan tsrs dengan Port TypeScript ke Go?

Keduanya adalah port, tapi tujuannya berbeda. Tim TypeScript sudah memindahkan implementasi dari JavaScript ke Go, dan Cloudflare menyebut port Go itu satu-satunya port yang berhasil dari sekian banyak percobaan selama bertahun-tahun. Port Go memberi lompatan besar: Cloudflare menulis bahwa versi Go membuat TypeScript sekitar 10 kali lebih cepat dan jauh lebih hemat memori dibanding implementasi JavaScript sebelumnya.

Pertanyaan wajarnya: kalau sudah 10 kali lebih cepat, kenapa masih perlu Rust? Cloudflare menjawab bahwa isunya bukan hanya kecepatan. Kombinasi Rust dan Wasm membuka jalur distribusi yang tidak bisa dicapai port Go, karena Go membawa garbage collector-nya saat dikompilasi ke Wasm. Repositori port Go bisa dilihat di microsoft/typescript-go.

Karena itu posisi tsrs bukan pengganti resmi. Ini eksperimen paralel yang mengikuti keputusan tim TypeScript, dengan asumsi bahwa kalau port Rust melenceng dari implementasi asli, ia akan cepat jadi tidak kompatibel dan kehilangan gunanya.

Kapan Sebaiknya Lo Mencoba tsrs?

Waktu paling masuk akal adalah sekarang, tapi hanya untuk eksperimen di mesin lokal atau CI yang tidak kritis. Cloudflare menyediakan rilis eksperimental, dan justru umpan balik dari pemakaian nyata yang mereka cari. Kalau codebase lo besar dan type checking terasa jadi bottleneck harian, mengukur sendiri di repo lo jauh lebih berguna daripada percaya angka benchmark vendor.

Yang perlu disiapkan: versi TypeScript yang dipakai sebagai pembanding, konfigurasi worker yang sama, dan catatan memori puncak. Ukur tiga hal minimal: waktu type check penuh, memori puncak proses, dan waktu respons editor saat file besar dibuka. Tanpa tiga angka itu, perbandingan akan berubah jadi debat rasa.

Kalau hasilnya menjanjikan, jangan langsung mengganti tooling tim. Jalankan berdampingan di CI sebagai job terpisah selama beberapa minggu, lalu bandingkan selisih temuan diagnostik. Compiler yang lebih cepat tapi menghasilkan satu peringatan berbeda bisa mengubah pipeline jadi merah tanpa alasan yang jelas.

Apa Risiko yang Perlu Diwaspadai?

Risiko pertama adalah kompatibilitas. Port yang mengikuti implementasi asli berarti setiap perubahan semantik di TypeScript harus dikejar, dan jeda sekecil apa pun bisa membuat hasil type checking berbeda. Cloudflare mengakui ini sebagai konsekuensi desain, bukan bug sementara.

Risiko kedua adalah klaim performa yang tidak sebanding di workload lo. Type checking di codebase dengan banyak deklarasi pihak ketiga, path mapping rumit, dan plugin kustom tidak selalu mencerminkan benchmark sintetis. Risiko ketiga soal distribusi: rilis eksperimental berarti API, nama paket, dan perilaku bisa berubah tanpa jaminan stabilitas.

Ada juga konteks yang lebih luas. Cloudflare menyebut model AI frontier sekarang bisa melakukan port skala besar dalam hitungan hari, dan itu melahirkan banyak versi TypeScript di Rust maupun C++ dengan kualitas campur aduk. Dalam situasi seperti itu, port yang punya jalur kolaborasi resmi dengan tim TypeScript punya nilai lebih dibanding port yang sekadar cepat. Dokumentasi bahasa dan rilis resmi tetap ada di typescriptlang.org.

Bagaimana Cara Mengukur Performa di Repo Sendiri?

Mulai dari baseline yang jujur. Jalankan type check penuh dengan versi TypeScript yang sekarang dipakai, catat waktu total, memori puncak, dan jumlah worker. Ulangi tiga kali dan pakai nilai median, karena run pertama biasanya lebih lambat akibat cache kosong dan itu bukan sinyal yang berguna.

Setelah baseline terkumpul, jalankan versi eksperimental tsrs dengan konfigurasi worker yang identik. Jangan menaikkan jumlah worker saat menguji, karena itu mengubah dua variabel sekaligus dan hasilnya tidak bisa dibandingkan. Kalau ingin menguji mode adaptive yang disebut Cloudflare, jadikan itu percobaan terpisah dengan catatan sendiri.

Langkah ketiga yang sering dilewatkan: bandingkan keluaran diagnostik. Hitung jumlah error dan warning, lalu diff daftar file yang terdampak. Compiler baru yang lebih cepat tapi memunculkan lima warning tambahan bisa memaksa tim mematikan aturan strict, dan itu kerugian yang jauh lebih mahal daripada waktu yang dihemat.

Langkah keempat, ukur di CI dengan cache yang realistis. Banyak pipeline menyimpan cache hasil build, dan perbedaan performa compiler bisa menyusut drastis saat cache hangat. Angka yang lo dapat di mesin lokal tanpa cache tidak otomatis berlaku di runner CI yang punya cache persisten.

Apa Dampaknya untuk Editor dan CI?

Untuk editor, efek yang paling terasa bukan waktu build, melainkan latensi saat mengetik di file besar. Language server yang lebih hemat memori biasanya bertahan lebih lama sebelum prosesnya perlu di-restart, dan itu menghilangkan satu jenis gangguan yang paling menyebalkan: menunggu editor memuat ulang proyek di tengah alur kerja.

Untuk CI, keuntungannya muncul sebagai kombinasi dua hal: job selesai lebih cepat dan runner tidak perlu RAM sebesar sebelumnya. Cloudflare menyebut konfigurasi adaptive memakai lebih banyak memori untuk hasil lebih cepat, jadi pilihan konfigurasi di CI sebaiknya disesuaikan dengan batas memori runner, bukan dengan angka benchmark terbaik.

Ada satu efek samping yang perlu diantisipasi: kalau type checking jadi jauh lebih murah, tim cenderung menambah cakupan pemeriksaan. Itu sehat, tapi berarti penghematan waktu tidak otomatis terlihat di dashboard durasi pipeline. Bandingkan juga jumlah pemeriksaan yang berjalan, bukan hanya total menit.

Siapa yang Sebaiknya Menunggu?

Tim yang pipeline-nya sudah stabil dan tidak punya masalah kecepatan sebaiknya menunggu. Biaya migrasi tooling tidak kecil: dokumentasi internal, skrip editor, konfigurasi CI, dan kebiasaan tim semuanya ikut berubah. Kalau tidak ada rasa sakit yang mau diobati, menukar compiler default hanya menambah risiko.

Sebaliknya, tim yang punya monorepo besar dengan waktu type check lebih dari beberapa menit punya alasan kuat untuk mengukur sekarang. Begitu juga tim yang menjalankan tooling di lingkungan terbatas memori, misalnya container CI kecil atau perangkat edge, karena di situ selisih memori bekerja sebagai pengali.

FAQ

Apakah tsrs menggantikan TypeScript?

Tidak. tsrs adalah port compiler, bukan bahasa baru. Tim TypeScript tetap memegang keputusan desain bahasa, dan tsrs mengikuti implementasi asli. Statusnya eksperimental, jadi TypeScript resmi masih jadi acuan untuk produksi.

Berapa kecepatan tsrs dibanding TypeScript 7.0?

Cloudflare mengklaim sampai 8 kali lebih cepat dengan memori sekitar 70 persen lebih rendah, diukur pada jumlah type check worker yang sama. Angka ini berlaku untuk type checking, bukan untuk seluruh siklus build aplikasi.

Apakah tsrs bisa jalan di browser?

Itu salah satu alasan utama memilih Rust. Tanpa garbage collector, kompilasi ke WebAssembly menghasilkan interaksi memori yang lebih sederhana, sehingga toolchain bisa dijalankan di browser atau sandbox edge dengan jejak memori kecil.

Apakah aman dipakai di pipeline produksi sekarang?

Belum disarankan. Rilisnya masih eksperimental dan perilakunya bisa berubah. Pola yang lebih aman adalah menjalankannya sebagai job pembanding di CI sampai selisih diagnostiknya stabil dan bisa dipertanggungjawabkan.