Deno की गिरावट की अफवाहें काफ़ी बढ़ा-चढ़ाकर कही गई हैं

• हाल में Deno Deploy, KV, Fresh और कंपनी व प्रोजेक्ट की कुल momentum को लेकर आलोचनाएँ और चिंताएँ सामने आई हैं
• इन आलोचनाओं में कुछ बातें वाजिब हैं, और प्रगति को पर्याप्त रूप से सार्वजनिक न करने से भ्रम भी बढ़ा, लेकिन इन अफवाहों और आलोचनाओं का बड़ा हिस्सा बिना आधार के अटकलें या तथ्यात्मक रूप से ग़लत बातें हैं
• Deno 2 के रिलीज़ (अक्टूबर 2023 के बाद) के बाद मासिक सक्रिय उपयोगकर्ता मेट्रिक्स के आधार पर adoption 2 गुना से अधिक बढ़ा है
• Deno 2 की मज़बूत Node compatibility ने वास्तविक उपयोग में एक बड़ा hurdle हटाया है, और प्लेटफ़ॉर्म अब पहले से अधिक तेज़, शक्तिशाली और सरल हो गया है

Deno Deploy में बदलाव और विकास

• सबसे ज़्यादा पूछे जाने वाले सवालों में से एक हाल में Deno Deploy के उपलब्ध regions में कमी की वजह है
• इस कमी के पीछे सिर्फ़ लागत ही नहीं, बल्कि वास्तविक usage patterns और ज़रूरतों में बदलाव भी शामिल हैं
  • ज़्यादातर apps के लिए सभी regions नहीं, बल्कि डेटा के क़रीब वाले क्षेत्रों में speed, debug और compliance ज़्यादा महत्वपूर्ण हैं
• Deploy लॉन्च के बाद regions की संख्या 25 से 35 और अब 6 तक बदली है
• कई regions का वास्तव में लगभग कोई उपयोग नहीं हो रहा था, और ज़रूरत से ज़्यादा फैलाव की वजह से प्रदर्शन में गिरावट (latency, capacity issues) भी हो रही थी
• अब उपयोगकर्ताओं की ज़रूरतों के अनुरूप एक व्यावहारिक “edge” विज़न को फिर से बनाया जा रहा है
• Deploy का नया version विकसित किया जा रहा है, और प्लेटफ़ॉर्म full application hosting की दिशा में विकसित हो रहा है
  • इसमें subprocesses, background jobs, OpenTelemetry, build pipelines, self-hosted regions आदि का support आने वाला है
• जल्द ही apps को किसी region में pin करने या अपने cloud में चलाने की सुविधा दी जाएगी

KV (key-value store) की दिशा

• Deno KV एक सरल API वाला store है जो बिना configuration के, global consistency guarantee और real-time features देता है
• यह session data, feature flags और collaborative state जैसी चीज़ों के लिए उपयुक्त है, लेकिन general-purpose database के लिए नहीं
• व्यापक data management की ज़रूरतों के लिए दो प्रयास चल रहे हैं
  • मौजूदा relational databases का Deno Deploy में integration और मज़बूत किया जा रहा है
  • compute और state के जुड़ाव को सरल बनाने वाला एक नया project आगे बढ़ाया जा रहा है (Cloudflare Durable Objects से प्रेरित)
• इसी दिशा के अनुसार KV beta में ही रहेगा, और केवल गंभीर bugs तथा security issues पर लगातार काम होगा
• संपूर्ण state management solution के केंद्र में या उसके विकसित रूप में आगे किसी दूसरे project की भूमिका रहने की संभावना है

Fresh framework की स्थिति

• Fresh अब भी सभी internal apps और web services की नींव है, और इसे सक्रिय रूप से maintain व improve किया जा रहा है
• Fresh 2 को लेकर ऊँची अपेक्षाओं और लंबे इंतज़ार की स्थिति को स्वीकार किया गया है
• जल्दबाज़ी में रिलीज़ करने के बजाय मूल गुणवत्ता और संरचना को बेहतर बनाना प्राथमिकता है
• हाल में घोषित विस्तृत सुधारों पर ब्लॉग पोस्ट देखी जा सकती है
• इस साल के भीतर स्थिर Fresh 2 रिलीज़ करने की योजना है

Deno: runtime से आगे का platform

• Deno सिर्फ़ एक runtime नहीं, बल्कि एक पूर्ण JavaScript system platform है
• एक ही toolchain के साथ लिखना, चलाना, test करना, deploy करना, monitor करना जैसी चीज़ें एकीकृत रूप से की जा सकती हैं
• integration, default settings, flags और tools के बीच कनेक्शन लगातार मज़बूत किए जा रहे हैं
• लक्ष्य सिर्फ़ साधारण feature parity नहीं, बल्कि एक integrated ecosystem बनाना है
• यह JavaScript development की बुनियादी गुणवत्ता सुधारने की दिशा में काम कर रहा है, और उसी के लिए अपने दायरे का विस्तार कर रहा है

इस platform का लक्ष्य और कारण

• scripting languages तेज़ व्यावहारिक development में अपरिहार्य भूमिका निभाती हैं
• standardization, बड़े ecosystem और general-purpose scalability के लिहाज़ से JavaScript का भविष्य और भी मज़बूत दिखता है
• एक “batteries included” platform की ज़रूरत है, और Deno उसी दिशा में है (permission management, web server, observability, lint, type check आदि built-in)
• यह बिखरे हुए tools की जगह एकीकृत अनुभव प्रदान करता है

भविष्य की योजनाएँ और मज़बूत communication

• Deno सिकुड़ नहीं रहा, बल्कि विस्तार के चरण में प्रवेश कर रहा है
• platform की speed, compatibility और maturity में लगातार सुधार हो रहा है, और JSR की independent governance भी बढ़ रही है
• TC39/ WinterTC जैसे community collaboration और JavaScript ecosystem के लिए कई समानांतर प्रयास जारी हैं
• Deploy और KV के अनुभव के आधार पर सतत और distributed नए products विकसित किए जा रहे हैं, और जल्द ही अधिक जानकारी साझा की जाएगी
• विवाद और अविश्वास कम करने के लिए communication को और मज़बूत किया जाएगा, और developers के साथ trust को महत्व दिया जाएगा

[yangeok]

क्या bun, deno से बेहतर है?

[xguru]

Deno की गिरावट: वैश्विक regions घटकर 6 रह गए
लगता है यह उस पोस्ट के जवाब में है।

Fresh update में देरी क्यों हो रही है, इस पर भी अलग से लिखा गया है Deno का web framework Fresh 2 update

[GN⁺]

Hacker News राय

• ऐसा शुरू से ही स्पष्ट लग रहा था कि ज़्यादातर डेवलपर सिर्फ़ साधारण stateless functions deploy नहीं करते, बल्कि full-stack app जैसे वास्तविक applications बनाते हैं जो database से बात करते हैं। यह बात अब जाकर समझ में आना थोड़ा स्वाभाविक लगता है

• हाल में Deno, Deploy, KV, Fresh, और कुल मिलाकर इसकी growth trajectory को लेकर आलोचनात्मक माहौल रहा है, इस बात की साझा समझ। growth पर आई आलोचना के बारे में कोई खास टिप्पणी या जवाब नहीं दिखा, तो यह जानने की जिज्ञासा है कि क्या यह जानबूझकर था। चूँकि कहा गया कि कुछ आलोचनाएँ वैध थीं, इसलिए अगर यह भी खुलकर बताया जाता कि कौन-सी आलोचनाएँ वैध थीं और उन्हें कैसे सुलझाने की योजना है, तो भरोसा और बढ़ता। कंपनी जब ईमानदारी से अपनी कमियाँ भी मानती है, तो वह चयन के लिए उल्टा सकारात्मक कारक बनता है। Migadu के pro/con page की तरह फ़ायदे-नुकसान पारदर्शी रूप से बताना पसंद आने का अनुभव साझा किया गया

  • Deno की ओर से हाल की growth को लेकर जो बात कही गई, वह यह थी कि launch के बाद लगभग 6 महीनों में monthly active users की संख्या दोगुने से ज़्यादा बढ़ी। लेकिन किस आधार पर दोगुनी हुई, या किस metric की बात हो रही है, यह सार्वजनिक नहीं किया गया। शुरुआती दौर में अस्पष्ट उम्मीदों और नई service पर भरोसे के कारण इसे सकारात्मक रूप से देखा गया था, लेकिन अब बिना आँकड़ों या प्रमाण के growth expectations और वास्तविकता के बीच के फ़ासले से निराशा का माहौल बन रहा है, ऐसी राय

• शुरुआत में Deno से उम्मीद इस वजह से थी कि वह existing compatibility पर अटकने के बजाय कम complexity के साथ साफ़-सुथरी नई शुरुआत कर सकता था। Node की तुलना में कुछ नई असुविधाएँ थीं, लेकिन वे संभालने लायक लगीं। लेकिन अपनी अलग solutions बनाने के बजाय यह धीरे-धीरे Node compatibility से चिपकता गया, और अब यह Node से भी ज़्यादा complex dual structure जैसा लगता है। Node packages का Deno में स्वाभाविक रूप से चलना ज़रूरी है, लेकिन कुछ unimplemented APIs या bugs की वजह से बहुत से edge cases पैदा हो गए हैं। मेरा पसंदीदा test framework AVA अभी भी supported नहीं है। पहले मैं npm compatibility layer को नज़रअंदाज़ करके सिर्फ़ Deno ही इस्तेमाल करता था, लेकिन अब यह धीरे-धीरे और झंझट वाला लगने लगा है। सिर्फ़ command-line options देख लें, तो कुछ ही वर्षों में वे काफ़ी जटिल हो गए हैं, और उनमें से ज़्यादातर npm integration के लिए हैं, इसलिए मेरे लिए वे सिर्फ़ अनावश्यक जानकारी हैं। Node compatibility में मेरी सबसे बड़ी इच्छा यह थी कि Deno linter में ESLint config support हो, लेकिन इसमें रुचि दिखाई नहीं देती। फिर भी मैं चाहता हूँ कि Deno सफल हो, क्योंकि इससे Node में सुधार की प्रेरणा मिलती है। बस Deno की मौजूदा दिशा अपने शुरुआती उद्देश्य के साथ सुसंगत नहीं लगती

  • पूछा गया कि क्या हाल में AVA support और ESLint config support फिर से जाँचा गया है। official docs के अनुसार AVA support का उल्लेख है, और ज़्यादातर Deno developers built-in testing features का ज़्यादा उपयोग करते दिखते हैं। official docs में यह भी स्पष्ट लिखा है कि ESLint के साथ काम करने वाले custom rules, plugins, और settings supported हैं। लगभग 6 साल से Deno इस्तेमाल करने के अनुभव से, अलग test/lint setup के बिना भी default features काफ़ी संतोषजनक लगते हैं

• ऐसा महसूस होता है कि Deno ने अपनी दिशा खो दी है। शुरुआत में इसकी positioning एक simple, safe, fast JS/TS runtime की थी जो Rust में बना था, लेकिन अब website के ‘Products’ dropdown में कई products बेतरतीब ढंग से जुड़ गए हैं। लगता है कि इसने Vercel के उस रास्ते का अनुसरण करने की कोशिश की है जिसमें NextJS के बाद deploy platform बनाया गया

  • यह भी लगता है कि यह बदलाव Deno की अपनी मंशा से ज़्यादा JavaScript और Node community के तेज़ी से आगे बढ़ने का असर है, जिसने इसे पीछे से पकड़ लिया। शुरुआती दिनों में Deno की अपनी innovations काफ़ी आकर्षक लगी थीं, लेकिन JS/Node पक्ष भी तेज़ी से बेहतर हुआ, इसलिए अब इसका differentiation कम महसूस होता है

• Deno ने जब Node compatibility जोड़ते हुए अपना शुरुआती वादा छोड़ा, तभी से मेरा उत्साह खत्म हो गया। मेरे लिए Deno का मुख्य आकर्षण यह था कि उसने Node की अवांछित complexity और legacy baggage को हटा दिया था, लेकिन अब built-in TypeScript और permissions जैसे कुछ छोटे फ़र्क छोड़ दें तो यह Node से अलग नहीं बचा। bun.sh भी Node compatibility देता है। क्या कोई ऐसा server-side TypeScript scripting engine पता है जो Node compatibility का पीछा नहीं करता?

  • npm compatibility एक अतिरिक्त feature है, इसलिए ऐसा नहीं लगता कि उससे कुछ खो गया। चाहें तो Node APIs का इस्तेमाल किए बिना भी jsr.io से मनचाही libraries लेकर काम किया जा सकता है। व्यवहार में Node से अलग development experience अभी भी Deno में लिया जा सकता है, यह तर्क दिया गया। हाँ, पूरी ‘purity’ चाहने वाले लोग बहुत कम हैं, इसलिए लोकप्रियता और व्यावहारिकता चुनना शायद बेहतर है

  • Node compatibility का पीछा न करने वाले TypeScript runtime की तलाश पर सवाल उठाया गया। Node में कई समस्याएँ हैं, लेकिन इसके बावजूद यह व्यापक रूप से इस्तेमाल होने लायक काफ़ी उपयोगी है। कोई व्यावहारिक विकल्प बनाने के लिए या तो (1) इतने मज़बूत फ़ायदे होने चाहिए कि बड़े migration का जोखिम उठाया जा सके, या (2) migration cost बहुत कम हो और सुधार स्पष्ट हों, जैसे performance, reliability, usability। लेकिन Deno इन दोनों में ही अधूरा रह गया। यह existing Node code आसानी से नहीं चला पाता, और दूसरी ओर इसके फ़ायदे इतने क्रांतिकारी नहीं हैं कि लोग उमड़ पड़ें; इसलिए यह ‘idealists’ या ‘hobby developers’ तक सीमित रहने वाला approach लगता है

  • Node compatibility का पीछा न करने वाले TypeScript runtime के रूप में Cloudflare Workers workerd याद आता है, लेकिन मूल रूप से वह general-purpose backend runtime नहीं है, और उसमें व्यावहारिक रूप से उपलब्ध default packages या built-in features भी बहुत कम हैं

  • मैं व्यक्तिगत रूप से JSDoc का उपयोग पसंद करता हूँ। यह Node से असंबंधित रहते हुए भी compile chain complexity के बिना काफ़ी मिलते-जुलते फ़ायदे देता है

  • अगर backend में JS से बँधे रहना ज़रूरी नहीं है, तो TypeScript की जगह बेहतर विकल्पों पर विचार करना ज़्यादा तर्कसंगत हो सकता है। अगर पूरे stack पर नियंत्रण है, तो compile-to-JS language पर टिके रहने की कोई ख़ास वजह नहीं है

• लगता है कि यह हालिया लेख पुराने https://news.ycombinator.com/item?id=43863937 पर आई प्रतिक्रिया है

• यह CEO द्वारा लिखा गया लेख है, लेकिन Deno पर विशिष्ट आलोचनाओं की बजाय internal decisions को उचित ठहराने पर ज़्यादा केंद्रित है। फिर भी, Deno product line Deno environment में काफ़ी अच्छी तरह काम करती हुई लगती है

  • फिर से पूछा गया कि Deno से जुड़ी कौन-सी आलोचनाएँ हैं जो अब भी अनसुलझी लगती हैं

• अभी भी भरोसा या पक्का विश्वास नहीं बन पाया है। Deploy कैसा निकलेगा, यह शायद जल्द पता चल जाएगा, लेकिन अगर KV beta stage में ही बिना आगे बढ़ाने की इच्छा के छोड़ दिया गया है, तो नए projects में उसे इस्तेमाल करने की कोई वजह नहीं दिखती। Fresh को Q3 के अंत के आसपास alpha के रूप में refactor किया जाने वाला बताया गया है, लेकिन वह व्यावहारिक रूप से एक minimal framework ही था, और उसका जो build/compile-free structure ध्यान खींचता था, वह भी गायब हो रहा है। runtime का development जारी है, लेकिन “दूसरे runtimes के साथ feature parity का पीछा नहीं करेंगे” जैसी घोषणा के बावजूद release notes में Node/NPM compatibility पर इतना ज़ोर दिलचस्प लगता है

  • KV का ongoing development रोकने का फ़ैसला वाकई बहुत खराब विकल्प लगता है। कंपनियाँ KV का उपयोग इसलिए नहीं टालतीं कि उसके features कमज़ोर हैं, बल्कि इसलिए कि उस पर beta का लेबल लगा है। मैंने Cloudflare Workers KV का बहुत उपयोग किया है और Durable Objects में मेरी विशेष रुचि नहीं थी, इसलिए Deno KV से उम्मीद थी, लेकिन अब लगता है कि इसे आगे consideration से बाहर करना पड़ेगा। नया product announce करके लगभग तुरंत छोड़ दिया गया-सा प्रभाव रणनीतिक रूप से भी बहुत बुरा दिखता है

  • KV इस्तेमाल करने पर विचार किया था, लेकिन आगे कोई स्पष्ट दिशा न दिखने के कारण alternatives देखने पड़े, यह ईमानदार अनुभव साझा किया गया

• क्या यह बात वास्तव में पूरे serverless जगत पर लागू होती है कि ज़्यादातर developers साधारण stateless functions नहीं, बल्कि full-stack apps deploy करते हैं जो databases से काफ़ी गहराई से जुड़े होते हैं? अगर हाँ, तो क्या यह मूल serverless movement के इरादे के अनुरूप है, या लोग बस Docker/Kubernetes जैसी जटिल infrastructure से बचने के लिए इसे चुनते हैं, यह सवाल है

  • मेरी intuition यह है कि बहुत से लोग एक modernized Heroku जैसा अनुभव चाहते हैं, यानी managed RDBMS और auto-scaling करने वाले servers का सेट। ज़्यादातर कंपनियों को ultra-large scale की वास्तव में ज़रूरत नहीं होती

• बताया गया कि Deno Deploy में regions की संख्या घटने को लेकर अक्सर सवाल पूछे जाते हैं। Deno की ओर से समझाया गया कि ज़्यादातर apps को दुनिया भर की हर जगह चलाने की ज़रूरत नहीं होती; उनके लिए data के पास तेज़ी से चलना, debug करना आसान होना, और सिर्फ़ local regulations के अनुरूप होना ज़्यादा महत्वपूर्ण है। लेकिन मैंने ख़ुद Deno Deploy का इस्तेमाल नहीं किया, क्योंकि उसके region locations व्यवहार में मेरे लिए काफ़ी पास नहीं थे और performance को लेकर चिंता थी। data और users के और क़रीब मौजूद कई विकल्प पहले से हैं, और regulatory compliance भी ज़्यादातर मामलों में country level पर पर्याप्त होती है, इसलिए यह optimization direction मुझे विश्वसनीय नहीं लगती