Vue 3.6 akan melancarkan Vapor Mode pada musim luruh ini, dan ia melakukan sesuatu yang tidak pernah dilakukan oleh rangka kerja ini sebelum ini: ia mengkompil komponen fail tunggal (single-file components) terus kepada kemas kini terus-ke-DOM, dengan memintas sepenuhnya virtual DOM.

Mengapa Vue mula meninggalkan virtual DOM

Sejak Vue 2, virtual DOM telah menjadi teras kepada model reaktiviti rangka kerja ini. Apabila keadaan (state) berubah, Vue membina pokok dalam memori yang ringan, membandingkannya (diffs) dengan versi sebelumnya, dan menampal (patches) hanya bahagian yang berbeza. Ketidaklangsungan (indirection) ini membolehkan pembangun menulis kod deklaratif tanpa perlu risau tentang elemen mana yang sebenarnya perlu dikemas kini. Kesan sampingannya ialah setiap render masih menanggung kos pembinaan dan perbandingan pokok maya tersebut.

Vapor Mode menghapuskan langkah tengah tersebut. Semasa proses binaan (build), pengkompil Vue menganalisis templat dan menghasilkan JavaScript yang memanggil kaedah DOM asli—element.textContent = …, element.setAttribute(...)—secara terus di tempat perubahan diperlukan. Tiada nod maya dicipta, tiada gelung perbandingan (diffing loop) dijalankan. Bundle tersebut akhirnya hanya mengandungi kod yang diperlukan untuk kemas kini konkrit yang anda tulis, ditambah dengan runtime yang diperlukan untuk reaktiviti.

Impak dunia nyata terhadap saiz dan kelajuan

  • Saiz bundle – Dengan membuang runtime virtual-DOM dan struktur datanya, kod yang dihasilkan menjadi lebih kecil. Dalam projek dengan grid atau kanvas besar yang dikemas kini berpuluh-puluh kali sesaat, penjimatan tersebut akan terkumpul, terutamanya pada sambungan jalur lebar rendah.
  • Prestasi – Panggilan DOM secara terus melangkau beban kerja perbandingan (diffing overhead), yang menjadi ketara apabila UI berubah pada frekuensi tinggi. Dalam satu set permainan pelayar peribadi—sebuah nonogram, klon minesweeper, dan visualisator kiub Rubik 3-D—saya menulis logik rendering secara manual, dengan mengemas kini DOM hanya apabila perlu.
  • Ergonomik pembangun – Pengkompil melakukan kerja berat tersebut. Anda masih menulis templat Vue biasa; anda tidak perlu menulis panggilan document.querySelector secara manual. Kod yang dihasilkan mencerminkan pendekatan penulisan manual yang memberikan prestasi terbaik dalam permainan tersebut.

Bilakah Vapor Mode benar-benar membantu

  1. Kemas kini frekuensi tinggi pada struktur besar – Permainan, papan pemuka (dashboard) intensif data, atau mana-mana antara muka yang melukis semula banyak sel pada setiap kitaran (tick) akan mendapat manfaat paling besar. Membandingkan grid besar pada setiap kitaran boleh mendominasi bajet bingkai (frame budget); kemas kini terus memastikan kerja tersebut bersifat linear dan boleh diramal.
  2. Penyebaran dengan kekangan saiz bundle – Laman web berorientasikan mudah alih yang mesti dimuatkan di bawah beberapa ratus kilobait akan melihat pengurangan yang nyata apabila runtime virtual-DOM hilang.
  3. Keadaan (state) yang tulen dan boleh diramal – Vapor Mode mengandaikan anda mengekalkan state sebagai tidak boleh diubah (immutable) dan melayan DOM sebagai unjuran tulen bagi state tersebut. Jika kod anda mencampurkan kesan sampingan (side-effects) atau mengubah suai DOM di luar sistem reaktiviti Vue, kemas kini yang dihasilkan boleh menjadi tidak selaras, menyebabkan gangguan visual.

Di mana pendekatan lama masih menang

  • UI frekuensi rendah – Borang ringkas, halaman statik, atau panel pentadbir yang hanya dikemas kini semula melalui tindakan pengguna sekali-sekala tidak mendapat banyak peningkatan prestasi. Kerja tambahan untuk membina pokok maya adalah kecil berbanding kependaman rangkaian (network latency) atau masa pemprosesan pelayan.
  • Hierarki komponen yang kompleks – Apabila pokok yang dalam hanya mengubah satu nod daun (leaf node), virtual DOM boleh melangkau bahagian besar secara automatik. Kemas kini terus memaksa pengkompil untuk menghasilkan tampalan (patches) yang tepat bagi setiap kemungkinan perubahan, yang boleh meningkatkan saiz kod dalam kes-kes tertentu (edge cases).
  • Peralatan dan ekosistem – Banyak plugin Vue, devtools, dan utiliti ujian disambungkan ke lapisan virtual-DOM. Integrasi tersebut mungkin memerlukan kemas kini untuk berfungsi dengan komponen Vapor-mode sehingga ekosistem tersebut dapat menyesuaikan diri.

Apa yang perlu diperhatikan seterusnya

  • Pelepasan stabil – Vue 3.6 kini dalam status calon pelepasan (release-candidate). Pasukan merancang pelancaran stabil akhir pada musim luruh ini. Pengguna awal harus menunggu versi tersebut sebelum melancarkan kod pengeluaran (production code).
  • Laluan migrasi – Projek Vue sedia ada boleh memilih untuk menggunakan Vapor Mode berdasarkan komponen.
  • Peralatan prestasi – Penanda aras (benchmarks) yang membandingkan binaan virtual-DOM dan Vapor-mode pada aplikasi dunia nyata akan membantu pasukan memutuskan sama ada pertukaran tersebut berbaloi.

Kesimpulan

Vapor Mode memberikan pembangun Vue yang terbaik daripada kedua-dua dunia: sintaks deklaratif yang mereka gemari dan kelajuan mentah kemas kini DOM yang dibuat secara manual. Ia sangat menonjol untuk aplikasi yang menyegarkan bahagian besar UI berkali-kali dalam sesaat dan untuk deployment di mana setiap kilobait amat bermakna. Bagi antara muka trafik rendah, virtual DOM tradisional kekal sebagai pilihan yang lebih ringkas dan sangat praktikal. Apabila ciri ini beralih daripada release candidate kepada stabil, komuniti Vue perlu menimbang penjimatan saiz bundle berbanding kesediaan ekosistem dan profil prestasi khusus aplikasi mereka.