Deno Desktop

मूल लेख ↗ Hacker News चर्चा ↗

Deno ने “Deno Desktop” पेश किया है, जो TypeScript में web technologies का उपयोग करके cross‑platform desktop apps बनाने का तरीका है, और Electron, Tauri तथा इसी तरह के frameworks के विकल्प के रूप में स्थित है। टिप्पणियाँ Chromium को CEF के माध्यम से bundle करने बनाम system WebViews पर निर्भर रहने के trade‑offs पर केंद्रित हैं, जिनमें app size, performance, security, और पुराने या buggy platform web engines से निपटने की परेशानी शामिल है। यह launch web‑based बनाम native UI toolkits पर व्यापक बहस को भी फिर से जीवित करता है: बहुत से लोग web tech को “write once, run anywhere” का एकमात्र व्यावहारिक रास्ता मानते हैं, जबकि अन्य bloat, खराब accessibility, और OS‑स्तरीय UI consistency के क्षरण पर अफसोस जताते हैं.

Deno Desktop का अवलोकन

  • Deno का उपयोग करके web technologies (HTML/CSS/JS/TS) के साथ desktop apps बनाने का एक तरीका प्रदान करता है।
  • कई backends को सपोर्ट करता है: system WebView (डिज़ाइन में डिफ़ॉल्ट), CEF के माध्यम से bundled Chromium, और custom rendering (जैसे WebGPU) के लिए लक्षित एक low-level “raw” backend।
  • Deno की मौजूदा विशेषताओं के साथ एकीकृत होता है: single binaries में compilation, cross-compilation, Node compatibility, auto-updates, और npm ecosystem।

Electron, Tauri, और अन्य के साथ तुलना

  • “Tauri जैसा, लेकिन Electron जैसा भी हो सकता है” के रूप में स्थित:
    • OS engine का उपयोग करके छोटे binaries के लिए WebView backend।
    • प्लेटफ़ॉर्म्स के बीच सुसंगत, आधुनिक rendering के लिए वैकल्पिक CEF backend।
  • Electron से तुलना में: आसान setup, संभावित रूप से छोटे bundles, TS-first, Node के बजाय Deno API, और built-in tooling।
  • Tauri से तुलना में: Tauri Rust-based backend और केवल system WebView का उपयोग करता है (CEF आने वाला है), जबकि Deno Desktop JS/TS-based है और पहले से ही CEF ship करता है।
  • उल्लेखित अन्य विकल्प: Wails (Go), Dioxus/Blitz (Rust, custom engine), Sciter, Java/Qt/GTK, WASM-based approaches (Jumpjet)।

Binary Size, Performance, और WebViews बनाम CEF

  • कुछ उपयोगकर्ताओं के अनुसार Windows पर CEF के कारण लगभग 440 MB का “hello world” build मिलता है; sub-20 MB apps की अपेक्षा के हिसाब से यह निराशाजनक है।
  • Maintainers का कहना है कि WebView + compression लगभग 15 MB तक पहुँच सकता है, लेकिन वर्तमान में default/backend व्यवहार भ्रमित करने वाला है और docs को सुधारने की आवश्यकता है।
  • System WebViews:
    • फायदे: छोटे binaries, मौजूदा browser engine का पुनः उपयोग।
    • नुकसान: platform-specific bugs और पुरानापन (विशेषकर Linux पर WebKitGTK, पुराने macOS Safari/WebView)।
  • CEF:
    • फायदे: OSes के बीच predictable, evergreen rendering और APIs।
    • नुकसान: बड़े binaries; shared runtime/versioning को लेकर सवाल और क्या यह वास्तव में “Electron-per-app browser” duplication से बचाता है।

Native बनाम Web UI और UX Consistency

  • लंबे, गरमागरम बहस कि क्या “web UI slop” native toolkits की तुलना में स्वीकार्य है।
  • Web UIs के पक्ष में तर्क:
    • OSes के बीच cross-platform consistency।
    • HTML/CSS/JS से डेवलपर्स की भारी परिचितता।
    • Native toolkits fragmented, inconsistent, या painful हैं (Win toolkits churn, GTK बनाम Qt, SwiftUI issues, Linux diversity)।
  • Native UIs के पक्ष में तर्क:
    • OS-level consistency और patterns usability, discoverability, और accessibility में मदद करते हैं।
    • कई web/electron apps platform conventions की अनदेखी करते हैं, “pixel soup” बनाते हैं, और कमजोर a11y रखते हैं।
    • कुछ का कहना है कि users वास्तव में inconsistent behavior की शिकायत करते हैं, भले ही वे “native UI” शब्द का उपयोग न करें।
  • सामान्य धारणा कि स्वयं OSs कम consistent हो गए हैं, जिससे कई developers के लिए “ज़रूर native जैसा दिखना चाहिए” वाला तर्क कमजोर पड़ता है।

Security, Permissions, और IPC Model

  • सवाल कि compiled desktop binaries पर Deno का permission system कैसे लागू होता है।
    • वर्तमान docs: desktop apps अभी runtime permission prompts नहीं देतीं; permissions compile time पर baked in होती हैं।
    • कुछ लोगों को चिंता है कि permission prompts misleading होंगी अगर bundled runtime पर आपका नियंत्रण नहीं है।
  • सुझाव: डाउनलोड की गई apps को trusted local Deno (deno run) के माध्यम से चलाएँ या permissions लागू करने की चिंता हो तो containers/VMs का उपयोग करें।
  • IPC/architecture:
    • Backend और UI एक ही process (CEF) में या tightly coordinated process group (WebView) में चलते हैं, socket-based IPC के बजाय in-process C ABI bindings का उपयोग करते हुए।
    • इसे पारंपरिक Electron-style IPC की तुलना में कम overhead वाला माना जाता है; security implications पर बहस है, लेकिन thread में उनका समाधान नहीं हुआ।

Platform Support, Tooling, और Use Cases

  • वर्तमान में canary-only (Deno v2.9); कुछ उपयोगकर्ताओं को शुरुआती bugs (blank windows) मिले और उनसे issues file करने को कहा गया।
  • Mobile (iOS/Android) support “planned/being investigated” है, लेकिन उपलब्ध नहीं है; docs भविष्य के समर्थन का संकेत देती हैं।
  • चर्चा किए गए use cases: internal tools, kiosk apps, Steam/desktop के लिए web games पैकेज करना, optional GUIs के साथ Deno-based CLIs ship करना।
  • कुछ लोग Deno overall को लेकर उत्साहित हैं (TS-first, integrated tooling, compilation, Node compat); अन्य “भारी JavaScript desktop apps ship करने का एक और तरीका” से थक चुके हैं।