HTML-प्रथम साइट बनाने से हमारे उपयोगकर्ता रातोंरात दोगुने हो गए
एक किस्सा जिसमें एक UK utility ने एक fragile JavaScript-heavy form को Astro-powered, “HTML‑first” साइट से बदला और completed applications दोगुने कर दिए, इस बहस को फिर से तेज कर दिया है कि web कैसे बनाया जाना चाहिए। कई commenters का तर्क है कि progressive enhancement, standard HTML forms, और server-side rendering तेज़, अधिक accessible सेवाएँ देते हैं—खासकर low-end devices, खराब connections, या पुराने browsers वाले users के लिए—जबकि अन्य लोग नोट करते हैं कि सक्षम teams React और SPAs के साथ भी अच्छे परिणाम हासिल कर सकती हैं। यह thread दिखाता है कि defaults, tooling ecosystems, और developer education अक्सर teams को overcomplicated front ends की ओर धकेलते हैं, जिसका usability, accessibility, और यहाँ तक कि basic reach पर भी वास्तविक खर्च पड़ता है।
HTML-प्रथम और प्रगतिशील संवर्धन
- कई लोग इस कहानी को HTML-प्रथम, प्रगतिशील रूप से संवर्धित साइटों के लिए एक मज़बूत केस स्टडी मानते हैं, खासकर सार्वजनिक सेवाओं और फ़ॉर्म्स के लिए।
- क्लासिक वेब पैटर्न (लिंक, फ़ॉर्म, रीडायरेक्ट, बहु-पृष्ठ “विज़ार्ड”) की प्रशंसा इस वजह से की जाती है कि वे:
- JS बंद होने या टूटने पर भी काम करते हैं।
- उपयोगकर्ताओं को अंतर्निहित ब्राउज़र व्यवहार देते हैं (back/forward, validation UI, focus, keyboard access)।
- SPAs में आम दिखाई देने वाले अदृश्य विफलता मोड्स (spinners, silent JSON errors) को कम करते हैं।
- कुछ लोग नोट करते हैं कि यह मूलतः “progressive enhancement” की पुनर्खोज है, और वही चीज़ है जिसे लंबे समय से Rails/Django जैसे frameworks प्रोत्साहित करते आए हैं।
React, SPAs, और प्रदर्शन
- एक आवर्ती विषय भारी React/SPA stacks, build steps, और मूल फ़ॉर्म्स या लगभग स्थिर content के लिए megabytes of JS को लेकर निराशा है।
- कई लोग तर्क देते हैं कि जबकि आप React के साथ अच्छा UX बना सकते हैं, उसके साथ खराब, नाज़ुक, inaccessible, या bloated apps बनाना आसान है:
- Defaults client-side rendering और semantic HTML के बजाय custom widgets की ओर झुकते हैं।
- बहुत से developers को JS के बिना working forms बनाना नहीं आता।
- अन्य लोग पलटकर कहते हैं: असली समस्या design और developer skill है, framework खुद नहीं; आप HTML-only React या धीमे server-rendered sites भी ship कर सकते हैं।
Astro, HTMX, Go और अन्य stacks
- Astro की बार-बार सराहना की जाती है क्योंकि यह default रूप से static HTML और JS के “opt‑in” islands पर चलता है, React/Next के “opt‑out” रुझान के विपरीत।
- HTMX + Go + SQLite को कई apps के लिए एक “boring but effective” stack के रूप में उद्धृत किया जाता है, जिसमें minimal JS और आसान deployment होता है।
- कुछ लोग Hotwire, server-driven mobile approaches, static site generators (Jekyll), और simple SSR को भी व्यावहारिक विकल्पों के रूप में चर्चा करते हैं।
Accessibility, devices, और user empathy
- टिप्पणीकार low-end phones, पुराने browsers, consoles, या खराब connections पर वास्तविक users की बात करते हैं; ये user अक्सर JS-based analytics में अदृश्य रहते हैं।
- इस पर बहस है कि वास्तव में कितने users के पास JS या modern TLS नहीं है:
- एक पक्ष: भले ही यह ~1% हो, वे अक्सर सबसे vulnerable होते हैं और services (खासकर gov/utility) को उन्हें accommodate करना चाहिए।
- अन्य लोग तर्क देते हैं कि HTTPS‑only और JS‑heavy practices अब norm हैं, कभी-कभी browser और platform policies के कारण।
- उम्र और digital literacy पर भी चर्चा होती है: कई non-technical users (हर उम्र के) complex UIs के मानसिक मॉडल नहीं रखते, इसलिए simple, robust flows मायने रखते हैं।
Metrics, trade-offs, और culture
- कई लोग नोट करते हैं कि “doubled users” का परिणाम असल में traffic नहीं, बल्कि higher form completion / lower abandonment के बारे में है।
- कुछ लोग trade-offs पर ज़ोर देते हैं:
- HTML-first का मतलब अधिक bespoke UI work और कम ready-made component libraries हो सकता है।
- Teams और hiring pipelines React के लिए optimized हैं; इससे हटना जोखिमभरा या “more work” लग सकता है।
- उद्योग के incentives की व्यापक आलोचना भी है: fashion-driven tooling, fundamentals पर कम ज़ोर, और slow devices तथा disadvantaged users के लिए कमजोर empathy।