Deno Desktop: Deno प्रोजेक्ट को डेस्कटॉप ऐप के रूप में पैकेज करना

(docs.deno.com)

1 पॉइंट द्वारा GN⁺ 5 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें

वेब ऐप और TypeScript कोड से बने Deno प्रोजेक्ट को प्लेटफ़ॉर्म-विशिष्ट, दोबारा वितरित किए जा सकने वाले डेस्कटॉप ऐप बाइनरी में पैक किया जा सकता है
आउटपुट में application code, Deno runtime, और web rendering engine साथ शामिल होते हैं; यह Deno v2.9.0 में जोड़ा गया है, लेकिन अभी stable release नहीं है
डिफ़ॉल्ट WebView backend ऑपरेटिंग सिस्टम के built-in webview का उपयोग करता है ताकि छोटा binary मिले, और अगर rendering consistency चाहिए तो Chromium(CEF) backend चुना जा सकता है
Next.js, Astro, Fresh, Remix, Nuxt, SvelteKit, SolidStart, TanStack Start, Vite SSR प्रोजेक्ट को detect करके release mode और --hmr development mode के अनुसार server चलाया जाता है
Deno code और webview के बीच communication socket-based IPC की जगह in-process channel से होता है, और scope में cross compilation से लेकर bsdiff-आधारित automatic updates तक शामिल हैं

`deno desktop` की भूमिका और मौजूदा स्थिति

deno desktop Deno प्रोजेक्ट को self-contained desktop application में बदलता है
- input एक single TypeScript file से लेकर Next.js app तक हो सकता है
- output प्लेटफ़ॉर्म-विशिष्ट, दोबारा वितरित किया जा सकने वाला binary होता है
- binary में application code, Deno runtime, और web rendering engine शामिल होते हैं
यह फीचर Deno v2.9.0 में शामिल है, लेकिन अभी stable release नहीं है
- इसे अभी आज़माने के लिए deno upgrade canary से canary build इंस्टॉल करनी होगी
- command, config key, और TypeScript API stable होने से पहले बदल सकते हैं

backend चयन और web project चलाना

web technology को desktop UI toolkit की तरह इस्तेमाल करते हुए, मौजूदा web stack-आधारित desktop app tools के trade-offs कम करने की दिशा चुनी गई है
- Electron, Tauri, Electrobun जैसे tools में बड़े binary, platform support की कमी, JavaScript ecosystem की अनुपस्थिति, built-in updates का अभाव, या framework integration की कमी जैसे trade-offs हो सकते हैं
डिफ़ॉल्ट WebView backend ऑपरेटिंग सिस्टम के webview का उपयोग कर छोटे binary पर ज़ोर देता है
- Deno की Node compatibility layer के ज़रिए npm ecosystem का उपयोग किया जा सकता है
- macOS·Windows·Linux पर एक जैसी rendering चाहिए तो bundled Chromium वाला CEF backend चुना जा सकता है
framework auto-detection मौजूदा web project को बिना code बदले desktop पर चलाने का तरीका है
- लक्ष्य Next.js, Astro, Fresh, Remix, Nuxt, SvelteKit, SolidStart, TanStack Start, Vite SSR आदि हैं
- release mode में production server चलाया जाता है
- --hmr में hot reload वाला development server चलाया जाता है

runtime communication, build, updates

backend और UI communication के लिए in-process channel का उपयोग होता है
- values call boundary पार करते समय encode की जाती हैं
- Deno code और webview के बीच cross-process round trip नहीं होता
एक ही मशीन से macOS, Windows, Linux के लिए cross compile किया जा सकता है
- backend को local में build नहीं किया जाता, ज़रूरत पड़ने पर download किया जाता है
automatic updates latest.json manifest और bsdiff patch का उपयोग करने वाले built-in binary diff update तरीके से होते हैं
- runtime polling, apply करना, और failed launch पर rollback संभालता है

सरल उदाहरण और documentation संरचना

एक single-file desktop app Deno.serve() से HTML response लौटाने वाला main.ts बनाकर और deno desktop main.ts चलाकर बनाया जा सकता है

Deno.serve(() =>
  new Response("Hello, desktop

", {
    headers: { "content-type": "text/html" },
  })
);

deno desktop main.ts

compiled binary एक window खोलता है जो Deno.serve() handler से bound local HTTP server की ओर इशारा करती है
- macOS/Linux पर इसे ./main से चलाया जाता है
- Windows पर .\\main.exe से चलाया जाता है
Deno.serve() अपने-आप उस address से bind हो जाता है जिस पर webview navigate करता है, इसलिए port या host name देने की ज़रूरत नहीं होती
संबंधित documentation को settings, backends, HTTP serving, frameworks, window management, bindings, menu, tray और dock, dialogs, notifications, HMR, DevTools, automatic updates, error reporting, deployment, comparison, और CLI reference में बाँटा गया है
- Deno.BrowserWindow window lifecycle, multiple windows, और events से संबंधित है
- Deno.autoUpdate() manifest, bsdiff, और rollback से संबंधित है
- bindings.() webview से Deno code को call करने की binding विधि है

1 टिप्पणियां

GN⁺ 5 시간 전

Hacker News की राय

लगता है Deno Desktop ने उस trade-off पर काफ़ी मज़बूत राय के साथ फैसला किया है: “default छोटा, Node compatibility पूरी”
मैंने लेख में दिए 5-लाइन वाले Hello World से deno desktop index.ts चलाकर देखा, और Windows 10 पर नतीजा 442MB था
मुझे लगा था यह Electron build से छोटा होगा, लेकिन यह उससे काफ़ी बड़ा निकला; libcef.dll 247MB था और Hello World वाला deno-test.dll 78MB था
सोच रहा हूँ कहीं मैंने कुछ ग़लत तो नहीं किया
- मुझे याद है Electron Hello World भी browser/Chromium runtime सहित लगभग 100~150MB का था
  इसलिए उम्मीद थी कि OS webview जैसी किसी चीज़ का reuse करके 20MB से कम का हल मिल सकेगा, लेकिन 400MB से ज़्यादा होना थोड़ा भ्रामक लगता है
  हो सकता है मैंने config ग़लत किया हो, इसलिए सोच रहा हूँ कि deno desktop test.ts के अलावा कुछ और करना चाहिए या नहीं
यह हिस्सा दिलचस्प लगा कि “हर app के साथ अलग-अलग CEF bundle करने के बजाय अगर shared CEF runtime मैनेज किया जाए, तो प्रति-app binary size कुछ MB तक घट सकती है, और यह roadmap में है”
मुझे CEF की ज़्यादा जानकारी नहीं है, इसलिए सोच रहा हूँ version management कैसे होगा
अगर हर app को अलग CEF version चाहिए, तो क्या आखिरकार यह Electron की तरह हर app अपना browser साथ लेकर चलने वाले मॉडल पर वापस चला जाएगा, या ऐसे मामलों में भी shared runtime का फ़ायदा बना रहेगा
https://docs.deno.com/runtime/desktop/comparison/
- CEF का मतलब Chromium Embedded Framework है
  https://github.com/chromiumembedded/cef
- जानकारी के लिए, CEF का इस्तेमाल Riot और League of Legends client में भी हुआ था
  नतीजा अच्छा नहीं था, लेकिन पता नहीं वह CEF तकनीक की अपनी समस्या थी या किसी दूसरे component या process की
  https://www.riotgames.com/en/news/architecture-league-client...
- मुझे शक है कि फ़ायदा कितना बड़ा होगा
  desktop पर Electron apps लगभग सभी अलग-अलग Chromium version इस्तेमाल करते हैं, और upgrade पर टूटने के जोखिम की वजह से कई बार पुराने version पर ही टिके रहते हैं
- web developers उस target environment के लगातार latest में update होते रहने के आदी हैं, इसलिए शायद “जो latest तुम्हारे पास है वही दे दो” जैसे मॉडल में शामिल होने या उससे बाहर रहने का विकल्प संभव हो सकता है
- embedded browser को ख़ुद download और manage करने के बजाय system webview इस्तेमाल करना बेहतर होगा
  Windows में यह WebView2 जैसी चीज़ होगी
Deno लगातार प्रभावशाली लग रहा है
काफ़ी समय हो गया है जब मैंने कोई नया project Deno के बिना शुरू किया हो, और अब मैं Node.js से ज़्यादा Deno ecosystem का पूरी तरह समर्थक बन चुका हूँ
पता नहीं मैं इस feature का कितना इस्तेमाल करूँगा, लेकिन एक और विकल्प मिलना सच में अच्छा है
यह काफ़ी प्रभावशाली काम है
vibe coding से desktop app बनाते समय यह काफ़ी दिलचस्प हो सकता है
Lovable, Bolt, v0 जैसे tools web apps बनाते समय default रूप से TypeScript इस्तेमाल करते हैं, इसलिए यह उनके साथ अच्छी तरह मेल खाता दिखता है
छोटे desktop apps के लिए Chromium और Node bundle करने के बजाय मैं Go/Wails इस्तेमाल करता रहा हूँ, और Electron ने अपना काम ठीक किया है, लेकिन उसका बड़ा bundle मुझे हमेशा साफ़ तौर पर खटकता रहा है
मैं सोच रहा था कि Deno की सबसे बड़ी खूबियों में से एक, यानी permission system, इसके साथ कैसे integrate होगा
ख़ासकर तब, जब agents को मेरी मशीन पर काफ़ी आज़ादी से चलने दिया जाए
CLI reference docs में लिखा है कि “compile करते समय दिए गए permissions compiled binary में bake हो जाते हैं”
अच्छा होगा अगर इसे इस तरह सामने लाया जाए कि user जान सके और तय कर सके कि कौन-कौन से permissions देने हैं
https://docs.deno.com/runtime/reference/cli/desktop/#runtime...
- यहाँ स्थिति यह है कि आप developer से मिली binary चला रहे हैं
  अगर वहाँ Deno permission prompt दिखाया जाए, तो मुझे लगता है कि वह उल्टा भ्रम पैदा कर सकता है, क्योंकि उन permissions की integrity guarantee नहीं होगी
- Deno Desktop में अभी जो चीज़ नहीं है, उनमें से एक है desktop apps के लिए runtime permissions
  यानी ऐसा तरीका जिसमें filesystem या network access पर permission prompt दिखे, और Deno permission system को desktop sandboxing पर लागू किया जाए
release करने के लिए यह समझदारी भरा feature है
किस platform का इस्तेमाल करना है यह तय करते समय यह गंभीरता से विचार करने लायक लगता है
- सहमत हूँ
  छोटा install size और cross-platform होने पर यह Electron या Tauri का अच्छा विकल्प लग सकता है
मुझे नहीं लगता कि “web technologies दुनिया का सबसे widely known UI toolkit हैं” वाला कथन खास उपयुक्त है
Electron apps की बहुत आलोचना होने की वजह यह है कि वे UI toolkit की अवधारणा के लगभग उलट हैं
कई बार वे host OS के UI patterns को ठीक से follow नहीं कर पाते
web technologies बस web technologies हैं; वे button render कर सकती हैं, लेकिन बिना style वाला button भी OS native जैसा दिखे, इसकी कोई गारंटी नहीं होती, और browser के हिसाब से भी फर्क पड़ता है
- लोग Electron इसी वजह से नहीं इस्तेमाल करते
  लक्ष्य कभी सिर्फ “UI toolkit” या “host OS के UI patterns को follow करना” नहीं रहा
  Chromium में बहुत बड़ी मात्रा में functionality शामिल है, और Electron उसी utility को ज्यों का त्यों ले आता है, जो इसकी ताकत है
  उदाहरण के लिए, अगर आपने video पर काम किया है, तो आप जानते होंगे कि desktop app के भीतर modern browser की पूरी क्षमता का इस्तेमाल करना game changer हो सकता है
  सिर्फ video playback ही नहीं, बल्कि modern web और WebCodecs के जरिए संभव transcoding को खुद implement करना बहुत बड़ा काम है, और अगर desktop app को Windows/macOS/Linux पर चलना हो तो यह और भी कठिन है
  मैंने Electron से ऐसा app बनाया है जो कुछ दर्जन घंटों में बन गया; किसी और तरीके से शायद उसमें कई दर्जन दिन लगते, और AI का इस्तेमाल करने पर भी, अगर आप video expert नहीं हैं, तो यह मुश्किल ही रहता
- मुझे समझ नहीं आता कि इस अभिव्यक्ति को खराब क्यों कहा जा रहा है
  किसी ने इसे “native” UI होने का दावा नहीं किया
  Linux का native UI मुझे हमेशा काफी बदसूरत लगा है, और मुझे अक्सर अच्छी तरह से तैयार किया हुआ HTML+CSS layout कहीं बेहतर लगता है
  मेरे अनुभव में Electron को मुख्य रूप से bloated और slow होने की वजह से कोसा जाता है; native न होना तो लोग बस ऊपर से जोड़ देते हैं
  मैं लंबे समय से ऐसा direct browser integration बनाना चाहता था जिसमें layout के लिए HTML+CSS हो, लेकिन JavaScript runtime की जरूरत न पड़े
  मुझे नहीं पता Servo कितना lightweight है, लेकिन अच्छा होगा अगर किसी दिन ऐसा विचार सच हो जाए
- Linux, macOS, Windows पर जब भी मैं Zed इस्तेमाल करता हूँ, GPUI framework कितना stable और fast है यह देखकर हैरान होता हूँ
  user के तौर पर मैं इससे बहुत संतुष्ट हूँ, और accessibility जैसी बुनियादी सुविधियाँ अभी कम हैं, लेकिन लगता है कि वे जल्द आ जाएँगी
  developer के नज़रिए से Rust के अलावा entry barrier क्या है, यह मुझे साफ नहीं है, और साथ ही Rust ही इसकी खास पहचान भी है
- UI native जैसा दिखता है या नहीं, यह बात counterargument के रूप में बहुत पहले अपनी ताकत खो चुकी है
  यह लगभग 25 साल पुरानी बहस है, और जब Microsoft ने भी इसकी परवाह करना बंद कर दिया, तब से लगभग किसी ने इसकी खास चिंता नहीं की
- ऐसा लगता है कि आप host OS के UI patterns को follow न करने को नुकसान मानते हैं, लेकिन मेरे लिए तो यही Electron के मुख्य फायदों में से एक है
  मैं नहीं चाहता कि मेरी app अलग-अलग OS पर अलग दिखे
  मेरे पास हर device पर test करने के resources नहीं हैं, और एक system पर test किया गया UI दूसरे systems पर भी बिल्कुल वैसा ही दिखे, यह बहुत बड़ा फायदा है
इस क्षेत्र में competition आना अच्छा लग रहा है
खासकर Deno की यह बात अच्छी है कि मौजूदा Node implementation की तरह सिर्फ types हटाने के बजाय यह असल TypeScript को सीधे चला सकता है
हालांकि, इससे लगता है कि यह Tauri के market का काफी हिस्सा ले जाएगा
अब फिर Tauri क्यों इस्तेमाल करें?
ज्यादातर internet connections पर bundle size में 150MB की बढ़ोतरी का मतलब सिर्फ 1~10 सेकंड अतिरिक्त download time होता है, और बदले में आपको एक भरोसेमंद rendering engine मिलता है
- Deno भी TypeScript code चलाते समय default रूप से सिर्फ type annotations हटाता है
  type checking करनी हो तो deno run --check चलाना पड़ता है या अलग deno check subcommand इस्तेमाल करनी होती है
  development के दौरान आम तौर पर IDE type checking और linting अपने-आप कर देता है, इसलिए यह कोई बड़ी समस्या नहीं है
- Tauri आपको किसी खास JavaScript ecosystem में बंद नहीं करता
  सच तो यह है कि JavaScript इस्तेमाल करना भी जरूरी नहीं है
  और हमने Astro, Nuxt, UV, Bun, Vite जैसे developer framework startups को कई बार acquire होते देखा है
  जिस software को कई सालों तक maintain और support किया जाना है, उसके लिए ऐसा रुझान बहुत भरोसा नहीं देता
- जब “backend” JavaScript नहीं होता, तब मैं Tauri इस्तेमाल करता हूँ
- “भरोसेमंद rendering engine” मिलने वाली बात मुझे ठीक से समझ नहीं आई
  क्या Deno Desktop और Tauri दोनों system webview का ही इस्तेमाल नहीं करते?
- उस तर्क से तो फिर Electron इस्तेमाल करने की बात भी निकलती है
  फिर यह क्यों इस्तेमाल करें और Electron क्यों नहीं?
Deno की जारी की गई सामग्री में comparison section मुझे सबसे अच्छा लगा
आखिरी पंक्ति में iOS/Android support के लिए Electron को “no” और Deno को “not yet” कहा गया है; अगर वे सच में यह कर लेते हैं, तो चीज़ बहुत बड़ी हो जाएगी
web game को Steam app या online purchase app के रूप में distribute करने के लिए यह वाकई बहुत अच्छा लग रहा है
मैं इसे एक बार ज़रूर आज़माऊँगा

Deno Desktop: Deno प्रोजेक्ट को डेस्कटॉप ऐप के रूप में पैकेज करना

deno desktop की भूमिका और मौजूदा स्थिति

backend चयन और web project चलाना

runtime communication, build, updates

सरल उदाहरण और documentation संरचना

संबंधित पढ़ाई

1 टिप्पणियां

Hacker News की राय

`deno desktop` की भूमिका और मौजूदा स्थिति