JavaScript Geliştiricileri Parlak Paslı Araçlar Kullanıyor. İşte Nedeni.
Next.js 12 için kıyaslama sonuçları ikna edici. Ama geçiş yapmaya değer mi?
Son ekip oluşturma etkinliğimizde, JavaScript geliştiricilerinin araçlarını neden Rust'a taşıdıkları hakkında bir konuşma yaptım. Oldukça iyi karşılanan bir konuşmaydı ve bunu dünyayla paylaşmanın harika olacağına karar verdik. İşte burada. Bu, konuşmanın düzenlenmiş halidir, okunması için yazılmıştır ve Podcast kanalımızda bir ekran görüntüsü olacaktır. Öyleyse doğrudan içine dalalım.
Arka fon
Yazılımdaki yaygın bir eğilim, geliştiriciler olarak uygulamalarımızı oluşturmak için kullandığımız araçları, uygulama oluşturmak için kullandığımız dilde yazmaktır. Örneğin, pip Python'da yazılır, Composer PHP'de, Maven Java'da vb. Bu yüzden sadece seçtikleri dilde çalışmak daha kolay.
JavaScript bir istisna değildir. Gulp ve Bower'dan babel ve Webpack'e kadar hepsini JavaScript'te yazdık. Bu bizim için iyi çalıştı ama birkaç sorun vardı.
JavaScript ile İlgili Sorun
Sorunu görmek için JavaScript'in özelliklerine bakmalıyız. JavaScript, Web sayfaları için hafif, betik dilidir. Elbette artık arka uçlardan veritabanlarına kadar her yerde kullanıyoruz, ancak başlangıçta sayfaları önce parlak hale getirmek ve diğer her şeyi ikinci sırada yapmak için yapıldı, bu da gösteriyor.
Tam zamanında derlenebilen ve tek iş parçacıklı yorumlanmış bir dildir. Evet, evet, birden fazla örneği döndürmeyi ve web çalışanlarıyla iletişim kurmayı biliyorum... ama bence bu çoklu iş parçacığı değil, yerel çoklu iş parçacığına sahip olmadığımız gerçeğinden bizi uzaklaştırmaya çalışan garip bir vudu geçici çözümü .
Daha büyük bir sorun, diğer dillere kıyasla konsolda oldukça yavaş olmasıdır.
JavaScript bir sayfada harika olsa da, bir konsolda biraz berbat.
Bir gün bir grup JavaScript geliştiricisi karanlık bir odada bir araya geldi ve çok fazla içki içtikten sonra birisi şöyle dedi:
"Hey millet, ya... beni dinleyin... ya JavaScript'imizi oluşturan araçları JavaScript'te yazmazsak?"
Toplu bir soluklanma oldu, sandalyeler fırlatıldı, kavgalar çıktı ve ortalık yatıştıktan sonra herkes denemeyi kabul etti.
Tamam, bunu uydurmuş olabilirim ama sonuç yine aynı, artık JavaScript dışındaki dillerde JavaScript oluşturma araçları yapıyoruz.
Ama Neden Rust?
Tek kelimeyle… hız ve arabellek taşmaları .
Rust, performans ve güvenlik için tasarlanmış çok paradigmalı, genel amaçlı bir programlama dilidir. C++ gibi ama Y kuşağı ve zum yapanlar için. Bellek güvenliğini zorlayan ve "güvenli" eş zamanlılığa sahip bir sistem dilidir. Sözdizimsel olarak C++'a benzer ve daha da önemlisi, neredeyse C++ kadar hızlıdır.
Umut Verici Talepler
JavaScript araçlarını Rust tabanlı araçlarla değiştirmeye çalışan çok sayıda proje var. ParcelJS, Deno, ESBuild ve Speedy Web Compiler (SWC) birkaç örnektir. Hepsi, değiştirmeye çalıştıklarından daha hızlı performans gösterdiklerini iddia ediyor ve kıkırdamak istiyorsanız esbuild karşılaştırmasına bakın .
Bu yazı için hepsini kontrol etmeyeceğim ama Next.js aracılığıyla SWC'ye daha yakından bakacağım.
Hızlı Web Derleyicisi (SWC)
SWC, yeni nesil hızlı geliştirici araçları için genişletilebilir Rust tabanlı bir platformdur. Bu, inşaatçılar oluşturmak için bir çerçeve olduğu anlamına gelir. SWC'yi hem derleme hem de paketleme için kullanabilirsiniz. Modern JavaScript özelliklerini kullanan JavaScript / TypeScript dosyalarını alacak ve tüm büyük tarayıcılar tarafından desteklenen geçerli kodu tükürecektir.
En Yeni Next.js Rusty araçları
Next.js, SWC'ye dayalı olarak sürüm 12'de bir Rust derleyicisi tanıttı. Next.js sitesinde yerel olarak ~3 kat daha hızlı yenileme ve ~5 kat daha hızlı üretim kurulumları olduğunu iddia ettiler.
Bu bana test edilebilir bir iddia gibi geldi. Ben de test ettim.
Aynı projeyi sürüm 11 ve 12'de oluşturdum ve oluşturulan aynı 400 bileşeni ekledim. Bunun için React Benchmark Generator kullandım . Projeler arasındaki tek fark Next.js versiyonuydu, geri kalan her şey aynıydı.
Sonuçlar oldukça inandırıcıydı. İşte Next.js 11 için:
Ve Next.js 12 için işte:
Next.js 12, Next.js 11'in 1 dakika 40 saniyede yaptığını yapmak 12 saniye sürdü. Bu kabaca 8 kat daha hızlı. Yani kesinlikle abartmıyorlardı.
Next.js 12'nin 12 saniye sürmesini de beklemiyordum. Sanırım bu mutlu bir tesadüftü.
Heyecana Değer mi?
Şimdi bariz soru şu: acele etmeye değer mi?
Günün sonunda inşa ettiğimiz uygulama aynı değil mi? Bu, son kullanıcı deneyimini değiştirmez, yalnızca geliştirici deneyimini değiştirir, öyleyse neden rahatsız edesiniz? Zaten iyi çalışan bir şeyi neden düzeltelim?
Çünkü iyi çalışmıyordu. Daha önce de söylediğim gibi, JavaScript bir sayfada harika ama bir konsolda berbat. Geliştirici makineler güçlü canavarlardır ve bu gücü kullanmamak korkunç bir israftır. Aynı zamanda pahalı bir atıktır.
Bulut tabanlı bir CI üzerinde dağıtılan ve test edilen büyük bir proje üzerinde çalışan 20 geliştiriciden oluşan bir ekipte olduğunuzu hayal edin. Ekibinizin her bir üyesi her gün birden çok düzeltme ve özellik yayınlıyor, işte büyük ihtimalle şunlar olacak.
CI'niz sınırsız eşzamanlı derlemeler veriyorsa ancak derleme dakikasına veya işlemci süresinin saniyelerine göre ücret alıyorsa, Next.js size tam anlamıyla Next.js 12'den 8 kat daha pahalıya mal olacaktır.
Öte yandan, sabit bir fiyat ve sabit sayıda eşzamanlı derleme veriyorsa, derleme sıranız büyürse bir süre beklersiniz veya çalıştırabileceğiniz eşzamanlı derleme sayısını artırmak için ödeme yapmanız gerekir.
Her iki durumda da, yavaş derlemeler size zaman, para veya her ikisi açısından daha fazla mal olur.
Çözüm
JavaScript harika bir dildir ve internet onsuz olmazdı. Ancak araçlarımızı oluşturmak için onu kullanmak zorunda değiliz çünkü bunun için Rust gibi daha zor, daha iyi, daha hızlı, daha güçlü diller var ve sorun değil. JavaScript'ten uzaklaşmaz ve daha hızlı Rust tabanlı olanlar için JavaScript tabanlı yerleşik araçları bırakmak ihanet değildir. Ve kabul edelim ki, sadece voodoo multi-threading elde etmek için birden fazla JavaScript örneğiyle uğraşmayacağım.