यह गलतफहमी कि Single Page App के अलावा इंटरैक्टिव web app नहीं बनाए जा सकते

 (htmx.org)
15 पॉइंट द्वारा GN⁺ 2024-11-19 | 8 टिप्पणियां | WhatsApp पर शेयर करें
  • कुछ डेवलपर्स मानते हैं कि उच्च-गुणवत्ता वाले application development के लिए SPA frameworks (React, AngularJS आदि) अनिवार्य हैं
  • लेकिन SPA से पहले भी MPA-आधारित applications बेहतरीन user experience देती रही हैं
  • मैंने HTMX का उपयोग करके data-केंद्रित MPA-आधारित observation platform विकसित करने की कोशिश की, और उचित optimization के साथ server-rendered MPA में भी उत्कृष्ट performance और user experience देना संभव है

MPA से जुड़ी गलतफहमियाँ और सच

गलतफहमी 1: MPA में page transition धीमा होता है
  • समस्या: क्योंकि browser डिफ़ॉल्ट रूप से हर page transition पर JavaScript और CSS को फिर से डाउनलोड करता है
  • समाधान:
    • PJAX, Turbolinks, HTMX Boost जैसी libraries का उपयोग करके केवल HTML body को बदलें
    • service worker का उपयोग करके page caching और request handling को बेहतर किया जा सकता है
    • उदाहरण: service worker लागू करने पर DOMContentLoaded समय 2.9 सेकंड से घटकर 500ms हो गया
service worker को लागू करने का तरीका
  1. sw.js फ़ाइल बनाएँ: caching और network requests को manage करने वाली script लिखें
  2. cache की जाने वाली files की सूची तय करें: HTML, CSS, JS आदि मुख्य assets निर्दिष्ट करें
  3. caching strategy सेट करें: static assets को स्थायी रूप से cache करें या समय-समय पर refresh करें
गलतफहमी 2: MPA में offline चलाना और network बहाल होने पर requests को सहेजना संभव नहीं
  • service worker का उपयोग करके app को offline स्थिति में भी चलाया जा सकता है
  • Workbox का उपयोग:
    • network failure होने पर requests को cache करता है और अधिकतम 24 घंटे के भीतर फिर से प्रयास करता है
    • offline handler सेट करके request आने पर वैकल्पिक content प्रदान किया जा सकता है
गलतफहमी 3: MPA में page transition के समय screen flicker होता है
  • समाधान:
    • service worker और preload API के साथ assets तैयार होने तक screen painting को delay करें
    • 2019 के बाद से browsers एक ही domain के भीतर transition को बिना flicker के handle करते हैं
गलतफहमी 4: MPA में आकर्षक page transition effects लागू नहीं किए जा सकते
  • SPA page transition animations के लिए प्रसिद्ध रहे हैं, लेकिन browsers ने भी अब इसे support करना शुरू कर दिया है
  • Chrome 126 में केवल CSS से cross-document transition animations लागू की जा सकती हैं
  • डेमो लिंक
गलतफहमी 5: HTMX या MPA में हर user action server पर process होता है
  • HTMX को इस तरह डिज़ाइन किया गया है कि केवल कुछ actions ही server पर process हों
  • आवश्यकता होने पर WebComponents या JavaScript frameworks से client-side interactive features जोड़ी जा सकती हैं
  • केवल कुछ specific components पर ही SPA तरीका लागू किया जा सकता है
गलतफहमी 6: DOM manipulation धीमा है, इसलिए React/Virtual DOM ज़रूरी है
  • Virtual DOM केवल अत्यधिक जटिल applications में ही performance का अंतर दिखाता है
  • अधिकांश सामान्य applications में DOM की direct manipulation पर्याप्त रूप से तेज़ होती है
  • संदर्भ सामग्री: "Virtual DOM is pure Overhead"
गलतफहमी 7: छोटे interactive features के लिए भी JavaScript ज़रूरी है
  • आधुनिक browser technologies के साथ JavaScript के बिना भी कई तरह की functionalities लागू की जा सकती हैं
    • HTML checkbox और CSS से toggle functionality बनाई जा सकती है
    • HTMX के साथ मिलाकर click पर data को asynchronously load किया जा सकता है
अंतिम गलतफहमी: SPA के बिना client-side code spaghetti code बन जाता है
  • spaghetti code के दौर में भी बहुत-सा उत्पादक software विकसित किया गया था
  • शुरुआती MVP चरण में सरल structure अधिक लाभकारी हो सकता है

निष्कर्ष

  • 2024 तक browsers ने SPA क्रांति से सीखी गई बातों को समाहित करते हुए काफ़ी प्रगति की है
  • केवल browser के मूल tools (HTML, CSS, JavaScript) से भी interactive और offline में काम करने वाले applications बनाए जा सकते हैं
  • browser की क्षमता पर भरोसा करें और इसे एक बार फिर पूरी तरह उपयोग में लें

संबंधित पढ़ाई

8 टिप्पणियां

 
pcj9024 2024-11-20

अगर आप लगभग एक-जैसे साधारण डेवलपर्स के साथ डेवलपमेंट करके देखें, तो तुरंत समझ आ जाएगा कि यह बात कितनी हवा-हवाई है। यह लिखने वाला या तो जीनियस लोगों से घिरा हुआ है, या अकेले काम करता है... (अभी भी पुराने पड़ चुके angularjs का ज़िक्र कर रहा है, इससे भी समझ आता है) और डेवलपमेंट सिर्फ जीनियस लोगों से नहीं होता
कोई इसे 'अपने जैसे लोगों का ही समूह' कहकर खारिज कर सकता है, लेकिन बदलाव हमेशा साधारण लोगों ने ही किया है
ऐसी बातें देखकर पहले यही लगता है कि htmx को किसी भी हालत में स्वीकार नहीं किया जाना चाहिए
 
konh2e 2024-11-20

यह हाल में बार-बार उठने वाला विषय है,
कुछ साल पहले Rich Harris ने इस विषय पर अपनी राय बताने वाला एक वीडियो साझा किया था।
https://www.youtube.com/watch?v=860d8usGC0o&t=635s

जहाँ तक मुझे याद है, इसका सार यह है कि partial HTML आधारित update तरीकों में स्क्रीन और डेटा के बीच असंगति पैदा होने की संभावना हो सकती है।
 
kwj9211 2024-11-19

क्या आप अब भी browser spec पर भरोसा करते हैं...?

अगर कहना ही हो, तो मुझे लगता है कि SPA ऐप development का ऐसा तरीका है जो browser के behavior पर अपेक्षाकृत कम निर्भरता रखता है।

यह सही है कि browser ने SPA की शानदार संभावनाओं को काफी हद तक catch up कर लिया है, और वह HTTP के मूल रूप से डिज़ाइन किए गए communication तरीके के भी ज़्यादा अनुकूल लगता है, लेकिन शायद ऐसा इसलिए भी है क्योंकि Chrome ने browser दुनिया में लगभग एकाधिकार जैसी स्थिति हासिल कर ली है और उसे कुछ breathing room मिल गया है... पता नहीं यह कितने समय तक चलेगा। चाहे वह breathing room हो या market share...
 
clickin 2024-11-19

Phoenix LiveView जैसी WebSocket-आधारित पद्धति में अगर सर्वर से DOM को manipulate किया जाता है, तो वह एक अलग paradigm है।
जब मैंने htmx इस्तेमाल किया, तो यह बात कि सर्वर से टूटे-फूटे HTML fragments भेजने पड़ते हैं, मुझे खास सुखद नहीं लगी।
खासकर CSS वाले हिस्से में, अगर class तय करके भेजी जाए, तो सर्वर के नज़रिए से यह जानना संभव नहीं होता कि स्क्रीन पर कौन-सी CSS इस्तेमाल हो रही है, इसलिए व्यवहार में यह लगभग common CSS को मजबूरन लागू करने जैसा लगता है।
 
colus001 2024-11-20

कुछ साल पहले मैंने Phoenix liveview से थोड़ा जटिल UI बनाने की कोशिश की थी, लेकिन साधारण interaction को implement करना भी बहुत पेचीदा था, और क्योंकि एक liveview को एक Elixir process संभालता है, इसलिए बगल के component के साथ interaction करना बहुत मुश्किल था। आखिरकार हार मानकर React पर वापस लौटने की याद है।
 
silveris23 2024-11-19

मुझे तो liveview भविष्य जैसा लगता है…
 
clickin 2024-11-20

liveview नेटवर्क पर काफ़ी ज़्यादा निर्भर करता है, इसलिए अगर सर्वर remote location में हो और ping ज़्यादा हो, या third world जैसे इलाकों में जहाँ internet infrastructure अच्छा नहीं है, वहाँ इसकी कमज़ोरी काफ़ी बड़ी लगती है.
 
GN⁺ 2024-11-19
Hacker News राय

  • इस बात पर जिज्ञासा है कि लेख में browser cache का उपयोग करके static CSS और JS assets को मैनेज करने के तरीके का उल्लेख क्यों नहीं किया गया। अतीत में जब किसी shopping site को MPA तरीके से बनाया गया था, तब page transition लगभग नज़र ही नहीं आते थे

  • कुछ लोग यह भी कहते हैं कि PHP और jQuery के दौर का web development सबसे अधिक productive था। यह राय भी है कि क्या React जैसी आधुनिक तकनीकों की तुलना में पुराने paradigm अधिक productive हो सकते हैं। Amazon या Steam जैसी बड़ी sites भी अब तक server पर HTML render करके उसमें JS जोड़ने के तरीके से बनाई जाती हैं

  • एक राय में यह समझाने का अनुरोध है कि service worker strategy, मौजूदा HTTP cache headers की तुलना में किस तरह बेहतर है। यह network round-trip को कम कर सकती है, लेकिन छोटे optimization के लिए पूरी चीज़ को फिर से आविष्कार करने जैसा महसूस होता है

  • "You Can't Build Interactive Web Apps Except as Single Page Applications... And Other Myths" शीर्षक में छोड़े गए हिस्से की वजह से यह clickbait जैसा महसूस होता है

  • programming में सबसे खतरनाक चीज़ developer की ऊब और अतीत के बारे में अज्ञानता है

  • एक राय है कि Node.js web server के दौर में server-side और client-side (SPA) के बीच यह द्वंद्व क्यों मौजूद है, यह समझ में नहीं आता। सवाल यह है कि क्या server पर अधिकांश काम initialize करके उसे client को serialize नहीं किया जा सकता ताकि वह SPA की तरह काम करे

  • SPA और MPA को अक्सर एक-दूसरे के विरोधी camp की तरह देखा जाता है, लेकिन इन्हें web stack के स्वाभाविक उपयोग और "hacking" तरीके के रूप में अलग किया जा सकता है। SPA अभी hacking वाला तरीका है, लेकिन अतीत में CGI, Java applet, Flash आदि भी थे। इस तरह के hacking तरीके स्वाभाविक तरीकों की सीमाओं का विस्तार करने की भूमिका निभाते हैं

  • तकनीकी stack का निर्णय लेने से पहले ही, कई बार developers यह ठीक से नहीं समझते कि वे क्या बना रहे हैं। अगर बहुत उच्च स्तर की interactivity की ज़रूरत नहीं है, तो अधिकतर मामलों में server-side framework ही पर्याप्त हो सकता है

  • "अगर single page app नहीं है, तो interactive web app नहीं बनाया जा सकता" इस मिथक का खंडन भी किया गया है। SPA अधिक नियंत्रण देता है और code के कुछ हिस्सों को दोबारा काम करने की संभावना को कम करता है

  • HN headline, असली headline की तुलना में अधिक आक्रामक है। यह BigSkyDevCon में Tony Alaribe द्वारा प्रस्तुत एक essay है, जो non-SPA आधारित web applications को तेज़ और smooth बनाने की तकनीकों पर चर्चा करता है। इसमें नई तकनीकों का परिचय दिया गया है, और इसे conference की सर्वश्रेष्ठ presentations में से एक माना गया