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 بناتا ہے، اس کا پچھلے ورژن کے ساتھ diff کرتا ہے، اور صرف ان حصوں کو تبدیل (patch) کرتا ہے جو مختلف ہوتے ہیں۔ یہ بالواسطہ طریقہ ڈویلپرز کو اس فکر کے بغیر declarative code لکھنے کی اجازت دیتا ہے کہ اصل میں کس ایلیمنٹ کو اپ ڈیٹ کرنے کی ضرورت ہے۔ اس کا نقصان یہ ہے کہ ہر رینڈر (render) میں اس virtual tree کو بنانے اور diff کرنے کی قیمت چکانی پڑتی ہے۔

Vapor Mode اس درمیانی مرحلے کو ختم کر دیتا ہے۔ بلڈ (build) کے دوران، Vue compiler ٹیمپلیٹ کا تجزیہ کرتا ہے اور ایسا JavaScript جاری کرتا ہے جو براہ راست وہیں native DOM میتھڈز کال کرتا ہے جہاں تبدیلی کی ضرورت ہو—جیسے element.textContent = … یا element.setAttribute(...)۔ کوئی virtual nodes نہیں بنائے جاتے، اور نہ ہی کوئی diffing loop چلتا ہے۔ نتیجہ یہ نکلتا ہے کہ بنڈل (bundle) میں صرف وہی کوڈ شامل ہوتا ہے جو آپ کے لکھے ہوئے ٹھوس اپ ڈیٹس کے لیے ضروری ہے، ساتھ ہی reactivity کے لیے مطلوبہ runtime بھی۔

سائز اور رفتار پر حقیقی دنیا کے اثرات

  • Bundle size – virtual-DOM runtime اور اس کے ڈیٹا اسٹرکچرز کو نکال کر، تیار کردہ کوڈ چھوٹا ہو جاتا ہے۔ ان پروجیکٹس میں جہاں بڑے grids یا canvases ہوتے ہیں جو ایک سیکنڈ میں درجنوں بار اپ ڈیٹ ہوتے ہیں، وہاں یہ بچت بہت اہمیت رکھتی ہے، خاص طور پر کم بینڈوتھ والے کنکشنز پر۔
  • Performance – براہ راست DOM کالز diffing overhead کو ختم کر دیتی ہیں، جو اس وقت نمایاں ہو جاتا ہے جب UI بہت زیادہ فریکوئنسی پر تبدیل ہو رہا ہو۔ میں نے اپنے ذاتی براؤزر گیمز—ایک nonogram، ایک minesweeper کلون، اور ایک 3-D Rubik’s-cube visualiser—میں رینڈرنگ لاجک خود لکھی تھی، جس میں صرف ضرورت کے مطابق ہی DOM کو اپ ڈیٹ کیا تھا۔
  • Developer ergonomics – مشکل کام compiler کرتا ہے۔ آپ اب بھی عام Vue templates ہی لکھتے ہیں؛ آپ کو خود سے document.querySelector کالز لکھنے کی ضرورت نہیں پڑتی۔ تیار کردہ کوڈ بالکل اسی ہاتھ سے لکھے ہوئے طریقے کی عکاسی کرتا ہے جس نے مجھے ان گیمز میں بہترین کارکردگی فراہم کی تھی۔

Vapor Mode کب اصل میں مددگار ثابت ہوتا ہے

  1. بڑے ڈھانچوں پر ہائی فریکوئنسی اپ ڈیٹس – گیمز، ڈیٹا سے بھرپور ڈیش بورڈز، یا کوئی بھی ایسا انٹرفیس جو ہر ٹِک (tick) پر بہت سے سیلز کو دوبارہ ڈرا (redraw) کرتا ہے، اسے سب سے زیادہ فائدہ ہوتا ہے۔ ہر ٹِک پر ایک بڑے grid کا diff کرنا فریم بجٹ (frame budget) پر حاوی ہو سکتا ہے؛ براہ راست اپ ڈیٹس کام کو لائنیر (linear) اور قابلِ پیش گوئی رکھتی ہیں۔
  2. محدود بنڈل سائز والی ڈیپلائمنٹس – موبائل فرسٹ سائٹس جنہیں چند سو کلو بائٹس کے اندر لوڈ ہونا ہوتا ہے، وہ virtual-DOM runtime کے ختم ہونے سے واضح کمی محسوس کرتی ہیں۔
  3. خالص اور قابلِ پیش گوئی اسٹیٹ (Pure, predictable state) – Vapor Mode یہ فرض کرتا ہے کہ آپ اسٹیٹ کو immutable رکھتے ہیں اور DOM کو اس اسٹیٹ کے خالص پروجیکشن کے طور پر استعمال کرتے ہیں۔ اگر آپ کا کوڈ side-effects کو مکس کرتا ہے یا Vue کے reactivity سسٹم سے باہر DOM کو تبدیل کرتا ہے، تو تیار کردہ اپ ڈیٹس ہم آہنگ (in sync) نہیں رہیں گی، جس سے بصری خرابیاں (visual glitches) پیدا ہو سکتی ہیں۔

پرانا طریقہ کار کہاں اب بھی بہتر ہے

  • لو فریکوئنسی UIs – سادہ فارمز، اسٹیٹک صفحات، یا ایڈمن پینلز جو صرف کبھی کبھار صارف کے اقدامات پر دوبارہ رینڈر ہوتے ہیں، انہیں کارکردگی میں بہت کم فائدہ ہوتا ہے۔ ایک virtual tree بنانے کا اضافی کام نیٹ ورک لیٹنسی (latency) یا سرور پروسیسنگ کے وقت کے مقابلے میں نہ ہونے کے برابر ہے۔
  • پیچیدہ کمپوننٹ ہائیرارکیز – جب ایک گہرے ٹری (tree) میں صرف ایک leaf node تبدیل ہوتا ہے، تو virtual DOM خود بخود بڑے حصوں کو چھوڑ سکتا ہے۔ براہ راست اپ ڈیٹس کمپائلر کو ہر ممکن تبدیلی کے لیے درست پیچز (patches) تیار کرنے پر مجبور کرتی ہیں، جو کچھ مخصوص حالات (edge cases) میں کوڈ کا سائز بڑھا سکتا ہے۔
  • ٹولنگ اور ایکو سسٹم – بہت سے Vue پلگ انز، devtools، اور ٹیسٹنگ یوٹیلیٹیز virtual-DOM لیئر کے ساتھ جڑے ہوئے ہیں۔ ان انٹیگریشنز کو Vapor-mode کمپوننٹس کے ساتھ کام کرنے کے لیے اپ ڈیٹس کی ضرورت پڑ سکتی ہے جب تک کہ ایکو سسٹم اس کے مطابق نہ ہو جائے۔

آگے کیا دیکھنا ہے

  • Stable release – Vue 3.6 اس وقت release-candidate اسٹیٹس میں ہے۔ ٹیم اس خزاں میں حتمی اسٹیبل لانچ کا منصوبہ بنا رہی ہے۔ ابتدائی صارفین کو پروڈکشن کوڈ ریلیز کرنے سے پہلے اس ورژن کا انتظار کرنا چاہیے۔
  • Migration path – موجودہ Vue پروجیکٹس ہر کمپوننٹ کی بنیاد پر Vapor Mode کو اپنا سکتے ہیں۔
  • Performance tooling – وہ بینچ مارکس (benchmarks) جو حقیقی دنیا کی ایپس پر virtual-DOM اور Vapor-mode بلڈز کا موازنہ کریں گے، ٹیموں کو یہ فیصلہ کرنے میں مدد دیں گے کہ آیا یہ تبدیلی فائدہ مند ہے یا نہیں۔

خلاصہ

Vapor Mode Vue ڈویلپرز کو دو جہتوں کا بہترین امتزاج فراہم کرتا ہے: وہ declarative syntax جسے وہ پسند کرتے ہیں اور ہاتھ سے تیار کردہ DOM اپڈیٹس کی خالص رفتار۔ یہ ان ایپس کے لیے بہترین ہے جو ایک سیکنڈ میں کئی بار UI کے بڑے حصوں کو ریفریش کرتی ہیں اور ان ڈیپلائمنٹس کے لیے جہاں ہر کلو بائٹ کی اہمیت ہوتی ہے۔ کم ٹریفک والے انٹرفیسز کے لیے، روایتی virtual DOM ایک مکمل طور پر قابل عمل اور سادہ انتخاب رہتا ہے۔ جیسے جیسے یہ فیچر release candidate سے stable ورژن کی طرف بڑھے گا، Vue کمیونٹی کو bundle-size میں بچت کا موازنہ ecosystem کی تیاری اور اپنی ایپلی کیشنز کے مخصوص performance profile کے ساتھ کرنا ہوگا۔