TypeScript 7 Resmi Dirilis Dan Sangat Cepat

Bahasa Indonesiaالعربية Deutsch English Español Français हिन्दी 日本語 한국어 Português Русский 中文

컴퓨터/소프트웨어AI/미래기술

Transcript

00:00:00TypeScript 7 telah resmi dirilis, dan setelah lebih dari setahun pengembangan yang melelahkan,

00:00:05porting pengompilnya ke Go terbukti bisa sepenuhnya dilakukan hanya dengan AI, jadi saya

00:00:10yakin para pengembang sangat senang tentang itu. Jika Anda menjalankan npm install typescript sekarang, Anda akan mendapatkan versi

00:00:167, yaitu versi dengan pengompil Go. Menyusul video pengumuman dari Microsoft

00:00:20beberapa hari yang lalu, saya ingin mendalami bagaimana tepatnya mereka mencapai peningkatan performa

00:00:25yang masif ini. Hasilnya benar-benar mengagumkan. Pengompil baru ini membangun basis kode VS Code

00:00:31yang terdiri dari 1,3 juta baris kode di hampir 8.000 file hanya dalam 10 detik, dibandingkan dengan 125

00:00:39detik dari pengompil lama. Dan dengan TypeScript yang kini bangga menjadi bahasa nomor satu di

00:00:44GitHub, percaya atau tidak, pengompil baru ini akan mengubah begitu banyak kehidupan. Saya sampai emosional

00:00:49memikirkannya. Namun daripada melihat fitur yang hampir identik antara versi 6 dan 7, saya ingin mendalami

00:00:54bagaimana tepatnya performa itu dicapai. Jadi mari kita lihat pengompil baru ini dan mengetahui apa

00:00:59yang membuatnya begitu cepat. Lantas mengapa ditulis ulang? Pencipta C# dan Technical Fellow di Microsoft,

00:01:09Anders Hejlsberg, menyatakannya dengan sangat jelas. JavaScript dioptimalkan untuk UI dan peramban, tidak benar-benar

00:01:16dioptimalkan untuk alur kerja komputasi intensif dan pengompil. Alasannya sangat jelas, yaitu karena sifatnya yang single-threaded

00:01:22dan pemrosesan seperti abstract syntax tree atau pemeriksaan tipe hanya bisa ditingkatkan batasnya

00:01:27dengan akses ke satu core saja. Secara teknis Anda bisa membagi pekerjaan ke beberapa worker, tetapi

00:01:32Anda harus melakukan serialisasi dan deserialisasi data, yang lambat dan memakan banyak memori, lalu Anda harus

00:01:38menghadapi kerumitan dalam mengelola semua itu. Jadi mereka memilih Go, yang memberikan peningkatan performa

00:01:43drastis menggunakan bahasa yang pada dasarnya memang cocok untuk tujuan ini. Go adalah bahasa terkompilasi,

00:01:48yang berarti kita dapat menjalankan kode terkompilasi secara langsung di CPU daripada harus menginterpretasikannya, dan Go memiliki

00:01:54model konkurensi yang sangat bagus, yang berarti kita bisa dengan mudah menjalankan beberapa thread eksekusi sekaligus

00:02:00semuanya dengan memori terbagi. Ini berarti kita dapat memanfaatkan semua core di mesin Anda daripada hanya

00:02:06satu core, dan pembagiannya kira-kira seimbang: hingga setengah peningkatan kecepatan berasal dari kode native,

00:02:12dan sisanya dari konkurensi memori terbagi. Go pada dasarnya adalah bahasa yang sempurna untuk ini.

00:02:17Bukan sekadar Go lebih cepat, ia secara harfiah memiliki lebih banyak sumber daya untuk menyelesaikan masalah ini, dan hasilnya

00:02:23membuktikannya sendiri. Jika kita lihat angkanya, VS Code dengan 1,3 juta baris kode butuh 125,7 detik di pengompil lama,

00:02:32menjadi 10,6 detik, yang merupakan peningkatan 11,9 kali lipat. Untuk Bluesky, kita melihat dari 24,3 menjadi 2,8 detik, peningkatan 8,7 kali lipat.

00:02:42Lalu untuk Playwright, dari 12,8 detik turun menjadi 1,5 detik, peningkatan 8,7 kali lipat. Dan uniknya, hanya

00:02:49butuh satu detik untuk berlangganan Better Stack. Kesenjangan ini akan semakin melebar karena core CPU tidak lagi

00:02:54menjadi lebih cepat pada tingkat yang sama seperti dulu, tetapi yang kita dapatkan adalah lebih banyak core. Saya menggunakan M3 Max saat ini,

00:03:00misalnya, yang memiliki 14 core, sungguh luar biasa. Saya ingat membangun PC gaming waktu kuliah dulu yang memiliki

00:03:06Intel i7 dengan empat core, dan saya pikir itu sudah sangat hebat. Pengompil JavaScript hanya akan

00:03:11menggunakan salah satu core tersebut, tetapi dengan Go, saya membuka potensi semuanya. Dan tentu saja, semakin banyak core yang Anda miliki, semakin tinggi

00:03:17performa yang Anda dapatkan. Jika saya mengompilasi proyek besar di mesin ini di versi 6, Anda akan melihat perlunya waktu 45

00:03:24detik, dan dengan versi 7 kita bisa memangkasnya menjadi hanya tiga detik. Ada beberapa

00:03:29tahap dalam proses kompilasi, dan tahap pemeriksaan tipe hanyalah salah satunya. Untuk ini, Go

00:03:34akan menjalankan empat pemeriksa tipe dan meminta masing-masing memeriksa seperempat dari basis kode, tetapi Anda sebenarnya

00:03:39bisa meningkatkannya lebih jauh lagi. Jadi saat kompilasi, Anda bisa mengatur pemeriksa ke 12 untuk performa yang jauh lebih cepat.

00:03:45Saya telah mengunduh repositori VS Code ke mesin saya agar kita bisa melihat perbedaan antara TypeScript 7 dan 6.

00:03:51Secara default tsc di mesin saya sekarang akan mengarah ke TypeScript 7, jadi kita langsung jalankan diagnostik di

00:03:57repositori ini dan Anda bisa melihat itu memakan waktu 5,4 detik, dan sebagian besar waktu sebenarnya dihabiskan untuk melakukan

00:04:02waktu pemeriksaan, yaitu 4,7 detik dari total waktu tersebut. Kita sebenarnya bisa mempercepatnya juga, jadi jika kita menambahkan flag lain

00:04:08checkers 12, Anda dapat melihat total waktunya sekarang telah turun dari 5,4 menjadi 3,5 detik, dan semua itu memangkas

00:04:15waktu pemeriksaan. Di sini kita melihat 4,7 detik lalu turun menjadi 2,9 detik. Sekarang mari kita jalankan

00:04:20perintah yang sama lagi, tetapi kali ini kita akan menggunakan TypeScript 6 dan ini akan memakan waktu

00:04:23agak lama, jadi kita percepat saja. Setelah menunggu, Anda bisa melihat bahwa TypeScript 6 selesai dalam

00:04:2845,3 detik dibandingkan dengan 3,5 detik yang kita dapatkan saat menjalankannya di semua core. Jadi itu secara efektif

00:04:36merupakan peningkatan 15 kali lipat pada chip M3 Max saya. Bagi saya, dari sinilah asal 3,5 detik tersebut. Melakukan

00:04:43hal ini tentu saja akan mengambil daya dari proses lain, tetapi jika Anda tidak sedang melakukan apa pun, maka

00:04:47sebaiknya gunakan semua sumber daya yang dimiliki mesin Anda. Mari kita lihat beberapa kode nyata

00:04:52dari pengompil baru untuk memahami bagaimana Go mampu mencapai performa ini. Di sini kita memiliki fungsi

00:04:57bind source files yang tugasnya adalah menyusun setiap deklarasi dalam file dan menentukan scope mana miliknya.

00:05:03Kita memproses mungkin ribuan file. Kita melakukan perulangan untuk setiap file, kita mengantrekan fungsi untuk mengikatnya,

00:05:09lalu kita menunggu semuanya selesai. Bagian indahnya adalah kita tidak perlu memikirkan bagaimana pekerjaan itu

00:05:14didistribusikan ke seluruh core. Runtime Go menangani semua itu secara otomatis. Kita tidak perlu membuat thread baru atau

00:05:20mengelola komunikasi yang rumit antar core. Kita cukup berkata “ini ada pekerjaan” dan ia tahu cara menyelesaikan

00:05:26sisanya. Di JavaScript kita bisa menulis kode yang hampir identik, tetapi ini sia-sia untuk pekerjaan terikat CPU. Semuanya

00:05:32tetap akan berjalan pada satu thread secara berurutan, meskipun Promise memberikan ilusi paralelisme.

00:05:38Worker secara teknis adalah cara mengatasi ini, tetapi Anda tidak bisa berbagi objek di antara mereka, hanya byte mentah dengan

00:05:43SharedArrayBuffer. Jadi menyerahkan parsed syntax tree ke worker berarti melakukan serialisasi pada seluruh bagian,

00:05:48mencopy-nya, dan menyusunnya kembali di sisi lain. Untuk file besar, biayanya bisa lebih mahal daripada pekerjaan itu sendiri.

00:05:53Pada dasarnya hal-hal seperti inilah yang membuat Go secara inheren lebih baik untuk pekerjaan terikat CPU. Go memiliki

00:05:58runtime yang dapat menangani semua konkurensi ini untuk Anda dan memiliki memori terbagi sehingga Anda bisa melempar objek

00:06:03tanpa harus mencopy-nya. Sekarang selain waktu kompilasi, hal yang paling akan Anda rasakan

00:06:07adalah kecepatan server bahasa Anda. Siapa pun yang pernah bekerja di basis kode TypeScript yang besar pasti tahu

00:06:13rasanya menunggu pemeriksaan tipe, dan jujur saja, Mac berprosesor Intel benar-benar merasakannya. Saya ingat bekerja pada

00:06:20beberapa proyek beberapa tahun lalu dan ketika Anda membuka repositori, Anda benar-benar harus menunggu

00:06:24hingga dua menit hanya untuk melihat garis bergelombang merah muncul. Dan kemudian setiap kali Anda membuat perubahan,

00:06:29prosesnya terasa sangat menyiksa. Pengalaman pengembangnya sangat buruk dan tidak ada yang ingin

00:06:34mengerjakan basis kode tersebut. Namun server bahasa yang baru menghadirkan umpan balik instan di IDE Anda, jadi Anda dapat

00:06:40membuka file, membuat perubahan, dan melihat error hanya dalam hitungan milidetik, bahkan jika Anda mengerjakan

00:06:46basis kode yang sangat masif. Selain performa, server bahasa yang baru kini lebih stabil, jadi

00:06:51kebutuhan untuk merestart IDE saat pemeriksaan tipe mendadak berhenti bekerja telah berkurang drastis. TypeScript 7

00:06:57mengurangi kegagalan perintah server bahasa hingga lebih dari 80 persen dan mengurangi crash server hingga lebih dari 60 persen.

00:07:04Artinya lebih sedikit laptop yang dibanting ke dinding, yang sebenarnya cukup bagus untuk lingkungan. Jadi

00:07:08siapa yang menyangka Microsoft ternyata peduli dengan bumi? Perlu disebutkan juga bahwa ini adalah hasil porting,

00:07:13bukan penulisan ulang secara total. Tim TypeScript sangat berhati-hati untuk memastikan bahwa pengompil baru ini pada dasarnya

00:07:19sepenuhnya kompatibel dengan yang lama. Anda mungkin tidak akan menyadari perbedaannya kecuali pada kecepatannya. Namun

00:07:24meskipun sekarang Anda dapat menjalankan TypeScript 7 di proyek sendiri, Anda masih perlu menunggu paket favorit Anda

00:07:29menyusul. API programatis mereka masih belum ada, yang berarti paket apa pun yang bergantung padanya

00:07:35harus menunggu rilis versi 7.1. Jadi paket seperti typescript-eslint, ts-jest, atau ts-node akan

00:07:42tertinggal. Rilis penuh TypeScript 7 kini sudah tersedia untuk Anda unduh, tetapi Anda

00:07:47perlu menginstal ekstensi TypeScript 7 secara eksplisit untuk VS Code. Paket bawaan akhirnya akan

00:07:53diperbarui, tetapi untuk saat ini cukup instal ekstensi itu. Namanya TypeScript 7 di toko ekstensi, dan

00:07:58segalanya akan berjalan seperti yang diharapkan. Jika Anda ingin melihat lebih banyak tentang himpunan fitur TypeScript 7, kami telah

00:08:03membuat video tentang hal itu yang bisa Anda tonton di sini. Dan jika Anda menyukai ulasan seperti ini, silakan berlangganan

00:08:08Better Stack untuk konten lainnya. Semoga Anda mempelajari sesuatu di sini, dan sekarang Anda bisa memanfaatkan

00:08:12pengembangan cepat yang akan Anda dapatkan dengan TypeScript 7. Saya pribadi pasti akan sangat menikmati

00:08:16menggunakan versi ini. Terima kasih telah menonton, dan tentu saja sampai jumpa di video berikutnya.

Key Takeaway

TypeScript 7 mengalihkan pengompilnya ke bahasa Go untuk memanfaatkan seluruh core CPU dan memori terbagi, memangkas waktu kompilasi basis kode besar seperti VS Code hingga lebih dari 11 kali lipat.

Highlights

TypeScript 7 menggunakan pengompil berbasis Go yang menggantikan pengompil berbasis JavaScript tua.
Waktu kompilasi basis kode VS Code dengan 1,3 juta baris kode berkurang dari 125,7 detik menjadi 10,6 detik.
Proses kompilasi pada chip Apple M3 Max meningkat hingga 15 kali lipat dengan flag checkers 12, turun dari 45,3 detik menjadi 3,5 detik.
Go memanfaatkan memori terbagi (shared memory) dan seluruh core CPU tanpa overhead serialisasi data seperti pada JavaScript Web Workers.
Server bahasa baru mengurangi kegagalan perintah hingga lebih dari 80% dan menekan angka crash server hingga lebih dari 60%.

Timeline

Peluncuran TypeScript 7 dan Peningkatan Performa Utama

TypeScript 7 kini resmi dirilis melalui npm dengan pengompil berbasis Go.
Proses build basis kode VS Code yang mencakup 1,3 juta baris kode di 8.000 file membaik dari 125 detik menjadi 10 detik.
Pengompil baru difokuskan pada peningkatan performa tanpa mengubah himpunan fitur utama dari versi sebelumnya.

Pengembangan pengompil baru ini memakan waktu lebih dari satu tahun dengan porting ke Go. Hasilnya menunjukkan efisiensi tinggi pada proyek-proyek besar yang terdaftar di GitHub. Transisi ini memberikan dampak langsung pada kecepatan eksekusi build proyek pengembang.

Alasan Teknis di Balik Peralihan ke Bahasa Go

JavaScript dirancang untuk lingkungan UI dan browser single-threaded, sehingga kurang optimal untuk komputasi kompilasi yang intensif.
Go mengeksekusi kode terkompilasi langsung di CPU dan mengelola beberapa thread sekaligus dalam memori terbagi.
Kecepatan eksekusi Bluesky meningkat 8,7 kali lipat (24,3 detik ke 2,8 detik) dan Playwright meningkat 8,7 kali lipat (12,8 detik ke 1,5 detik).

Pemeriksaan tipe data dan Abstract Syntax Tree pada JavaScript terhalang batasan satu core CPU. Penggunaan Web Workers pada JavaScript memerlukan proses serialisasi dan deserialisasi data yang lambat serta boros memori. Bahasa Go menyelesaikan masalah ini dengan menjalankan native code di seluruh core CPU yang tersedia secara seimbang.

Optimasi Multi-Threading dan Hasil Pengujian pada Chip M3 Max

Pengompil Go secara bawaan membagi proses pemeriksaan tipe ke dalam 4 thread terpisah.
Penambahan flag checkers 12 menurunkan waktu pemeriksaan repositori VS Code dari 4,7 detik menjadi 2,9 detik.
Total waktu eksekusi tsc diagnostik pada chip M3 Max turun dari 45,3 detik di versi 6 menjadi 3,5 detik di versi 7.

Proses kompilasi membagi beban kerja ke seluruh core yang ada pada mesin pengembang. Pengujian langsung pada repositori VS Code menunjukkan bahwa sebagian besar durasi build dihabiskan pada tahap pemeriksaan tipe. Memaksimalkan jumlah checker thread memanfaatkan seluruh daya komputasi CPU untuk memangkas waktu tunggu secara signifikan.

Mekanisme Internal Go vs JavaScript Web Workers

Fungsi bind source files di Go mendistribusikan penentuan scope file ke seluruh core secara otomatis via runtime.
Eksekusi paralel di JavaScript menggunakan Promise tetap berjalan secara sekuensial pada satu thread untuk tugas CPU-bound.
Go mentransfer objek syntax tree antar thread tanpa perlu menyalin data berkat arsitektur memori terbagi.

Pengembang tidak perlu mengelola pembuatan thread atau komunikasi antar core secara manual di Go. Pada JavaScript, penggunaan SharedArrayBuffer untuk berbagi data antar worker membutuhkan konversi byte mentah yang memakan biaya komputasi lebih besar daripada tugas kompilasi itu sendiri. Runtime Go mengeliminasi hambatan tersebut secara inheren.

Peningkatan Stabilitas IDE dan Keterbatasan Ekosistem API

Server bahasa baru memberikan umpan balik kesalahan tipe dalam hitungan milidetik pada IDE.
TypeScript 7 menekan kegagalan perintah server bahasa sebesar 80% dan crash sebesar 60%.
Paket seperti typescript-eslint, ts-jest, dan ts-node memerlukan rilis API programatis di TypeScript 7.1.

Perbaikan pada server bahasa menghilangkan keterlambatan pemunculan indikator kesalahan yang sebelumnya bisa memakan waktu hingga dua menit pada basis kode besar. Meskipun pengompil baru ini kompatibel penuh dengan versi lama, pustaka pihak ketiga yang bergantung pada API programatis TypeScript harus menunggu pembaruan pada versi 7.1. Pengguna VS Code perlu menginstal ekstensi TypeScript 7 secara manual untuk menikmati fitur ini.

Community Posts

Write about this video