Vue 3.6 चा आगामी Vapor Mode या शरद ऋतूत (autumn) उपलब्ध होईल, आणि तो असे काहीतरी करेल जे या फ्रेमवर्कने यापूर्वी कधीही केलेले नाही: तो single-file components ला थेट-DOM अपडेट्समध्ये संकलित (compile) करतो, ज्यामुळे virtual DOM पूर्णपणे वगळले जाते.

Vue ने virtual DOM कडे पाठ फिरवण्याचे कारण काय?

Vue 2 पासून, virtual DOM हे फ्रेमवर्कच्या reactivity model चे केंद्र राहिले आहे. जेव्हा state बदलतो, तेव्हा Vue एक हलके (lightweight) in-memory tree तयार करते, त्याची मागील आवृत्तीशी तुलना (diff) करते आणि फक्त बदललेल्या भागांमध्ये patches करते. या अप्रत्यक्ष पद्धतीमुळे डेव्हलपर्सना कोणता घटक (element) प्रत्यक्षात अपडेट करण्याची गरज आहे याची काळजी न करता declarative code लिहिणे सोपे जाते. मात्र, याचा तोटा असा आहे की प्रत्येक render साठी त्या virtual tree ला तयार करण्याचा आणि त्याची तुलना करण्याचा खर्च (cost) करावा लागतो.

Vapor Mode ही मधली पायरी काढून टाकते. बिल्ड दरम्यान, Vue compiler टेम्पलेटचे विश्लेषण करते आणि असे JavaScript तयार करते जे थेट जिथे बदल आवश्यक आहे तिथे native DOM methods—element.textContent = …, element.setAttribute(...)—ला कॉल करते. यामध्ये कोणतेही virtual nodes तयार केले जात नाहीत आणि कोणतीही diffing loop चालवली जात नाही. यामुळे bundle मध्ये फक्त तुम्ही लिहिलेल्या प्रत्यक्ष अपडेट्ससाठी आवश्यक असलेला कोड आणि reactivity साठी लागणारे runtime समाविष्ट असते.

आकार (size) आणि वेगावर (speed) होणारा वास्तविक परिणाम

  • Bundle size – virtual-DOM runtime आणि त्याच्या डेटा स्ट्रक्चर्सना काढून टाकल्यामुळे, तयार झालेला कोड लहान होतो. ज्या प्रोजेक्ट्समध्ये मोठ्या grids किंवा canvases आहेत जे दर सेकंदाला डझनभर वेळा अपडेट होतात, तिथे ही बचत महत्त्वाची ठरते, विशेषतः कमी बँडविड्थ असलेल्या कनेक्शनवर.
  • Performance – थेट DOM calls मुळे diffing चा अतिरिक्त भार (overhead) वाचतो, जो UI उच्च वारंवारतेने (high frequency) बदलत असताना स्पष्टपणे जाणवतो. काही वैयक्तिक ब्राउझर गेम्समध्ये—एक nonogram, एक minesweeper clone आणि एक 3-D Rubik’s-cube visualiser—मी rendering logic स्वतः हाताने लिहिले होते, जिथे आवश्यक आहे तिथेच DOM अपडेट केला होता.
  • Developer ergonomics – मुख्य काम compiler करते. तुम्ही अजूनही नियमित Vue templates लिहू शकता; तुम्हाला document.querySelector कॉल्स स्वतः हाताने लिहावे लागणार नाहीत. तयार झालेला कोड अगदी त्या हाताने लिहिलेल्या पद्धतीसारखाच असतो, ज्यामुळे मला त्या गेम्समध्ये सर्वोत्तम performance मिळाले होते.

Vapor Mode प्रत्यक्षात कधी उपयुक्त ठरते

  1. मोठ्या स्ट्रक्चर्सवर उच्च-वारंवारता अपडेट्स (High-frequency updates) – गेम्स, डेटा-केंद्रित dashboards, किंवा असे कोणतेही इंटरफेस जे प्रत्येक tick ला अनेक सेल्स पुन्हा काढतात (redraw), त्यांना याचा सर्वाधिक फायदा होतो. प्रत्येक tick ला मोठ्या grid ची तुलना (diffing) करणे फ्रेम बजेटवर ताण आणू शकते; थेट अपडेट्समुळे हे काम रेषीय (linear) आणि अंदाजित (predictable) राहते.
  2. Bundle-size मर्यादित असलेल्या deployments – ज्या मोबाईल-फर्स्ट साइट्सना काही शेकडो किलोबाइट्सच्या आत लोड व्हावे लागते, त्यांना virtual-DOM runtime निघून गेल्यामुळे आकारामध्ये लक्षणीय घट दिसून येते.
  3. शुद्ध आणि अंदाजित state (Pure, predictable state) – Vapor Mode असे गृहीत धरते की तुम्ही state immutable ठेवता आणि DOM ला त्या state चे शुद्ध प्रक्षेपण (projection) मानता. जर तुमच्या कोडमध्ये side-effects मिसळले असतील किंवा Vue च्या reactivity system च्या बाहेर DOM मध्ये बदल (mutate) केले असतील, तर तयार झालेले अपडेट्स sync च्या बाहेर जाऊ शकतात, ज्यामुळे visual glitches येऊ शकतात.

जुनी पद्धत कुठे अजूनही सरस ठरते

  • कमी-वारंवारता असलेले UIs – साधे फॉर्म्स, स्टॅटिक पेजेस किंवा ॲडमिन पॅनल्स जे केवळ अधूनमधून युजरच्या कृतींवर rerender होतात, त्यांना फारसा परफॉर्मन्स फायदा मिळत नाही. नेटवर्क लेटन्सी किंवा सर्व्हर प्रोसेसिंग वेळेच्या तुलनेत virtual tree तयार करण्याचे अतिरिक्त काम नगण्य असते.
  • जटिल component hierarchies – जेव्हा एखाद्या खोल (deep) tree मध्ये फक्त एक leaf node बदलतो, तेव्हा virtual DOM आपोआप मोठ्या भागांना वगळू शकते. थेट अपडेट्समुळे compiler ला प्रत्येक संभाव्य बदलासाठी अचूक patches तयार करण्यास भाग पाडले जाते, ज्यामुळे काही विशिष्ट प्रकरणांमध्ये (edge cases) कोडचा आकार वाढू शकतो.
  • Tooling आणि ecosystem – अनेक Vue plugins, devtools आणि testing utilities virtual-DOM लेयरशी जोडलेले असतात. जोपर्यंत ecosystem या नवीन बदलाशी जुळवून घेत नाही, तोपर्यंत Vapor-mode components सोबत काम करण्यासाठी त्या integrations ला अपडेट्सची आवश्यकता भासू शकते.

पुढे काय पाहायचे

  • Stable release – Vue 3.6 सध्या release-candidate स्थितीत आहे. टीम या शरद ऋतूत अंतिम stable लॉन्च करण्याचे नियोजन करत आहे. सुरुवातीच्या वापरकर्त्यांनी (early adopters) प्रोडक्शन कोड रिलीज करण्यापूर्वी त्या आवृत्तीची प्रतीक्षा करावी.
  • Migration path – सध्याचे Vue प्रोजेक्ट्स प्रत्येक component नुसार Vapor Mode वापरण्याचा पर्याय निवडू शकतात.
  • Performance tooling – वास्तविक जगातील ॲप्सवर virtual-DOM आणि Vapor-mode builds ची तुलना करणारे benchmarks टीम्सना हे ठरवण्यास मदत करतील की हा बदल (trade-off) फायदेशीर आहे की नाही.

थोडक्यात सांगायचे तर

Vapor Mode Vue डेव्हलपर्सना दोन भिन्न वैशिष्ट्यांचा उत्तम संगम देते: त्यांना आवडणारा declarative syntax आणि hand-crafted DOM अपडेट्सचा प्रचंड वेग. हे अशा ॲप्ससाठी उत्कृष्ट आहे जे UI चे मोठे भाग प्रति सेकंद अनेक वेळा रिफ्रेश करतात आणि अशा डिप्लॉयमेंट्ससाठी जिथे प्रत्येक किलोबाइट महत्त्वाचा असतो. कमी ट्रॅफिक असलेल्या इंटरफेससाठी, पारंपारिक virtual DOM हा एक पूर्णपणे व्यवहार्य आणि सोपा पर्याय आहे. जसजसे हे फीचर release candidate कडून stable आवृत्तीकडे सरकत आहे, तसतसे Vue कम्युनिटीला bundle-size मधील बचत आणि ecosystem ची सज्जता तसेच त्यांच्या ॲप्लिकेशन्सचे विशिष्ट performance profile यांचा विचार करून निर्णय घ्यावा लागेल.