अत्यधिक JavaScript-केंद्रित डेवलपमेंट वेब को बर्बाद कर रहा है
(jonoalderson.com)सारांश अवलोकन
अत्यधिक JavaScript-केंद्रित डेवलपमेंट वेब को बर्बाद कर रहा है
- JS frameworks के दुरुपयोग से वेबसाइटों की जटिलता बढ़ी
- डेवलपर अनुभव (DX) ने उपयोगकर्ता अनुभव (UX) को दबा दिया
- साधारण कामों के लिए भी अत्यधिक संरचना की मांग
- performance, accessibility और maintainability — तीनों में गिरावट
- वेब की मूल क्षमताओं की बहाली ही समाधान
परिचय
डेवलपर-केंद्रित वेब की बीमारी
- अधिकांश वेबसाइटें जरूरत से ज़्यादा जटिल और धीमी हैं
- JS-केंद्रित डिज़ाइन के कारण संरचना उपयोगकर्ता की बजाय डेवलपर-केंद्रित हो गई है
- छोटे बदलावों के लिए भी जटिल deployment प्रक्रिया की आवश्यकता अब आम हो चुकी है
मुख्य भाग
ऐप जैसा दिखने की चाह इसकी वजह है
- 2010 के दशक के बाद, mobile app की लोकप्रियता के साथ "ऐप-जैसे वेब" की मांग बढ़ी
- Angular जैसे JS frameworks के आने से जटिलता तेज़ी से बढ़ी
- साधारण content भी सिस्टम की तरह डेवलप किया जाने लगा
डेवलपर अनुभव (DX) को प्राथमिकता देने वाली संस्कृति
- आधुनिक frameworks डेवलपर सुविधा पर केंद्रित हैं
- component abstraction, UX से दूरी पैदा करता है
- "ब्लॉग में React क्यों इस्तेमाल करें" इस सवाल से पहले SSR compatibility पर चर्चा होने लगती है
जटिलता के standard बन जाने की हकीकत
- छोटे कामों के लिए भी build, routing, API, cache जैसी बहु-स्तरीय संरचना चाहिए
- जटिल stack के कारण गैर-डेवलपर content में बदलाव नहीं कर पाते
- तकनीकी बदलाव इतनी तेज़ी से होते हैं कि maintenance कठिन हो जाती है
frameworks के दुरुपयोग के दुष्प्रभाव
- SSR, cache, metadata जैसी मौजूदा वेब क्षमताओं को फिर से implement किया जा रहा है
- performance घटती है और dependencies बढ़ती जाती हैं
- नतीजतन JS frameworks से CMS को दोबारा बनाने जैसी विडंबना पैदा होती है
निरर्थक दोहराव और लागत
- frameworks को अपनाने और छोड़ने का चक्र चलता रहता है, इसलिए स्थिर संरचना नहीं बनती
- वास्तविक user समस्याएँ सुलझाने के बजाय आंतरिक जटिलता संभालने पर ज़ोर रहता है
- content marketing, SEO और experiments धीमे पड़ते हैं, जबकि user experience बिगड़ता है
JS के अति-उपयोग से उपयोगकर्ताओं और marketers को नुकसान
- content संशोधन के लिए डेवलपर का दखल जरूरी हो जाता है
- SEO और page quality दोनों खराब होते हैं
- उपयोगकर्ताओं को loading delay, interaction errors जैसी समस्याओं का सामना करना पड़ता है
JS सिर्फ एक tool है, लक्ष्य नहीं
- JS एक शक्तिशाली tool है, लेकिन अधिकांश वेबसाइटों के लिए इसका इतना अधिक उपयोग अनावश्यक है
- static content के लिए HTML, CSS और थोड़ा-सा JS ही काफी है
- Vanilla JS, server rendering और न्यूनतम scripts अधिक प्रभावी हैं
अधिकार का केंद्रीकरण और संरचनात्मक समस्या
- जटिल stack के कारण हर काम डेवलपर्स पर निर्भर हो जाता है
- संगठनात्मक संरचना में शक्ति डेवलपर्स के पास केंद्रित हो जाती है
- तकनीकी निर्णय उपयोगकर्ता की बजाय डेवलपर सुविधा के आधार पर लिए जाते हैं
निष्कर्ष
वेब की मूल प्रकृति की बहाली ही समाधान है
- ऐसी वेबसाइटें चाहिए जो तेज़ी से लोड हों, खोजी जा सकें और जिनका maintenance आसान हो
- server-rendered HTML, semantic markup और न्यूनतम JS जैसे मूल सिद्धांतों की ओर लौटना ही उत्तर है
- तकनीक नहीं, परिणाम-केंद्रित दृष्टिकोण की आवश्यकता है
- "हम यह तकनीक क्यों इस्तेमाल कर रहे हैं?" यह सवाल पूछा जाना चाहिए
- सरल और उपयोगकर्ता-केंद्रित वेब ही performance, लागत में कमी और flexibility देता है
23 टिप्पणियां
सिर्फ WordPress को देखें तो... लगता है यही ऊपर वाले सवाल का जवाब हो सकता है. मार्केट शेयर भी WordPress का कहीं ज़्यादा है, जबकि यह धीमा भी है..
मुझे लगता है कि अगर समर्थन में benchmark नतीजे हों, तो डेवलपर्स उससे ज़्यादा सहमत हो पाएंगे। अगर framework-केंद्रित coding बहुत ज़्यादा हो, तो साइट का धीमा होना तय है, लेकिन व्यक्तिगत रूप से मैंने page transition के मामले में vanilla code से बनी साइटों को optimized framework साइटों से ज़्यादा धीमा देखा है। बेशक, अगर कोई साइट सिर्फ static data से बनी हो, तो शायद केवल HTML + CSS होना ज़्यादा तेज़ हो, लेकिन आज के समय में सिर्फ static data वाली साइटें कितनी आम हैं, इस पर मुझे पक्का नहीं है।
अगर React या Vue जैसी चीज़ें न हों,
तो वही फीचर implement करने पर भी code को ज़्यादा complex तरीके से लिखना पड़ता है, है न?
खासकर popup handle करते समय सिर्फ एक props पास करना भी pure JavaScript में करें तो code काफ़ी complex हो जाता है.
ऐसी simple चीज़ें करने में भी अगर code complex हो जाए, तो सच में
complex features को implement करना मुश्किल हो जाता है.
यह तो अपरिहार्य जटिलता है। यह पहले की तरह साधारण template html नहीं है।
लोग जिन browsers का इस्तेमाल करते हैं, उनकी किस्में भी इतनी ज़्यादा नहीं हैं, फिर frameworks इतने सारे क्यों हैं? क्या बेहतर नहीं होगा कि browsers को मैनेज करने वाली कंपनियाँ एक optimal framework बनाकर उसे साथ में मैनेज करें? आखिर हम इस बुरे चक्र को कब तक दोहराते रहेंगे?
क्योंकि लोग जिस development philosophy का पीछा करते हैं, वह बहुत अलग-अलग होती है.........
मैं इस स्थिति से सहमत हूँ, लेकिन निष्कर्ष से सहमत नहीं हूँ.
इस स्थिति का सतही कारण, जैसा कि मूल लेख में भी कहा गया है, यह है कि "ऐप-जैसे वेब" की मांग बढ़ गई है,
और तब भी और अब भी, वेब "ऐप-जैसी किसी चीज़" को बनाने के लिए उपयुक्त नहीं था, लेकिन बहुत जुगाड़ किया जाए तो "कुछ हद तक वैसा बनाया जा सकता है" — मैं इसे ऐसी स्थिति मानता हूँ.
असल में, वेब की उत्पत्ति ही शोध-पत्र जैसी किसी "दस्तावेज़" प्रकृति की चीज़ों को साझा करने के लिए बने एक प्लेटफ़ॉर्म के रूप में हुई थी.
सिर्फ HTML के बुनियादी घटकों को देखकर भी यह समझा जा सकता है.
फिर CGI जैसी dynamic content बनाने वाली तकनीकें आईं, और browser पक्ष में script language एम्बेड होने से आउटपुट में dynamism देना संभव हुआ, जिसके साथ "दस्तावेज़ के रूप में वेब" से बाहर निकलने की शुरुआत हुई.
समस्या यह है कि उस शुरुआती बदलाव के क्षण से लेकर आज तक, वेब की बुनियाद अब भी "दस्तावेज़" आधारित सिस्टम ही है.
बेशक web socket, webrtc, wasm जैसी "दस्तावेज़" उन्मुखता से हटने वाली कई नई तकनीकें आई हैं, लेकिन आज भी अधिकांश वेबसाइटें उसी पुराने "दस्तावेज़" आधारित प्लेटफ़ॉर्म पर निर्भर रहकर विकसित की जाती हैं.
आज भी हमें स्क्रीन बनाने के लिए
divटैगों को एक के ऊपर एक जमाना पड़ता है.यहीं तक इस स्थिति का विश्लेषण है, और फिर सवाल आता है कि समाधान क्या है.
अगर व्यवहारिकता जैसी बातों को बिल्कुल न सोचें और अगले आदर्श प्लेटफ़ॉर्म की क्षमताओं की कल्पना करें, तो वह कुछ ऐसी हो सकती है.
(यह नहीं कि हर साइट ऐसी ही होनी चाहिए, बल्कि सिर्फ application प्रकृति वाली साइटों तक सीमित करके)
सबसे पहले, browser एक तरह का app launcher बन जाएगा.
एक बार डाउनलोड कर लेने के बाद उसे offline में भी चलना चाहिए.
और app को मौजूदा html/css/js से हटकर किसी दूसरी भाषा में implement किया जाएगा.
उस प्रक्रिया में Android की तरह browser एक तरह का framework दे सकता है.
server के साथ communication का तरीका भी मौजूदा web request से हटकर किसी दूसरे paradigm का उपयोग कर सकता है.
जिन संचारों में real-time की जरूरत हो, वहाँ मौजूदा TCP communication को वैसे का वैसा इस्तेमाल किया जा सकता है,
और HTTP protocol का उपयोग न करने वाला कोई और अधिक सरल RPC communication नया बनाकर इस्तेमाल किया जा सकता है.
आपने जिस आख़िरी बात को एक आदर्श प्लेटफ़ॉर्म कहा, उसका मतलब क्या है, यह मुझे ठीक से समझ नहीं आया।
आख़िरकार बात तो उस दौर की है जब native program डाउनलोड करके उसमें ActiveX इस्तेमाल किया जाता था।
समस्या का मूल सार यह है कि HTTP प्रोटोकॉल, जो वेब "दस्तावेज़" पर आधारित है, उसके भीतर app-जैसा web बनाने की एक तरह की ज़बरदस्त जुगाड़ चल रही है,
और इसे हल करने के लिए अगर app-लेवल की सुविधाएँ चाहिएँ, तो app के लिए कोई नया protocol और framework बना लेना कैसा रहेगा—ऐसी राय थी।
जैसे smartphone पर शुद्ध native program नहीं चलते, बल्कि किसी तरह के sandboxed app चलते हैं, वैसे ही वह browser-लेवल पर चलने वाली संरचना होगी।
बेशक, यह ActiveX जैसी स्थिति न बने, इसके लिए openness और standardization पहले से सुनिश्चित होने चाहिए।
वेब भले ही ऐप जैसा हो, फिर भी मेरा मानना है कि निष्कर्ष में कही गई दिशा के करीब जाने की कोशिश करनी चाहिए। JavaScript का ज़्यादा इस्तेमाल करने पर क्लाइंट के नज़रिए से चीज़ें भारी हो जाती हैं.
असल में ऐसा implement कर सकने वाले framework मौजूद नहीं हैं, ऐसा भी नहीं है। अभी Next.js में भी अगर client component का इस्तेमाल सिर्फ़ ज़रूरत पड़ने पर किया जाए और उसे न्यूनतम रखा जाए, तो यह मोटे तौर पर संभव है। और जैसा किसी और ने कहा था, Rails ecosystem में Hotwire(https://hotwired.dev/) जैसा framework suite (Turbo, Stimulus आदि) है, जो लेखक के बताए निष्कर्ष के काफ़ी करीब पहुँचते हुए ऐप-जैसे वेब को support करता है।
मैं इस लेख की मूल समस्या-चेतना से सहमत हूँ, लेकिन कुछ हिस्से ऐसे भी हैं जो थोड़ा अटपटा महसूस कराते हैं.
उदाहरण के लिए, हमारी कंपनी द्वारा संचालित एक खास सेवा-प्रचार वेबसाइट ठीक वैसी ही सादगी बनाए हुए है जिसकी इस लेख में प्रशंसा की गई है. अच्छी बात यह है कि इस वेबसाइट के ज़्यादातर तत्व काफ़ी static हैं. फ्रंटएंड का HTML और CSS जैसी चीज़ों का कोड बिना किसी framework के सीधे लोगों ने हाथ से लिखा है, और JS भी बस jQuery और Google Analytics तक ही लगा हुआ है. notice या board जैसी चीज़ें jQuery-आधारित AJAX से लागू की गई हैं, लेकिन मुझे नहीं लगता कि वह किसी तरह से अव्यावहारिक या ज़रूरत से ज़्यादा जटिल स्तर की हैं. जब मैंने बहुत पहले बुनियादी web development सीखना शुरू किया था, तब jQuery के आधार पर जिस स्तर तक implement कर सकता था, मुझे यह लगभग वैसा ही लगता है. जहाँ तक मुझे पता है, यह साइट Internet Explorer के दौर से चल रही है, इसलिए मैंने इसे खुद नहीं बनाया, लेकिन मुझे यह बुरी नहीं लगती.
लेकिन इसके साथ Git version control और CI/CD pipeline जुड़ी हुई है, और staging server तथा actual production server को अलग रखा गया है. Main branch में Pull Request merge होते ही pipeline में bundler चलाकर बने artifacts अपने-आप staging server पर deploy हो जाते हैं, और ज़िम्मेदार व्यक्ति staging server की जाँच करके deployment को अंतिम approval दे दे तो वही फिर production server पर deploy हो जाता है. पहले यह बस FTP के ज़रिए source files को सीधे production server पर overwrite करने का तरीका था, लेकिन संबंधित काम हमारी टीम में आने के बाद हमने इसे इस तरह बदल दिया.
क्या यह सचमुच अव्यावहारिक जटिलता है? पहले उस वेबसाइट का title tag बदलना मतलब बस FTP access सपोर्ट करने वाले AcroEdit (हाँ, जिन्होंने मूल रूप से उस साइट का HTML सीधे लिखा था, वे अब भी यही इस्तेमाल कर रहे थे.) से production server के HTML file में सीधे जाकर एक लाइन बदलना, save करना, और काम ख़त्म हो जाना था. इसलिए वे लोग शायद सचमुच ऐसा महसूस कर सकते हैं.
लेकिन मेरी नज़र में, इस हद तक जटिलता बढ़ाना पूरी तरह स्वीकार करने लायक था. हर काम सिर्फ़ title tag की एक पंक्ति बदलने जितना आसान तो नहीं होता. और पुराना code comment-out करके जगह-जगह चिपकाए रखने के बजाय, जब चाहें rollback कर सकने की वजह से उसे बेझिझक पूरी तरह हटा सकना, बदलावों को पारदर्शी तरीके से track और rollback कर पाना, और bundler के ज़रिए ज़रूरत हो तो कुछ बुनियादी optimization और जोड़ पाना—मेरे हिसाब से ये काफ़ी बड़े फ़ायदे हैं. actual environment में deploy होने से पहले preview करने के लिए staging server जोड़ना भी किसी नज़रिए से जटिलता ही कहा जा सकता है, लेकिन मुझे लगता है कि इसकी ज़रूरत थी.
मैं भी इस बात से काफ़ी असंतुष्ट हूँ कि तरह-तरह की वेबसाइटों का अंदरूनी code structure ज़रूरत से ज़्यादा जटिल और भारी हो गया है. आजकल Windows का Outlook app web app-आधारित है, और हाल के समय में वह ख़ास तौर पर और भी भारी हो गया है. हालत यह है कि सिर्फ़ स्क्रीन पर mail body लिखने या body को select all करने भर से lag होने लगता है, यहाँ तक कि कभी-कभी "page not responding" तक आ जाता है. यह क्यों हो रहा है, यह देखने के लिए मैंने web Outlook में developer tools खोले, और मैं चौंक गया. एक बार cache साफ़ करके refresh किया तो एक मिनट बाद भी न जाने कैसी requests लगातार आती रहीं. browser में जाँचने पर देखा कि सिर्फ़ MS Office साइट से जुड़ी चीज़ों के लिए ही कई gigabytes data store हो रखा था.
लेकिन यह लेख कई बातों को आपस में मिलाकर पेश करता है; कुछ हिस्सों से मैं सहमत हूँ, लेकिन कुछ हिस्से मुझे बिल्कुल नहीं जँचते. semantic HTML या accessibility के बारे में तो मेरी जानकारी में अतीत और भी ज़्यादा भयानक था. इसके अलावा, developer experience बेहतर होने से user experience खराब होता है—इस बात से, शायद इसलिए कि मैं web frontend developer नहीं हूँ, मुझे बिल्कुल भी सहमति नहीं होती. यहाँ तक कि यह कहना कि सारी शक्ति और नियंत्रण developers के हाथ में केंद्रित हो गए हैं, मुझे बेतुकी बात लगती है. कंपनी में शक्ति management के पास नहीं होती क्या? क्या पश्चिम में कंपनियों की संरचना कोरिया से इतनी अलग है?
हमेशा की तरह, संतुलन और मध्यम मार्ग, सादगी और व्यावहारिकता महत्वपूर्ण मूल्य हैं, और decision-making में इन्हें प्राथमिकता मिलनी चाहिए—इस बात से मैं पूरी तरह सहमत हूँ. लेकिन यह लेख ऐसा दावा करता है मानो "हर वेबसाइट को software product की तरह treat करना" पूरी तरह developers की ही ज़िम्मेदारी हो, और मुझे लगता है कि यही हिस्सा मूल समस्या-बोध को उल्टा धुंधला कर देता है. और जो हिस्से कुछ इस तरह दिखते हैं मानो बिना व्यवस्थित system वाले 'अच्छे पुराने दिनों' का महिमामंडन किया जा रहा हो, मुझे लगता है कि उल्टा वही आलोचना के ज़्यादा योग्य हैं.
क्या आप जो कह रहे हैं, वह पूरी तरह अलग बात नहीं है?
आपको किस हिस्से में यह पूरी तरह अलग बात लगती है?
आखिरकार, मुझे लगता है कि इस लेख में जिस चीज़ की आलोचना की जा रही है, वह है अत्यधिक जटिलता और उससे पैदा होने वाली अनावश्यक फुलावट। सिर्फ इसलिए कि मैंने अपनी टिप्पणी में JavaScript की बात नहीं उठाई, मैं इसे पूरी तरह असंबंधित टिप्पणी नहीं मानता। एक तरह से देखें तो यह अपेक्षाकृत गौण हिस्से की आलोचना ही है। और जैसा कि मैंने अपनी टिप्पणी में शुरू से कहा था, मैं भी मूल लेख की बुनियादी समस्या-चेतना से सहमत हूँ।
लगता है आपने मूल लेख की मंशा को गलत समझा है।
"...यहाँ Git version control और CI/CD pipeline जुड़ी हुई है, और staging server तथा actual production server को अलग रखा गया है। जब Main branch में Pull Request merge होती है, तो pipeline में bundler चलाकर बने output को staging server पर अपने-आप deploy किया जाता है, और ज़िम्मेदार व्यक्ति staging server की जाँच करने के बाद deployment को final approve करता है, तब उसे फिर production server पर deploy किया जाता है। पहले तो बस FTP के ज़रिए source files को सीधे production server पर overwrite कर दिया जाता था, लेकिन संबंधित काम हमारी टीम में आने के बाद हमने इसे इस तरह बदल दिया।
क्या यह सचमुच अव्यावहारिक जटिलता है?"
आपने ऐसा कहा, लेकिन यह लेख उससे बहुत संबंधित नहीं लगता। deployment और management को उस तरह करना, और इस लेख का जो तर्क है, दोनों मुझे काफ़ी अलग बातें लगती हैं।
मूल लेख का आशय सिर्फ़ जटिल हो चुके JS framework की आलोचना करना नहीं है।
सुविधा के लिए मैं ऊपर दिए गए Korean अनुवाद लिंक से उद्धृत करूँगा।
> अब तो सिर्फ़ एक साधारण शीर्षक बदलने के लिए भी 4 engineer, 3 framework, और एक CI/CD pipeline चाहिए। वेबपेज प्रकाशित करना हैरान करने वाली हद तक जटिल हो गया है.
> धीरे-धीरे, web ऐसी चीज़ बन गया है जिसे प्रकाशित करने से पहले compile करना पड़ता है। इसलिए नहीं कि users को इसकी ज़रूरत थी, बल्कि इसलिए कि developers आधुनिक महसूस करना चाहते थे।
> सब कुछ developers के लिए optimize किया गया है, और बाकी सभी के लिए यह शत्रुतापूर्ण है।
> अब हम सिर्फ़ complexity को सहन ही नहीं कर रहे, बल्कि उसे स्वाभाविक मानने लगे हैं। हम मान लेते हैं कि हर site को build step, bundler, hydration strategy, routing layer, API layer, design system, और चतुर cache invalidation logic चाहिए। हम microservice में build करते हैं, edge network पर host करते हैं, और साधारण content पहुँचाने के लिए pipeline deploy करते हैं।
> हम WordPress जैसे platform की features को फिर से बना रहे हैं, लेकिन नतीजा 10 गुना ज़्यादा भारी और usability में बहुत खराब निकलता है। इससे भी बुरा यह है कि हर नई layer नए bug, नई compatibility problem, और नया cognitive burden जोड़ती है। अब हम सिर्फ़ homepage को online डालने के लिए hydration logic, cache strategy, और build pipeline maintain कर रहे हैं।
> component library पर्याप्त flexible नहीं है, इसलिए marketing campaign में देरी होती है। analytics layer hydration strategy के साथ compatible नहीं है, इसलिए A/B test रद्द हो जाते हैं। content update के लिए build का कई दिनों तक इंतज़ार करना पड़ता है। बुनियादी SEO adjustment backlog में दब जाते हैं।
> marketers ticket डाले बिना copy update नहीं कर सकते और न ही experiment चला सकते हैं। वे content preview नहीं कर सकते, layout test नहीं कर सकते, या page export नहीं कर सकते। हर बदलाव को developer, pipeline, approval, और rebuild की प्रक्रिया से गुज़रना पड़ता है।
> marketer, content editor, SEO प्रभारी, designer — ये सभी process से बाहर कर दिए जाते हैं। क्योंकि अब साधारण कामों के लिए भी technical fluency चाहिए। अगर आप title tag बदलना चाहें, तो आपसे कहा जाएगा कि engineer से बात कीजिए; अगर campaign publish करना हो, तो ticket डालिए और दो sprint इंतज़ार कीजिए।
> सब कुछ development team के माध्यम से बहता है। यानी development team तय करती है कि क्या महत्वपूर्ण है, क्या deploy होगा, और क्या अनिश्चितकाल के लिए priority से बाहर हो जाएगा। और वे जितनी अधिक complexity जोड़ते हैं, उतने ही अधिक अपरिहार्य बन जाते हैं।
कोरिया में जहां development culture management -> planner -> developer के क्रम में नीचे आती है, वहीं पश्चिम में कोरिया जैसी planner की अवधारणा नहीं होती और developer product planning आदि में सक्रिय रूप से शामिल होते हैं। पश्चिम में PM जैसी भूमिकाएं भी cover letter और self-introduction letter की तरह पूरी तरह एक जैसी अवधारणाएं नहीं हैं, इसलिए वे कोरिया के planner से भी पूरी तरह मेल नहीं खातीं। बेशक, जिन games में creative project का स्वभाव मजबूत होता है और fun व gameplay महत्वपूर्ण होते हैं, वहां पश्चिम भी एशिया की तुलना में अधिक horizontal है, लेकिन फिर भी director से developer तक नीचे आने वाली संरचना मौजूद रहती है।
अच्छा, तो ऐसा अंतर है।
लेकिन मुझे नहीं लगता कि यह ऊपर की बातों से बहुत ज़्यादा संबंधित हिस्सा है।
Rails का इस्तेमाल करें, खुश रहें
मैं इस लेख के सार से सहमत हूँ। आजकल JS का इतना ज़्यादा इस्तेमाल हो रहा है कि i9-9900k इस्तेमाल करने पर भी कई बार साइट अटकने लगती है। गेमिंग या काम के लिए यह थोड़ा बीच का स्पेक हो सकता है, लेकिन हक़ीक़त यह है कि इससे भी कम स्पेक वाले दफ़्तरों के कंप्यूटर बहुतायत में मौजूद हैं.
इसीलिए मुझे Astro और hotwired पसंद हैं, क्योंकि ये उस सोच वाले framework हैं कि JS का इस्तेमाल केवल वहीं किया जाए जहाँ वह सच में ज़रूरी हो, जैसे interactive हिस्सों में या interactive page navigation में। मुझे server-side rendering भी पसंद है, यानी server side पर render करना। दूसरी ओर, CSR (जिसमें केवल meta tag server side पर render किए जाते हैं और बाकी हिस्सा CSR से संभाला जाता है, वह भी शामिल है) मुझे बिल्कुल पसंद नहीं है। क्योंकि मैं इसे server का काम client पर थोपने जैसा मानता हूँ। व्यक्तिगत रूप से मेरा मानना है कि CSR का इस्तेमाल करने वाला पारंपरिक SPA तरीका Electron जैसे apps में, जहाँ frontend को local पर चलाया जाता है, वहीं इस्तेमाल होना चाहिए। बेशक, जब frontend को server से load किया जाए, तब SSR का इस्तेमाल करना चाहिए।
नीचे पोस्ट पर आई टिप्पणियों की प्रतिक्रियाओं को 5 प्रकारों में वर्गीकृत किया गया सारांश है:
1. पूर्ण सहमति और समर्थन
मुख्य विशेषताएँ: लेख के दावों से पूरी तरह सहमत हैं और जटिल JS stack की समस्याओं को स्वीकार करते हैं।
राय के उदाहरण:
2. framework के अति-उपयोग पर चिंता
मुख्य विशेषताएँ: React, Angular जैसे framework के अत्यधिक उपयोग की आलोचना, और यह राय कि सरल तकनीकें ही काफ़ी हैं।
राय के उदाहरण:
3. आंशिक सहमति + व्यावहारिक दृष्टिकोण
मुख्य विशेषताएँ: दावे से सहमति है, लेकिन यह व्यावहारिक दृष्टिकोण भी मौजूद है कि कुछ स्थितियों में जटिलता अपरिहार्य या आवश्यक होती है।
राय के उदाहरण:
4. development culture और industry structure की आलोचना
मुख्य विशेषताएँ: यह संकेत कि framework की अधिकता केवल तकनीकी समस्या नहीं, बल्कि hiring, culture और marketing structure का परिणाम है।
राय के उदाहरण:
5. आलोचना या विरोध
मुख्य विशेषताएँ: लेख की मूल धारणा से असहमति, या इसे एकतरफ़ा तर्क कहकर आलोचना।
राय के उदाहरण:
ओह, इसे प्रकार के हिसाब से बाँट दिया गया है, इसलिए देखना आसान है और अच्छा लग रहा है।
मैं मूल लेख में उठाई गई ‘वेब की अत्यधिक जटिलता’ वाली समस्या से सहमत हूँ। लेकिन उसके कारण को सिर्फ developer culture या framework के overuse तक सीमित कर देना मुझे सही नहीं लगता। आज के वेब की जटिलता का बड़ा हिस्सा दरअसल उन अनिवार्य features और security की छाया है, जिनकी मांग ‘business model’ करता है। इस बिंदु को छोड़े बिना बात अधूरी ही रहेगी।
वेब अब सिर्फ ‘मुफ़्त प्रदर्शनी स्थल’ नहीं रहा। आज public sites को छोड़कर ज़्यादातर web services का लक्ष्य revenue generate करना है। इसलिए technology choice का मुख्य सवाल “यह code कितना pure है?” नहीं, बल्कि “क्या यह technology हमारे business को सफल बनाती है?” होना चाहिए।
इस नज़रिए से देखें तो मूल लेख जिस आदर्श ‘हल्के content web’ की बात करता है, वह वास्तविक business requirements की दीवार से टकराता है। उदाहरण के लिए, content बेचने वाला business सिर्फ साधारण static pages पर नहीं चल सकता। paid subscription और payment process करने के लिए user authentication, subscription status verification और access control जैसे state-based logic की ज़रूरत होती है, और content protection के लिए illegal copying या unauthorized access को रोकने वाली real-time token verification जैसी security layer भी अनिवार्य है। आगे बढ़कर, personalization और A/B testing के ज़रिए user experience और conversion rate बढ़ाने के लिए dynamic data processing भी चाहिए।
यह सब ‘sophisticated application’ के दायरे में आता है, और framework इन्हें लागू करने का एक व्यावहारिक tool है।
बेशक, हर जटिलता को सही नहीं ठहराया जा सकता। हमें जटिलता को दो हिस्सों में बाँटना चाहिए।
अनिवार्य जटिलता: यह वह जटिलता है जो business features (authentication, payment, personalization आदि) को लागू करने के लिए पैदा होती है, और जिसका ROI स्पष्ट होता है। यह वह लागत है जिसे स्वीकार करना पड़ता है.
आकस्मिक जटिलता: यह वह अनावश्यक जटिलता है जो development convenience या अत्यधिक technical abstraction के कारण पैदा होती है। यह technical debt और बर्बादी है, जिसे लगातार मापकर हटाना चाहिए।
सफल services इन दोनों में फर्क करके यथार्थवादी architecture बनाती हैं। यानी जहाँ marketing और SEO महत्वपूर्ण हैं, उस frontline को जितना हो सके हल्का रखा जाता है, जबकि core transaction या personalization features की ज़रूरत वाले अंदरूनी हिस्सों में framework-based stability सुनिश्चित की जाती है। इस hybrid strategy के ज़रिए वे speed और functionality, दोनों को साथ लेकर चलते हैं।
मूल लेख ने user experience के बिगड़ने का कारण सिर्फ framework culture पर केंद्रित किया, और ‘revenue model से पैदा हुई अनिवार्य मांगों’ को बाहर कर दिया। इस पहलू को हटाकर web development की बात करना वैसा ही है जैसे मेहमान की मेज़ पर ‘तेज़ और स्वादिष्ट खाना’ परोसने की बात तो की जाए, लेकिन उसे बनाने वाली जटिल रसोई और भुगतान लेने वाले counter के अस्तित्व को नज़रअंदाज़ कर दिया जाए।
सिर्फ इसलिए कि web भारी हो गया है, framework को बिना सोचे-समझे छोड़ा नहीं जा सकता। असली सवाल यह होना चाहिए कि business की मांग वाले features को कितनी दक्षता से, कितनी न्यूनतम लागत पर लागू करके user तक value पहुँचाई जाए।
हंगुल अनुवादित संस्करण नीचे है.
https://junghan92.medium.com/%EB%B2%88%EC%97%AD-%EC%9E%90%EB%B0%94%EC%…