Vue 3.6-ന്റെ വരാനിരിക്കുന്ന Vapor Mode ഈ ശരത്കാലത്ത് പുറത്തിറങ്ങും, ഇത് ഫ്രെയിംവർക്ക് മുമ്പ് ഒരിക്കലും ചെയ്യാത്ത ഒരു കാര്യം ചെയ്യുന്നു: ഇത് സിംഗിൾ-ഫയൽ കംപോണന്റുകളെ (single-file components) നേരിട്ട് DOM-ലേക്ക് അപ്‌ഡേറ്റ് ചെയ്യുന്ന രീതിയിലേക്ക് കംപൈൽ ചെയ്യുന്നു, ഇതിലൂടെ virtual DOM പൂർണ്ണമായും ഒഴിവാക്കപ്പെടുന്നു.

എന്തുകൊണ്ടാണ് Vue virtual DOM-ൽ നിന്ന് പിന്മാറുന്നത്

Vue 2 മുതൽ, virtual DOM ആണ് ഫ്രെയിംവർക്കിന്റെ റിയാക്റ്റിവിറ്റി മോഡലിന്റെ (reactivity model) കാതൽ. സ്റ്റേറ്റ് (state) മാറുമ്പോൾ, Vue ഒരു ലഘുവായ ഇൻ-മെമ്മറി ട്രീ (in-memory tree) നിർമ്മിക്കുകയും, അത് മുൻപത്തെ വേർഷനുമായി താരതമ്യം ചെയ്ത് (diffs) മാറ്റമുള്ള ഭാഗങ്ങൾ മാത്രം അപ്‌ഡേറ്റ് (patch) ചെയ്യുകയും ചെയ്യുന്നു. ഏത് എലമെന്റാണ് യഥാർത്ഥത്തിൽ അപ്‌ഡേറ്റ് ചെയ്യേണ്ടതെന്ന് ആശങ്കപ്പെടാതെ ഡെക്ലറേറ്റീവ് കോഡ് (declarative code) എഴുതാൻ ഈ രീതി ഡെവലപ്പർമാരെ സഹായിക്കുന്നു. എന്നാൽ ഇതിന്റെ പോരായ്മ എന്തെന്നാൽ, ഓരോ റെൻഡറിംഗിനും ആ virtual tree നിർമ്മിക്കാനും താരതമ്യം ചെയ്യാനുമുള്ള സമയം ചിലവാകുന്നു എന്നതാണ്.

Vapor Mode ആ ഇടനില ഘട്ടത്തെ ഒഴിവാക്കുന്നു. ബിൽഡ് സമയത്ത്, Vue കംപൈലർ ടെംപ്ലേറ്റ് വിശകലനം ചെയ്യുകയും മാറ്റം ആവശ്യമുള്ള ഇടങ്ങളിൽ നേരിട്ട് element.textContent = …, element.setAttribute(...) തുടങ്ങിയ നാറ്റീവ് DOM മെത്തേഡുകൾ വിളിക്കുന്ന ജാവാസ്ക്രിപ്റ്റ് (JavaScript) പുറപ്പെടുവിക്കുകയും ചെയ്യുന്നു. ഇവിടെ virtual നോഡുകൾ നിർമ്മിക്കപ്പെടുന്നില്ല, diffing ലൂപ്പുകളും പ്രവർത്തിക്കുന്നില്ല. നിങ്ങൾ എഴുതിയ കൃത്യമായ അപ്‌ഡേറ്റുകൾക്ക് ആവശ്യമായ കോഡും റിയാക്റ്റിവിറ്റിക്ക് വേണ്ട റൺടൈമും (runtime) മാത്രമായിരിക്കും ബണ്ടിലുണ്ടാകുക.

വലിപ്പത്തിലും വേഗതയിലും ഉണ്ടാകുന്ന യഥാർത്ഥ പ്രത്യാഘാതങ്ങൾ

  • ബണ്ടിൽ സൈസ് (Bundle size) – virtual-DOM റൺടൈമും അതിന്റെ ഡാറ്റാ സ്ട്രക്ചറുകളും ഒഴിവാക്കുന്നതിലൂടെ നിർമ്മിക്കപ്പെടുന്ന കോഡിന്റെ വലിപ്പം കുറയുന്നു. സെക്കൻഡിൽ ഡസൻ കണക്കിന് തവണ അപ്‌ഡേറ്റ് ചെയ്യപ്പെടുന്ന വലിയ ഗ്രിഡുകളോ കാൻവാസുകളോ (canvases) ഉള്ള പ്രോജക്റ്റുകളിൽ, പ്രത്യേകിച്ച് കുറഞ്ഞ ബാൻഡ്‌വിഡ്ത്ത് ഉള്ള കണക്ഷനുകളിൽ, ഈ ലാഭം വളരെ വലുതാണ്.
  • പെർഫോമൻസ് (Performance) – നേരിട്ടുള്ള DOM കോളുകൾ diffing overhead ഒഴിവാക്കുന്നു, ഇത് UI ഉയർന്ന ഫ്രീക്വൻസിയിൽ മാറുന്ന സാഹചര്യങ്ങളിൽ വ്യക്തമായി കാണാൻ സാധിക്കും. നോണോഗ്രാം (nonogram), മൈൻസ്വീപ്പർ ക്ലോൺ (minesweeper clone), 3-D റൂബിക്സ് ക്യൂബ് വിഷ്വലൈസർ (3-D Rubik’s-cube visualiser) എന്നിങ്ങനെയുള്ള ചില പേഴ്സണൽ ബ്രൗസർ ഗെയിമുകളിൽ, ആവശ്യമുള്ള ഇടങ്ങളിൽ മാത്രം DOM അപ്‌ഡേറ്റ് ചെയ്തുകൊണ്ട് ഞാൻ റെൻഡറിംഗ് ലോജിക് നേരിട്ട് എഴുതിയിരുന്നു.
  • ഡെവലപ്പർ എർഗണോമിക്സ് (Developer ergonomics) – കംപൈലറാണ് പ്രധാന ജോലി ചെയ്യുന്നത്. നിങ്ങൾ ഇപ്പോഴും സാധാരണ Vue ടെംപ്ലേറ്റുകൾ തന്നെ എഴുതുന്നു; document.querySelector കോളുകൾ നേരിട്ട് എഴുതേണ്ടി വരുന്നില്ല. ആ ഗെയിമുകളിൽ എനിക്ക് മികച്ച പെർഫോമൻസ് നൽകിയ രീതിയെ തന്നെയാണ് നിർമ്മിക്കപ്പെടുന്ന കോഡും അനുകരിക്കുന്നത്.

Vapor Mode എപ്പോഴാണ് യഥാർത്ഥത്തിൽ സഹായിക്കുന്നത്

  1. വലിയ ഘടനകളിലെ ഉയർന്ന ഫ്രീക്വൻസി അപ്‌ഡേറ്റുകൾ – ഗെയിമുകൾ, ഡാറ്റാ-ഇന്റൻസീവ് ഡാഷ്‌ബോർഡുകൾ (data-intensive dashboards), അല്ലെങ്കിൽ ഓരോ ടിക്കിലും (tick) നിരവധി സെല്ലുകൾ വീണ്ടും വരയ്ക്കുന്ന ഇന്റർഫേസുകൾ എന്നിവയാണ് ഇതിന്റെ ഏറ്റവും വലിയ ഗുണഭോക്താക്കൾ. ഓരോ ടിക്കിലും ഒരു വലിയ ഗ്രിഡ് ഡിഫിംഗ് (diffing) ചെയ്യുന്നത് ഫ്രെയിം ബജറ്റിനെ ബാധിച്ചേക്കാം; എന്നാൽ നേരിട്ടുള്ള അപ്‌ഡേറ്റുകൾ ഈ പ്രക്രിയ ലളിതവും പ്രവചിക്കാവുന്നതുമാക്കുന്നു.
  2. ബണ്ടിൽ സൈസ് പരിമിതപ്പെടുത്തപ്പെട്ട ഡിപ്ലോയ്മെന്റുകൾ – ഏതാനും നൂറ് കിലോബൈറ്റുകൾക്കുള്ളിൽ ലോഡ് ചെയ്യേണ്ട മൊബൈൽ-ഫസ്റ്റ് സൈറ്റുകളിൽ, virtual-DOM റൺടൈം ഇല്ലാതാകുന്നതോടെ വലിപ്പത്തിൽ വലിയ കുറവ് കാണാൻ സാധിക്കും.
  3. ശുദ്ധവും പ്രവചിക്കാവുന്നതുമായ സ്റ്റേറ്റ് (Pure, predictable state) – സ്റ്റേറ്റ് മാറ്റമില്ലാത്തതായി (immutable) നിലനിർത്തുമെന്നും DOM-നെ ആ സ്റ്റേറ്റിന്റെ ഒരു പ്രതിഫലനമായി (projection) കാണുമെന്നും Vapor Mode കരുതുന്നു. നിങ്ങളുടെ കോഡ് സൈഡ്-ഇഫക്റ്റുകൾ (side-effects) കലർത്തുകയോ Vue-യുടെ റിയാക്റ്റിവിറ്റി സിസ്റ്റത്തിന് പുറത്ത് DOM മാറ്റം വരുത്തുകയോ ചെയ്താൽ, നിർമ്മിക്കപ്പെടുന്ന അപ്‌ഡേറ്റുകൾ കൃത്യമല്ലാതാകാനും വിഷ്വൽ ഗ്ലിച്ചുകൾ (visual glitches) ഉണ്ടാകാനും സാധ്യതയുണ്ട്.

പഴയ രീതി എവിടെയാണ് ഇപ്പോഴും മികച്ചതാകുന്നത്

  • കുറഞ്ഞ ഫ്രീക്വൻസിയിലുള്ള UIs – ലളിതമായ ഫോമുകൾ, സ്റ്റാറ്റിക് പേജുകൾ, അല്ലെങ്കിൽ ഇടയ്ക്കിടെ മാത്രം അപ്‌ഡേറ്റ് ചെയ്യപ്പെടുന്ന അഡ്മിൻ പാനലുകൾ എന്നിവയിൽ പെർഫോമൻസിൽ വലിയ മാറ്റം ഉണ്ടാകില്ല. നെറ്റ്‌വർക്ക് ലേറ്റൻസിയുമായോ (network latency) സെർവർ പ്രോസസ്സിംഗുമായോ താരതമ്യം ചെയ്യുമ്പോൾ ഒരു virtual tree നിർമ്മിക്കുന്നതിലെ അധിക ജോലി വളരെ കുറവാണ്.
  • സങ്കീർണ്ണമായ കംപോണന്റ് ഹൈരാർക്കി (Complex component hierarchies) – ഒരു വലിയ ട്രീയിലെ ഒരു ചെറിയ ഭാഗം (leaf node) മാത്രം മാറുമ്പോൾ, virtual DOM വലിയൊരു ഭാഗം തനിയെ ഒഴിവാക്കും. എന്നാൽ നേരിട്ടുള്ള അപ്‌ഡേറ്റുകളിൽ, ഓരോ മാറ്റത്തിനും കൃത്യമായ പാച്ചുകൾ (patches) നിർമ്മിക്കാൻ കംപൈലർ നിർബന്ധിതമാവുന്നു, ഇത് ചില സന്ദർഭങ്ങളിൽ കോഡിന്റെ വലിപ്പം കൂട്ടിയേക്കാം.
  • ടൂളിംഗും ഇക്കോസിസ്റ്റവും (Tooling and ecosystem) – പല Vue പ്ലഗിനുകളും, ഡെവ്‌ടൂളുകളും (devtools), ടെസ്റ്റിംഗ് യൂട്ടിലിറ്റികളും virtual-DOM ലെയറുമായി ബന്ധപ്പെട്ടവയാണ്. ഇക്കോസിസ്റ്റം ഇതിനനുസരിച്ച് മാറുന്നത് വരെ, Vapor-mode കംപോണന്റുകൾക്കൊപ്പം പ്രവർത്തിക്കാൻ ഈ ഇന്റഗ്രേഷനുകൾക്ക് അപ്‌ഡേറ്റുകൾ ആവശ്യമായി വന്നേക്കാം.

ഇനി ശ്രദ്ധിക്കേണ്ട കാര്യങ്ങൾ

  • സ്റ്റേബിൾ റിലീസ് (Stable release) – Vue 3.6 ഇപ്പോൾ റിലീസ്-ക്യാൻഡിഡേറ്റ് (release-candidate) ഘട്ടത്തിലാണ്. ഈ ശരത്കാലത്ത് ഒരു സ്റ്റേബിൾ വേർഷൻ പുറത്തിറക്കാൻ ടീം പദ്ധതിയിടുന്നു. പ്രൊഡക്ഷൻ കോഡുകൾ ഉപയോഗിക്കുന്നതിന് മുൻപ് ആ വേർഷനായി കാത്തിരിക്കാൻ ഡെവലപ്പർമാർ ശ്രദ്ധിക്കണം.
  • മൈഗ്രേഷൻ പാത്ത് (Migration path) – നിലവിലുള്ള Vue പ്രോജക്റ്റുകളിൽ ഓരോ കംപോണന്റ് അടിസ്ഥാനത്തിലും Vapor Mode ഉപയോഗിക്കാൻ സാധിക്കും.
  • പെർഫോമൻസ് ടൂളിംഗ് (Performance tooling) – യഥാർത്ഥ ആപ്പുകളിൽ virtual-DOM-ഉം Vapor-mode-ഉം തമ്മിലുള്ള വ്യത്യാസം താരതമ്യം ചെയ്യുന്ന ബെഞ്ച്മാർക്കുകൾ (benchmarks), എപ്പോഴാണ് ഈ മാറ്റം ലാഭകരമാകുന്നത് എന്ന് തീരുമാനിക്കാൻ ടീമുകളെ സഹായിക്കും.

ചുരുക്കത്തിൽ

Vapor Mode Vue ഡെവലപ്പർമാർക്ക് രണ്ട് വ്യത്യസ്ത ലോകങ്ങളിലെ മികച്ച കാര്യങ്ങൾ നൽകുന്നു: അവർ ഇഷ്ടപ്പെടുന്ന declarative syntax-ഉം നേരിട്ട് തയ്യാറാക്കിയ DOM അപ്‌ഡേറ്റുകളുടെ വേഗതയും. സെക്കൻഡിൽ പലതവണ UI-യുടെ വലിയ ഭാഗങ്ങൾ പുതുക്കേണ്ടി വരുന്ന ആപ്പുകൾക്കും, ഓരോ കിലോബൈറ്റും പ്രധാനപ്പെട്ട ഡിപ്ലോയ്മെന്റുകൾക്കും ഇത് ഏറെ അനുയോജ്യമാണ്. കുറഞ്ഞ ട്രാഫിക് ഉള്ള ഇന്റർഫേസുകൾക്ക്, പരമ്പരാഗതമായ virtual DOM ഇപ്പോഴും ലളിതവും പ്രായോഗികവുമായ ഒരു തിരഞ്ഞെടുപ്പാണ്. ഈ ഫീച്ചർ release candidate-ൽ നിന്ന് stable ഘട്ടത്തിലേക്ക് മാറുമ്പോൾ, bundle-size ലാഭവും ecosystem-ന്റെ തയ്യാറെടുപ്പും തങ്ങളുടെ ആപ്ലിക്കേഷനുകളുടെ പ്രത്യേക performance profile-ഉം തമ്മിൽ താരതമ്യം ചെയ്യാൻ Vue കമ്മ്യൂണിറ്റിക്ക്ാകും.