यह बिल्कुल वही चीज़ थी जिसकी मुझे ज़रूरत थी, इसलिए मैं इसे खुद बना रहा था... लेकिन यह उन्होंने बना दिया। मैं Claude Code Max इस्तेमाल करता हूँ, और एक साथ कई प्रोजेक्ट्स डेवलप करते समय यह सच में बहुत ज़रूरी सॉफ़्टवेयर था।
डिस्क स्पेस की बर्बादी की समस्या से तो काफ़ी हद तक सहमत होना ही पड़ता है...
AKS चलाता हूँ, और हर बार 1GB से ऊपर जाने वाली Python ऐप की container image देखता हूँ तो सिर दर्द होने लगता है.
अभी तो बस Dockerfile उठाकर मैं खुद ही फिर से size कम करके अपलोड करता हूँ, और 500MB से नीचे नहीं ला पाऊँ तो बस हार मान लेता हूँ, हाहा
वाह...! जब मैंने इसे पहली बार इस्तेमाल किया था, तो वह Python होने की वजह से इस्तेमाल किया गया एक प्रोजेक्ट था...
काफी लंबा समय बीत गया!
अच्छा होगा अगर फिर से ऐसे माहौल में काम कर सकूँ जहाँ इसे इस्तेमाल किया जा सके :) हाहा
सोच रहा हूँ, शायद साइड प्रोजेक्ट में ही ट्राय करूँ...
मुझे भी लगातार Android push notifications मिल रही थीं कि DNS server तक access नहीं हो पा रहा है.
मैं थोड़ी देर के लिए Google DNS पर शिफ्ट हो गया था. https://developers.google.com/speed/public-dns/…
शायद बस एक जबरदस्त कीमत वाली जबरदस्त मशीन से काम चल जाएगा? कोई बड़ा लॉ फर्म तो खरीद ही लेगा। लेकिन फिर उसे फैक्ट्री की मशीन की तरह 24 घंटे चलाना पड़ेगा, haha
मूल लेख का आशय सिर्फ़ जटिल हो चुके 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 जोड़ते हैं, उतने ही अधिक अपरिहार्य बन जाते हैं।
मैं मूल लेख में उठाई गई ‘वेब की अत्यधिक जटिलता’ वाली समस्या से सहमत हूँ। लेकिन उसके कारण को सिर्फ 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 पहुँचाई जाए।
स्ट्रीमिंग फीचर देने वाली चैटबॉट जैसी सेवाओं में concurrent processing के दौरान Prefill काम decode तक को प्रभावित कर देता है, इसलिए VRAM पर्याप्त होने पर भी यूज़र की नज़र में परफॉर्मेंस बहुत खराब दिखती है।
मैंने chunk prefill से जुड़े options और vLLM में experimental तौर पर दिए जाने वाले Disaggregated Prefilling फीचर भी लागू करके देखे, लेकिन फिर भी नया request आते ही पहले से generate हो रहे जवाब बीच-बीच में टूटने लगते हैं। शुरुआती डेवलपर के नज़रिए से GPU या nodes बढ़ाने के अलावा सबसे efficient तरीका क्या हो सकता है, यही जानना चाहता हूँ।
यह बिल्कुल वही चीज़ थी जिसकी मुझे ज़रूरत थी, इसलिए मैं इसे खुद बना रहा था... लेकिन यह उन्होंने बना दिया। मैं Claude Code Max इस्तेमाल करता हूँ, और एक साथ कई प्रोजेक्ट्स डेवलप करते समय यह सच में बहुत ज़रूरी सॉफ़्टवेयर था।
Django को जन्मदिन की शुभकामनाएँ!
हिंदी अनुवाद नीचे दिया गया है.
https://roy-jung.github.io/250701-history-of-js/
काफी सुधार, बेहतरीन प्रदर्शन और सटीकता को अगर आँकड़ों के साथ दिखाया जाता तो अच्छा होता।
कोरिया में यह कैसे अलग होगा?
डिस्क स्पेस की बर्बादी की समस्यासे तो काफ़ी हद तक सहमत होना ही पड़ता है...AKS चलाता हूँ, और हर बार 1GB से ऊपर जाने वाली Python ऐप की container image देखता हूँ तो सिर दर्द होने लगता है.
अभी तो बस Dockerfile उठाकर मैं खुद ही फिर से size कम करके अपलोड करता हूँ, और 500MB से नीचे नहीं ला पाऊँ तो बस हार मान लेता हूँ, हाहा
वाह...! जब मैंने इसे पहली बार इस्तेमाल किया था, तो वह Python होने की वजह से इस्तेमाल किया गया एक प्रोजेक्ट था...
काफी लंबा समय बीत गया!
अच्छा होगा अगर फिर से ऐसे माहौल में काम कर सकूँ जहाँ इसे इस्तेमाल किया जा सके :) हाहा
सोच रहा हूँ, शायद साइड प्रोजेक्ट में ही ट्राय करूँ...
जब Claude 4 आ चुका है, तब उसकी तुलना Claude 3 से करना क्या लगभग धोखा नहीं है...
कोरियाई समय के अनुसार लगभग 7:00 बजे से करीब 50 मिनट तक सेवा बाधित रही, लेकिन अब यह ठीक से काम कर रही है
CMD> nslookup news.hada.io 1.1.1.1
मुझे भी लगातार Android push notifications मिल रही थीं कि DNS server तक access नहीं हो पा रहा है.
मैं थोड़ी देर के लिए Google DNS पर शिफ्ट हो गया था.
https://developers.google.com/speed/public-dns/…
वाह...
बिलकुल, उद्देश्य क्या है और यह क्यों करना चाहिए, इसमें जितनी गहराई से उतरते हैं, उतना ही साफ़ समाधान सामने आता है।
अच्छा लगा कि आपको लेख पसंद आया, धन्यवाद!
अच्छी बातों के लिए धन्यवाद!
शायद बस एक जबरदस्त कीमत वाली जबरदस्त मशीन से काम चल जाएगा? कोई बड़ा लॉ फर्म तो खरीद ही लेगा। लेकिन फिर उसे फैक्ट्री की मशीन की तरह 24 घंटे चलाना पड़ेगा, haha
ऐसा शख्स जो सिर्फ Porsche की कीमत के बारे में सोचता है और maintenance, fuel cost, insurance वगैरह के बारे में ज़रा भी नहीं सोचता।
मूल लेख का आशय सिर्फ़ जटिल हो चुके 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 जोड़ते हैं, उतने ही अधिक अपरिहार्य बन जाते हैं।
शायद यह कोरियाई कंपनियों पर लागू नहीं होगा।
मैं मूल लेख में उठाई गई ‘वेब की अत्यधिक जटिलता’ वाली समस्या से सहमत हूँ। लेकिन उसके कारण को सिर्फ 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 पहुँचाई जाए।
स्ट्रीमिंग फीचर देने वाली चैटबॉट जैसी सेवाओं में concurrent processing के दौरान Prefill काम decode तक को प्रभावित कर देता है, इसलिए VRAM पर्याप्त होने पर भी यूज़र की नज़र में परफॉर्मेंस बहुत खराब दिखती है।
मैंने chunk prefill से जुड़े options और vLLM में experimental तौर पर दिए जाने वाले Disaggregated Prefilling फीचर भी लागू करके देखे, लेकिन फिर भी नया request आते ही पहले से generate हो रहे जवाब बीच-बीच में टूटने लगते हैं। शुरुआती डेवलपर के नज़रिए से GPU या nodes बढ़ाने के अलावा सबसे efficient तरीका क्या हो सकता है, यही जानना चाहता हूँ।