वेब डेवलपमेंट की दुनिया ने एक दशक का बड़ा हिस्सा खुद को यह समझाने में बिता दिया कि ब्राउज़र को ही सारा भारी काम (heavy lifting) करना चाहिए। हमने दस्तावेज़ों (documents) और फॉर्मों से शुरुआत की, और फिर धीरे-धीरे हर संभावित ऑपरेशन को क्लाइंट पर स्थानांतरित कर दिया। राउटिंग, स्टेट मैनेजमेंट, डेटा फेचिंग, रेंडरिंग लॉजिक, यहाँ तक कि GraphQL के माध्यम से डेटाबेस क्वेरी ऑर्केस्ट्रेशन — यह सब JavaScript बंडल्स में चला गया जो हर रिलीज़ के साथ भारी होते गए। फ्रेमवर्क्स की संख्या बढ़ती गई, बिल्ड पाइपलाइन्स जटिल होती गईं, और जो चीज़ ऐप्स को तेज़ (snappy) बनाने के तरीके के रूप में शुरू हुई थी, वह एक ऐसे आर्किटेक्चर में बदल गई जहाँ मेगाबाइट्स का कोड डाउनलोड, पार्स और निष्पादित होने तक एक पेज एक भी सार्थक पिक्सेल रेंडर नहीं कर सकता था।
इस बदलाव ने वास्तविक समस्याओं को हल किया। jQuery के थोड़े से इस्तेमाल वाले सर्वर-रेंडर किए गए पेज उन स्मूथ, ऐप-जैसे ट्रांज़िशन देने के लिए संघर्ष करते थे जिनकी उपयोगकर्ता अपेक्षा करते थे। सिंगल पेज एप्लीकेशन (Single Page Applications) ने हमें इंस्टेंट नेविगेशन, पर्सिस्टेंट स्टेट और रिच इंटरैक्शन दिए। लेकिन इसकी कीमत चुकानी पड़ी। अब टीमें जटिल क्लाइंट-साइड स्टेट स्टोर्स को मैनेज करती हैं, विशाल JavaScript बंडल्स को संभालती हैं, नाजुक डेटा सिंक्रोनाइज़ेशन लेयर्स को बनाए रखती हैं, और ऐसी बिल्ड पाइपलाइन्स को डिबग करती हैं जो कभी-कभी अपने आप में एक फुल-टाइम जॉब जैसी लगती हैं। हमने एक तरह की समस्याओं के बदले दूसरी तरह की समस्याएँ चुन लीं, और अब कई डेवलपर्स यह पूछ रहे हैं कि क्या हर एप्लिकेशन को इस कीमत को चुकाने की ज़रूरत है।
दो विकास ऐसे हैं जो इस प्रश्न का उत्तर देना आसान बना रहे हैं।
HTMX और हाइपरमीडिया की वापसी
पहला है HTMX। सतही तौर पर, यह एक छोटी लाइब्रेरी जैसा दिखता है, लेकिन इसका आर्किटेक्चरल प्रभाव बहुत बड़ा है। HTMX HTML को JavaScript द्वारा फुलाए जाने वाले एक स्टैटिक शेल के रूप में देखने के बजाय, इसे एप्लिकेशन लॉजिक के लिए नेटिव फॉर्मेट के रूप में मानता है।
व्यवहार में यहाँ क्या बदलता है, इसे देखें। पारंपरिक रूप से, जब कोई उपयोगकर्ता अधिक कमेंट लोड करने के लिए बटन पर क्लिक करता है, तो फ्रंटएंड एक fetch रिक्वेस्ट भेजता है, एक JSON पेलोड प्राप्त करता है, उसे क्लाइंट-साइड स्टोर में नॉर्मलाइज़ करता है, उसे एक कंपोनेंट टेम्पलेट के माध्यम से चलाता है, वर्चुअल DOM को डिफ (diff) करता है, और अंत में पेज को पैच करता है। HTMX इस पूरी श्रृंखला को छोटा (short-circuit) कर देता है। बटन में ही ऐसे एट्रिब्यूट्स होते हैं जो ब्राउज़र को बताते हैं कि रिक्वेस्ट कहाँ भेजनी है और किस पेज एलिमेंट को बदलना है। सर्वर एक HTML फ्रैगमेंट लौटाता है — बस नए कमेंट्स, जो एक div में लिपटे होते हैं। ब्राउज़र उसे बदल देता है। यहाँ कोई JSON नहीं है, कोई फ्रंटएंड स्टेट ट्री नहीं है, कोई रिकॉन्सिलिएशन एल्गोरिदम नहीं है, और UI को सर्वर के साथ सिंक में रखने के लिए कोई इम्पेरेटिव JavaScript नहीं है।
यह आधुनिक विकास का त्याग नहीं है। यह अनावश्यक एब्स्ट्रैक्शन (abstraction) का त्याग है। HTMX यह साबित करता है कि हाइपरमीडिया, वह आर्किटेक्चरल स्टाइल जिसने शुरुआती वेब को शक्ति दी थी, आधुनिक एर्गोनॉमिक्स के साथ मिलकर अभी भी परिष्कृत इंटरफेस का समर्थन कर सकता है। कोई भी एलिमेंट रिक्वेस्ट जारी कर सकता है, न कि केवल फॉर्म और लिंक। कोई भी इवेंट अपडेट ट्रिगर कर सकता है। सर्वर डेटा और प्रेजेंटेशन दोनों के लिए 'सोर्स ऑफ ट्रुथ' बना रहता है।
Chrome के डिक्लेरेटिव पार्शियल अपडेट्स (Declarative Partial Updates)
दूसरा बदलाव नया है और ब्राउज़र के भीतर ही मौजूद है। Chrome 'डिक्लेरेटिव पार्शियल अपडेट्स' या DPU पेश कर रहा है। यह फीचर ब्राउज़र को HTML स्ट्रीम करने और बाइट्स के आते ही उन्हें पेज के लक्षित हिस्सों में सीधे डालने की अनुमति देता है।
DPU से पहले, यदि आप किसी वेब पेज में लाइव डेटा स्ट्रीम करना चाहते थे, तो आप आमतौर पर WebSockets, Server-Sent Events, या मैनुअल DOM मैनिपुलेशन के साथ लॉन्ग-पोलिंग का उपयोग करते थे। फ्रंटएंड को कनेक्शन को मैनेज करना, पेलोड को पार्स करना और यह तय करना पड़ता था कि मार्कअप को ठीक से कैसे और कहाँ इंजेक्ट किया जाए। DPU इस प्रक्रिया को डिक्लेरेटिव बनाकर समीकरण बदल देता है। डेवलपर एक टारगेट कंटेनर निर्दिष्ट करता है, और ब्राउज़र बाकी काम संभालता है: स्ट्रीम प्राप्त करना, फ्रैगमेंट को पार्स करना, और उसे ठीक वहीं रखना जहाँ उसकी ज़रूरत है, यहाँ तक कि पूरा रिस्पॉन्स बंद होने से पहले भी।
सर्वर लॉग दिखाने वाले मॉनिटरिंग डैशबोर्ड या रियल टाइम में अपडेट होने वाली सपोर्ट क्यू के बारे में सोचें। DPU के साथ, बैकएंड जैसे ही HTML चंक्स जनरेट होते हैं, उन्हें भेज देता है। ब्राउज़र बिना किसी क्लाइंट-साइड स्ट्रीमिंग लॉजिक के उन्हें सीधे टेबल बॉडी या फीड कंटेनर में स्ट्रीम कर देता है। इसका असेंबली काम नेटिव रूप से होता है।
सर्वर-फर्स्ट मॉडल (The Server-First Model)
HTMX और DPU को एक साथ रखें, तो आपको एक सुसंगत आर्किटेक्चर मिलता है जहाँ सर्वर स्टेट का स्वामित्व रखता है और UI जनरेट करता है, जबकि ब्राउज़र डिस्प्ले और यूजर इनपुट को संभालता है। Rails, Laravel, Django, Go templates, या ASP.NET जैसे बैकएंड फ्रेमवर्क्स फिर से प्राथमिक इंटरफ़ेस लेयर बन जाते हैं। फ्रंटएंड कोई अलग एप्लिकेशन नहीं है जो API का उपयोग करता है। यह वह हाइपरमीडिया इंटरफ़ेस है जिसे सर्वर तैयार करता है।
यह मॉडल सॉफ्टवेयर के एक आश्चर्यजनक रूप से विस्तृत हिस्से पर सटीक बैठता है। एक विशिष्ट SaaS एप्लिकेशन पर विचार करें। इसमें सॉर्ट करने योग्य तालिकाओं (tables) वाले डैशबोर्ड होते हैं। इसमें फॉर्म और फिल्टर वाले एडमिन पैनल होते हैं। इसमें ऐसे आंतरिक उपकरण (internal tools) होते हैं जो रिकॉर्ड्स को एक स्थिति से दूसरी स्थिति में ले जाते हैं। इसमें CRUD वर्कफ़्लो होते हैं जो एक सूची दिखाते हैं, विवरण दृश्य (detail view) प्रदान करते हैं, और उपयोगकर्ता को फ़ील्ड संपादित करने की अनुमति देते हैं। यह यहाँ तक कि वे AI इंटरफेस भी हैं जहाँ एक लैंग्वेज मॉडल यूजर को टोकन स्ट्रीम करता है, और प्रत्येक टोकन या पैराग्राफ को HTML में लपेटा जा सकता है और बातचीत के थ्रेड में जोड़ा जा सकता है। इन सभी के लिए, एक भारी JavaScript क्लाइंट अक्सर ज़रूरत से ज़्यादा (overkill) होता है।
इसके लाभ तत्काल और व्यावहारिक हैं। शुरुआती पेज लोड तेज़ होते हैं क्योंकि पहला सार्थक पेंट (meaningful paint) HTML के रूप में आता है, न कि हाइड्रेशन साइकिल (hydration cycle) पूरा होने के बाद। JavaScript पेलोड कम हो जाते हैं क्योंकि इसमें कोई वर्चुअल DOM, कोई क्लाइंट-साइड राउटर, और कोई स्टेट मैनेजमेंट लाइब्रेरी भेजने की ज़रूरत नहीं होती। सर्च इंजन बंडल्स को निष्पादित (execute) किए बिना पूरा कंटेंट देख सकते हैं, इसलिए SEO डिफ़ॉल्ट रूप से काम करता है। जटिलता कम हो जाती है क्योंकि एक ही कोडबेस रूटिंग, बिजनेस लॉजिक और रेंडरिंग को संभालता है। डिबगिंग आसान हो जाती है। जब कुछ गलत दिखता है, तो आप नेटवर्क टैब (Network tab) का निरीक्षण करते हैं और देखते हैं कि सर्वर ने वास्तव में कौन सा HTML भेजा है। यहाँ रिवर्स-इंजीनियर करने के लिए कोई अस्पष्ट क्लाइंट-साइड स्टेट ऑब्जेक्ट नहीं होता है।
React और भारी क्लाइंट्स का क्या?
इसका मतलब यह नहीं है कि React खत्म हो गया है, या SPAs एक गलती हैं। जटिल, एडिटर-ग्रेड एप्लिकेशन को अभी भी एक भारी क्लाइंट की आवश्यकता होती है। Figma ब्राउज़र के अंदर WebAssembly में कंपाइल किए गए C++ इंजन को चलाता है क्योंकि सर्वर राउंड-ट्रिप ड्राइंग को असंभव बना देंगे। Canva क्लाइंट-साइड ज्योमेट्री के साथ साठ फ्रेम प्रति सेकंड पर कैनवास को नियंत्रित करता है। Google Docs मिलीसेकंड में एडिटिंग संघर्षों (conflicts) को हल करने के लिए ऑपरेशनल ट्रांसफॉर्म्स का उपयोग करता है। ये उपकरण मूल रूप से ब्राउज़र टैब के माध्यम से दी जाने वाली डेस्कटॉप एप्लिकेशन हैं। वे वापस सर्वर-रेंडर किए गए फॉर्म्स पर नहीं जाने वाले हैं।
लेकिन अधिकांश सॉफ्टवेयर Figma नहीं हैं। अधिकांश सॉफ्टवेयर रियल-टाइम ग्राफिक्स एडिटर नहीं हैं। अधिकांश सॉफ्टवेयर एक रिपोर्टिंग स्क्रीन, एक कॉन्फ़िगरेशन पैनल, एक बुकिंग फ्लो, या एक कंटेंट मैनेजमेंट फॉर्म है। अनुप्रयोगों की उस लंबी श्रृंखला (long tail of applications) के लिए, केवल एक मोडल को टॉगल करने या रिकॉर्ड्स की सूची प्राप्त करने के लिए सैकड़ों किलोबाइट का JavaScript फ्रेमवर्क भेजना कभी भी बहुत समझदारी भरा नहीं रहा। स्टैक की अर्थव्यवस्था बदल रही है। हम फिर से खोज रहे हैं कि एज (edge) की बदौलत सर्वर यूजर के करीब हो सकता है, और ब्राउज़र स्वयं हर बाइट के लिए फ्रेमवर्क की मध्यस्थता के बिना अंशों (fragments) को अपडेट करने के लिए पर्याप्त सक्षम हो गया है।
पेंडुलम संतुलन पा रहा है
वेब आर्किटेक्चर का चाप (arc) सरलता की ओर वापस लौट रहा है, लेकिन यह नब्बे के दशक की ओर कोई नासमझ वापसी नहीं है। ब्राउज़र अधिक स्मार्ट हो रहा है। DPU जैसी विशेषताएं डेवलपर की चतुराई (ingenuity) को प्रतिस्थापित नहीं करती हैं; वे उन पैटर्नों को स्वयं प्लेटफॉर्म में समाहित कर लेती हैं जिन्हें हम हाथ से लागू किया करते थे — स्ट्रीमिंग, आंशिक अपडेट (partial updates), लक्षित DOM इंसर्शन (targeted DOM insertion)। HTMX हमें फ्रंटएंड में एक छोटा ऑपरेटिंग सिस्टम फिर से बनाए बिना उन व्यवहारों को व्यक्त करने के लिए शब्दावली प्रदान करता है।
अब आपको एक सरल आर्किटेक्चर और एक रिस्पॉन्सिव यूजर एक्सपीरियंस के बीच चयन करने की आवश्यकता नहीं है। आप दोनों पा सकते हैं। सर्वर इंटरफ़ेस को चला सकता है, ब्राउज़र इसे असेंबल कर सकता है, और आपके द्वारा लिखा गया JavaScript प्लंबिंग के बजाय वास्तविक इंटरएक्टिविटी पर ध्यान केंद्रित कर सकता है।
अगली पीढ़ी के डैशबोर्ड, एडमिन टूल्स और AI-संचालित इंटरफेस के लिए, सबसे स्मार्ट क्लाइंट वह हो सकता है जो कम काम करता है।