- Bir Google mühendisi, resmi standartlaştırma komitesine JavaScript’in iki dile bölünmesini öneren bir teklif sundu
- Çalışma zamanı motorunda uygulanacak çekirdek ile bunu derleyen araçlara dayanan, daha fazla özelliğe sahip bir varyanta ayrılması öneriliyor
- Sunum bu ayın başında yapılan Ecma TC39 toplantısında gerçekleştirildi
- TC39, JavaScript’in (resmi adıyla ECMAScript) spesifikasyonunu geliştiren Ecma International komitesidir
- Sunumu Google’dan Shu-yu Guo yaptı; slaytlar Mozilla, Apple, Moddable ve Sony’den ortak yazarlarla birlikte hazırlandı
- Shu-yu, JIT, VM, derleyici ve standardizasyon alanlarında uzman
- Yazarların iddiaları
- Dile eklenen yeni özellikler neredeyse her zaman güvenliği kötüleştiriyor ve performans üzerinde ya nötr ya da olumsuz etki yaratıyor
- Kararlılık da bazen kötüleşiyor; uygulama işlevselliği ise yalnızca geliştiriciler yeni özellikleri kullandığında artıyor
- JavaScript VM’leri (sanal makineler), hız baskısı nedeniyle zaten çok karmaşık hale geldi ve bu da güvenliği tehlikeye atıyor. Ayrıca yeni özellikler benimsenmediğinde bu durum özellikle daha da kötü görünüyor
- Güvenlik açıkları ve çalışma zamanının “karmaşıklık maliyeti” milyarlarca kullanımı etkilerken, faydalar yalnızca gerçekten bu karmaşıklıktan yararlanan geliştiriciler ve uygulamalarla sınırlı kaldığı için JavaScript’in temel teknolojisinin basit olması gerektiği savunuluyor
- Birden fazla kuruluş sürece dahil olsa da, bu girişim bir ölçüde Google öncülüğünde ilerliyor gibi görünüyor
- Slaytlardan birinde şu feragat notu yer alıyor: "Bu olası çözüm Google’ın tercih ettiği çözümdür ve diğer uygulayıcıların çözümü olmak zorunda değildir"
- Önerilen çözüm
- Mevcut özellikleri geri almak yerine, bundan sonra çoğu yeni özelliğin motor yerine araçlarda uygulanacağı bir yaklaşıma geçilmesi öneriliyor
- Motorda uygulanan dile "JS0", araçlarda uygulanan dile ise "JSSugar" adı veriliyor
- Birçok geliştirici zaten fiilen TypeScript ile kod yazdığı ve Babel, Webpack, TypeScript derleyicisi gibi derleyicilere güvendiği için bunun JavaScript’e özellikle uygun bir fikir olduğu belirtiliyor
- Kabul edilirse, gelecekteki sözdizimi özellikleri JSSugar’a; yalnızca API’ler ve işlevsel özellikler JS0’a gidecek
- Uyumlu motorların yalnızca JS0’ı desteklemesi yeterli olacak
- JSSugar desteği yükü araç geliştiricilerine aktarılacak
- Yan etki olarak, araç geliştiricilerinin standart sürece daha fazla dahil olması ve yeni bir teknik grup oluşturmaları gerekebilir
- Teklif şimdiden tartışmalı
- JavaScript araçlarına resmi statü verilmemesini isteyen geliştiriciler var ve birçok JavaScript geliştiricisi bu araçlara daha az bağımlı olmak istiyor
- Güvenlik, performans ve kararlılığa öncelik verilmesi konusunda geniş bir uzlaşı olsa da, JavaScript’i ara araçlara bağımlı hale getirme fikri popüler değil
- Bir geliştirici hatta "RIP Vanilla JS" dedi
GN⁺ görüşü
- Bu teklif, JavaScript geliştirme ekosisteminde büyük bir değişime yol açabilir. Geliştiricilerin yeni sözdizimi özelliklerini kullanmak için derleyicilere daha fazla bağımlı hale gelmesi endişe yaratıyor
- Ancak çalışma zamanı motorunun karmaşıklığını azaltma, güvenliği ve performansı iyileştirme hedefinin kendisi olumlu. Uzun vadede JavaScript’in gelişimine yardımcı olabilir
- Benzer bir yaklaşımı benimseyen başka bir dil olarak Dart örnek verilebilir. Dart, geliştirici dostu bir sözdizimi sunarken JavaScript’e derlenip tarayıcıda çalışır
- Bu teklif benimsenirken mevcut kodla uyumluluk, geliştirici deneyimi ve araç desteği gibi çeşitli etkenler dikkatle değerlendirilmeli. Ayrıca topluluğun görüşlerini yeterince toplama sürecine de ihtiyaç var
- JavaScript, web geliştirmenin temeli olan bir dil olduğu için, önümüzdeki dönemde de yoğun tartışmalar ve gelişmelerin sürmesi bekleniyor
4 yorum
Görünüşe göre bir katman daha ekleyip, o katmana DX'e yardımcı olacak içerikler eklemek istiyorlar.
Daha JSX örneğinde bile ekosistem transpilasyon gerektirecek şekilde kurulmuşken bunun gerçekçi olmayan bir görüş olduğunu düşünüyorum. Sanki NodeJS her şeymiş gibi geliyor.
Tam olarak doğru anlayıp anlamadığımı bilmiyorum ama C++'ta BOOST diye bir şey var; ona benzer bir his veriyor. Google'ın önerisi kabul edilip mevcut kütüphaneler JSSugar'a entegre edilirse, içine neler girer? Babel?
Hacker News görüşleri
Java'nın Hotspot VM'i diğer dillere büyük başarı getirdi. JavaScript'in de benzer şekilde çekirdek dili hedeflemesi ve sözdizimsel şekeri önceden derlemesi mantıklı
WebAssembly'ye odaklanmak daha iyi. JavaScript script yazımı için kullanılmalı, diğer diller ise daha büyük uygulamalar için kullanılmalı
VanillaJS tercih eden biri olarak, zorla değiştirilen dil özelliklerinden memnun değilim. Web uygulamalarının native uygulamalarla eşdeğer hale gelmesi için API iyileştirmelerine odaklanılmalı
BigInt için kullanım alanı olmadığı iddiasına katılmıyorum. Google'ın frontend geliştiricileri kullanmıyor olsa bile, diğer JS geliştiricileri kullanıyor. Dilin gelişimine odaklanılmalı
JavaScript ile Wasm ayrılmalıydı. Bunun yerine Wasm, web API erişimi olmayan ikinci sınıf bir vatandaş haline getirildi
Önerilen çözüm temel sorunu çözmüyor ve araçlara bağımlılık yaratıyor. JavaScript, performansı artırmak ve karmaşıklığı azaltmak için yeni bir dile geçmeli
TC39 ile geliştirici topluluğu arasındaki kopukluk sorunlara yol açıyor. TypeScript araçları standartlaştırılmadı ve Rust'a port etme planı da yok
Google'ın V8 motorunun bakım sorunları nedeniyle JavaScript değişiklikleri öneriliyor. Güvenlik sorunları ve karmaşıklık maliyeti kullanıcıları etkiliyor. C++ yerine başka bir dil denenmeli