- View Transitions API जैसे modern CSS features के आने से अब स्मूद page transitions के लिए SPA संरचना की ज़रूरत नहीं रह गई है
- अधिकांश SPA sites वास्तव में अपेक्षित performance या smooth experience नहीं दे पातीं, बल्कि भारी JavaScript code अक्सर user experience को खराब करता है
- Chromium-आधारित browsers में native page transitions और Speculation Rules का उपयोग करके, JavaScript के बिना भी तेज़ और स्वाभाविक navigation लागू किया जा सकता है
- SPA की जटिल संरचना browser optimizations में बाधा डालती है, इसलिए वास्तविक websites के लिए HTML और CSS-केंद्रित MPA structure अधिक तेज़ और प्रबंधन में आसान है
- आगे चलकर अनावश्यक SPA अपनाने से बचना चाहिए, और modern CSS व native features का उपयोग करके कुशल और maintainable website development की आवश्यकता है
परिचय: SPA का अंत और modern CSS का उदय
- हाल के View Transitions API जैसे नए CSS features के आने से, पारंपरिक SPA (single-page application) के मुख्य फायदे अब आवश्यक नहीं रह गए हैं
- अभी भी कई development teams React, Vue जैसे SPA frameworks चुनती हैं, लेकिन उस निर्णय का केंद्र performance नहीं बल्कि interaction और smooth navigation experience को लेकर गलतफहमी है
- स्मूद navigation के लिए SPA अनिवार्य है, यह मान्यता अब पुरानी सोच बन चुकी है
SPA का भ्रम और वास्तविकता
- कभी SPA सबसे स्वाभाविक page transitions लागू करने का एकमात्र तरीका था, लेकिन अब ऐसा नहीं है
- कई SPA में निम्न समस्याएँ होती हैं:
- केवल loading state fade effects होते हैं, पर असली content transition की smoothness की कमी रहती है
- scroll restoration issues और inconsistent focus handling
- rendering/hydration delay के कारण navigation delay
- layout shift, content pop-in, skeleton loading आदि
- performance के मुकाबले बहुत कम लाभ देने वाली अनावश्यक जटिलता और JavaScript का अत्यधिक उपयोग
- प्रमुख SPA frameworks (Next.js, Gatsby, Nuxt आदि) मूल native browser behavior की नकल करने के लिए बड़ी मात्रा में JS code जोड़ते हैं
- परिणामस्वरूप native smoothness की कुर्बानी देनी पड़ती है, speed धीमी हो जाती है और SEO भी प्रभावित होता है
web platform का विकास और CSS की बदलती भूमिका
- नवीनतम Chromium-आधारित browsers (Chrome, Edge आदि) native, declarative page transitions को support करते हैं
- View Transitions API के माध्यम से JavaScript के बिना भी documents या full pages के बीच smooth animations लागू किए जा सकते हैं
- इसकी मुख्य क्षमताएँ इस प्रकार हैं:
- pages के बीच fade effect (सिर्फ 3~4 lines of CSS से संभव)
- thumbnail से detail image तक स्वाभाविक बदलाव जैसे shared element animations
- header, navbar जैसी persistent elements को बनाए रखना
- वास्तविक URL और वास्तविक page navigation होने के कारण SEO, link sharing, back/forward cache आदि के साथ अधिकतम compatibility
CSS और JS की synergy का पूरा लाभ कैसे लें
- ज़रूरत पड़ने पर JS के माध्यम से page-internal transitions के लिए भी View Transition को manually trigger किया जा सकता है
- उदाहरण: theme switch, tab toggle, dark mode transition आदि में बहुत कम JavaScript का उपयोग
Speculation Rules और त्वरित navigation
- Speculation Rules browser को pages को पहले से preload/prerender करने देते हैं, ताकि user behavior (जैसे mouse hover) का अनुमान लगाकर तुरंत navigation दिया जा सके
- इसे declaratively
<script type="speculationrules"> के माध्यम से सेट किया जा सकता है
- शर्त: जब page हल्का और optimized हो, तब performance को अधिकतम करने में प्रभावी; भारी pages में यह उल्टा resource waste भी कर सकता है
browser की native capabilities का सम्मान और bfcache
- bfcache(Back/Forward Cache) उपयोगकर्ता के पीछे/आगे जाने पर पूरे page को snapshot की तरह तुरंत restore कर देता है
- शर्त: शुद्ध HTML और CSS आधारित, clean architecture होनी चाहिए; SPA जैसी routing-intercepting संरचना में यह लागू नहीं हो पाता
- निष्कर्षतः, modern browsers सरल और मज़बूत websites को पुरस्कृत करने की दिशा में विकसित हो रहे हैं
SPA और MPA performance तुलना
- औसत SPA (Next.js के आधार पर):
- JS bundle size: 1~3MB
- TTI (usable होने का समय): 3.5~5 सेकंड
- route transition: नकली/सिम्युलेटेड
- SEO: जटिल, maintain करना कठिन
- scroll/anchor behavior: अस्थिर
- modern MPA (CSS transitions और Speculation Rules के साथ):
- JS bundle: 0KB (केवल optional enhancement)
- TTI: लगभग 1 सेकंड
- route transition: असली native behavior
- SEO: बहुत आसान
- smart scroll, focus, history: browser default behavior और पूर्ण support
website और app का अंतर, उपयुक्तता पर पुनर्विचार की ज़रूरत
- अधिकांश websites वास्तव में "app" नहीं हैं, और उन्हें shared state, client routing, complex interactions की आवश्यकता नहीं होती
- marketing pages, documentation portals, e-commerce, blogs आदि के लिए HTML-केंद्रित, तेज़ loading, simple structure अधिक उपयुक्त है
- हर project में SPA stack अपनाने से अनावश्यक जटिलता और performance degradation हो सकता है
- "app जैसा दिखना चाहिए" जैसी मांग
- framework अपनाना
- client routing और जटिलता में वृद्धि
- performance में गिरावट और अतिरिक्त optimization की ज़रूरत
- फिर भी native link transitions + CSS animations वाली संरचना से धीमा रहना
निष्कर्ष और सिफारिश
- SPA अतीत में platform limitations के लिए एक अस्थायी उपाय जैसा था, लेकिन अब वे बाधाएँ काफी हद तक समाप्त हो चुकी हैं
- अब निम्न native features का सक्रिय उपयोग संभव है:
- असली page-to-page transitions
- Speculation Rules के माध्यम से त्वरित pre-rendering
- progressive degradation के प्रति मज़बूत संरचना
- साफ markup, तेज़ loading, वास्तविक URLs का उपयोग
- ऐसी संरचना जो platform की क्षमताओं का अधिकतम लाभ उठा सके
- यदि केवल "smoothness" के कारण SPA पर अड़े रहेंगे, तो जटिलता, performance और maintainability—तीनों की कीमत चुकानी पड़ेगी
- server rendering, real pages, CSS-based animations, intentional preloading, और minimal JS के साथ आज के समय के अनुरूप तेज़ और बेहतर websites बनाई जा सकती हैं
- 2025 की तकनीक का उपयोग करते हुए, हमें अधिक तेज़, अधिक सरल और सभी के लिए स्वागतयोग्य web experience की दिशा में बढ़ना चाहिए
10 टिप्पणियां
शुरू से ही अगर सिर्फ़ "smoothness" की वजह से SPA पर विचार करने की स्थिति होती, तो मैं वैसे भी बस smoothness छोड़कर MPA में ही लिखता, इसलिए इससे ख़ास सहमति नहीं बनती...
इस लेख की कमी यह है कि
SPA के असली उद्देश्य की संकीर्ण व्याख्या की गई है
View Transitions API वाकई शानदार है, लेकिन केवल उससे SPA की ज़रूरत खत्म नहीं हो जाती।
सभी वेबसाइटों को एक ही मानदंड से देखा गया है
मार्केटिंग साइट ≠ डैशबोर्ड ≠ कॉमर्स ऐप ≠ रियल-टाइम collaboration tool
इन सभी की संरचनात्मक ज़रूरतें अलग होती हैं।
वास्तविक उपयोग में SPA + SSR + MPA साथ-साथ मौजूद हैं
Next.js जैसे hybrid framework इसे अच्छी तरह दिखाते हैं।
स्टैटिक assets के लिए SSG, लॉगिन के बाद डैश के लिए CSR/SPA, search engine के लिए SSR जैसे लचीले संयोजन की ज़रूरत होती है।
मेरा मानना है कि SPA केवल user experience ही नहीं, बल्कि structural improvement का भी परिणाम है।
जिन पेजों में SPA की ज़रूरत नहीं है, वहाँ MPA + modern CSS एक अच्छा विकल्प हो सकता है, लेकिन संरचना, state, scalability और maintenance के लिहाज़ से SPA अब भी ज़रूरी है। मेरा मानना है कि modern CSS, SPA को "पूरक" कर सकता है, लेकिन "प्रतिस्थापित" नहीं कर सकता।
आपके दिए गए उदाहरणों में SPA को View Transition वगैरह से प्रतिस्थापित न कर पाने वाला मामला वास्तव में सिर्फ real-time collaboration tool का है, और अधिकांश वेबसाइटें real-time collaboration tool नहीं होतीं। मार्केटिंग साइट, डैशबोर्ड, commerce app—इन सबको SPA framework के बिना भी server rendering, full page, CSS-आधारित animation, जानबूझकर preloading, और न्यूनतम JS अपनाने जैसी शर्तें रखते हुए बनाया जा सकता है। इस दिशा को लक्ष्य बनाने वाला Rails ecosystem का Hotwire भी है, और इसके production उदाहरण के तौर पर Basecamp और HEY भी मौजूद हैं। State management? जब तक वह real-time collaboration tool जैसा कुछ न हो, URL parameter, server session जैसी server-side विधियाँ या local storage ही काफी हैं। Page transition देखकर SPA अपनाने के मामले भी निश्चित रूप से हैं (जैसे AGF की official site; वहाँ Astro से भी पर्याप्त काम चल सकता था, फिर भी React अपनाया गया), और SPA के प्रतिनिधि फायदों में page transition का अक्सर उल्लेख होना इस बात से इनकार नहीं किया जा सकता।
मौजूदा SPA frameworks और उन पर आधारित frontend trends के बारे में यह सच है कि उन्हें लगातार non-standardization से सावधान रहने की ज़रूरत है, और वे over-engineering तथा अनावश्यक resource consumption को बढ़ावा देने में भी आसान हो सकते हैं, लेकिन…
SPA की अवधारणा को भी बहुत संकुचित तरीके से देखा जा रहा है, लेकिन उससे भी बढ़कर मुझे संदेह है कि लोग यह समझते हैं या नहीं कि SPA frameworks पूरे development पर किस तरह का प्रभाव डालते हैं।
यह कहना कि सिर्फ View Transition API और CSS से सब कुछ हो जाएगा, दूसरे शब्दों में यह कहने जैसा है कि उससे असंबंधित बाकी सभी features, और उन्हें हासिल करने के paradigms, सब पूरी तरह निरर्थक हैं — मुझे यह कुछ ज़्यादा ही अहंकारी दृष्टिकोण लगता है.
यह उस over-engineering से अलग मुद्दा है जो brochure की जगह लेने भर वाली site को React से बनाने पर होता है।
मैं इस बात से सहमत हूँ कि ज़्यादातर छोटे projects में बेवजह SPA framework की ज़रूरत नहीं होती, लेकिन जिन services में complex interaction, continuous user experience, और उसके अनुरूप maintenance तथा निरंतर improvement की requirements होती हैं, वहाँ CSS के विकास के बावजूद ऐसा नहीं मानता।
सच कहूँ तो, यह वैसा ही लगता है जैसे Rust या Haskell को छुए बिना ही कहना, 'उसकी ज़रूरत नहीं, आजकल C++ से सब हो जाता है।'
हम्म, पता नहीं। क्या SPA framework इस्तेमाल करने का मकसद smooth transition से ज़्यादा user के साथ complex interaction के लिए नहीं होता?
सिर्फ एक smooth interaction के लिए भी SPA framework अपनाने के मामले वाकई मौजूद हैं। लेकिन SPA लागू की गई बहुत-सी साइटों को जटिल interactions की ज़रूरत ही नहीं होती।
पूरी तरह सहमत हूँ
सीधे उदाहरण के तौर पर React खुद भी फ्रंटएंड का Spring ही है
यह भारी और जटिल है; लगता है कि काम आसान हो गया है, लेकिन असल में हल्के काम करने के लिए पहले ज़्यादा जटिल प्रक्रिया सेट कर दी जाती है, और फिर उसी बेवजह जटिल हुई प्रक्रिया को सुविधाजनक बना देने वाली एक अजीब तरह की सुविधा बन जाती है
सहमत हूँ। अगर वह Google Docs जैसा कोई जटिल web app नहीं है, तो Rails इकोसिस्टम में बना Howired भी काफ़ी है, और static pages के लिए Astro भी पर्याप्त है।
Hacker News की राय
SPA तब मायने रखता है जब यूज़र एक ही ऐप में लंबा सेशन बिताते हैं; यानी एक बार बड़ा bundle लोड किया जाता है और उसके बाद सिर्फ छोटे network requests के साथ ऐप इस्तेमाल किया जा सकता है। स्मूद transition effects तो बस अतिरिक्त फायदा हैं, और मुझे नहीं लगता कि वही SPA की मूल समस्या है जिसे यह हल करता है। यह कहना कि client-side routing सिर्फ page transitions के लिए है, SPA के उद्देश्य को गलत समझना है। अगर आपने इसी गलत धारणा पर SPA अपनाया, तो यह लेख सही है, लेकिन SPA का उदय jQuery के दौर में जटिल apps के लिए हुआ था। उस समय बड़े jQuery codebase में हर div एक mini-app की तरह व्यवहार करता था और कई छोटे network requests से sync होता था। पुराने browsers और धीमे internet में हर बार पूरा code दोबारा reload किए बिना इसे अधिक कुशलता से चलाया जा सकता था। बाद में React जैसे frameworks ने structured app development को आसान बनाया, और SPA का असली फायदा यही है कि लंबे सेशन वाले users के लिए एक बार बड़ा bundle cache कर लिया जाए और उसके बाद network traffic को न्यूनतम रखा जाए।
(ऊपर की राय से उद्धरण: "...if you shared that misunderstanding of SPAs and used them to solve the wrong problem, this article is 100% correct.") मैं इससे पूरी तरह सहमत हूँ। लेखक एक SEO consultant है, इसलिए लगता है कि वह सिर्फ marketing websites पर ध्यान दे रहा है। असली apps (marketing websites नहीं) SPA से बहुत लाभ उठा सकते हैं। उदाहरण के लिए, सोचिए Google Maps को SPA के बिना बनाया जाए—सिर्फ page transition animation जोड़ देने पर भी UX बुरी तरह खराब हो जाएगा।
इसमें “सिर्फ jQuery spaghetti जमा की” जैसा भाव है, लेकिन वास्तव में मैंने IIFE जैसे शुरुआती JS design patterns का इस्तेमाल करके code structure, lazy module loading, code obfuscation आदि किया था। और मेरे अनुभव में frontend को संरचित करने की कोशिशों में AngularJS सबसे बड़ा कदम था, और Java developers को यह इसलिए भी आकर्षक लगा क्योंकि इसमें modularity, DI, और testing आसान थी। शुरुआत में जब Backbone से ऐप बनाया था, तब लगा था कि ज़्यादातर functionality backend में रहेगी इसलिए testing पर ज़्यादा ध्यान नहीं दिया। बाद में AngularJS में rebuild करते समय frontend testing बहुत बढ़ गई। हाँ, आज के Angular code या Java code की verbosity, complexity और indirection से अब मुझे भी चिढ़ होती है।
मुझे लगता है कि धीमा network connection और आक्रामक caching ऐसा मजबूत कारण है जिसकी वजह से SPA की ज़रूरत पड़ सकती है, खासकर websites की तुलना में applications में। अगर शुरुआत में ठीक-ठाक connection मिल जाए और पूरा frontend एक बार में cache हो जाए, तो बाद का उपयोग बहुत कम bandwidth में हो सकता है।
अगर आप किसी ऐसे स्थान पर काम करते हैं जहाँ modern CI/CD pipeline है, तो दिन में कई बार deployment होने पर वह बड़ा JS bundle बार-बार rebuild होगा और cache invalidate होने की संभावना रहेगी। HTTP2 को browser default बने 10 साल हो चुके हैं, और multiplexing की वजह से JS bundle को बहुत बड़ा करके बाँधने का कारण कम हो गया है। बड़े bundle बनाने वाला SPA तरीका browser और server की आधुनिक क्षमताओं का पूरा लाभ नहीं उठाता।
मैं जानना चाहता हूँ कि loading के बाद network requests वाकई कितनी छोटी हो जाती हैं। मेरे अनुभव में अधिकांश SPA loading के बाद भी बड़े calls करते रहते हैं, और सीधे HTML भेजने की तुलना में बहुत धीमे होते हैं। यह दावा भी सही नहीं कि JSON किसी तरह magically HTML से बेहतर compress हो जाता है। HTML भी काफ़ी अच्छी तरह compress होता है। वास्तव में network वजहों से SPA बेहतर है—यह तर्क अक्सर प्रचार या अंधविश्वास जैसा लगता है।
मेरे हिसाब से SPA की value सिर्फ smooth transitions में नहीं, बल्कि इस बात में है कि user journey का अधिकांश हिस्सा client side पर संभाला जा सकता है और server की लगभग चिंता नहीं करनी पड़ती। उदाहरण के तौर पर, 2025 में भी यह खलता है कि ज़्यादातर online stores में filter बदलने या category खोलने पर पूरा page reload होता है और data फिर से लाना पड़ता है। अगर user category के बीच बार-बार जा रहा है, तो पूरा catalog एक बार client पर उतारकर उसके बाद server से बात किए बिना filtering कर पाना UX को बहुत बेहतर बना सकता है। हाँ, कोई कह सकता है कि data बहुत होगा, लेकिन अधिकतर shopping categories कुछ KB में समा जाती हैं, एक product photo से भी छोटी। 2005 से ऐसे apps बनाते हुए भी मैं अब तक नहीं समझ पाया कि यह UX अधिक व्यापक क्यों नहीं हुआ।
मेरे विचार से full reload की सबसे बड़ी असुविधा data size नहीं, बल्कि site efficiency है। असली data तो कुछ KB होता है, लेकिन page खुद 100MB download करता है और browser 1GB RAM खा जाता है। उदाहरण के लिए, Hacker News में अधिकतर navigation reload आधारित है और यह पुराने laptop पर भी ठीक चलता है। जबकि DoorDash जैसा SPA उसी मशीन पर 30 सेकंड लेता है, और असल में खाना order करने में 3 मिनट से ज़्यादा लग गए। UI आने में ही 2.5 मिनट लग गए थे, और तब भी लगभग कुछ भी full reload नहीं था।
HTMX जैसे tools इन समस्याओं का बड़ा हिस्सा हल कर देते हैं। मुझे लगता है SPA तरीका अंततः frontend और backend नाम के दो अलग apps बना देता है। मैं server side पर ज़्यादातर काम करने और client side पर सिर्फ साधारण interactive effects (show/hide, expand/collapse, effects आदि) जोड़ने के पक्ष में हूँ। बेशक, कुछ जगहों पर SPA उपयोगी है।
इसी तरह का एक अनुभव यह है कि मेरे कुछ personal projects static web server पर host हैं। हज़ारों अलग-अलग pages render करने के बजाय मैं एक JSON file से SPA में client-side rendering करता हूँ। मैंने Github Pages का भी इस्तेमाल किया है। हाल में मैं sqlite database के wasm build के साथ ऐसी संरचना पर प्रयोग कर रहा हूँ जिसमें HTTP Range Requests के ज़रिए सिर्फ ज़रूरी pages लाए जाते हैं। sqlite का Full Text Search काम तो करता है, लेकिन छोटे search के लिए पूरी table लानी पड़ती है, जो थोड़ा निराशाजनक है। शायद पूरा DB डाउनलोड करके local में FTS table बनाना बेहतर हो।
एक counter-example भी है। मान लीजिए “sci-fi” category को Shift-click करके नए tab में खोलना है। MPA में यह बिना अतिरिक्त मेहनत के हो जाता है, लेकिन SPA में इसे अलग से संभालना पड़ता है, जो झंझट है। और अगर category links ही न हों और सिर्फ Select Box से पहुँचना पड़े, तो UX अच्छा नहीं रहता।
आम तौर पर कंपनियाँ नहीं चाहतीं कि user पूरा catalog download कर ले, क्योंकि competitor उसका आसानी से analysis कर सकता है। और book selling जैसे मामलों में titles लाखों में हो सकते हैं, इसलिए सब कुछ एक साथ भेजना user experience, bandwidth और memory—तीनों दृष्टि से अक्षम है।
SPA का उद्देश्य हरगिज़ page transitions नहीं है। अच्छे page transitions सही तरह लागू करने वाले SPA बहुत कम हैं। उदाहरण के लिए, Next.js में root loading के तरीके की वजह से page transitions लागू करना लगभग असंभव जैसा है। मैंने खुद Next.js में उचित page transition support जोड़ने की कोशिश की थी, और वह एक बुरा सपना था। मुझे SPA के दो साफ फायदे दिखते हैं। पहला, ज़्यादातर apps कुछ हद तक interactivity चाहते हैं, इसलिए React और plain HTML को मिलाकर चलाना बहुत दर्दनाक है, खासकर जब global state management चाहिए हो। दूसरा, अगर पूरी page structure पहले से load हो, तो बाद में data loading तेज़ होती है, और click के तुरंत बाद प्रतिक्रिया व loading state दिखना 500ms बाद प्रतिक्रिया मिलने से बेहतर UX देता है। (हाँ, अगर देरी 100ms से कम हो तो बात अलग है।) पूरा page दोबारा draw नहीं करना पड़ता, इसलिए frontend performance ऐसी चीज़ है जिसमें सिर्फ HTML पीछे रह जाता है। Basecamp जैसे जटिल webapp ऐसे उदाहरण हैं जो SPA के बिना भी अच्छे बने हैं, लेकिन 30 सेकंड इधर-उधर click करके देखिए, वे SPA की performance तक नहीं पहुँचते। मैं चाहता हूँ कि web अपने मूल स्वभाव के अनुरूप काम करे, लेकिन Next.js और SPA जो complexity जोड़ते हैं, उन्होंने apps को तेज़ और अधिक responsive तो बनाया है, साथ ही development को अधिक झंझटभरा और bundles को बड़ा भी किया है। फिर भी मुझे नहीं लगता कि सिर्फ HTML अभी SPA की performance तक पहुँच सकता है।
मुझे नहीं पता यह SEO consultant किस दुनिया में रह रहा है। Next और Nuxt को SPA के विपरीत खड़े प्रमुख frameworks के रूप में दिखाना पूरी तरह गलत है। 1. अमेरिका/पश्चिमी दुनिया में Next ने लगभग पूरी तरह कब्ज़ा कर लिया है, और नई React app की बात हो तो अधिकतर लोग Next ही मतलब रखते हैं। Vue ecosystem में Nuxt लगभग standard है, और Nuxt = Vue दुनिया का Next है। यानी लोग अनजाने में Next और MPA strategy चुन रहे हैं। पेंडुलम इतना MPA की ओर झूल चुका है कि अब तो उल्टा SPA आज़माने की सलाह देनी चाहिए। पिछले 8 साल MPA की लहर के रहे हैं, और अब Facebook भी आधिकारिक docs में Create React App के बजाय Next recommend करता है। 2. Next की complexity पर शिकायत दरअसल आधुनिक MPA strategy की कठिनाई की शिकायत है; SPA पक्ष तो लगभग 10 साल से ठहरा हुआ है। 3. MPA development, SPA से कहीं कठिन है, क्योंकि server और client के बीच विभाजन को अधिक सख्ती से निभाना पड़ता है। 4. अगर आप SPA में MPA-style data loading करना चाहते हैं, तो वह developer का चुनाव है, और उसके फायदे-नुकसान भी उसी को उठाने होंगे। चाहें तो data पहले से load करके SPA navigation को instant बनाया जा सकता है। 5. सिर्फ SEO-गंभीर मुख्य frontend ही नहीं, उससे कहीं अधिक internal dashboards और apps भी होते हैं। React developers अक्सर उन्हीं पर काम करते हैं, इसलिए पहली frame को हर हाल में परफेक्ट बनाने के बोझ से अनावश्यक भार न लेना महत्वपूर्ण है।
मुझे लगता है SPA को नीचा दिखाने वाला लहजा अनुचित है। SPA में निस्संदेह ज़्यादा मेहनत लगती है, लेकिन उसके फायदे भी स्पष्ट रूप से अधिक हैं। लंबे समय तक app-जैसा UX बनाने का एकमात्र तरीका SPA ही था। लेखक app fatigue की बात करता है, लेकिन अगर सचमुच ‘application’ जैसा अनुभव देना है, तो SPA लगभग अकेला रास्ता है। भारी SPA की तुलना हल्की website (static site) से करना उचित नहीं है। अगर कोई हल्की website बना सकता है, तो वैसी ही हल्की SPA भी बना सकता है। SPA हो या website, अगर उसे अक्षम ढंग से बनाया जाए तो दोनों धीमे और भारी हो सकते हैं। SPA में बहुत निवेश करने वाले व्यक्ति के रूप में मैं हमेशा इस बात में दिलचस्पी रखता रहा हूँ कि क्या कम मेहनत में वही अनुभव देने का कोई तरीका है, लेकिन यह लेख मुझे थोड़ा-सा visual garnish जैसा लगता है। यह policy मूल्यवान है, पर इतना प्रभावशाली नहीं कि सिर्फ इसी से SPA बनाम non-SPA का निर्णय हो जाए।
“SPA framework के बिना linear.app बनाकर दिखाओ” यह माँग वाजिब लगती है, और “Native CSS transitions ने SPA का सबसे बड़ा फायदा (client routing) खत्म कर दिया” यह कथन तर्कहीन है।
Linear, SPA के भीतर भी एक बहुत खास मामला है। यह बात नहीं हो रही कि SPA पर प्रतिबंध लगा दो या browser से JS पूरी तरह हटा दो। Linear तेज़ इसलिए है क्योंकि उसका design “offline-first” है, लेकिन बहुत कम services ऐसा करती हैं। Ticket booking, forums, news, blogs, और information sites के लिए SSR-आधारित development कहीं अधिक उपयुक्त लगता है। जहाँ सच में SPA ज़रूरी हो वहीं SPA इस्तेमाल करें, और बाकी जगह SSR से तेज़ development करें, साथ में CSS से उसे SPA जैसा अहसास दें—यह कहीं अधिक कुशल है।
SPA के लिए जगह है, लेकिन बाकी 99% sites को SPA होने की ज़रूरत नहीं है।
SPA का उद्देश्य view transitions (page transitions) नहीं है। मूल लेख (TFA) यह संकेत देता है कि pages के बीच flashy transitions महत्वपूर्ण हैं—जो गलत सोच है। “CMO” या “brand manager” को दोष देने के बजाय SPA के मूल मूल्य पर रोशनी डालनी चाहिए। SPA client logic के लिए उत्कृष्ट framework है, concerns की separation (frontend logic और backend को अलग करना), बेहतर developer experience, तेज़ development speed आदि जैसे कई फायदे देता है। ऐसे लेख बहुत दिखते हैं क्योंकि वे मेरे इस comment की तरह बहस खड़ी करने के लिए बने होते हैं, लेकिन सच कहूँ तो मुझे नहीं लगता कि यह इतना ध्यान पाने योग्य लेख है।
मेरी नज़र में SPA का मुख्य वादा smooth transitions नहीं, बल्कि backend से पूरी तरह अलग data API और frontend बनाना है। इसी वजह से मुझे SSR और client rendering का मिश्रण पसंद नहीं। मेरे हिसाब से या तो चीज़ website होनी चाहिए या app।
मेरे मन में यह सवाल भी है कि “SPA और MPA की कसौटी आखिर क्या है?” मेरी Next.js-आधारित personal site में वस्तुतः लगभग सब कुछ server-side render होता है। technically वह SPA है, लेकिन JS चालू होने पर RSC और client-side navigation काम करते हैं, और JS बंद होने पर भी client-only components (जैसे QR code generator) fallback content दिखाते हैं और बाकी सब पूरी तरह SSR में render होता है, इसलिए थोड़ा धीमा सही, पर सही ढंग से काम करता है। Components को server पर render न करना वास्तव में ज़्यादा मेहनत का काम है। Progressive enhancement सबसे बेहतर है।
SEO industry या कोविड के बाद भर्ती हुए नए web developers द्वारा SPA को बार-बार गलत समझना और नीचा दिखाना मेरे लिए बहुत निराशाजनक है। 2000 के दशक से development कर रहे व्यक्ति के रूप में मैं कहूँगा कि SPA की असली उत्पत्ति मूल लेख में बताए गए “झूठे वादे” से नहीं हुई थी, बल्कि 2000 के दशक के अंत से 2010 के शुरुआती वर्षों में mobile-first strategy फैलने के कारण frontend और backend को पूरी तरह अलग करना आवश्यक हो गया था। उससे पहले frontend का मतलब अक्सर server templates से HTML render करना और उस पर थोड़ा-सा jQuery लगाना भर होता था। लेकिन अब mobile और desktop apps दोनों को वही business logic और DB इस्तेमाल करनी होती है, इसलिए REST architecture, Roy Fielding के papers, service-oriented architecture, और APIs को बाहरी रूप से expose करना मुख्यधारा बन गया। इसमें cost optimization का पहलू भी था। इसी दौर में Ruby on Rails या Django जैसे full-stack web frameworks कुछ समय के लिए सुस्त पड़े। Node.js के उभार के साथ browsers और mobile devices भी अधिक शक्तिशाली होते गए, जिससे काफ़ी business logic को “edge devices” यानी client side पर ले जाना संभव हुआ। SPA का असली सार यही है। मुझे नहीं लगता कि CSS उस ज़रूरत की जगह ले सकता है।