Vue 3.6 sürüm adayı, sanal DOM olmadan özellik açısından tamamlanmış Vapor Mode'u sunuyor

Vue 6, sürüm adayı aşamasına girdi ve dev.to'da yayımlanan bir yazıya göre, bileşenleri güncellemeleri sanal DOM üzerinden yönlendirmek yerine doğrudan DOM işlemlerine derleyen render stratejisi Vapor Mode artık özellik açısından tamamlandı. Sürüm adayı temmuzda geldi; kararlı sürümün ise sonbaharda gelmesi bekleniyor.

Vapor Mode neyi değiştiriyor

Vapor Mode altında single-file component'ler, güncellemelerin düz DOM manipülasyonlarına çevrilecek şekilde derleniyor: bu elementin class'ını değiştir, şu attribute'u ata, şu belirli node'ları yamala. Sanal ağaç ve onu normalde uzlaştıran diffing aşaması tamamen atlanıyor. Bundle boyutları küçülüyor çünkü diffing için gereken runtime mekanizmasına artık ihtiyaç duyulmuyor; güncellemeler de hızlanıyor çünkü yalnızca gerçekten gereken işlemler yürütülüyor.

dev.to yazarının çerçevesi dikkat çekici: sanal DOM'un temel işi hiçbir zaman ham hız değildi — geliştiriciyi kolaylaştırmak için var, programcının bir view'ı state'in fonksiyonu olarak tanımlamasına ve minimal güncellemeleri hesaplama işini framework'e devretmesine olanak tanıyor. Diffing, bu kolaylığın bedeli. Vapor Mode'un iddiası şu: bir derleyici, bildirimsel yazım tarzını korurken, runtime'a yaslanacak bir şey olmasaydı bir geliştiricinin elle yazacağı türden hedefli güncelleme kodunu üretebilir.

Framework'süz tarayıcı oyunları yazmanın dersleri

Yazarın kanıtı sıra dışı bir yan projeden geliyor: kişisel bir sitede yayımlanan, elle inşa edilmiş bir dizi mantık oyunu — bir nonogram, üretilen gridleri bir çözücüyle doğrulayarak oyuncuların asla tahmine zorlanmadığı bir mayın tarlası türevi, numberlink, mastermind, birkaç yerleşik çözme yöntemi barındıran 3D bir Rubik küpü ve bir speedcubing kronometresi. Her oyun tek bir sayfa; ağır bağımlılıklar olmadan, framework kullanmadan, düz state ve doğrudan DOM manipülasyonuna dayanarak inşa edilmiş.

Üç ders öne çıkıyor. Birincisi, delta ile düşünün: nonogram hücresine bir tıklama tek bir hücreyi ve birkaç ipucu göstergesini değiştirir; doğru yanıt da tam olarak o yazma işlemleri ve başka hiçbir şeydir. İkincisi, agresif biçimde birleştirin: bir mayın tarlası flood-fill'i aynı anda düzinelerce hücreyi açığa çıkardığında, değişikliklerin tamamı düz JavaScript ile hesaplanıp tek geçişte uygulanır, böylece hiçbir DOM node'una gereksizce dokunulmaz. Üçüncüsü, ilginç işi state modelinde tutun: Rubik küpünün render katmanı yalnızca state'ini yansıtır hale geldiğinde, render olmayı bıraktı uygulamanın zor kısmı olmayı.

Yazar, bunun özünde Vapor Mode'un yaptığının elle yapılmış bir önizlemesi olduğunu, şu anda derleyicinin yaptığı işi bir insanın yaptığını savunuyor.

Kazançlar gerçekte nereye düşüyor

Yazı, tavan hakkında açık sözlü. Büyük gridler üzerindeki yüksek frekanslı, yerelleşmiş mutasyonlar doğrudan DOM güncellemeleri için en iyi senaryo. Formlardan ve tablolardan oluşan tipik bir uygulama o kadar seyrek yeniden render ediliyor ki sanal DOM'un ek maliyeti fiilen duyulmaz bile; bu tür uygulamalar için Vapor Mode'un ana kazancı daha keskin etkileşimler değil, daha küçük bir bundle — ve iki faydadan hangisinin sizin uygulamanız için önemli olduğunun netleştirilmesi değerli.

Bu disiplin genellenebilir de: bileşen state'ini DOM'dan ayrı tutmak, bileşenleri her render stratejisi altında hızlı kılan şeydir. Birbirine dolanmış state, bir framework'un önüne koyduğu her optimizasyonu etkisiz bırakır.

Neden önemli

Vapor Mode, bildirimsel framework'lerde ergonominin runtime maliyetiyle satın alındığı uzun süredir süregelen bir ödünleşmeyi daraltıyor. Cerrahi hassasiyette DOM güncellemeleri üreten bir derleyici, ergonomiyi korurken maliyetin önemli kısmını geri iade ediyor; bir zamanlar yalnızca elle yazılmış, düşük seviyeli koda ayrılmış bir tekniği sıradan bileşen kodunun varsayılan çıktısına dönüştürüyor. Önemli bir frontend framework'ünün bunu bir fork ya da deney olarak değil, desteklenen bir mod olarak teslim etmesi, standart runtime'ının görünümünde gerçek bir değişim.

Her zamanki sürüm adayı uyarısı geçerli. Özellik açısından tamamlanmış olmak kararlı olmak değildir; Vue'yu müşteri işlerinde günlük olarak kullanan yazar da kararlı sürüm gelene kadar 3.6'yı production projelerine dağıtmayacak. Kararlı sürüm gelse bile, elle yazılmış oyunlar framework'süz kalacak — kalıcılık ve güncelleme mantığını elle yazmanın keyfi için bilinçli bir tercih — ürün çalışması ise Vapor stabil olduğunda ona doğru ilerleyecek.