ویب ڈویلپمنٹ کی دنیا نے ایک دہائی کا بڑا حصہ خود کو یہ یقین دلانے میں گزار دیا کہ براؤزر کو تمام بھاری کام کرنے چاہئیں۔ ہم نے دستاویزات اور فارمز سے آغاز کیا، پھر رفتہ رفتہ ہر ممکن آپریشن کو کلائنٹ کی طرف منتقل کر دیا۔ Routing، state management، data fetching، rendering logic، یہاں تک کہ GraphQL کے ذریعے ڈیٹا بیس کوئری کی ترتیب (orchestration) — یہ سب JavaScript bundles میں منتقل ہو گیا جو ہر نئی ریلیز کے ساتھ مزید بھاری ہوتے گئے۔ Frameworks کی تعداد بڑھتی گئی، build pipelines پیچیدہ ہوتی گئیں، اور جس چیز کا آغاز ایپس کو تیز رفتار (snappy) بنانے کے لیے ہوا تھا، وہ ایک ایسی آرکیٹیکچر میں بدل گئی جہاں ایک پیج کا ایک بھی بامعنی پکسل تب تک رینڈر نہیں ہو سکتا تھا جب تک کہ میگا بائٹس کا کوڈ ڈاؤن لوڈ، پارس اور ایگزیکیوٹ نہ ہو جائے۔
اس تبدیلی نے حقیقی مسائل حل کیے۔ jQuery کے ہلکے استعمال کے ساتھ server-rendered صفحات صارفین کی توقع کے مطابق ہموار اور ایپ جیسی تبدیلیوں (transitions) کو فراہم کرنے میں جدوجہد کرتے تھے۔ Single Page Applications نے ہمیں فوری نیویگیشن، مستقل اسٹیٹ (persistent state) اور بھرپور انٹرایکشنز فراہم کیں۔ لیکن اس کی قیمت چکانی پڑی۔ اب ٹیمیں پیچیدہ client-side state stores کو سنبھالتی ہیں، بڑے JavaScript bundles کے ساتھ نمٹتی ہیں، نازک ڈیٹا سنکرونائزیشن لیئرز کو برقرار رکھتی ہیں، اور ایسی build pipelines کو ڈی بگ کرتی ہیں جو کبھی کبھی ایک مکمل وقت کی ملازمت محسوس ہوتی ہیں۔ ہم نے ایک طرح کے مسائل کے بدلے دوسرے مسائل اپنا لیے، اور اب بہت سے ڈویلپرز یہ سوال کر رہے ہیں کہ کیا ہر ایپلی کیشن کو اس قیمت (tax) کی ادائیگی کی ضرورت ہے۔
دو ایسی پیش رفتیں ہو رہی ہیں جو اس سوال کا جواب دینا آسان بنا رہی ہیں۔
HTMX اور Hypermedia کی واپسی
پہلی پیش رفت HTMX ہے۔ بظاہر یہ ایک چھوٹی لائبریری معلوم ہوتی ہے، لیکن اس کے آرکیٹیکچرل اثرات بہت بڑے ہیں۔ HTMX، HTML کو ایک ایسے جامد خول (static shell) کے طور پر دیکھنے کے بجائے کہ جسے JavaScript کے ذریعے بھرنا ضروری ہو، ایپلی کیشن لاجک کے لیے ایک نیٹو فارمیٹ کے طور پر استعمال کرتا ہے۔
عملی طور پر کیا تبدیلیاں آتی ہیں، وہ یہ ہیں: روایتی طور پر، جب کوئی صارف مزید کمنٹس لوڈ کرنے کے لیے بٹن پر کلک کرتا ہے، تو فرنٹ اینڈ ایک fetch request بھیجتا ہے، JSON payload وصول کرتا ہے، اسے client-side store میں نارملائز کرتا ہے، اسے ایک component template کے ذریعے گزارتا ہے، virtual DOM کا فرق (diff) نکالتا ہے، اور آخر کار پیج کو اپ ڈیٹ (patch) کرتا ہے۔ HTMX اس پورے سلسلے کو مختصر کر دیتا ہے۔ بٹن کے اندر ہی ایسے attributes ہوتے ہیں جو براؤزر کو بتاتے ہیں کہ درخواست کہاں بھیجنی ہے اور پیج کے کس عنصر (element) کو تبدیل کرنا ہے۔ سرور ایک HTML fragment واپس کرتا ہے — صرف نئے کمنٹس، جو ایک div میں لپٹے ہوئے ہوتے ہیں۔ براؤزر اسے تبدیل کر کے وہاں لگا دیتا ہے۔ نہ کوئی JSON ہے، نہ فرنٹ اینڈ اسٹیٹ ٹری، نہ کوئی reconciliation algorithm، اور نہ ہی UI کو سرور کے ساتھ ہم آہنگ رکھنے کے لیے کوئی imperative JavaScript کی ضرورت ہے۔
یہ جدید ڈویلپمنٹ کی نفی نہیں ہے۔ یہ غیر ضروری تجرید (abstraction) کی نفی ہے۔ HTMX یہ ثابت کرتا ہے کہ hypermedia، یعنی وہ آرکیٹیکچرل اسٹائل جس نے ابتدائی ویب کو طاقت بخشی تھی، جدید سہولیات (ergonomics) کے ساتھ مل کر اب بھی پیچیدہ انٹرفیس کو سپورٹ کر سکتا ہے۔ صرف فارمز اور لنکس ہی نہیں، بلکہ کوئی بھی عنصر درخواستیں جاری کر سکتا ہے۔ کوئی بھی ایونٹ اپ ڈیٹ کا باعث بن سکتا ہے۔ سرور ڈیٹا اور پریزنٹیشن دونوں کے لیے 'سورس آف ٹرتھ' (source of truth) رہتا ہے۔
Chrome کے Declarative Partial Updates
دوسری تبدیلی نئی ہے اور خود براؤزر کے اندر موجود ہے۔ Chrome، Declarative Partial Updates یا DPU متعارف کروا رہا ہے۔ یہ فیچر براؤزر کو اس قابل بناتا ہے کہ وہ HTML کو اسٹریم کرے اور جیسے ہی بائٹس (bytes) موصول ہوں، انہیں پیج کے مخصوص حصوں میں براہ راست شامل کر دے۔
DPU سے پہلے، اگر آپ کسی ویب پیج میں لائیو ڈیٹا اسٹریم کرنا چاہتے تھے، تو آپ عام طور پر WebSockets، Server-Sent Events، یا long-polling کے ساتھ دستی DOM manipulation کا سہارا لیتے تھے۔ فرنٹ اینڈ کو کنکشن سنبھالنا، payload کو پارس کرنا، اور یہ فیصلہ کرنا پڑتا تھا کہ مارک اپ کو بالکل کیسے اور کہاں شامل کرنا ہے۔ DPU اس عمل کو declarative بنا کر صورتحال بدل دیتا ہے۔ ڈویلپر ایک ٹارگٹ کنٹینر (target container) متعین کرتا ہے، اور براؤزر باقی کام خود سنبھال لیتا ہے: اسٹریم وصول کرنا، فرگمنٹ کو پارس کرنا، اور اسے بالکل اسی جگہ رکھنا جہاں اس کا ہونا چاہیے، یہاں تک کہ مکمل رسپانس ختم ہونے سے پہلے ہی۔
ایک مانیٹرنگ ڈیش بورڈ کے بارے میں سوچیں جو سرور لاگز دکھا رہا ہو یا کوئی سپورٹ کیو (support queue) جو ریئل ٹائم میں اپ ڈیٹ ہو رہی ہو۔ DPU کے ساتھ، بیک اینڈ جیسے ہی HTML کے ٹکڑے (chunks) تیار کرتا ہے، انہیں بھیج دیتا ہے۔ براؤزر کلائنٹ سائیڈ اسٹریمنگ لاجک کی ایک بھی لائن کے بغیر انہیں ٹیبل باڈی یا فیڈ کنٹینر میں اسٹریم کر دیتا ہے۔ یہ عمل قدرتی طور پر (natively) ہوتا ہے۔
Server-First ماڈل
HTMX اور DPU کو ایک ساتھ ملا دیں، تو آپ کو ایک مربوط آرکیٹیکچر ملتا ہے جہاں سرور اسٹیٹ کا مالک ہوتا ہے اور UI تیار کرتا ہے، جبکہ براؤزر ڈسپلے اور صارف کے ان پٹ کو سنبھالتا ہے۔ Rails، Laravel، Django، Go templates، یا ASP.NET جیسے بیک اینڈ فریم ورکس دوبارہ بنیادی انٹرفیس لیئر بن جاتے ہیں۔ فرنٹ اینڈ کوئی الگ ایپلی کیشن نہیں ہے جو API استعمال کرتی ہے، بلکہ یہ وہ hypermedia انٹرفیس ہے جو سرور تیار کرتا ہے۔
یہ ماڈل سافٹ ویئر کے ایک حیرت انگیز طور پر وسیع حصے پر فٹ بیٹھتا ہے۔ ایک عام SaaS ایپلی کیشن پر غور کریں۔ یہ ترتیب کے قابل (sortable) ٹیبلز والے ڈیش بورڈز ہیں۔ یہ فارمز اور فلٹرز والے ایڈمن پینلز ہیں۔ یہ وہ اندرونی ٹولز ہیں جو ریکارڈز کو ایک حالت سے دوسری حالت میں منتقل کرتے ہیں۔ یہ CRUD ورک فلو ہیں جو ایک فہرست دکھاتے ہیں، تفصیل کا منظر (detail view) فراہم کرتے ہیں، اور صارف کو فیلڈز ایڈٹ کرنے کی اجازت دیتے ہیں۔ یہ یہاں تک کہ AI انٹرفیس بھی ہیں جہاں ایک لینگویج ماڈل صارف کو ٹوکنز (tokens) فراہم کرتا ہے، اور ہر ٹوکن یا پیراگراف کو HTML میں لپیٹ کر گفتگو کے سلسلے (conversation thread) میں شامل کیا جا سکتا ہے۔ ان سب کے لیے، ایک بھاری (thick) JavaScript کلائنٹ اکثر ضرورت سے زیادہ (overkill) ہوتا ہے۔
فوائد فوری اور عملی ہیں۔ ابتدائی پیج لوڈنگ تیز ہوتی ہے کیونکہ پہلا بامعنی پینٹ (meaningful paint) HTML کی صورت میں آتا ہے، نہ کہ ہائیڈریشن سائیکل (hydration cycle) مکمل ہونے کے بعد۔ JavaScript پے لوڈز کم ہو جاتے ہیں کیونکہ وہاں کوئی virtual DOM، کوئی کلائنٹ سائیڈ روٹر، اور کوئی اسٹیٹ مینجمنٹ لائبریری بھیجنے کی ضرورت نہیں ہوتی۔ سرچ انجن بنڈلز کو چلائے بغیر مکمل مواد دیکھ لیتے ہیں، اس لیے SEO خود بخود کام کرتا ہے۔ پیچیدگی کم ہو جاتی ہے کیونکہ ایک ہی کوڈ بیس روٹنگ، بزنس لاجک اور رینڈرنگ کو سنبھالتی ہے۔ ڈی بگنگ (Debugging) آسان ہو جاتی ہے۔ جب کچھ غلط نظر آئے، تو آپ نیٹ ورک ٹیب کا معائنہ کرتے ہیں اور بالکل وہی HTML دیکھتے ہیں جو سرور نے بھیجا تھا۔ وہاں ریورس انجینئر کرنے کے لیے کوئی مبہم کلائنٹ سائیڈ اسٹیٹ آبجیکٹ نہیں ہوتا۔
React اور بھاری کلائنٹس کا کیا؟
اس کا مطلب یہ نہیں کہ React ختم ہو گیا ہے، یا کہ SPAs ایک غلطی ہیں۔ پیچیدہ، ایڈیٹر لیول کی ایپلی کیشنز کو اب بھی ایک بھاری کلائنٹ کی ضرورت ہوتی ہے۔ Figma براؤزر کے اندر WebAssembly میں کمپائل شدہ C++ انجن چلاتا ہے کیونکہ سرور کے راؤنڈ ٹرپس ڈرائنگ کو ناممکن بنا دیں گے۔ Canva کلائنٹ سائیڈ جیومیٹری کے ساتھ ساٹھ فریم فی سیکنڈ پر کینوس کو کنٹرول کرتا ہے۔ Google Docs ملی سیکنڈز میں ایڈیٹنگ کے تنازعات کو حل کرنے کے لیے آپریشنل ٹرانسفارم (operational transforms) کا استعمال کرتا ہے۔ یہ ٹولز بنیادی طور پر ڈیسک ٹاپ ایپلی کیشنز ہیں جو براؤزر ٹیب کے ذریعے فراہم کی جاتی ہیں۔ یہ دوبارہ سرور رینڈرڈ فارمز کی طرف نہیں جا رہے ہیں۔
لیکن زیادہ تر سافٹ ویئر Figma نہیں ہیں۔ زیادہ تر سافٹ ویئر ریئل ٹائم گرافکس ایڈیٹر نہیں ہوتے۔ زیادہ تر سافٹ ویئر ایک رپورٹنگ اسکرین، کنفیگریشن پینل، بکنگ فلو، یا مواد کے انتظام (content management) کا فارم ہوتا ہے۔ ایپلی کیشنز کے اس بڑے گروہ کے لیے، صرف ایک موڈل (modal) کو آن/آف کرنے یا ریکارڈز کی فہرست حاصل کرنے کے لیے سینکڑوں کلو بائٹ کا JavaScript فریم ورک بھیجنا کبھی بھی زیادہ معنی نہیں رکھتا تھا۔ اسٹیک کی معیشت بدل رہی ہے۔ ہم دوبارہ دریافت کر رہے ہیں کہ 'ایج' (edge) کی بدولت سرور صارف کے قریب ہو سکتا ہے، اور براؤزر خود اتنا قابل ہو گیا ہے کہ وہ ہر بائٹ کے لیے کسی فریم ورک کی مداخلت کے بغیر ٹکڑوں (fragments) کو اپ ڈیٹ کر سکے۔
پینڈولم توازن تلاش کر رہا ہے
ویب آرکیٹیکچر کا رخ دوبارہ سادگی کی طرف مڑ رہا ہے، لیکن یہ نوے کی دہائی کی طرف کوئی سادہ واپسی نہیں ہے۔ براؤزر زیادہ ذہین ہو رہا ہے۔ DPU جیسے فیچرز ڈویلپر کی ذہانت کی جگہ نہیں لیتے؛ بلکہ وہ ان پیٹرنز کو خود پلیٹ فارم میں جذب کر لیتے ہیں جنہیں ہم پہلے ہاتھ سے نافذ کرتے تھے — جیسے اسٹریمنگ، جزوی اپ ڈیٹس، اور ٹارگٹڈ DOM انسرشن۔ HTMX ہمیں فرنٹ اینڈ میں ایک چھوٹا آپریٹنگ سسٹم دوبارہ بنائے بغیر ان طرزِ عمل کو ظاہر کرنے کے لیے الفاظ فراہم کرتا ہے۔
اب آپ کو ایک سادہ آرکیٹیکچر اور ایک ریسپونسیو صارف تجربے کے درمیان انتخاب کرنے کی ضرورت نہیں ہے۔ آپ دونوں حاصل کر سکتے ہیں۔ سرور انٹرفیس کو چلا سکتا ہے، براؤزر اسے ترتیب دے سکتا ہے، اور آپ جو JavaScript لکھتے ہیں وہ بنیادی ڈھانچے (plumbing) کے بجائے حقیقی انٹرایکٹیویٹی پر توجہ مرکوز کر سکتی ہے۔
ڈیش بورڈز، ایڈمن ٹولز اور AI سے چلنے والے انٹرفیس کی اگلی نسل کے لیے، سب سے ذہین کلائنٹ وہ ہو سکتا ہے جو کم سے کم کام کرے۔