TypeScript'in Go'ya port edilmesi: Ne Anlama Geliyor?
TypeScript ekibinden geçen hafta oldukça heyecan verici bir haber geldi: TypeScript’in Go’ya port edilmesi. Bu haber epey konuşuldu ve ben de biraz kafa karışıklığı yaşadım açıkçası. Türkçe kaynak pek göremediğim için düşüncelerimi paylaşmak istedim.
Neden Port Ediliyor?
TypeScript, projelerdeki developer experience’ı (DX) artıran harika bir araç, ancak son zamanlarda en çok talep edilen özellik özellikle performans oldu. Özellikle proje boyutu büyüdükçe, TypeScript’in type-checking süresi artıyor. Bazen bir süre sonra language server’ı yeniden başlatmak zorunda kalıyorduk. Bu durum DX üzerinde olumsuz etki yapıyordu.
Bunun ana sebeplerinden biri, TypeScript compiler’ın TypeScript ile yazılmış olmasıydı. Bu durum iki soruna yol açıyor:
-
Tooling native olarak çalışmıyor; bunun yerine tsc, JavaScript’e transpile edilip Node üzerinde çalışıyor. Bu durumda performans olumsuz etkileniyor.
-
JavaScript’in dil olarak sahip olduğu limitasyonlar. JavaScript single threaded bir yapıya sahip; her ne kadar Web Worker gibi çözümlerle bu engel aşılmaya çalışılsa da, javascript genel olarak browserlari için optimize edilmiş bu yüzden bu sistem seviyesi veya cli toollarda faydası olmuyor.
Her ne kadar TypeScript ekibi inanılmaz yetenekli uzmanlardan oluşsa da, bu limitasyonların üstesinden gelmenin bir sınırı var ve TypeScript bu sınıra ulaştı.
Go Portunun Avantajları
Yeni tsc, Go ile yazıldığı için first-class concurrency ve parallelism sunuyor. Aynı zamanda, Go’nun native binary olarak compile edilmesi performansı artırıyor. Günün sonunda, bu portun amacı yalnızca performansı artırmaktır; TypeScript’in syntax’ı ve özellikleri aynı kalacaktır.
esbuild vs tsc: Fark Ne?
Birçok kişinin kafasını karıştıran sorulardan biri: esbuild varken neden Go ile yazılan tsc’ye ihtiyaç duyuluyor?
Kısa cevap: İkisi farklı amaçlara hizmet ediyor.
Uzun cevap ise; esbuild sadece transpile ve bundling işlemleri yapıyor. tsc ise bundling yapmaz; onun yerine daha fazla işlevi üstlenir. tsc, TypeScript’in language server’ını çalıştırır, type-checking yapar ve declaration file’larını oluşturur. Bu işlemler esbuild’te bulunmaz.
Aralarındaki farkı şu şekilde özetleyebiliriz:
Özellik | tsc | esbuild |
---|---|---|
Type Checking | ✓ | Sınırlı |
Declaration File Generation | ✓ | Yok |
Language Server | ✓ | Yok |
Bundling | Yok | ✓ |
Bu Değişiklik Nerede Hissedilecek?
Bu değişiklik TypeScript’in çalışma anındaki performansını etkilemiyor; developer experience’ı (DX) artırıyor. Büyük hatta ortalama boyutlardaki TypeScript projeleri çalışırken bilgisayara ağır yük bindiriyor. Type-checking süreleri uzayabiliyor veya language server’ın bazı özellikleri bir süre sonra çalışmıyor.
Aynı zamanda, modern dönemde dil özellikleri Microsoft tarafından geliştirilen Language Server Protocol (LSP) ile sağlanıyor. LSP’ler, yazıldıkları diller için standart IDE özelliklerini sunuyor; bu sayede IDE geliştiricileri LSP’leri kullanarak pek çok dile destek sağlayabiliyor.
Ancak, TypeScript’in resmi bir LSP’si yok ve mevcut üçüncü parti TypeScript LSP’leri sınırlı özellikler sunuyor. LSP yerine bu dil özellikleri doğrudan VSCode’a entegre edilmiş durumda, bu da farklı IDE kullanıcılarının TypeScript’in özelliklerinden tam olarak yararlanmasını engelliyor.
Bu port ile beraber resmi bir LSP sunulacak ve bu sayede hem VSCode hem de VSCode tabanlı olmayan diğer IDE’lerde TypeScript dil desteğinden tamamen faydalanılabilecek. Tüm bu değişikliklerle beraber editör performansı da artacak.
Geçiş Süreci Nasıl İşleyecek?
Geçiş süreci birçok kişinin kafasını karıştırmış durumda. Sürecin nasıl ilerleyeceğini özetlemem gerekirse:
- Go ile yazılmış tsc, TypeScript 7 sürümü ile birlikte çıkacak
- TypeScript 6(js) ve typescript 7(go) beraber yaşıyacaklar.
- Şu anda, public bir repository‘de kullanılabilir durumda
Bu sürümün ne zaman çıkacağı kesin olmasa da 2025 sonlarına doğru yayınlanacağını tahmin ediyorum. Yukarıda bahsettiğim giib şu anda, public bir repository’de kullanılabilir durumda, ancak henüz hazır bir binary bulunmuyor; dolayısıyla kendinizin compile etmesi gerekiyor.
Çoğu projenin sorunsuz bir şekilde TypeScript 7’ye geçmesi hedeflenirken, özellikle bazı legacy API’lere bağlı projelerde problem yaşanmaması için, typescript 6 js ile yazılmaya devam edecek. Bu şekilde projenizi typescript 6 ya upgrade edip ihtiyacınız olan özelliklerin go sürümüne gelmesini bekleyebilir geldiği zaman geçişi yapabilirsiniz yada tam tersi go sürümünde bulduğunuz bir hata veya eksiklik durumunda typescript 6 ya geçip devam edebilirsiniz.
“Neden Go da Rust Değil?”
Bu konuda da bir tartışma var tabii. Ben bu konuyu açıkçası pek umursamadım, ama merak edenler bu Reddit gönderisine bakabilir.
Bu değişiklik, TypeScript ekosisteminde önemli bir dönüm noktası olacak gibi görünüyor. Performans iyileştirmeleri ve daha iyi IDE desteği, TypeScript’in zaten güçlü olan developer experience’ını daha da ileriye taşıyacak.