- HTML-प्राथमिक दृष्टिकोण ने सार्वजनिक सेवा आवेदन फ़ॉर्म को JavaScript के बिना भी काम करने लायक बनाया, जिससे कमज़ोर डिवाइस, ब्राउज़र और नेटवर्क पर भी उपयोगकर्ता आवेदन पूरा कर सके
- पुराना React ऐप ग्राहक शिकायतों के कारण 3 दिन में हटा लिया गया, और समस्या में loading spinner, global JavaScript state, accessibility issues, तथा
localStorageकी 5MB सीमा में फँसी image storage पद्धति शामिल थीं - नए implementation में Astro के आधार पर फ़ॉर्म के हर चरण को अलग पेज बनाया गया, और submit data व uploads को हर चरण पर backend session में सहेजा गया ताकि इनपुट डेटा न खोए
- फ़ॉर्म validation को browser के built-in HTML validation को wrap करने वाले web component से संभाला गया, और failure पर browser की default validation से backend API validation तक जाने वाली progressive enhancement संरचना अपनाई गई
- लॉन्च के बाद फ़ॉर्म पूरा करने वालों की संख्या दोगुनी हो गई, और यह भी सामने आया कि JavaScript failure के कारण छूट गए उपयोगकर्ता JavaScript-आधारित analytics package में दिखते ही नहीं थे
समस्या की पृष्ठभूमि और पिछला असफल प्रयास
- ग्राहक एक utility company थी, और service application वेबसाइट के पुराने ASP फ़ॉर्म या manual process के ज़रिए किया जा सकता था
- manual process कंपनी के लिए अधिक महँगा था, और यह एक regulated monopoly की स्थिति थी जहाँ customer satisfaction 96% से नीचे जाने पर लाखों पाउंड का जुर्माना लग सकता था
- समस्या सुलझाने के लिए पहले दो प्रयास असफल हो चुके थे, और सबसे हालिया प्रयास में दूसरे देश के contractors ने React ऐप बनाया था
- React ऐप ऑनलाइन public release के 3 दिन बाद ग्राहक शिकायतों के कारण हटा लिया गया
- उस ऐप में loading spinner और global JavaScript state उलझे हुए थे, और उसमें accessibility का अभाव था
- image upload फ़ॉर्म की मुख्य सुविधा थी, लेकिन images और पूरा फ़ॉर्म डेटा 5MB सीमा वाले
localStorageमें सहेजने की कोशिश की गई थी
HTML-प्राथमिक के रूप में तय किए गए मानदंड
- नई साइट Astro पर बनाई गई और HTML-प्राथमिक संरचना अपनाई गई
- JavaScript का उपयोग केवल web components के अंदर किया गया, और उसकी भूमिका JavaScript के बिना भी सामान्य रूप से चलने वाली वेबसाइट को क्रमिक रूप से बेहतर बनाना था
- यह मानदंड रखा गया कि सार्वजनिक सेवा हर संभव डिवाइस पर काम करनी चाहिए
- यह मानदंड रखा गया कि खराब कनेक्शन की स्थिति में भी यह काम करे
- यह मानदंड रखा गया कि एक बार भरा गया फ़ॉर्म डेटा कभी गायब नहीं होना चाहिए
- Terence Eden का उदाहरण दिखाता है कि GOV.UK के सरल HTML pages ने धीमे और अक्सर memory shortage वाले PlayStation Portable browser पर भी housing benefit information पढ़ना संभव बनाया
- GOV.UK pages हल्के, simple HTML में डिज़ाइन किए गए थे और उन्हें बेहद खराब browsers पर भी काम करना था
फ़ॉर्म संरचना और डेटा सुरक्षित रखने का तरीका
- फ़ॉर्म के हर session का एक unique ID होना ज़रूरी था
- फ़ॉर्म wizard के सभी चरणों में submit data और uploaded files backend में सहेजे जाने चाहिए थे
- JavaScript के बिना भी फ़ॉर्म पूरा किया जा सकना चाहिए था
- पुराने और कम प्रदर्शन वाले web browsers पर भी फ़ॉर्म पूरा किया जा सकना चाहिए था
- accessibility को WCAG मानकों को पूरा करना था, और टीम ने AAA नहीं बल्कि AA को लक्ष्य बनाया
- JavaScript और modern CSS का उपयोग अनुभव बेहतर बनाने के लिए होना चाहिए था
- अंतिम संरचना में फ़ॉर्म wizard का हर चरण अलग पेज बन गया, और उपयोगकर्ता के Next दबाने पर फ़ॉर्म submit होता था
- यदि API डेटा को वैध मानती, तो browser अगले चरण पर redirect हो जाता था
- फ़ॉर्म submit और redirect पुराना web application pattern है, और Remix की वजह से इसका छोटा आधुनिक पुनरुत्थान हुआ है
- यह सेवा real-time data दिखाने वाला ऐप नहीं बल्कि एक बड़ा फ़ॉर्म थी, इसलिए rendering से पहले 20MB JavaScript भेजना अनुचित था
फ़ॉर्म validation और progressive enhancement
- फ़ॉर्म validation और फ़ॉर्म error rendering को अक्सर ऐसा क्षेत्र माना जाता है जहाँ टीमें React validation libraries के कारण कई person-months खर्च करती हैं
- browsers में पहले से validation system मौजूद है, और इसका उपयोग अलग library संभालने वाली निम्न-गुणवत्ता की नकल की तुलना में कम मेहनत से किया जा सकता है
- लागू किया गया HTML web component मौजूदा HTML को wrap करने वाला एक simple custom element था
- इस web component ने shadow DOM का उपयोग नहीं किया, और JavaScript के भीतर लगभग कोई HTML render नहीं किया
- component ने HTML form को wrap किया और HTML validation को आधुनिक रूप में प्रदर्शित किया
- HTML validation popup tooltip को रोका गया, और errors को field से जुड़े
aria-describedbyelement के अंदर रखा गया - अब
aria-errormessageके उपयोग की सिफारिश की जाती है - इनपुट valid होते ही validation साफ़ कर दी जाती थी, और
blurतथा submit के समय फिर से जाँची जाती थी - यह user experience 1KB से कम में दिया गया, और failure की स्थिति में browser की default validation पर लौट जाता था
- अगर browser की default validation भी विफल हो जाती, तो backend API validation संभालती थी
- validation समस्या उपयोगकर्ता के browser द्वारा अनुमति दिए गए सबसे शुरुआती समय पर बताई जाती थी, और failure होने पर भी हमेशा स्वीकार्य अनुभव पर fallback होता था
- बाद में सामान्य उपयोग के लिए web component का नया version शुरू से दोबारा लिखा गया, जिसका नाम validation-enhancer है
- उपयोग उदाहरण में
validation-enhancerHTML form को wrap करता है, औरinput type="email",required,aria-errormessageका सीधा उपयोग करता है
Email
Submit
लॉन्च के नतीजे और निष्कर्ष
- लॉन्च के बाद फ़ॉर्म पूरा करने वाले लोगों की संख्या दोगुनी हो गई
- analytics टीम नहीं जान सकी कि ये उपयोगकर्ता कहाँ से आए
- JavaScript-आधारित analytics packages उन उपयोगकर्ताओं को देख ही नहीं पाते जो JavaScript failure के कारण छूट जाते हैं
- backend session बनाए रखने और उपयोगकर्ता डेटा कभी न खोने वाला दृष्टिकोण प्रभावी साबित हुआ
- एक मामले में उपयोगकर्ता ने फ़ॉर्म शुरू करने के एक महीने बाद उसे पूरा किया
- contract काम समाप्त होने के बाद उत्तराधिकारी की प्रतिक्रिया थी कि JavaScript के बिना भी हमेशा काम करने वाली संरचना टीम के लिए अधिक काम पैदा करती है
- पुराने browsers के उपयोगकर्ताओं, खराब नेटवर्क कनेक्शन वाले उपयोगकर्ताओं और assistive technology उपयोगकर्ताओं को बाहर करना एक monopoly public service में स्वीकार्य नहीं है
- software industry के विस्तार काल में उभरी खुरदरी और अपरिपक्व पद्धतियों को लगातार आगे बढ़ाने की प्रवृत्ति छोड़नी चाहिए
- यदि आप ऐसा web application बनाते हैं जो PlayStation Portable और 3G connection पर भी काम करे, तो वह सभी उपयोगकर्ताओं के लिए काम करेगा और 30 साल बाद भी काम कर सकता है
2 टिप्पणियां
Hacker News की टिप्पणियाँ
मैं non-web developer हूँ, इसलिए जिज्ञासा है कि यह तरीका ज़्यादा काम क्यों बन जाता है, यह समझ नहीं आता।
लेख में समझाया गया approach काफ़ी simple लगता है: forms के लिए standard components बनाइए और नीचे submit button रख दीजिए। बहुत पहले जब मैंने अपनी personal website बनाई थी, तब भी यही किया था और यह इतना मुश्किल नहीं था। हो सकता है कि मैं इस क्षेत्र को अच्छी तरह नहीं जानता, लेकिन flashy frontend बनाना इससे कहीं ज़्यादा कठिन लगता है
ऐसा नहीं कि वे बेवकूफ़ हैं। अगर आप सीधे पूछें, “क्या React के बिना website बनाई जा सकती है?” तो वे निश्चित ही “हाँ” कहेंगे। लेकिन जब उनसे नई website बनाने को कहा जाता है, तो familiarity और काम जल्दी निपटाने की इच्छा के कारण वे बिना ज़्यादा सोचे नया React project शुरू कर देते हैं।
कुछ लोग सचमुच दूसरे तरीके जानते ही नहीं। उन्हें न तो plain HTML भेजने वाला सामान्य HTTP server खड़ा करना आता है, न JavaScript के बिना validate और submit होने वाले forms बनाने का अनुभव होता है। ऐसे लोग HN पर लिखने वाले लोग नहीं हैं, और न ही नए tools या techniques, या पुराने tools और techniques पर होने वाली online discussions में हिस्सा लेते हैं। उन्होंने bootcamp या university के किसी एक webapp course में नौकरी पाने लायक जितना ज़रूरी था उतना ही सीखा, और उसके बाद employer जो माँगे या टीम में किसी ने जो specific tool चुन लिया हो, वही समय-समय पर सीखते रहे।
उम्रदराज़ नज़रिए से यह समझने में मुझे थोड़ा समय लगा, लेकिन अब बात समझ आती है। career path के अनुसार कुछ लोग HTML, CSS और plain JavaScript के सबसे basic हिस्सों से बाद में परिचित होते हैं, जबकि हर technology के framework-specific complex हिस्सों से पहले। इसलिए उनके लिए यह कम professional नहीं, बल्कि उल्टा ज़्यादा obscure, advanced या peripheral knowledge जैसा महसूस हो सकता है।
“इससे हमारा काम बहुत बढ़ जाता है” यह बात भी ज़रूरी नहीं कि जानबूझकर ग़लत दावा हो। अगर आप किसी unfamiliar tool से काम करते हैं, तो वह tool कम complex हो तब भी वास्तविक रूप से काम कहीं ज़्यादा लग सकता है।
app तेज़ और simple था, लेकिन इसकी कीमत भी चुकानी पड़ी। rich UI elements को npm packages के रूप में सीधे उठा लाने की क्षमता सीमित हो गई, और अच्छा user experience देने के लिए कहीं ज़्यादा काम करना पड़ा। हर चीज़ में ज़्यादा समय लगा और नतीजे में user experience भी बदतर रहा। हमने परवाह की, लेकिन कई बार अंत तक हर detail देखने का समय नहीं होता।
company fail हो गई, और मुझे नहीं लगता कि React उसे बचा लेता। लेकिन मैं यह प्रत्यक्ष रूप से कह सकता हूँ कि “simplicity” के प्रति moral obsession ने भी मदद नहीं की। यह हमेशा एक trade-off होता है।
कोई कहता है कि उसने वह solution दिया जो ज़्यादातर लोगों के मन में आने वाले solution से ज़्यादा simple और sensible था, लेकिन जिसने handover लिया वह संतुष्ट नहीं था।
क्या हमें पता है कि handover किया गया code high quality का था? क्या उस व्यक्ति की प्रतिक्रिया सिर्फ इस बात पर थी कि “यह React नहीं है”? क्या company में app बनाने के तरीक़े को लेकर कोई enforced template था?
पता नहीं।
अब यह बात बहुत सुनने को नहीं मिलती, लेकिन HTML Triptych प्रस्ताव अभी भी उन चीज़ों में से है जिन्हें मैं कभी browser में आते देखना चाहता हूँ। HTML forms का REST endpoint से बात करने का तरीका एक अच्छा pattern है।
user-assistive validation input attributes से हो, वास्तविक validation request के दूसरी तरफ़ हो, और flow कुछ ऐसा हो: GET /form => POST /thing => GET /thing/1। अगर triptych feature लागू हो जाए, तो यह एक शानदार pattern होगा।
[0] https://triptychproject.org/
मुझे React sites बिल्कुल पसंद नहीं हैं, लेकिन जो बात समझ नहीं आती वह यह है कि क्या ये sites lazy loading बिल्कुल नहीं करतीं?
बड़े single-page apps भी अगर components को सिर्फ ज़रूरत पड़ने पर load करें, तो बहुत तेज़ हो सकते हैं।
Angular1 -> Vue2 -> Svelte2 से होते हुए मैं बिना shadow DOM वाले plain web components पर आकर रुका, और इनके साथ काम करना सुखद भी है और तेज़ भी।
आजकल ज़्यादातर ऐप्स बस HTMX + Go + SQLite से बनाता हूँ
ज़्यादातर प्रोजेक्ट्स के लिए यह काफ़ी लगता है।
मेरी एक साइट में बहुत सारी इमेजेज़ हैं और वह हर महीने 10TB ट्रैफ़िक संभालती है। इस मामले में सेटअप कुछ ऐसा है: 1. भरोसेमंद data store चाहिए, इसलिए S3 इस्तेमाल करता हूँ 2. आगे Cloudflare लगाया और Tiered Cache ऑन किया। इससे POPs origin की बजाय Cloudflare से fetch करना पसंद करते हैं। ब्राउज़र और Cloudflare दोनों तरफ़ 1 साल के लिए सब कुछ cache किया, और ऐसे rules सेट किए जो origin cache policy और query strings को ignore करते हैं, साथ ही सिर्फ़ immutable objects इस्तेमाल किए जिन्हें revision की ज़रूरत हो 3. उसके आगे BunnyCDN लगाया
सिर्फ़ Cloudflare से इमेज-heavy साइट चल नहीं पा रही थी, इसलिए इस तरीके से काफ़ी लागत घटाई। policy के हिसाब से इसे मुख्य रूप से images के लिए नहीं, बल्कि HTML, CSS, JavaScript और दूसरे साइट content के लिए इस्तेमाल करना चाहिए।
सिर्फ़ S3 इस्तेमाल करें तो खर्च बहुत बढ़ जाता है।
लेकिन हाल में मैं mobile app बना रहा हूँ। PWA की सीमाएँ हैं। OS IndexedDB storage को reclaim कर सकता है, इसलिए signup या backend के दखल के बिना app के भीतर भरोसेमंद data store देना संभव नहीं है।
आख़िरकार Android पर Flutter में जाना पड़ा, लेकिन वहाँ दूसरी तरह की परेशानी थी। कभी-कभी app update लंबे समय तक “in review” पर अटका रहता है, जो काफ़ी निराशाजनक है। उसी app के web app version में इसके मुक़ाबले updates बहुत तेज़ आते हैं।
समझ नहीं आता कि कोई mobile OS ऐसा क्यों नहीं है जो JavaScript, HTML, CSS से app बनाने दे और बिना ज़्यादा मेहनत के stable storage भी दे। PWA apps को जल्दी update कर पाना अच्छी बात है।
time travel आसान हिस्सा है, उसके बाद Palm के पतन और webOS के smartphone OS के रूप में भुला दिए जाने से किसी तरह रोकना होगा।
अगर 2009 बहुत दूर लगता है, तो 2012 के Firefox OS पर भी दाँव लगा सकते हैं।
मज़ाक अपनी जगह, लोगों और कंपनियों ने यह कोशिश की थी। लेकिन ख़राब timing और कई घटनाओं के मिल जाने से हमारी timeline में वह हक़ीक़त बन नहीं पाई।
ऐसा लगता है कि यह ठीक उसी sweet spot पर है जहाँ C जैसी अनावश्यक झंझट नहीं है, लेकिन Java की तरह business logic पर फ़ोकस करने के लिए रास्ते से हट जाता है। Rust जैसा नहीं।
यह हर काम के लिए अच्छा नहीं है। ख़ासकर abstractions बनाने की इसकी सीमित क्षमता खटकती है। लेकिन business-logic-heavy server apps के लिए यह शानदार है। यह हर काम करने वाली language नहीं, बल्कि उस क्षेत्र के लिए special-purpose language जैसी लगती है।
SQL और HTMX/web/OAuth हिस्सों को abstract करने के लिए कुछ libraries भी बनाई हैं। अब मेरे apps आपस में इतने मिलते-जुलते हैं कि features को इधर-उधर ले जाना आसान हो गया है।
https://github.com/cattlecloud/webtools
https://github.com/cattlecloud/litesql
जवाबी तर्क के रूप में In Defence of the Single Page Application भी है
https://williamkennedy.ninja/javascript/2022/05/03/in-defenc...
In Defence of the Single Page Application - https://news.ycombinator.com/item?id=31275178 - मई 2022, 32 comments
यह लेख अच्छा है, और किसी समस्या को उठाकर उसे सही तकनीक और सही गहराई से हल करने का बढ़िया उदाहरण है। जब आपके पास ग्राहक के domain knowledge की पूरी समझ हो, तो वह सचमुच मदद करता है।
लेकिन “simple HTML React से बेहतर है” जैसी framing मुझे पसंद नहीं आती। क्योंकि React developer के रूप में भी यही बात बिल्कुल वैसे ही कही जा सकती है।
server-based session storage और browser-based storage की complexity और subtlety जैसी कई बातें हैं जिन्हें यह लेख बस सरसरी तौर पर पार कर जाता है, लेकिन उन पर अनंत तक बात की जा सकती है, जो बहुत लंबा हो जाएगा।
HTML में जो चीज़ें simple हैं, वे React में भी simple हैं।
सचमुच वही code है। React में browser-based HTML validation इस्तेमाल करने से कोई रोकता नहीं है। जो code React में complex हो जाता है, जैसे बहुत ज़्यादा जटिल validation logic, वह Astro में भी complex ही होगा। Astro के schema validation वगैरह पर अपने तरीक़े हैं, और उसे Astro site में integrate करने के लिए client router जैसी चीज़ें भी integrate करनी पड़ती हैं, इसलिए वहाँ भी चीज़ें बहुत आसानी से बेवजह complex हो सकती हैं।
तुलना शायद किसी ऐसी offshore outsourcing team से की जा रही है जिसके पास अधूरा ज्ञान है, और project structure के हिसाब से उनके पास ऐसा solution बनाने की incentive होती है जो जितनी जल्दी हो सके, जितने कम समय में हो सके, और जितनी ज़्यादा complexity के साथ हो सके।
आख़िरी बिंदु काफ़ी चालाक है। मेरा मतलब यह नहीं कि outsourcing company जानबूझकर ऐसा करती है, लेकिन incentive structure ऐसा है कि ज़रूरत से ज़्यादा complexity वास्तव में उनके फ़ायदे में जाती है, इसलिए सीधे-सादे तरीक़े की ओर जाने का उनके पास प्रत्यक्ष incentive नहीं होता।
खैर, सामने मौजूद समस्या को सीधे संभालने वाला simple solution हमेशा बेहतर होता है, और यह बात किसी भी stack पर लागू होती है।
मुझे Astro के form validation से कोई आपत्ति नहीं है, मैं बस यह रेखांकित करना चाहता था कि “native HTML browser validation” से आगे भी बहुत कुछ है।
यह एक बेहतरीन लेख है, लेकिन ऐसे प्रेरक लेख पढ़ते समय मैं हमेशा दुविधा में पड़ जाता हूँ। पूरी बात सही लगती है, और मुझे सरल साइट का विचार पसंद है जो अच्छी तरह काम करे, तेज़ी से लोड हो, और आधुनिक browser पर निर्भर न हो
फिर मैं सोचने लगता हूँ कि कहीं ऐसा इसलिए तो नहीं कि मैं React या उस समय चल रही किसी चमकदार trendy tech को समझने लायक पर्याप्त स्मार्ट नहीं हूँ
ऐसा लगता है जैसे समझ की एक ऐसी सीमा है जिसे मैं पार नहीं कर सकता। अगर मुझे Sublime जैसा कोई साधारण editor दे दिया जाए और कहा जाए कि वेबपेज बनाओ, तो JavaScript होने पर भी वह मेरे लिए सुखद जगह है। लेकिन VSCode या Zed, इधर-उधर Claude/Copilot/ChatGPT plugins, और React tutorial दे दो, तो दिमाग पिघलने लगता है
चीजों को सरल रखना बुरी बात नहीं है; अक्सर इसके लिए इतना समझदार होना पड़ता है कि आप उसे बेवजह ज़रूरत से ज़्यादा complex न बना दें
Embrace Extend Extinguish सच है, और जो लोग उसमें साथ दे रहे हैं वे अगर और तेज़ झूठ बोलने और घटिया code उगलने वाले LLM से replace हो जाएँ, तो भी ठीक ही है
इससे मुझे लगभग 15 साल पहले का समय याद आ गया। मैं Grails में backend session management इस्तेमाल करता था, और responsive CSS व “थोड़े से” JS से बेहतर किए गए HTML forms इस्तेमाल करता था
उस समय से फर्क यह है कि browser tech आज जैसी विकसित नहीं थी। अलग-अलग browsers का ध्यान रखना पड़ता था, IE7 बल्कि IE6 तक संभालना पड़ता था, इसलिए काम मुश्किल था और बहुत व्यापक QA चाहिए होता था। BrowserStack बाद में आया
JavaScript libraries के विकसित होने की वजह थी। npm नहीं था, bower भी नहीं था। फिर Backbone.js आया और मुझे वह पसंद आया। AngularJS कमाल का था, फिर अगले Angular version में बड़ा compatibility break आया, और उसके बाद React, Polymer वगैरह आए
आज के native browsers बहुत कुछ कर सकते हैं और progressive enhancement भी आसान है। लेकिन हमेशा ऐसा नहीं था। उस समय React चुनने का फैसला कई वजहों से जायज़ था, और शायद यहाँ भी ऐसा ही रहा हो
10 साल से भी पहले मैंने Ministry of Justice के लिए GOV.UK में ऐसे apps बनाए थे। लंबे forms को step-by-step validate करने और कई pages में बाँटने के लिए हमने अपनी form wizard library बनाई थी। Ruby on Rails यह default रूप से support नहीं करता था
उस समय यह सिद्धांत बहुत महत्वपूर्ण था कि कोई भी user, चाहे वह किसी भी environment से आए, digital services का उपयोग कर सके
हर session ID के लिए multi-page application के pages को उस session ID से मिलाया जा सकता है, इसलिए ज़रूरत पड़े तो user खुद भी उसे दर्ज कर सकता है। लेकिन अगर आपके पास IP address, upload date, browser, operating system जैसी पर्याप्त जानकारी हो, तो पहचान कर पाना चाहिए। फिर भी सबसे सटीक session browser के भीतर ही होना चाहिए, ताकि किसी एक application का cookie किसी दूसरे applicant, जैसे PlayStation Portable इस्तेमाल करने वाले किसी रिश्तेदार, के साथ mix न हो जाए
मुझे जिज्ञासा है कि mobile app में वे कौन-सी technology इस्तेमाल करते हैं। मेरा अनुमान है कि वह पूरी तरह native mobile app नहीं है, शायद webview इस्तेमाल करती हो
यह “हमने React app को HTML form में बदला और performance बेहतर हो गई” वाली बात नहीं है। यह “हमने खराब web page को अच्छे web page में बदला और performance बेहतर हो गई” वाली बात है
इसे browser experience चलाने वाली technology की गलती बताना मूर्खता है। React से भी शानदार user experience बनाया जा सकता है, और plain HTML से भी भयानक website बनाई जा सकती है
सुधार technology से नहीं, design change से आया था
लेकिन बात सही है। user-side बदलाव इस्तेमाल की गई technology से नहीं, design ठीक करने से आया
यह खराब resume bullet points जैसा ही है। जैसे कोई लिख दे कि “वेबसाइट को HTML-first में rewrite किया, visitors 100% बढ़े”, मानो business outcome code change की वजह से आया हो। लेकिन जब आप उस point के बारे में पूछते हैं, तो अंत में मानना पड़ता है कि उन्होंने design problems ठीक करने या features जोड़ने के लिए पूरी साइट को redesign किया था, और visitors की बढ़ोतरी उसी की वजह से हुई
Douglas Crockford की JavaScript: The Good Parts जितनी मज़ाकिया रूप से छोटी है। React: The Good Parts उससे भी छोटी होगी
दिलचस्प बात यह है कि मूल लेख एक multi-page wizard-style form का वर्णन करता है, जैसा मैंने पिछले लगभग 10 वर्षों में बहुत कम देखा है। लेकिन जब भी मैंने ऐसे कुछ देखे हैं, वे ज़्यादातर भयानक enterprise systems रहे हैं। आखिरी बार मैंने ऐसा कुछ expense processing के लिए किसी Oracle product जैसा देखा था
उनकी समस्या हमेशा यह होती है कि काम के बीच-बीच में वे धीमे पड़ जाते हैं। हर button पर कुछ सेकंड इंतज़ार करना पड़ता है। अगर एक-दो steps पीछे जाना पड़े तो झुंझलाहट दोगुनी हो जाती है। खराब तरीके से बने single-page apps की शुरुआत धीमी होती है। उन्हें load होने में समय लगता है, लेकिन एक बार load हो जाएँ तो आम तौर पर performance ठीक रहती है
Lobste.rs की रायें
इंसानों के लिए ठीक से काम करने वाली चीज़ बनाना जाहिर है ज़्यादा मेहनत का काम है। लेकिन आखिरकार वही पूरे काम का मूल भी है
लगता है कि बाद में आने वालों का असल मतलब यह था कि उन्हें web platform की बुनियाद की अच्छी समझ नहीं है
इसका मतलब यह नहीं कि यह वांछनीय है, बस अभी की हक़ीक़त ऐसी ही है
यह बात कड़वी लगी कि साथियों को “form submission और redirect” समझाने में समय लगा। वजह यह है कि सब लोग client-centric web app के आदी हो गए हैं
आज web development की हालत सच में दुखद है, और बहुत-सी चीज़ें फिर से सिखानी पड़ रही हैं
मुझे नहीं लगता कि इस approach को सही ठहराने के लिए इतनी ऊँची compatibility भी ज़रूरी है। जैसा लेख में कहा गया है, दुनिया में यह बस एक form ही है
इसलिए मैं होता तो हर हाल में इसे इसी तरह बनाता
मैं लेख में बताए गए तरीके से साइट बनाना चाहूँगा। लगभग हर browser में चलना चाहिए और accessibility का भी ध्यान रखना हो, साथ ही बहुत छोटा download होना चाहिए — यह काफ़ी दिलचस्प चुनौती लगती है
सोचता हूँ क्या इस तरह की चीज़ों में विशेषज्ञता रखने वाली कोई कंपनी है, और क्या वे hiring कर रही हैं। शायद मैं बस वह उम्रदराज़ इंसान हूँ जिसे पुराने सरल तरीके याद आते हैं
यह functionality इतनी अच्छी तरह isolated है कि इसे reusable library के रूप में निकालना बहुत आसान होगा, और अभी भी करने को काफ़ी काम बाकी है। मन करता है कि ऐसी चीज़ें web framework defaults में हों। सच में बहुत अच्छा लेख है
थोड़ा विडंबनापूर्ण यह रहा कि Firefox में किसी style की वजह से मुख्य लेख पूरा दिख भी नहीं रहा था और न ही select हो रहा था, इसलिए मुझे reading mode में जाना पड़ा। title, गुलाबी quote markers, और code blocks दिख रहे थे, लेकिन बाकी कुछ नहीं दिख रहा था
संपादन: नीचे देखा तो शायद यह मेरे environment की समस्या लगती है। संदर्भ के लिए छोड़ रहा हूँ
लेख खुद मैंने अच्छे से पढ़ लिया। चाहे developer हों या end user, हम सब React की “agility” की कीमत चुका रहे हैं। मैंने कई बार सोचा है कि काश कंपनी में कोई दूसरा stack इस्तेमाल कर पाते
साथ ही लेखक की empathy और इसे “सबकी जीत” वाली संरचना में ढालने का तरीका प्रभावशाली लगा। परवाह करने का रवैया आखिरकार फल देता है
इससे बहुत सहमति है। मैंने पहले एक ऐसा blog बनाया था जिसमें JavaScript बेहद ज़्यादा था, और JS-आधारित features की वजह से लगभग बगावत जैसी स्थिति बन गई थी
अभी तक उसे HTML-first तरीके में बदलने का समय नहीं मिला, लेकिन ऊपर-ऊपर से उसे ज़्यादातर HTML-first webpage जैसा दिखने लायक बना दिया है
मेरे analytics data में भी ऐसा ही नतीजा दिखा। bounce rate 80% से घटकर लगभग 50% रह गया, और उसके बाद की posts पर नए visitors लगभग दोगुने हो गए
सोचकर ही डर लगता है कि JS से बनाई गई अपनी शुरुआती घटिया implementation की वजह से कितने लोग मेरे domain को हमेशा के लिए avoid करने लगे होंगे। अगर web page या blog बना रहे हों, तो यह सबसे अहम सलाहों में से एक है
यह तरीका autofill में भी मदद करता है। पहले एक बार पूरा form dynamic था और हर हिस्से की पहचान के लिए attributes नहीं थे, इसलिए auto input बनाना संभव नहीं था
यह अफ़सोसजनक था कि functionality से ज़्यादा सुंदर दिखने पर over-engineering की गई थी, इसलिए user-first design पर यह लेख पढ़कर अच्छा लगा
इसमें SSE streaming और morph library जोड़ दें तो dynamic, real-time, multiplayer features भी काफ़ी शानदार ढंग से बनाए जा सकते हैं