10 kat daha hızlı TypeScript
(devblogs.microsoft.com)- Microsoft, derleyici ve araçların native ortama taşınmasıyla TypeScript performansının 10 kat artırıldığını duyurdu
- Editör açılış süresi büyük ölçüde iyileşiyor, build süresi 10 kata kadar kısalıyor ve bellek kullanımı ciddi biçimde azalıyor
tscönizleme sürümünün 2025 ortasına kadar yayımlanması, 2025 sonuna kadar da tam proje build’i ve language service sunulması planlanıyor
TypeScript performans iyileştirmelerinin arka planı
- TypeScript’in temel değeri, sunduğu üstün geliştirici deneyimi
- Kod tabanı büyüdükçe TypeScript’in değeri artıyor, ancak büyük ölçekli projelerde performans sorunları ortaya çıkıyor
- Uzun yükleme ve denetim süreleri yaşanıyor
- Hızlı editör başlangıcı ile tüm kod tabanını analiz etme arasında denge gerekiyor
- Yapay zeka tabanlı özellikler, hızlı ve doğru anlamsal bilgi sunulmasını gerektiriyor
- Komut satırı build’leriyle kod tabanının durumunu doğrulama ihtiyacı artıyor
Native porta geçiş planı
- TypeScript derleyicisi ve araçlarının native porta taşınması için çalışmalara başlandı
- Performans iyileştirme hedefleri:
- Editör açılış süresini büyük ölçüde kısaltmak
- Build süresini 10 kata kadar azaltmak
- Bellek kullanımını düşürmek
- 2025 ortası: komut satırından type checking yapabilen
tscönizleme sürümünün yayımlanması planlanıyor - 2025 sonu: tam proje build’i ve language service sunulması planlanıyor
Kodu çalıştırma ve test etme
- Kod, TypeScript Go kod deposu üzerinden build edilip çalıştırılabiliyor
- Depoda
tscve language server için build ve çalıştırma talimatları yer alıyor - Yeni özellikler hakkında düzenli güncellemeler paylaşılacak
Ne kadar hızlandı?
- Mevcut TypeScript projelerinin build süreleri çeşitli popüler kod tabanlarında test edildiğinde şu performans artışları görüldü:
- VS Code projesi, yaklaşık 1,5 milyon satır kodda 77,8 saniyeden 7,5 saniyeye düşerek yaklaşık 10,4 kat hızlandı
- Playwright projesi, yaklaşık 350 bin satır kodda 11,1 saniyeden 1,1 saniyeye düşerek yaklaşık 10,1 kat iyileşti
- TypeORM projesi, yaklaşık 270 bin satır kodda 17,5 saniyeden 1,3 saniyeye düşerek yaklaşık 13,5 kat iyileşti
- date-fns projesi, yaklaşık 100 bin satır kodda 6,5 saniyeden 0,7 saniyeye düşerek yaklaşık 9,5 kat iyileşti
- tRPC projesi, yaklaşık 18 bin satır kodda 5,5 saniyeden 0,6 saniyeye düşerek yaklaşık 9,1 kat iyileşti
- rxjs projesi, yaklaşık 2 bin satır kodda 1,1 saniyeden 0,1 saniyeye düşerek yaklaşık 11 kat iyileşti
- Henüz tüm özellikler tamamlanmış değil, ancak çoğu kod tabanında 10 katı aşan performans artışı bekleniyor
- Daha hızlı type checking ve kod gezinmesi mümkün hale geliyor
- Yapay zeka araçları entegrasyonu ve gelişmiş refactoring desteği mümkün olacak
Editör performansındaki iyileşmeler
- Editörün yüklenme ve yanıt verme hızı iyileşiyor
- Visual Studio Code kod tabanı baz alındığında yükleme süresi:
- Şu an: 9,6 saniye → native sürüm: 1,2 saniye (yaklaşık 8 kat iyileşme)
- Bellek kullanımı da yaklaşık %50 azalıyor
- Language service işlemlerinde (otomatik tamamlama, hızlı bilgi gösterimi, tanıma gitme vb.) performans artışı bekleniyor
- Language Server Protocol (LSP) tabanında geçiş çalışmaları sürüyor
Sürüm yol haritası
- TypeScript 5.8 yayımlandı, TypeScript 5.9 ise yakında çıkacak
- JS tabanlı TypeScript kod tabanı 6.x sürüm serisiyle geliştirilmeye devam edecek
- Native kod tabanı kararlı hale geldiğinde TypeScript 7.0 olarak yayımlanacak
- TypeScript 6 → JS tabanlı sürüm
- TypeScript 7 → native tabanlı sürüm
- TypeScript 7 yayımlandıktan sonra da 6.x sürümü bir süre daha desteklenecek
Sonraki adımlar
- Performans, derleyici API’si, LSP ve diğer konular hakkında ek bilgiler paylaşılacak
- Sık sorulan sorular için GitHub FAQ sayfasına bakılabilir
- 13 Mart 2025 tarihinde TypeScript topluluğu Discord’unda AMA düzenlenecek (PDT 10:00 | UTC 17:00)
24 yorum
Herkesin structural typing meselesini pek düşünmeden ortaya attığını hissettim.
C# ya da Rust gibi nominal typing kullanan bir dile yeniden yazmak için projenin temel yapısını fazlasıyla değiştirmek gerekeceğinden, bu da muhtemelen kolay olmazdı.
Structural typing benimseyen diller arasında mevcut JS tabanlı yapıya göre daha yüksek performans sağlayabilecek seçenek muhtemelen ya C++ ya da Go olurdu; ama üretkenliği de hesaba katınca başka bir alternatif yok.
Bir süredir TS ile daha az haşır neşir olmaya başlamıştım ama böyle bir haberi görünce yine ilgimi çekiyor doğrusu?
TS'te gerçekten kaçınılmaz durumlar dışında
any'yi gelişi güzel kullanırsan, vanilla kullanmaktan farksız olur.. hahaGörünüşe göre tartışma epey hararetli; Anders Hejlsberg bizzat yorum bırakmış.
https://github.com/microsoft/typescript-go/…
TypeScript ile derleyip çıktının doğrudan ikili dosya olarak gelmesini isteyen biri
Front-end konusunda yabancıyım da.. swc'den farklı mı?
SWC, Babel gibi uyumlu JavaScript kodu üretmeye ve paketlemeye odaklanırken, bu ise TypeScript kodunu JavaScript'e dönüştürmeye veya hataları kontrol etmeye odaklanıyor.
Buna "kendi yaptığını kullanmak" deniyor ya. Kendi yaptığın şeyi bizzat kullanmak. Ama konu bir dil olunca, insan biraz düşünüyor.
Bence, ts’nin temelini oluşturan js’in runtime’larının (ör. spidermonkey, v8) çoğu C++ ile yazılmış ve js ile gerçekleştirilmiş bir runtime da yok;
js -> js derlemede de pure js kullanınca aşırı yavaş kaldığı için herkes esbuild falan gibi araçlara geçiyorsa,
ts tarafında da ille de kendi yemeğini kendi pişirme yaklaşımında ısrar etmeye gerek var mı diye düşünüyorum
İleride mevcut TypeScript kod tabanının bakımının ihmal edilmesinden endişe ediyorum
Sevindirici bir haber! İlginç bir şekilde, MS'in TypeScript dili beklentilerin aksine gerçekten de oldukça beklenmedik(?) seçimler yapıyor gibi görünüyor. MS açısından bakınca bu neredeyse ilk açık kaynak projesi sayılır; ayrıca JS'yi değiştirmeye çalışan Google'ın Dart'ından farklı olarak JS'yi tamamlamayı seçmesi de gerçekten akıllıca hissettirmişti. Bu kez yerel porta çevrilen dil için de kendi dilleri epey fazla olmasına rağmen Google'ın Go'sunu seçmiş olması şaşırtıcı.
Ha? Deno tarafında zaten Rust tabanlı bir toolchain yapan bir şey vardı sanki... birdenbire Go mu oldu?
Sanırım Node gibi bir runtime'dan bahsediyorsunuz; ancak burada kastedilen, TS dilinin derleyicisinin kendisi.
Ah, yazıyı biraz daha okuyunca editörün hızlanması gibi şeylerden de bahsedildiği için kafam karışmış sanırım.
tsc10 kat hızlanmış. Yanits -> jstranspile süresi çok ciddi biçimde kısalmış.tsile geliştirilmiş büyük projeler yüklenirken hız çok artmış. Yanitsnin sözdizimi denetimi gibitscnin işlevlerini paylaşan mantığın hızlandığı anlamına geliyor.Demek istenen bunlarmış.
Özyinelemeli generik tipler kullanırken yavaşlama yüzünden alternatif bir yol seçmek zorunda kaldığım oldu. 10 kat ise bu tür noktaların da iyileşebileceğini umuyorum.
"Neden Go?" tartışma başlığı oldukça ilginç.
https://github.com/microsoft/typescript-go/discussions/411
Düşünülmesi gereken şeyler de çok...
Öyle yani, ama .NET geliştiricilerinin ne hissettiğini de anlayabiliyorum...
Dotnet ve Rust geliştiricileri epey öfkelenmiş görünüyor.
Dotnet anlaşılır ama bence Rust, Go ile aynı konumda. Muhtemelen mevcut olarak yapılmış JS ile ilgili Go projeleri ve kütüphaneleri de bu kararı etkilemiş gibi görünüyor.
C# diline yönelik geliştirme durmuş değil ama C# kullanan framework'lerin ihmal edildiği hissini çok sık alıyorum.
Go ile yazın~
Gerçekten çok heyecan verici.
Hacker News görüşleri
tscdenemesi yapan iki projeden bahsediliyorstc: durdurulduezno: aktif olarak geliştiriliyor vetscile bire bir uyumluluğu hedeflemiyor