JavaScript araçlarını "daha hızlı bir dile" yeniden yazmaya dair şüpheci bir bakış

• Son dönemde Node.js araçlarını Rust, Zig, Go gibi daha hızlı dillere yeniden yazma eğilimi endişe verici görünüyor; buna dair nesnel kaygılar derlenmiş durumda

[Performans]

• JavaScript araçlarını hızlandırma konusunda henüz keşfedilmemiş pek çok imkan olduğu düşünülüyor
• ESLint, Tailwind gibi araçlarda kolayca iyileştirilebilecek çok sayıda nokta var
• Tarayıcıda JavaScript, çoğu iş yükü için "yeterince hızlı"
• CLI araçlarında ise neden JavaScript'ten vazgeçilmeye çalışılıyor?

Kapsamlı yeniden yazım

• Uzun süre boyunca JavaScript araç ekosistemi "çalışan bir şey" üretmeye odaklandı
• Artık API'lerin çoğu oturmuş durumda ve herkes "aynı şeyi, daha hızlı" istiyor
• Performans düşünülerek yeniden yazıldığı ve API zaten belirlenmiş olduğu için geliştirme süresinden tasarruf edildiğinden, yeni araçlar daha hızlı olabilir
• A'dan B'ye yeniden yazınca hız artışı görülmesi, B'nin A'dan daha hızlı olduğunu iddia etmeyi kolaylaştırır
• Ancak bunun nedeni yeniden yazımın kendisi de olabilir (çünkü ikinci seferde daha çok şey bilinir ve performansa daha fazla dikkat edilir)

Bytecode ve JIT

• Tarayıcıda doğal kabul edilse de bytecode önbelleği ve JIT (Just-In-Time derleyici) avantajlarından yararlanılır
• JavaScript doğru şekilde önbelleğe alınırsa, tarayıcının kaynak kodu bytecode'a parse edip derlemesi gerekmez
• Sık çalıştırılan fonksiyonlar makine koduna daha iyi optimize edilir (JIT)
• Node.js betikleri ise bytecode önbelleğinden hiç yararlanamaz
• Ancak artık Node'da da derleme önbelleği kullanılabiliyor (NODE_COMPILE_CACHE ortam değişkeni ayarlanarak)
• JIT'in fayda sağlaması için bir fonksiyonun birkaç kez çalışıp "ısınması" gerekir; bu yüzden tek seferlik betiklerde yararı sınırlıdır
• Pinafore'da JavaScript tabanlı blurhash kütüphanesini Rust (Wasm) sürümüyle değiştirme girişiminde, 5. yinelemede performans farkı ortadan kalkıyor
• Porffor gibi araçlarla Node betiklerini AOT derlemeyi düşünmek mümkün olabilir
• Wasm kullanıldığında saf native araçlara kıyasla performans kaybı yaşanır

[Katkı ve hata ayıklama kolaylığı]

• Asıl şüphecilik, "her şeyi native olarak yeniden yazma" hareketine yönelik
• JavaScript; esnek tip sistemi, öğrenmesinin kolay olması ve tarayıcı desteği nedeniyle popüler bir dil
• Uzun süre boyunca JavaScript ekosisteminde hem kütüphane yazarları hem de kullanıcılar JavaScript kullandı
• Bu da katkı yapma eşiğini düşürmeye yardımcı oldu
• Ancak JavaScript kütüphane yazarları başka dillere geçtiğinde bu avantaj bozuluyor
• Ayrıca JavaScript bağımlılıklarını yerelde düzeltmek basittir (doğrudan node_modules içinde değiştirilebilir)
• Buna karşılık native bir dille yazıldığında kaynak kodunu ayrıca çekip derlemek gerekir
• JavaScript kütüphanelerini hata ayıklarken alışıldık tarayıcı geliştirici araçları veya Node.js debugger'ı kullanılabilir
• Wasm'da da hata ayıklama imkansız değildir, ancak farklı bir teknik yetkinlik seti gerektirir

[Sonuç]

• JavaScript ekosistemi için yeni nesil araçların ortaya çıkması olumlu bir gelişme
• Mevcut araçların bazıları gerçekten çok yavaş ve rekabetten fayda görecek gibi duruyor
• Ancak JavaScript'in doğası gereği yavaş olduğu ya da artık geliştirilemeyeceği düşünülmüyor
• Chromium geliştirici araçlarındaki son iyileştirmeler, hâlâ gidilecek çok yol olduğunu düşündürüyor
• Dünyanın yalnızca Rust ve Zig geliştiricilerine ait hale gelmesi endişe verici
• Ortalama bir JavaScript geliştiricisi, build aracı hatalarıyla karşılaştığında kendini çaresiz hissedebilir
• Bu, genç web geliştiricilerine öğrenilmiş çaresizlik öğretmek anlamına gelebilir
• Bu, bilinmeyen bir yola girmek olur ve istenmeyen sonuçlar doğurabilir
• Oysa daha az riskli olup neredeyse aynı sonucu verebilecek başka bir yol da var
• Ancak mevcut eğilimde yavaşlama işareti görünmüyor

GN⁺ görüşü

• Rust veya Zig gibi dillere yeniden yazmak her zaman en iyi seçenek olmayabilir. Compile cache gibi alanlarda JavaScript tarafında hâlâ iyileştirme payı var gibi görünüyor
• Yeni başlayan geliştiricileri segfault gibi karmaşık sorunlarla karşı karşıya bırakmanın ne kadar doğru olduğu tartışmalı; hatta bu sadece çaresizlik hissi de öğretebilir
• Uzun yıllardır JavaScript ile kurulmuş ekosistemin avantajlarını (kütüphaneler arasında serbestçe değişiklik yapabilme, alışıldık hata ayıklama ortamı vb.) hız uğruna feda etmenin doğru yön olup olmadığı iyi düşünülmeli
• Mevcut JavaScript kütüphanelerini iyileştirme çabaları da sürmeli. JavaScript'in potansiyeli henüz tamamen keşfedilmiş değil
• Eğilim tersine çevrilemez gibi görünse de, bu yönelim hakkında topluluk düzeyinde daha ciddi tartışma ve değerlendirmeye ihtiyaç var

[labeldock]

Küçük işletmelerle büyük mağazaların çalışma biçimleri biraz farklı olabilir. Değişimin kendisine eleştirel yaklaşmaktansa, bu olgunun ne anlama geldiğini düşünmenin daha sağlıklı bir yaklaşım olduğunu düşünüyorum.
Tercihlere ya da modaya kapılıp değiştiriliyormuş gibi görünebilir, ama şirketler genelde kararlarını öyle vermiyor, değil mi?

[ndrgrd]

Python ya da JavaScript’in kendisi yavaş mı? Buna evet demek zor olsa da
Sık kullanılan Python veya JavaScript tabanlı araçlar yavaş mı? Buna cevabım evet.
Düşük güçlü birden fazla cihaz kullanıyorum ve insanı gerçekten çileden çıkaracak kadar yavaş araç çok fazla..

[youknowone]

Python topluluğu tarafında da neredeyse aynı söylem tekrarlanıp duruyor.

JavaScript, JavaScript ile yazılmamış olsa da JavaScript geliştiricilerinin çoğu bunu umursamıyor. "Acemi geliştiriciler" ve "genç web geliştiricileri" için JavaScript'in JavaScript ile yazılmamış olması sorun değilken, JavaScript geliştirme araçlarının JavaScript ile yazılmamış olmasının sorun sayılması çok da tutarlı bir argüman değil. Hatta buna kafa yoran geliştiriciler, iki grubun da içindeki çok küçük bir azınlıktan ibaret.

Yeterli optimizasyonla neredeyse benzer hızlara ulaşılabildiği gerçeğini inkâr etmesek bile, gerçekten buna değer mi?
Eskiden geliştirme araçlarını C++ yerine JavaScript ile yazmanın daha ekonomik olduğu bir dönem vardı; şimdi ise JavaScript ile yazmaktansa Rust ile yazmanın daha ekonomik olduğu bir döneme geçiyoruz.
Bu akışı tersine çevirmenin yolu, daha fazla maliyet harcayıp JavaScript için optimizasyon seferberliği başlatmak değil; daha düşük geliştirme maliyetiyle de verimli JavaScript araçları geliştirilebilmesini sağlamak. (Benzer bir şey söyleniyormuş gibi görünebilir ama fark, çabanın nereye harcandığında yatıyor.)

[savvykang]

Katılıyorum. Verimliliği araç geliştiricileri yerine araç kullanıcıları merkezli olacak şekilde yeniden tanımlamamız gerektiğini düşünüyorum.

Şimdiye kadar verimlilik, araç kullanıcılarından çok araç geliştiricilerini dikkate alan bir ölçüt değil miydi diye düşünüyorum. Araç kullanıcılarının yaşamak zorunda kaldığı verimsizlik ve performans sorunları, öncelik sıralamasında görece geri plana itilmiş gibi geliyor. Ben şahsen uv ve vite'ı severek kullanıyorum; mümkünse pip ya da create-react-app gibi araçlardan kaçınmak isterim.

[click]

CLI araçlarının bir runtime olmadan çalışabilmesi gerektiğini düşündüğüm için buna katılmam zor.
WASM ile bağımsız çalıştırılabilir dosya yapılamaz mı denirse, metinde de söylendiği gibi performans kaybı olacaktır.
Java ile CLI yazmak yaygın olmadığı gibi, JavaScript için de aynı durumun geçerli olduğunu düşünüyorum.

[savvykang]

Yazarın, hem SPA hem de JavaScript araç geliştirmede JavaScript kullanıldığı için bunun dışında gereken ilgili yetkinliklerin de aynı olduğunu sandığı görülüyor. Bence JavaScript araçları için sistem programlama ve derleyici alanlarında yetkinlik gerekiyor.

---

> Uzun zamandır JavaScript ekosisteminde hem kütüphane yazarları hem de kullanıcılar JavaScript kullanıyordu
> Bu, katkı eşiğini düşürmeye yardımcı oluyordu
> Ancak JavaScript kütüphane yazarları başka bir dil kullandığında bu durum bozuluyor

Dil aynı olsa bile çalışma ortamı tarayıcı ve NodeJS olarak farklı; bu farkı aşabilen kişiler ancak JavaScript araçlarına katkı sunabilir. Çalışma ortamları farklı olduğuna göre buna ayrı ekosistemler demek gerekmez mi?

---

> Ortalama bir JavaScript geliştiricisi, bir build aracı hatasıyla karşılaştığında kendini çaresiz hissedebilir
> Bu, genç web geliştiricilere öğrenilmiş çaresizlik öğretmek anlamına gelebilir

Bence bu da aynı şekilde, SPA geliştirme ile JavaScript araç geliştirme arasındaki sınırı aşabilen kişi sayısını fazla tahmin eden bir nokta. Frontend geliştiriciden sistem programlamaya yakın düzeyde bilgi beklemek gerçekçi değil. Araç kullanıcıları en fazla yüzeysel hata mesajlarını ya da görünen semptomları anlayabilir, değil mi? Bunun sadece dili bilmekle çözülebilecek bir mesele olduğunu düşünmüyorum.

[regentag]

Sanki araçlar ve kütüphaneler birbirine karıştırılıyor gibi. Kütüphaneler konusunda bir noktaya kadar katılabilirim ama araçlar için, emin değilim..
Diğer dil geliştiricileri de araçların native olarak yazılmış olmasına alışkındır diye düşünüyorum.

[ragus]

Bana kalırsa, ister bir araç ister bir kütüphane olsun, eğer JavaScript ile yazılmışsa JavaScript’e aşina geliştiriciler bunlarda hata ayıklayabilir ve gerekirse katkıda bulunabilir. Ama Rust ile yeniden yazıldığında, açık kaynak katkıları fiilen yalnızca Rust geliştiricilerinin yapabileceği bir şeye dönüşüyor. JavaScript geliştiricilerinin havuzu Rust’a kıyasla ezici biçimde daha büyük olduğu için, açık kaynak ekosisteminde ister araç ister kütüphane olsun, bunların JavaScript ile yazılması daha avantajlı olabilir.

[savvykang]

JavaScript, tarayıcı ve NodeJS arasında çalışma ortamı bakımından parçalanmış durumda; bu yüzden dil kullanıcı sayılarının basit bir karşılaştırmasının argüman olarak sınırlı olduğunu düşünüyorum. Backend Spring geliştiricileri ile JDK geliştiricilerinin, React/Angular/Vue geliştiricileri ile JavaScript araç geliştiricilerinin ilgi alanları ve konumları farklı; aralarında tüketici ve üretici ilişkisi var

JavaScript araçlarının performansını ve kullanılabilirliğini iyileştirme hedefi için, bir araç olan uygulama dilini değiştirmek de bence değerlendirilebilecek seçeneklerden biridir

[unqocn]

Bence geliştirme araçlarının tüketicileri ile üreticilerini net biçimde ayırmak zor. Şirket büyüdükçe, araç zincirini kendi istedikleri kurallara göre özelleştirme ya da ek eklentiler geliştirme durumu çok sık görülüyor; bu durumda aynı dili kullanmanın tek başına bile büyük bir avantaj olduğunu düşünüyorum.
Aracın kullanıcılarının, aracın kendisindeki iyileştirmelerle ya da implementasyonuyla ilgilenip doğal biçimde katkı sunmaya başlaması da oldukça sık görülen bir durum.

[savvykang]

Toolchain özelleştirmeyle ilgilenmeye başlayan ya da bu işi yapan kişilerin, tüketici rolünü aşarak prosumer hatta üretici rolünü üstlendiğini düşünüyorum. Eklenti söz konusu olduğunda ise bunun üretici ile tüketici arasındaki eklenti sözleşmesi içinde işlediğini düşünüyorum. Bu durumda aynı dili kullanmanın, ayrı bir yapılandırma dosyası biçimi ya da genişletme noktaları sunmaktan hem teknik açıdan hem de iletişim maliyeti açısından daha faydalı olduğuna ben de katılıyorum

Ancak JavaScript araçlarının performans sorununun ya da NodeJS'in JIT gecikmesi sorununun tüketicinin karar verme alanına girdiğini düşünmüyorum. Çünkü bu mimariyi ve çalışma spesifikasyonlarını oluşturanlar, araç üreticileri ve çalışma zamanı geliştiricileridir.

[passerby]

JavaScript ekosisteminin büyük olması, derleyici / transpiler kod tabanlarına katkı sunabilecek geliştirici sayısının da daha fazla olacağı anlamına geliyor mu, bundan şüpheliyim. Kütüphane framework'leri ile temel araçların tamamen farklı alanlar olduğunu düşünüyorum.

[aer0700]

Ama yeniden yazmanın kendisi daha hızlı olmasının nedeni olabilir -> Geriye dönüp bakınca bunun gerçekten çok doğru bir söz olduğunu görüyorum...

[coremaker]

Çok seçici olduğu için bu kişinin söylediklerine katılıyorum.
Ancak, başka bir açıdan bakıldığında JS dışında da çeşitli çözümlerin var olması teknolojik ilerleme açısından çok önemli bir unsur; bu yüzden bunun tersi durumun da saygı görmesi gerektiğini düşünüyorum!

[GN⁺]

Hacker News görüşleri

• JavaScript'in doğası gereği yavaş olduğu yönünde bir görüş var. Birçok mühendis bunu hızlandırmak için uğraştı, ancak hâlâ statik tipli dillere göre daha yavaş. Büyük ölçekli programlarda tiplerin açık olduğu diller daha uygun

  • Rust ve Go araç geliştirme için uygun; prototipler TypeScript ile yapılabilir ama büyük ölçekli eşzamanlılık işleri için başka diller kullanmak daha tercih edilir
  • Rust'ın tip sistemi araç geliştirmede güven verirken, Go'nun tip sisteminin geliştirilmesi gerektiği düşünülüyor

• JavaScript öğrenmesi kolay bir dil değil; karmaşık bir prototip ve tip sistemine sahip. TypeScript bunu telafi etse de hâlâ karmaşık

  • JavaScript ekosistemi karmaşık ve araçlarını kullanmak zor. Go ise öğrenmesi kolay ve araç kullanımı basit
  • JavaScript'te eşzamanlılık uygulamak için karmaşık kavramları anlamak gerekiyor

• Sadece dili değiştirmek bile performansı büyük ölçüde artırabilir. Mevcut bir sistemi JS ve PHP'den Go'ya taşıdıklarında 8-10 kat performans artışı yaşandığı belirtiliyor

• Paralel işlemenin önemi göz ardı ediliyor. Rust paralel kod yazmaya uygunken, JS paralel kod yazmak için uygun değil

  • Rust thread safety sağlayarak bakım sorunlarını azaltıyor

• JavaScript artık Java'ya benzer hızlarda ve C++'tan 2-4 kat daha yavaş. Performansı artırmak için konfor alanından çıkmak gerekiyor

  • Geliştiricilerin performansa verdiği tepkiler o kadar uç noktalardaydı ki başka bir mesleğe geçildiği söyleniyor

• Rust, Zig ve Go programlarında kaynak kodunu incelemek ve derlemek kolay. Yeni bir dil öğrenmek, problemlere yaklaşım biçimini etkiliyor

• JavaScript araçlarının performansını artırma konusunda henüz tüm olasılıkların tüketilmediği düşünülüyor. Yine de daha iyi bir temel üzerine inşa etmek daha verimli

• Rspack, Rust ile yazılmış ve Webpack ile uyumlu bir yeniden yazım; performansı 5-10 kat artırıyor. Webpack'in yerine kolayca kullanılabiliyor

• JavaScript bağımlılıklarını yerelde yamamak kolay, ancak Rust'ta hata daha az olduğu için buna daha az ihtiyaç duyuluyor. Rust öğrenmesi zor olsa da, insanı diğer dillerde de daha iyi bir programcı yapabiliyor

  • Hızdan çok doğruluk daha önemli; hatalı bir kütüphane yayımlamak kullanıcıların zamanını boşa harcar