Deno 2.8

• deno add और deno install अब CLI में बिना prefix वाले package name को डिफ़ॉल्ट रूप से npm: package मानते हैं, जिससे मौजूदा Node project में npm install·yarn·pnpm install की जगह इन्हें इस्तेमाल करना आसान हो जाता है
• deno audit fix npm dependency की vulnerable package को version constraint पूरा करने वाले सबसे नज़दीकी patch version तक अपने-आप upgrade करता है, और जिन items में major version change चाहिए उन्हें अलग से दिखाता है
• नए subcommand के रूप में deno ci, deno pack, deno transpile, deno why, deno bump-version जोड़े गए हैं, जो reproducible install, npm publish के लिए tarball बनाना, TS→JS conversion, dependency path tracing, और workspace version update को support करते हैं
• Node.js API compatibility Node के अपने test suite के आधार पर Deno 2.7 के लगभग 42% से बढ़कर Deno 2.8 में 76.4% (3,405/4,457) हो गई है, और कई node: module अब lazy-load होते हैं, जिससे उन modules का उपयोग न करने वाले programs का startup तेज़ होता है
• Performance में Deno 2.7.1 की तुलना में cold npm install 3,319ms से घटकर 906ms हो गया है, यानी 3.66 गुना तेज़; node:buffer base64 3.07 गुना, node:http throughput 2.21 गुना, और node:crypto scrypt 2.12 गुना बेहतर हुए हैं
• Compatibility change के तहत global setTimeout और setInterval अब number की बजाय Node का Timeout object लौटाते हैं, इसलिए जो code return value को number के रूप में store करता था या type check और arithmetic में इस्तेमाल करता था, उसे NodeJS.Timeout आदि के अनुसार बदलना होगा
• TypeScript 6.0.3 built-in है, और deno check, LSP अब डिफ़ॉल्ट रूप से lib.node शामिल करते हैं, जिससे NodeJS.*, Buffer, process जैसे Node types बिना अलग configuration के resolve हो जाते हैं
• Debugging में Chrome DevTools का Network tab अब Deno के fetch(), node:http/node:https, WebSocket traffic को दिखाता है, और --cpu-prof, --cpu-prof-flamegraph, --cpu-prof-md से V8 profile, SVG flamegraph, और Markdown report बनाई जा सकती है
• Package और workspace management में catalog: protocol, deno install --os --arch, --prod, nodeModulesLinker: "hoisted", .npmrc का min-release-age, और --package-json जोड़े गए हैं, जो monorepo version alignment, cross-platform install, production install, और मौजूदा Node project migration को बेहतर बनाते हैं
• deno compile अब Next.js, Astro, Fresh, Remix, SvelteKit, Nuxt, SolidStart, TanStack Start, Vite SSR project को detect करके deno task build चलाता है और उपयुक्त entry point बनाता है, साथ ही बड़े npm dependency tree को process करते समय progress भी दिखाता है
• Testing और Web API में Deno.test() के sanitizeOps और sanitizeResources के डिफ़ॉल्ट मान false हो गए हैं, per-test timeout और function-level coverage जोड़ी गई है, और OffscreenCanvas, transferable Headers·Request·Response·Streams, SHA3 digest, और P-521 Web Crypto support शामिल हैं
• Upgrade और runtime foundation में deno upgrade उपलब्ध होने पर delta update के जरिए download को लगभग 48MB से घटाकर 3~6MB कर देता है, deno upgrade pr <number> से PR build install की जा सकती है, और V8 को 14.6 से 14.9 तक upgrade किया गया है

[GN⁺]

Hacker News की राय

• Deno का डिफ़ॉल्ट permission model उपयोगी है, यह Rust में लिखा गया है, और TypeScript को native रूप से सपोर्ट करता है
  मैं web development/Node/Bun ecosystem में बहुत गहराई से नहीं हूँ, लेकिन कुछ सालों से छोटे services के लिए Deno को संतोषजनक तरीके से इस्तेमाल करता रहा हूँ। मुझे जिज्ञासा है कि Bun इतनी तेज़ी से बढ़ता हुआ क्यों दिखता है। पता नहीं इसे मुख्यतः bundler के रूप में इस्तेमाल किया जाता है और JavaScript runtime के रूप में कम
  सिर्फ permission system की वजह से भी Deno आकर्षक लगता है, इसलिए लोग Node से Bun पर जाते हुए Deno पर क्यों नहीं जाते, यह मुझे ठीक से समझ नहीं आता

  • Deno और Bun के लॉन्च के समय उनका फोकस काफ़ी अलग था। Deno में Node के मूल निर्माता Ryan ने Node में जो बहुत-सी चीज़ें ग़लत मानी थीं, उन्हें ठीक करने की कोशिश की, जबकि Bun ने शुरू से Node compatibility और Next.js जैसे लोकप्रिय frameworks चलाने पर ध्यान दिया
    लंबे समय तक बहुत-सी dependencies और frameworks Deno पर सही से काम नहीं करते थे, और शुरुआत में तो npm से dependencies install करने की सुविधा भी नहीं थी। npm supply-chain attacks को देखते हुए शायद Ryan का फैसला सही रहा हो
    इसलिए Bun बहुत कम configuration में तुरंत काम करने वाले, सुविधाओं से भरपूर बेहतर Node जैसा लगता था। Deno टीम को भी शायद समझ आ गया कि सफल होने के लिए Node compatibility चाहिए, और पिछले कुछ सालों से उन्होंने उसी पर ध्यान दिया है। अब मुझे लगता है कि Deno, Bun से भी ज़्यादा Node-compatible है
  • जब कोई छोटा TypeScript side project शुरू करना हो, तो npm/yarn/berry/pnpm/bubble/vite/webpack/rollup/rolldown/rollout/swc/esbuild/teatime के समंदर में डूबने की बजाय सिर्फ Bun इस्तेमाल कर सकते हैं
    वैसे, इनमें से कुछ ही Pokémon moves हैं, बाकी सचमुच JS/TS ecosystem के tools हैं
  • मैं दोनों का इस्तेमाल करता हूँ और दोनों पसंद हैं। Bun, Node के drop-in replacement के ज़्यादा क़रीब है
    जब test config, tsconfig, ES modules जैसी चीज़ों को छेड़ना न हो, तो यह बस काम कर देता है। Deno की standard library अच्छी है और CLI support भी शानदार है, और पहले deno deploy भी पसंद था, लेकिन आजकल वह काफ़ी झंझट भरा हो गया है
  • मैं मुख्यतः backend developer हूँ, लेकिन जब personal projects में थोड़ा frontend छूना होता है, तो Deno सबसे तर्कसंगत विकल्प लगता है
    इसके साथ काम करना सच में अच्छा है, और अफ़सोस है कि यह JS वालों के बीच ज़्यादा नहीं फैला
  • मैंने Deno को लगभग 1 साल इस्तेमाल किया और ऊपर बताए गए फ़ायदों की वजह से पसंद भी किया, लेकिन Astro, Prisma, Vite जैसे packages के साथ compatibility issues बहुत ज़्यादा थे
    इसलिए मैं Bun पर चला गया और अनुभव कहीं ज़्यादा smooth हो गया

• मुझे जिज्ञासा है कि आजकल Deno की स्थिति क्या है
  Node एक स्थिर समाधान है और आगे भी बना रहेगा। अब इसमें TypeScript भी इस्तेमाल कर सकते हैं, और लगता है कि जल्द ही native dependencies समेत apps को single executable file में build करना भी संभव होगा
  Bun थोड़ा अव्यवस्थित है, लेकिन तेज़ है, और standard library में सब कुछ शामिल करने वाला इसका approach दिलचस्प है। ऊपर से, इसे Anthropic ने acquire भी कर लिया है
  Deno के पास sandboxing और third-party dependencies import करने की आसानी जैसी एक अच्छी कहानी थी, लेकिन अब sandboxing काफ़ी आम-सी लगती है, और import का तरीका भी आख़िरकार npm add से इतना बेहतर था या नहीं, यह पता नहीं

  • Deno ने लगभग 2 महीने पहले अपनी कंपनी के लगभग आधे लोगों को निकाल दिया था: https://news.ycombinator.com/item?id=47467746
  • Anthropic द्वारा acquire किए जाने को सकारात्मक रूप में कौन देखता है?
  • ecosystem के ठहराव से बचने के लिए कई विकल्प होना अच्छा है
  • single executable file deployment पहले से संभव है। मेरे product का CLI, Node single-executable-file application है
  • मुझे नहीं पता था कि native dependencies समेत single executable file build करना संभव होने वाला है। यह काफ़ी शक्तिशाली feature है

• Deno शानदार है। मैं छोटे web services और मध्यम आकार की web services Deno में लिख रहा हूँ
  यह Swiss watch की तरह चलता है, और project philosophy भी Unix spirit के साथ अच्छी तरह मेल खाती है
  व्यक्तिगत रूप से मुझे लगता है कि Deno बनाने वाले लोग थोड़ा ज़्यादा विनम्र हैं। आभारी users project को donation देने की पेशकश भी करते हैं, तो वे विनम्रता से मना कर देते हैं। वजह समझ में आती है, लेकिन लंबी अवधि में इससे project पर अनावश्यक आर्थिक दबाव बन सकता है
  ऐसे users के लिए जो project की long-term success पर निर्भर हैं, “कृपया पैसे ले लीजिए” जैसी monthly subscription काफ़ी अच्छी बैठ सकती है

  • इसे इस्तेमाल करना सच में बहुत आनंददायक है। यह लगभग JavaScript और Go के मिश्रण जैसा लगता है
    यह तेज़ और लचीला है, और दूसरे JS/TS विकल्पों की तुलना में ज़्यादा ताकतवर features वाला थोड़ा ज़्यादा समझदार package management, बेहतर security model, बेहतर standard library देता है। और यह बहुत तेज़ है

• जिन लोगों को Deno नाम परिचित नहीं है, उनके लिए बता दूँ कि Deno एक JavaScript और TypeScript runtime है
  Deno 2.6 की competitor Bun 1.3 और Node.js 25 के साथ तुलना करने वाली एक review है: https://www.devtoolreviews.com/reviews/bun-vs-node-vs-deno-2...

  • यह हैरान करने वाला है कि web requests संभालने में Bun इतना ज़्यादा तेज़ है। लेख में Zig को कारण बताया गया है, लेकिन क्या सिर्फ memory की बारीक management से Node की तुलना में 2x से ज़्यादा फ़ायदा मिल सकता है, यह जानना चाहूँगा
    इसी तरह, लेख में साफ़ नहीं कहा गया, लेकिन Bun शायद warm package cache की स्थिति में चलाया गया लगता है। जानना चाहूँगा कि क्या दूसरे runtimes के लिए भी cache मौजूद था

• Deno का लगातार release cycle प्रभावशाली है। इस version में कौन-कौन से performance improvements आए हैं, यह देखने की उत्सुकता है

• नया deno pack command सुरक्षित और सरल packaging के लिए एक अच्छा addition है
  अगर आप Node.js इस्तेमाल कर रहे हैं, तो ऐसा ही single-command तरीका https://www.npmjs.com/package/ts-node-pack से संभव है
  अब जबकि Node.js .ts modules import करना सपोर्ट करता है, ज़्यादा repositories इसे build step या checkout में build artifacts डाले बिना इस्तेमाल कर पाएँगी

  • इस blog post को देखते ही मैं इसी पर सोचने लगा। deno pack शायद मेरे open source package के मौजूदा npm publish flow की जगह ले सकता है, और काम को Deno-first/Deno-centric दिशा में आगे बढ़ाने के लिए अच्छा हो सकता है
    दूसरी तरफ़, Node का TypeScript support बढ़ रहा है, इसलिए इसे TypeScript-only npm package में बदलना भी ecosystem को भेजा गया एक बहुत छोटा-सा संदेश हो सकता है
    फिर भी, यह अच्छा है कि JSR अपेक्षाकृत ज़्यादा साफ़-सुथरे ecosystem के रूप में मौजूद है
  • यह लंबे समय से मौजूद DNT(https://github.com/denoland/dnt) से काफ़ी मिलता-जुलता लगता है
    लेकिन अगर यह Deno CLI के अंदर आ जाए, तो इसकी visibility बहुत बढ़ जाती है

• अगर Deno ने अपनी शुरुआती value proposition को थोड़ा और लंबे समय तक पकड़े रखा होता, तो Node compatibility का दबाव कुछ हद तक AI agents कम कर सकते थे
  उस दबाव का बड़ा हिस्सा familiarity की समस्या से आता है। अगर आपको सिर्फ express.js के साथ configuration करना आता है, तो उसके बाद कोई भी tool या runtime इस्तेमाल करते समय आपको लगेगा कि smooth transition के लिए वैसी ही abstractions मिलनी चाहिए। इससे फ़र्क नहीं पड़ता कि पहला समाधान शुरू से कितना ख़राब था
  आजकल product के साथ ज़रूरी tech bundle भी दिया जा सकता है और developers को नई technologies से परिचित कराया जा सकता है, और कई बार यह सचमुच documentation की जगह ले लेता है तथा बेहतर वैकल्पिक approaches दिखाने में काफ़ी अच्छा साबित होता है

  • अगर किसी SaaS vendor से मिला JS/TS SDK बिना बदलाव के Deno पर नहीं चलता, तो उसे ठीक करने में मैं 1 सेकंड भी नहीं लगाऊँगा

• कई hobby projects में Deno इस्तेमाल करने के बाद, मुझे यक़ीन है कि Deno वही दिशा है जिस तरफ़ JS ecosystem को जाना चाहिए
  लेकिन काम के माहौल में, बहुत खास और आमतौर पर सीमित use cases के बाहर इसे recommend करना जटिल है। किसी बिंदु पर अगर project business reasons की वजह से pivot करता है, तो आख़िरकार Node की ज़रूरत पड़ती है

• Edge.js [1] के लॉन्च के बाद Deno ने Node.js compatibility को ज़्यादा गंभीरता से लेना शुरू किया, यह देखना अच्छा है
  लगभग 2 महीनों में यह 40% के दायरे से बढ़कर करीब 75% तक आ गया, तो चाहे यह संयोग हो या नहीं, यह सही दिशा में एक स्पष्ट कदम है
  Deno टीम के सभी लोगों को बधाई
  [1] https://edgejs.org/

  • क्या self-promotion से तुम कभी नहीं थकते?

• मैं ज़्यादातर Node-शैली के idioms को wrap करके Deno को runtime की तरह इस्तेमाल करता हूँ। यह अच्छी तरह काम करता है
  अगर project pure TypeScript है, तो मैं उसे सीधे Deno से चलाता हूँ। security के लिए extra options भी अच्छे हैं, और install scripts का default रूप से disabled होना भी अच्छा है
  अगर आप सीधे Node इस्तेमाल कर रहे हैं, तो उम्मीद है कि आप ऐसा बंद करेंगे। कम से कम Bun इस्तेमाल करना बेहतर है
  agent-based work में Rust और TypeScript के अलावा कुछ और इस्तेमाल करने का कारण लगभग नहीं है। असहमति हो सकती है, लेकिन type safety, memory safety, और विशाल work corpora महत्वपूर्ण हैं। agents को tricky errors और built-in patterns चाहिए होते हैं ताकि वे आसानी से रास्ता निकाल सकें। UI के लिए TypeScript सबसे तर्कसंगत है, क्योंकि design examples की संख्या बहुत ज़्यादा है