9 ms·

Deno Desktop

1122 points by GeneralMaximus 3mo ago

paulbjensen 3mo ago
Actually, this would be amazing for distributing web games as apps for Steam or online purchase. I am going to give it a try.
solarkraft 3mo ago
This is a smart thing to ship. For me it would totally be a consideration when deciding on a platform to use.
- sjeno 3mo ago
  agree, small footprint & cross-platform looks like a nice alternative to electron or tauri..
  - franz899 3mo ago
    Their comparison page shows some savings, but not in every case (~40 MB / ~150 MB) https://docs.deno.com/runtime/desktop/comparison/ https://docs.deno.com/runtime/desktop/comparison/
    - merelysounds 3mo ago
      To be fair the ~150MB is for the CEF scenario (when chromium gets bundled); and eventually they want to introduce a shared CEF runtime across apps.
bossyTeacher 3mo ago
How is this better than Electron?
- IshKebab 3mo ago
  Vastly easier to set up, optionally lets you use platform web renderers, Typescript by default, you can use the Deno API instead of Node (compatible with less code but much better designed), built-in auto update, you can use Fresh which IMO is the best web framework.
- zamadatix 3mo ago
  These from the comparison table stick out to me: - Can use "raw, system WebView, or bundled CEF" vs "bundled Chromium" - The size can be smaller in the Raw/WebView cases. - Built-in automatic differential updates - Built-in cross-compilation (+the compilations just come built into Deno itself rather than as a 3rd party package). And, of course, the same lists as one would generate when comparing the base Deno vs Node themselves.
jorisw 3mo ago
> Web technology is the most widely-known UI toolkit in the world. Poor choice of words there IMHO. The reason Electron apps get a lot of flak is because they are everything _but_ a UI toolkit. They consistently miss the mark in adopting UI patterns from their host OS. Web tech is just web tech. Yes it will allow you to render a button, but even unstyled, the button won't necessarily look native to the OS, and will vary between browsers.
- divan 3mo ago
  This. It's nuts how the whole industry accepts that typesetting engine from 80s with bunch of hacks on top is currently dominating cross-platform UI development.
- utopiah 3mo ago
  > look native to the OS Is that a problem? A button with a legible label is a button. The host OS doesn't have to look exactly like the applications it runs.
  - jorisw 3mo ago
    Consistency is a large factor in any good design, UI design more so.
    - Gigachad 3mo ago
      They have internal consistency. The iOS version looks like the macos version which looks like the web version, etc. This upsets HN users but the rest of the world decided that apps looking like windows built ins doesn't matter.
      - ahartmetz 3mo ago
        It's more like developers decided - nobody asked the users.
        3mo ago
sheept 3mo ago
I was wondering how this integrates with Deno's permission system, which is one of its biggest strengths especially for letting agents run amok on your device. The CLI reference page[0] notes, > The permissions you grant at compile time are baked into the compiled binary: I think it would be nice if this could be surfaced to the user somehow, like letting the user know and decide which permissions they want to give access to. [0]: https://docs.deno.com/runtime/reference/cli/desktop/#runtime-flags https://docs.deno.com/runtime/reference/cli/desktop/#runtime...
- porridgeraisin 3mo ago
  > What deno desktop doesn't have yet > Runtime permissions for desktop apps (a permission prompt on every filesystem / network access, i.e. Deno's permission system applied to desktop sandboxing).
- tomComb 3mo ago
  You are running a binary that you got from the developer. If it presented you with Deno permissions, I think that would be misleading because there’s no guarantee of their integrity.
  - sheept 3mo ago
    That is true. I wonder if it could be possible to let the user supply and wrap the app around their own, trusted installation of Deno (rather than the one bundled in the app) to specify permissions.
    - minraws 3mo ago
      Why not run it in a vm or container instead then, it seems a bit much imho.
  - hdjrudni 3mo ago
    Then do `deno ./my_downloaded_deno_gui` instead. If you trust the copy of deno you downloaded, then hopefully it can be trusted to verify the permissions of random downloaded deno-apps. Yes, it kind of defeats the standalone binary aspect but if you're really concerned about security, maybe it's a happy medium.
lillesvin 3mo ago
As much as I like cross-platform stuff, I also really like native UIs that follow native UX patterns, etc.
- deely3 3mo ago
  We spend a lot of time using different browsers. As far as I know there no web engine that use native OS UI for rendering.
  - kuekacang 3mo ago
    Isn't all uses native OS UI widget? But since the brand need to be experienced the same across platform, it overrides the native rendering and use custom styles instead.
  - nicce 3mo ago
    > As far as I know there no web engine that use native OS UI for rendering. That sounds like a monster I would be afraid to touch.
- mohsen1 3mo ago
  In practice it's much harder to maintain a native app. I am noticing this with ChatGPT Mac app vs. Codex Mac app. ChatGPT on Mac is constantly behind compared the web ChatGPT while Codex is shipping features at a much higher velocity. Also ChatGPT hangs and has more weird bugs compared to Codex.
  - LtWorf 3mo ago
    Did they run out of tokens? Why don't they ask their agent to update the mac version?
  - hbn 3mo ago
    The issues with the ChatGPT Mac app could also be reflective of the state of Swift UI considering not even Apple themselves can ship Swift UI apps that aren't janky. https://daringfireball.net/2026/06/swiftui_only_makes_it_easy_to_develop_bad_apps https://daringfireball.net/2026/06/swiftui_only_makes_it_eas...
nimchimpsky 3mo ago
[dead]
utopiah 3mo ago
Interesting but IMHO as we see on mobile providing WebViews work. Maybe instead of having Electron, Tauri, Electrobun, now Deno desktop but also plenty of alternatives then desktop browsers should provide WebViews on desktop with sandbox and permissions that make those applications usable. The alternatives listed here would just be fallback for a transition period until the WebViews are "good enough".
- andyferris 3mo ago
  Is it not a web view? With nodejs capabilities from the “backend” half of the app for normal desktop app filesystem access etc?
  - utopiah 3mo ago
    If a Web View is not provided by a browser then it's an already installed browser then it's as they say "web rendering engine" that they ship along. I'm trying to argue that it should already be available via Firefox, Chromium, etc on desktop.
    - koolala 3mo ago
      Firefox doesn't release a webview engine but if they did I wonder if Linux distros would use it.
- pjmlp 3mo ago
  Webviews have always worked since MSHTML, the issue is being comfy helping Google's market share instead of writing portable Web code.
  - utopiah 3mo ago
    That's a whole can of worms, Micro$lop entangling its own browser with its OS, getting a (gentle) slap on the hand for its abuse of monopoly position for it, having to remove it claiming it's "impossible", etc.
jaimehrubiks 3mo ago
This web page stole my scroll liberty
droidjj 3mo ago
> The default WebView backend uses the operating system's own webview for small binaries, and you still have the entire npm ecosystem available through Deno's Node compat layer. Sounds like a similar architecture to Tauri, but your business logic is in typescript instead of rust.
- progx 3mo ago
  > Opt into the bundled Chromium (CEF) backend when you need identical rendering across macOS, Windows, and Linux. Sound more like Electrobun
deleted 3mo ago
[deleted]
sureglymop 3mo ago
Looks actually good! I wonder if it supports opening invisible browser windows and doing things like intercepting cookies. In my desktop application I leverage a hidden browser window to manage auth state and use it like a proxy for the rest of the application. Might try to port it to deno desktop.
m00dy 3mo ago
would be cool to have a comparison with tauri.
- tarcon 3mo ago
  They really did their best comparing it with other tools here https://docs.deno.com/runtime/desktop/comparison/ https://docs.deno.com/runtime/desktop/comparison/
  - prohobo 3mo ago
    RE: Tauri not having cross-compile... There's a GitHub action that compiles for Linux, Windows, and Mac. So practically it does have it, just not out of the box.
    - zamadatix 3mo ago
      Practically that's just the ability to generate binaries for more than one target. "Cross compiling" is specifically that ability without having to invoke a separate external environment to get the additional targets. If cross compiling were really just about the result rather than the means, what would the difference be between that and normal support for multiple targets?
porridgeraisin 3mo ago
While I've never liked to use deno compared to node and bun, this looks particularly good. The zero config options are nice, all the features seem to be in the place I like, and I'm happy they're not dogmatic about using the system webview and let you ship your own CEF. The state of system webviews on non-windows platforms is horrendous.
bel8 3mo ago
I'm happy for competition in this space, specially because Deno can run true TypeScript directly and not just strip types like the current Node implementation. With that said, this is going to eat a lot of Tauri market. Why would I use Tauri now? The 150mb of additional bundle size is just an extra 1 to 10 seconds of download time in most internet connections and you get a reliable rendering engine.
- swiftcoder 3mo ago
  > and you get a reliable rendering engine How is it more reliable than Tauri - aren't they both using the system webview?
  - bel8 3mo ago
    Deno Desktop can bundle CEF (Chromium Embedded Framework) according to https://docs.deno.com/runtime/desktop/comparison https://docs.deno.com/runtime/desktop/comparison
  - fiatpandas 3mo ago
    Deno desktop can use system web view OR embed CEF. Tauri is just system web view.
    - aabhay 3mo ago
      The benefit of Deno Desktop is it's like Tauri except for when you want it to be Electron???
      - GeneralMaximus 3mo ago
        This is a feature many apps actually need. E.g. Tauri uses WebKitGTK on Linux, which has historically been slow, unstable, and frequently lagging behind the main WebKit project. This is enough of an issue that even Tauri is working on the ability to use CEF instead of the system web view in Tauri apps. Things are generally fine on recent versions of Windows and macOS. The system web views on these platforms will be evergreen versions of WebKit or Blink. But if you want to support very old versions of Windows or macOS, you might choose to use CEF instead of wrestling with Safari-from-five-years-ago.
SudoSlayer90 3mo ago
[dead]
huflungdung 3mo ago
[dead]
DiabloD3 3mo ago
I don't get the point of this. The world is trying to make computers faster and more accessible, more web UI slop isn't going to help that. Dumping Javascript entirely is the first step on that road.
- vinkelhake 3mo ago
  I've seen variants of this comment for many years. The alternative to "web UI slop" would presumably be one of the many native toolkits. I see it in a different way. The fact that "web UI slop" has managed to make great inroads on the desktop is an indictment of the state of native toolkits. If you think it's a problem that desktop apps are being written with web toolkits, the solution for that isn't to shame (as the term "web UI slop" clearly tries to do), but rather to figure out how to improve the native toolkits. The opportunity to improve those toolkits was always there, and the ball was dropped.
  - DiabloD3 3mo ago
    It hasn't made any inroads on the desktop though... all anyone did was just package their own SWA into a self-contained browser that serves its own content. They continue to be websites, with all the pitfalls of them. I don't need to spend 2GB-4GB of RAM just to have a over-glorified IRC clone! Also, the native toolkits are fine. Windows has two toolkits, the ShellUI/MFC family (which does everything required, although it doesn't always get hidpi on legacy apps correct; it gets integration for blind people and also unicode/multilingual correct, and also works with touch interfaces), and WinUI does it more modernly (and ticks all the boxes). OSX has its toolkit, seems to nail everything correctly. Linux has Qt (lets ignore GTK for now, only reason you use GTK is if you want to appear Gnome-native), and Qt also does native++ uplifting on other toolkits (ie, native widget + additional feature expansion, plus perfect mimicry of native look for entirely new widgets), plus Qt does everything you need to do correctly and easily. There are also new UI toolkits coming up through the ranks that are trying to knock Qt off that #1 position. None of the WebUIs would even place in this race. Web UI toolkits always look non-native, are hard to interpret, often use low contrast (and frankly ugly) colorschemes, are easy to use in ways that do not comply with usability standards across OSes, and usually do nothing for A11Y. The opportunity to improve those toolkits was always there, and the ball was dropped.
arikrahman 3mo ago
I've decided on using a Clojure/Flutter hybrid that gets the best of all worlds. May integrate move from Bun to using Deno here https://codeberg.org/arik/clutter https://codeberg.org/arik/clutter
- chem83 3mo ago
  Care to expand on what this solution is? What is Clojure bringing to Flutter in this case? Ty.
  - arikrahman 3mo ago
    Howdy, the Clojure dialects such as ClojureDart as well as Jank interop with the Flutter to provide a better development experience as well as more capable engine. This is inspired by Toyota's Fluorite implementation within flutter, which may be integrated into Clutter on its release.
wg0 3mo ago
I hope bun desktop is coming soon?
- tonyedgecombe 3mo ago
  I expect a poorly conceived and buggy vibe coded version will be available this afternoon.
DaanDL 3mo ago
I swear we're just going to end up with Java again.
- mfru 3mo ago
  At this point I think that would be a more sane outcome than whatever it is we have right now.
  - tonyedgecombe 3mo ago
    We were writing and shipping desktop applications with it back in the nineties. Although many of the arguments against it were similar to the arguments against Electron today.
    - ivell 3mo ago
      I think the UI look and feel was very ugly for many users and that caused its demise. The cross platform skin was ugly. The native skins were in the uncanny valley. The framework was reasonably good for its time. By the time good looking UI frameworks came, the bad reputation was already set.
      - frou_dh 3mo ago
        Even the later JavaFX was a tasteless exercise. I opened some apps and you could tell within 1 second that something was wrong because all the text was using fugly non-platform-native (or somehow screwed up) text rendering.
      - tonyedgecombe 3mo ago
        I think SWT was the best option if you wanted native controls.
    - LtWorf 3mo ago
      Yeah back then a java application could take several minutes to open.
- 3mo ago
daft_pink 3mo ago
Is it going to support iOS/Android?
- koolala 3mo ago
  No customizable programmable browser runtimes exist for those.
  - rbits 3mo ago
    What do you mean by that? Does this[1] not count? [1] https://capacitorjs.com/ https://capacitorjs.com/
    - koolala 3mo ago
      Correct, that isn't a browser it uses a webview. The limited webview version of Deno Desktop could work like that on phones.
- bartlomieju 3mo ago
  Bartek from the Deno team here. No promises yet, but we're looking into feasibility of it.
- robtro 3mo ago
  The docs say it's planned but no proper roadmap for it yet.
krawcu 3mo ago
Why did they describe electrobun as macOS only? I checked their docs and it has support for Windows, macOS and Linux https://docs.deno.com/runtime/desktop/comparison/ https://docs.deno.com/runtime/desktop/comparison/ https://github.com/blackboardsh/electrobun#platform-support https://github.com/blackboardsh/electrobun#platform-support
- bartlomieju 3mo ago
  Thanks, I'll update the docs. When we wrote them a couple weeks back, Electrobun was announcing Linux only support.
numlock86 3mo ago
How does this differ from electrobun, which they explicitly mention, but make no point about? I had a quick drive with deno desktop and don't see how it's better. If anything it's lacking in comparison in my opinion. But hey, we can build desktop apps with deno now, too. So they got that going I guess ...
- actionfromafar 3mo ago
  I think for a little while longer, you can catch bun anything, electro or not, refugeess just by not being bun.
- bartlomieju 3mo ago
  Bartek from Deno team hear. I'll love to hear what you feel is missing so we could improve `deno desktop` for more users.
leleat 3mo ago
> Shared CEF runtime across apps. Every app currently bundles its own CEF copy. A managed shared runtime would drop binary sizes to a few MB per app. On the roadmap. This[0] sounds interesting. I am not familiar with CEF, so I wonder how the versioning works. When different apps require different versions of CEF, do we just essentially end up with the electron model where every app bundles their own browser (just slightly less bad). Or is there still an advantage to a "shared runtime" in that case? [0]: https://docs.deno.com/runtime/desktop/comparison/ https://docs.deno.com/runtime/desktop/comparison/
- tonyedgecombe 3mo ago
  In case anybody else wondered CEF is the Chromium embedded framework. https://github.com/chromiumembedded/cef https://github.com/chromiumembedded/cef
  - echelon 3mo ago
    The biggest weakness of a framework like Tauri is the choice to target system webviews instead of bundling a browser runtime. It seems great to be able to cut hundreds of megabytes out of your app installer, but the platform differences wind up being a complete and ongoing pain in the ass. Tauri support on Windows is phenomenal. Tauri on Mac runs into lots of WebKit/Safari issues, especially on older Mac machines that have an older engine that doesn't support modern web APIs. Your app can crash or be left non-functional. You'll find out about these runtime bugs in the wild randomly, and patching for some customers can take days, if not weeks. Linux support is hellish, and it's best to not even try targeting Linux with Tauri. Tauri is in the process of adding CEF support. It should probably become the default build target for all platforms.
    - oooyay 3mo ago
      I use Wails which is Tauri but for Go and I don't have the kind of issues you're mentioning. Maybe that is a difference between Wails and Tauri but I don't think the system WebView is a significant factor.
lwansbrough 3mo ago
Similar to something I'm working on for games: https://jumpjet.dev https://jumpjet.dev WASM you can bundle for Windows, macOS, Linux, Android, iOS and web. Unlike Deno Desktop, it doesn't rely on a browser engine.
- ai_fry_ur_brain 3mo ago
  Do you reccomend and resources for building w/ & learning about wasm?
  - lwansbrough 3mo ago
    It's all so bleeding edge right now. It also depends how deep you want to go. An increasing number of languages support wasm as a compile target, which is helpful. Bytecode Alliance do semi-regular streams on Youtube. I think reading (recent) material on WASI (0.3) and the Component Model would be a good start. Understanding the relationship between a host and a guest is valuable. Learning what wasmtime is and how it works is also illuminating: https://docs.wasmtime.dev https://docs.wasmtime.dev
    - ai_fry_ur_brain 3mo ago
      Tyty
- matharmin 3mo ago
  Do you mean "Unlike Deno Desktop"? Deno Desktop definitely relies on a browser engine.
  - lwansbrough 3mo ago
    Yes, thanks.
- catears 3mo ago
  Just FYI, when checking out jumpjets homepage, the white-dot airship in the background made the white text in the hero banner hard to read. Cool project!
unliftedq 3mo ago
[flagged]
LauraMedia 3mo ago
Maybe it is because it is still in development, but building and running the Hello World example just gives me a blank terminal and a white window that is not responding.
- bartlomieju 3mo ago
  Sorry to hear that, could I ask you to file an issue in our bug tracker?
pippoit 3mo ago
can i open a socket with these tools ? can i open an odbc connection for example ? Or have i need to have a backend ? On desktop usually you can do much more than in the sandbox of a browser . I ask because i don't know these technologies. On windows, even if i don't like it, if the interface and the logic are not too complex, powershell with winform make you create things without "anything" installed and you can easily interact with other windows programs ( office 365 suite, autocad and so on ) so for doing "fast things" in my opinion is a very strong alternative .
- bartlomieju 3mo ago
  Yes, you can do all that. You get a fully-fledged Deno program that can do all of this, _plus_ you get a frontend GUI app.
deleted 3mo ago
[deleted]
asim 3mo ago
Curious to know who is using Deno in anger most days and in production full time? It seems like the choice of JS runtimes exploded over the past few years with that, Bun, etc.
- flexagoon 3mo ago
  Why "etc."? Isn't it just node, bun and deno? Genuine question
  - asim 3mo ago
    In case someone is using something we haven't heard of e.g some are running using cloudflare workers which also has some unique runtime properties. AWS has something called LLRT. https://github.com/awslabs/llrt https://github.com/awslabs/llrt https://developers.cloudflare.com/workers/runtime-apis/ https://developers.cloudflare.com/workers/runtime-apis/
    - syrusakbary 3mo ago
      We have created Edge.js that can run Node.js apps fully using your preferred JS runtime: V8 or QuickJS. https://edgejs.org/ https://edgejs.org/
  - gr4vityWall 3mo ago
    There's QuickJS, LLRT, Rhino, and GameMaker is about to get TS/JS support.
- steve_adams_86 3mo ago
  I use it for several applications (frontend, backend, CLIs) in production settings, and it has been excellent. Caveat: I serve small internal teams mostly, some projects only serve < dozen users. One is around 500/day. No issues at all. I’ll definitely use Deno desktop for these internal tools. Their binary compilation (especially now that it can include other binaries) has been totally sound and I expect this to work well too. Worth noting is that the team has improved compilation features steadily. Every issue I watched last year has been completed and I’m not encountering blockers anymore.
liampulles 3mo ago
Having deno desktop do the framework handling for a bunch of popular options is an interesting choice. It seems deno is trying less to be an agnostic JS runtime, and more an "integrate everything toolkit" (not unlike Spring in the Java space).
taosu_la 3mo ago
Is this a new trend? Why are everyone starting to do desktop runtime? For example, I recently saw Bun Electron, and then I saw this project.
- iagooar 3mo ago
  I guess people are tired of each instance of an Electron-based app using 1GB+ of RAM.
  - josephernest 3mo ago
    I just tried `deno desktop helloworld.ts` and the result is 442 MB. So it's not any lighter than Electron (see my toplevel comment)
    - iagooar 3mo ago
      Then it probably was wishful thinking on my side...
  - yboris 3mo ago
    Why are people parroting this meme? For 8 years now, constantly updating to newest Electron, my Electron app has been using only about 150mb of RAM - (see Video Hub App)
HackerThemAll 3mo ago
https://docs.deno.com/runtime/desktop/#hello%2C-desktop https://docs.deno.com/runtime/desktop/#hello%2C-desktop Yeah, hello desktop. D:\source\DenoTest>deno desktop main.ts error: Module not found "file:///D:/source/DenoTest/desktop".
- sippeangelo 3mo ago
  deno desktop ships in Deno v2.9.0 and is not in a stable release yet. To try it now, run deno upgrade canary to install the canary build. The command, configuration keys, and TypeScript APIs may still change before the feature is stable.
mb2100 3mo ago
> Backend and UI communication goes through in-process channels, not socket-based IPC Are they running the frontend and backend in the same process? Sounds a bit dangerous security-wise?
- whilenot-dev 3mo ago
  How can in-process channels be more dangerous than a socket-based IPC? The frontend still goes through the "secure" JavaScript engine AFAICS.
shevy-java 3mo ago
I watched traditional GUIs for a while and used many of them, mostly via ruby as wrapper, sometimes also via java. I finally reached the conclusion not too long ago, that web-apps are the only real alternatives now. Too many things do not work when it comes to traditional desktop applications. There are even regressions, e. g. ruby-gtk4 barely works for me. And there is no real support for any problems really. People make fun of e. g. electron "soooo big so bloated", and WebAssembly is still not really in any breakthrough after almost 20 years. But traditional desktop apps are also even more dead. So I'll have to add JavaScript/TypeScript/Node now simply because there are no real alternatives to this anymore. I'd wish we would have a real "write once, run everywhere"...
- calvinmorrison 3mo ago
  Odd because I'm wrapping up an app that uses Xaw. It should run on the billion or so machines that support X11
- zero-st4rs 3mo ago
  > I'd wish we would have a real "write once, run everywhere"... Hi! I'm trying my best okay? Hokusai Pocket might currently be composed of wood and string, but one day he will be a real boy!
nottorp 3mo ago
Hmm suppose you have a node GUI-less application. What would you pack it in to have something reasonably self contained to deploy?
- tones411 3mo ago
  Look into Single Executable Applications https://nodejs.org/api/single-executable-applications.html https://nodejs.org/api/single-executable-applications.html
  - nottorp 3mo ago
    Thanks!
- bobajeff 3mo ago
  Deno actually has had a built in compile to binary feature * I've used it before a few times. * https://docs.deno.com/runtime/reference/cli/compile/ https://docs.deno.com/runtime/reference/cli/compile/
jessinra98 3mo ago
what happens when two apps need different cef versions? doesn't that just mean you're back to bundling your own browser anyway. does the shared runtime actually save memory when the underlying chrome versions diverge?
catapart 3mo ago
Awesome! Looking forward to trying this out.
scirob 3mo ago
They had this before I used it to ship some stuff but binaries were big . How small did they get it with this update
G_o_D 3mo ago
I was just today morning thinking about some such idea, for mhtml to be embedded with light weight renderer so it does'nt have to rely on other browser
- c-smile 3mo ago
  > for mhtml to be embedded with light weight renderer so it does'nt have to rely on other browser That's Sciter (https://sciter.com https://sciter.com) and Sciter.Quark (https://quark.sciter.com https://quark.sciter.com) in particular, no?
T3RMINATED 3mo ago
[dead]
karol 3mo ago
Of all the content they put out I liked the comparison section the most. The last row says iOS/Android - Electron: no, deno: not yet. If they deliver on this it will get much bigger.
josephernest 3mo ago
> deno desktop is opinionated about those tradeoffs: > Small by default, full Node compatibility I tried `deno desktop index.ts` with the 5-line Hello world in the article. Result (Windows 10): 442 MB. Ouch. I thought it would be smaller than an Electron build, but it's far worse. Did I do something wrong? (libcef.dll: 247 MB) (deno-test.dll: 78 MB <- contains the hello world)
- josephernest 3mo ago
  IIRC Electron hello world is ~ 100-150 MB because it bundles a browser/Chromium runtime. So I hoped we could have a <= 20 MB solution by reusing the OS webview or similar. Having more than 400 MB is a bit deceptive for me. (Again: maybe I just did something wrong in the config: should I do something else than `deno desktop test.ts`?)
- fny 3mo ago
  libcef is the Chromium embedded framework[0], so your build isn't using a webview or maybe its using both. I just tried it on my mac, and I can't keep libcef out even with `--backend webview`. https://github.com/chromiumembedded/cef https://github.com/chromiumembedded/cef
- undefined_void 3mo ago
  Try the webview backend: `deno desktop --backend webview`
  - IdiotSavage 3mo ago
    The docs say that's the default: https://docs.deno.com/runtime/desktop/backends/#webview-(default) https://docs.deno.com/runtime/desktop/backends/#webview-(def...
    - crowlKats 3mo ago
      apologies, this is inaccurate currently, will get things updated
  - 3mo ago
omojo 3mo ago
Impressive work. This is going to be really interesting for vibe coding Desktop apps. I imagine this on Lovable, Bolt or v0 since they basically default to using Typescript for building web apps. I've been using Go/Wails for desktop projects rather than a bundled Chromium and Node in a small desktop app, Electron did a good job but that was a big No for me.
40four 3mo ago
Deno continues to impress me. It’s honestly been quite a while since I started a new project without it. It has fully won my support over Node.js, the ecosystem has really matured nicely. I don’t know how often I’ll use this feature, but it’s really nice to have the option!
- liamgm 3mo ago
  yes the big win from this is the Node API / NAPI support , if you write node_modules in nodejs , electron , raycast , edgejs you can reuse it . https://wasmer.io/posts/edgejs-safe-nodejs-using-wasm-sandbox https://wasmer.io/posts/edgejs-safe-nodejs-using-wasm-sandbo... "NAPI allows native Node dependencies to target Node without actually depending on a specific version of Node or V8. NAPI abstracted the V8 JS engine away, by providing JS-like APIs for: creating an object, declaring a property, etc. NAPI is the contract that all modern native Node modules use to interact with Javascript." [1] 1: https://wasmer.io/posts/edgejs-safe-nodejs-using-wasm-sandbox https://wasmer.io/posts/edgejs-safe-nodejs-using-wasm-sandbo...
- esperent 3mo ago
  I'm still using node/npm and it's... fine. Every so often I read these posts and think I should change but node/npm is already a low friction part of my workflow. However, what I have seen is that a lot of other libraries I use have switched to Bun. I haven't seen any that switched to Deno, and so I've been under the impression that Bun is becoming a strong node replacement candidate while Deno is not, or at least that the community is making a strong preference for Bun. Anyone have more insight into this?
undefined_void 3mo ago
Deno Desktop supports two backends as of now: CEF (Chromium) and Webview You can get your app sizes as low as 15mb with `deno desktop --compress` (in canary) A tiny "raw" windowing backend exists for WebGPU rendering as well
SpaceL10n 3mo ago
I think the last time I tried Deno for desktop it didn't allow for fullscreen webview apps. that was a showstopper for our kiosk apps. I'll have to revisit that issue and see if it's resolved now. I'm glad to see Deno continuing to march on.
- zamadatix 3mo ago
  You may have played with a 3rd party/unofficial solution or similar in the past as Deno Desktop has only just now become available in the Canary branch.
jesse_dot_id 3mo ago
This is kind of exciting. I have a lot of web development experience but every time I've tried to write a desktop app in the past, it just feels like a very clunky and unintuitive experience. Smart move from the Deno team to get me to try out their ecosystem. I probably wouldn't have bothered prior. I've been mostly fine with npm, as its been much faster of late, and the security features recently released are good.
bobajeff 3mo ago
I'm happy to see this I see that this provides CEF, Webview and Raw * backbends but it would be nice if there was also a launch in browser option (like WebUI has). To me that has the best tradeoffs if you want to avoid the mess that is webkitgtk but still not ship (and be in charge of updating) a chromium engine with your app. * https://docs.deno.com/runtime/desktop/backends/ https://docs.deno.com/runtime/desktop/backends/
- echelon 3mo ago
  > I'm happy to see this I see that this provides CEF, Webview and Raw They beat Tauri at their CEF support. Webviews are a mistake in most cases. They're too platform-specific, and certain Webviews (Safari/Webkit) are buggy as hell, making platform support a nightmare. (Linux, ironically, is even worse due to how underbaked webviews are on the major desktop Linuces - Tauri is barely functional on Linux.) Deno Desktop could be a real contender in this space. It's good to see more Electron alternatives.
  - c-smile 3mo ago
    I think that my Sciter is better option when you need HTML/CSS/JS native application running on Windows (XP and beyond), MacOS and Linuxes. Sciter SDK [1] contains scapp[.exe] - standalone Sciter engine that can be attached to HTML/CSS/JS bundle making standalone (single exe file) and portable executable. https://quark.sciter.com/ https://quark.sciter.com/ tool allows to compile such apps. Size of "hello world" is a size of scapp.exe binary + size of compressed HTML/CSS/JS bundle. On Windows scapp.exe is of ~14 Mb. On Linux ~18 Mb. Linux version at startup detects GTK4, Wayland or X11 and uses those as windowing backends. On all platforms Sciter provides out of the box: HTML/CSS/JS runtime, libuv based Node.JS alike runtime, GPU accelerated rendering, WebGL 3D runtime, JS built-in persistence (NoSQL DB). It does not have TS compiler built-in as Deno, but that TS-to-JS compiler is better to be outside anyway as it is used only once - at app loading. [1] https://gitlab.com/sciter-engine/sciter-js-sdk/ https://gitlab.com/sciter-engine/sciter-js-sdk/
    - shunia_huang 3mo ago
seego 3mo ago
Neat! Is there any "bundle/integrate with existing native application" story like Tauris sidecar [0]? [0]: https://v2.tauri.app/develop/sidecar/ https://v2.tauri.app/develop/sidecar/
- gabeidx 3mo ago
  From what I understood, what you want is `deno desktop --include […]`. > Includes an additional module or file/directory in the compiled executable.
  - steve_adams_86 3mo ago
    This works well. I’ve been using it to bundle other binaries with my applications and so far my users have had no issues on Windows, Linux, and macOS. I’m still a bit surprised given how new it is
    - seego 3mo ago
      That's great to know, thanks! Will look into that.
kettlez 3mo ago
Great, another way to make shipping bloated javascript apps easier. Just what we need.
puskavi 3mo ago
No matter how good they get, I still hate everything about js desktop apps
- epistasis 3mo ago
  I'm truly curious about running another desktop environment inside via WASM, honestly...
- ozim 3mo ago
  No matter how much you hate everything about js desktop apps — there are no proper alternatives. The web is probably the closest thing the software industry has to a truly universal, open application platform. There is corporate influence, but it is substantially more vendor-neutral than any other UI platforms. The web stuff mostly uses licenses such as MIT, Apache 2.0, and BSD. GPL-licensed projects exist, but still many more on permissive side. Web is based on open standards developed through organizations and specifications are publicly available, royalty-free, and implemented by multiple independent browser engines rather than being owned by a single corporation.
opem 3mo ago
Deno desktop supporting other backends using raw is crazy!
deleted 3mo ago
[deleted]
qudat 3mo ago
> Bindings are not IPC. The Deno runtime and the rendering backend run as threads / processes inside the same address space (CEF) or coordinated process group (WebView). Calls go through in-process channels, and the backend dispatches them from its run loop. -- https://docs.deno.com/runtime/desktop/bindings/ https://docs.deno.com/runtime/desktop/bindings/ I don't understand how the coordinated process group works. Doesn't that mean in this multi-process mode it must be IPC? Maybe the claim "shared memory space" is more an architectural description than an OS-level claim?
- jankiel 3mo ago
  this is what I wonder as well.
- whilenot-dev 3mo ago
  My guess is that it's not using IPC on OS level, like D-Bus on Linux, but rather a supervisior process starts and orchestrates child processes as needed. And all these processes use a shared memory model. Here's the CEF docs on processes: https://chromiumembedded.github.io/cef/general_usage.html#processes https://chromiumembedded.github.io/cef/general_usage.html#pr... EDIT: ...and the CEF docs on IPC: https://chromiumembedded.github.io/cef/general_usage.html#inter-process-communication-ipc https://chromiumembedded.github.io/cef/general_usage.html#in...
- billywhizz 3mo ago
  from what i understand after a quick look at the source is it uses a C ABI to communicate between the WebView/CEF "host" application and the deno runtime which is loaded by the host as a shared library. marshalling of values back and forth between the JS/C++/Rust layers still has to happen but these are just straight C api calls in process under the hood so much less overhead than having to do serdes across a socket/pipe. - https://github.com/denoland/deno/blob/main/cli/rt_desktop/lib.rs https://github.com/denoland/deno/blob/main/cli/rt_desktop/li... - https://github.com/littledivy/laufey/blob/main/webview/src/main_linux.cc https://github.com/littledivy/laufey/blob/main/webview/src/m...
  - billywhizz 3mo ago
mococa 3mo ago
Another Chrome wrapper...
doodlesdev 3mo ago
The overall feature seems really solid, but I'm impressed they couldn't reduce the average package size further from 40MB even when not using CEF. I guess that wasn't a huge focus when developing this feature? Tauri and Dioxus can easily hit less than 5MB for package sizes. I find the feature matrix comparison to be extremely well done and the sections beneath explaining advantages and disadvantages to be some of the best docs I've read recently. https://docs.deno.com/runtime/desktop/comparison/ https://docs.deno.com/runtime/desktop/comparison/
- eric-p7 3mo ago
  Deno Desktop is bundling the V8 JavaScript runtime so it can have JavaScript on the backend. Tauri uses rust for the backend and your browser's JavaScript engine for the frontend.
  - deleted 3mo ago
    [deleted]
xgulfie 3mo ago
Funny how Deno desktop supports prompt(), which electron refuses to implement
pier25 3mo ago
So how much does a hello world weight?
holistio 3mo ago
I'm very inexperienced with regards to "JS on the desktop" environments. Does this mean any kind of improvements for Electron apps? Is it possible to port them to Deno?
umvi 3mo ago
So I guess this is a competitor to Electron?
OhMeadhbh 3mo ago
Any indication when v2.9.0 will be released? I'd love to play with this, but the install instructions (at least for linux) don't seem to work. Is it working in Windowsland or on macOS?
microflash 3mo ago
This is something that can bring me back to Deno. Binary size is still pretty big IMO. If they can trim down runtime based on the specific uses of standard library (sort of treeshake Deno runtime itself), it would be revolutionary. Java promised this with `jlink` but sadly failed to deliver for wider adoption.
sharts 3mo ago
Why this and not rust or go?
- api 3mo ago
  That would give us efficient desktop apps that don’t need a JavaScript runtime.
- ifh-hn 3mo ago
  Literally the first question in TFA.
elwebmaster 3mo ago
Enough with web trash! Isn't vibe coding enough to build a proper program?
auraham 3mo ago
For me, the best about Tauri is that: - We can embed an existing application using a sidecar [1]. - Now, we can also use Elixir in the backend, embed the BEAM, and deliver a single binary, see ElixirKit [2]. As far as I know, LiveBook Desktop [3] is using Tauri for building binaries for MacOS and Windows. If Tauri works for the Elixir team, I think it works for me too. Also, I know that Tauri is not bullet proof. WebView can be limited for some use cases, see [4]. There is some effort to use CEF to mitigate those problems, though [5]. I'd like to know how Deno Desktop compares with Tauri in this context. I know it is a new product, not sure if we could bundle an existing binary in Deno Desktop, like in ElixirKit. [1] https://v2.tauri.app/develop/sidecar/ https://v2.tauri.app/develop/sidecar/ [2] https://elixirkit.hexdocs.pm/tauri.html https://elixirkit.hexdocs.pm/tauri.html [3] https://github.com/livebook-dev/livebook/blob/main/rel/app/tauri.sh https://github.com/livebook-dev/livebook/blob/main/rel/app/t... [4] https://www.youtube.com/watch?v=vmslGvxObvM&t=621s https://www.youtube.com/watch?v=vmslGvxObvM&t=621s [5] https://github.com/orgs/tauri-apps/discussions/8524 https://github.com/orgs/tauri-apps/discussions/8524
- gabeidx 3mo ago
  There's a comparison page: https://docs.deno.com/runtime/desktop/comparison/ https://docs.deno.com/runtime/desktop/comparison/ And you can embed anything on the binary with `deno desktop --include […]`.
acimen101 3mo ago
[flagged]
baliex 3mo ago
This is pretty cool, I have an interest in running admin interfaces (think web CMS) for non-technical users locally. I tried out the most basic possible example, from the linked page: Deno.serve(() => new Response("<h1>Hello, desktop</h1>", { headers: { "content-type": "text/html" }, }) ); It worked, after a little wrangling to get a 2.9 preview (deno upgrade canary). Amazing! So, so, so simple! There's a downside though... that "Hello, desktop" app weight in at 308MB on macOS. Now, I don't know how that compares to an electron app, or the most lightweight app possible handcrafted specifically for macOS, and there are many, many layers of abstraction between my 1 line of code and the resultant but that is enormous!

1122 points by GeneralMaximus 3mo ago

Actually, this would be amazing for distributing web games as apps for Steam or online purchase. I am going to give it a try.

solarkraft 3mo ago

This is a smart thing to ship. For me it would totally be a consideration when deciding on a platform to use.

sjeno 3mo ago
agree, small footprint & cross-platform looks like a nice alternative to electron or tauri..
- franz899 3mo ago
  Their comparison page shows some savings, but not in every case (~40 MB / ~150 MB) https://docs.deno.com/runtime/desktop/comparison/ https://docs.deno.com/runtime/desktop/comparison/
  - merelysounds 3mo ago
    To be fair the ~150MB is for the CEF scenario (when chromium gets bundled); and eventually they want to introduce a shared CEF runtime across apps.

bossyTeacher 3mo ago

How is this better than Electron?

IshKebab 3mo ago
Vastly easier to set up, optionally lets you use platform web renderers, Typescript by default, you can use the Deno API instead of Node (compatible with less code but much better designed), built-in auto update, you can use Fresh which IMO is the best web framework.
zamadatix 3mo ago
These from the comparison table stick out to me: - Can use "raw, system WebView, or bundled CEF" vs "bundled Chromium" - The size can be smaller in the Raw/WebView cases. - Built-in automatic differential updates - Built-in cross-compilation (+the compilations just come built into Deno itself rather than as a 3rd party package). And, of course, the same lists as one would generate when comparing the base Deno vs Node themselves.

jorisw 3mo ago

> Web technology is the most widely-known UI toolkit in the world. Poor choice of words there IMHO. The reason Electron apps get a lot of flak is because they are everything _but_ a UI toolkit. They consistently miss the mark in adopting UI patterns from their host OS. Web tech is just web tech. Yes it will allow you to render a button, but even unstyled, the button won't necessarily look native to the OS, and will vary between browsers.

divan 3mo ago
This. It's nuts how the whole industry accepts that typesetting engine from 80s with bunch of hacks on top is currently dominating cross-platform UI development.
utopiah 3mo ago
> look native to the OS Is that a problem? A button with a legible label is a button. The host OS doesn't have to look exactly like the applications it runs.
- jorisw 3mo ago
  Consistency is a large factor in any good design, UI design more so.
  - Gigachad 3mo ago
    They have internal consistency. The iOS version looks like the macos version which looks like the web version, etc. This upsets HN users but the rest of the world decided that apps looking like windows built ins doesn't matter.
    - ahartmetz 3mo ago
      It's more like developers decided - nobody asked the users.
      - 3mo ago

sheept 3mo ago

I was wondering how this integrates with Deno's permission system, which is one of its biggest strengths especially for letting agents run amok on your device. The CLI reference page[0] notes, > The permissions you grant at compile time are baked into the compiled binary: I think it would be nice if this could be surfaced to the user somehow, like letting the user know and decide which permissions they want to give access to. [0]: https://docs.deno.com/runtime/reference/cli/desktop/#runtime-flags https://docs.deno.com/runtime/reference/cli/desktop/#runtime...

porridgeraisin 3mo ago
> What deno desktop doesn't have yet > Runtime permissions for desktop apps (a permission prompt on every filesystem / network access, i.e. Deno's permission system applied to desktop sandboxing).
tomComb 3mo ago
You are running a binary that you got from the developer. If it presented you with Deno permissions, I think that would be misleading because there’s no guarantee of their integrity.
- sheept 3mo ago
  That is true. I wonder if it could be possible to let the user supply and wrap the app around their own, trusted installation of Deno (rather than the one bundled in the app) to specify permissions.
  - minraws 3mo ago
    Why not run it in a vm or container instead then, it seems a bit much imho.
- hdjrudni 3mo ago
  Then do `deno ./my_downloaded_deno_gui` instead. If you trust the copy of deno you downloaded, then hopefully it can be trusted to verify the permissions of random downloaded deno-apps. Yes, it kind of defeats the standalone binary aspect but if you're really concerned about security, maybe it's a happy medium.

lillesvin 3mo ago

As much as I like cross-platform stuff, I also really like native UIs that follow native UX patterns, etc.

deely3 3mo ago
We spend a lot of time using different browsers. As far as I know there no web engine that use native OS UI for rendering.
- kuekacang 3mo ago
  Isn't all uses native OS UI widget? But since the brand need to be experienced the same across platform, it overrides the native rendering and use custom styles instead.
- nicce 3mo ago
  > As far as I know there no web engine that use native OS UI for rendering. That sounds like a monster I would be afraid to touch.
mohsen1 3mo ago
In practice it's much harder to maintain a native app. I am noticing this with ChatGPT Mac app vs. Codex Mac app. ChatGPT on Mac is constantly behind compared the web ChatGPT while Codex is shipping features at a much higher velocity. Also ChatGPT hangs and has more weird bugs compared to Codex.
- LtWorf 3mo ago
  Did they run out of tokens? Why don't they ask their agent to update the mac version?
- hbn 3mo ago
  The issues with the ChatGPT Mac app could also be reflective of the state of Swift UI considering not even Apple themselves can ship Swift UI apps that aren't janky. https://daringfireball.net/2026/06/swiftui_only_makes_it_easy_to_develop_bad_apps https://daringfireball.net/2026/06/swiftui_only_makes_it_eas...

nimchimpsky 3mo ago

[dead]

utopiah 3mo ago

Interesting but IMHO as we see on mobile providing WebViews work. Maybe instead of having Electron, Tauri, Electrobun, now Deno desktop but also plenty of alternatives then desktop browsers should provide WebViews on desktop with sandbox and permissions that make those applications usable. The alternatives listed here would just be fallback for a transition period until the WebViews are "good enough".

andyferris 3mo ago
Is it not a web view? With nodejs capabilities from the “backend” half of the app for normal desktop app filesystem access etc?
- utopiah 3mo ago
  If a Web View is not provided by a browser then it's an already installed browser then it's as they say "web rendering engine" that they ship along. I'm trying to argue that it should already be available via Firefox, Chromium, etc on desktop.
  - koolala 3mo ago
    Firefox doesn't release a webview engine but if they did I wonder if Linux distros would use it.
pjmlp 3mo ago
Webviews have always worked since MSHTML, the issue is being comfy helping Google's market share instead of writing portable Web code.
- utopiah 3mo ago
  That's a whole can of worms, Micro$lop entangling its own browser with its OS, getting a (gentle) slap on the hand for its abuse of monopoly position for it, having to remove it claiming it's "impossible", etc.

jaimehrubiks 3mo ago

This web page stole my scroll liberty

droidjj 3mo ago

> The default WebView backend uses the operating system's own webview for small binaries, and you still have the entire npm ecosystem available through Deno's Node compat layer. Sounds like a similar architecture to Tauri, but your business logic is in typescript instead of rust.

progx 3mo ago
> Opt into the bundled Chromium (CEF) backend when you need identical rendering across macOS, Windows, and Linux. Sound more like Electrobun

deleted 3mo ago

[deleted]

sureglymop 3mo ago

Looks actually good! I wonder if it supports opening invisible browser windows and doing things like intercepting cookies. In my desktop application I leverage a hidden browser window to manage auth state and use it like a proxy for the rest of the application. Might try to port it to deno desktop.

m00dy 3mo ago

would be cool to have a comparison with tauri.

tarcon 3mo ago
They really did their best comparing it with other tools here https://docs.deno.com/runtime/desktop/comparison/ https://docs.deno.com/runtime/desktop/comparison/
- prohobo 3mo ago
  RE: Tauri not having cross-compile... There's a GitHub action that compiles for Linux, Windows, and Mac. So practically it does have it, just not out of the box.
  - zamadatix 3mo ago
    Practically that's just the ability to generate binaries for more than one target. "Cross compiling" is specifically that ability without having to invoke a separate external environment to get the additional targets. If cross compiling were really just about the result rather than the means, what would the difference be between that and normal support for multiple targets?

porridgeraisin 3mo ago

While I've never liked to use deno compared to node and bun, this looks particularly good. The zero config options are nice, all the features seem to be in the place I like, and I'm happy they're not dogmatic about using the system webview and let you ship your own CEF. The state of system webviews on non-windows platforms is horrendous.

bel8 3mo ago

I'm happy for competition in this space, specially because Deno can run true TypeScript directly and not just strip types like the current Node implementation. With that said, this is going to eat a lot of Tauri market. Why would I use Tauri now? The 150mb of additional bundle size is just an extra 1 to 10 seconds of download time in most internet connections and you get a reliable rendering engine.

swiftcoder 3mo ago
> and you get a reliable rendering engine How is it more reliable than Tauri - aren't they both using the system webview?
- bel8 3mo ago
  Deno Desktop can bundle CEF (Chromium Embedded Framework) according to https://docs.deno.com/runtime/desktop/comparison https://docs.deno.com/runtime/desktop/comparison
- fiatpandas 3mo ago
  Deno desktop can use system web view OR embed CEF. Tauri is just system web view.
  - aabhay 3mo ago
    The benefit of Deno Desktop is it's like Tauri except for when you want it to be Electron???
    - GeneralMaximus 3mo ago
      This is a feature many apps actually need. E.g. Tauri uses WebKitGTK on Linux, which has historically been slow, unstable, and frequently lagging behind the main WebKit project. This is enough of an issue that even Tauri is working on the ability to use CEF instead of the system web view in Tauri apps. Things are generally fine on recent versions of Windows and macOS. The system web views on these platforms will be evergreen versions of WebKit or Blink. But if you want to support very old versions of Windows or macOS, you might choose to use CEF instead of wrestling with Safari-from-five-years-ago.

SudoSlayer90 3mo ago

[dead]

huflungdung 3mo ago

[dead]

DiabloD3 3mo ago

I don't get the point of this. The world is trying to make computers faster and more accessible, more web UI slop isn't going to help that. Dumping Javascript entirely is the first step on that road.

vinkelhake 3mo ago
I've seen variants of this comment for many years. The alternative to "web UI slop" would presumably be one of the many native toolkits. I see it in a different way. The fact that "web UI slop" has managed to make great inroads on the desktop is an indictment of the state of native toolkits. If you think it's a problem that desktop apps are being written with web toolkits, the solution for that isn't to shame (as the term "web UI slop" clearly tries to do), but rather to figure out how to improve the native toolkits. The opportunity to improve those toolkits was always there, and the ball was dropped.
- DiabloD3 3mo ago
  It hasn't made any inroads on the desktop though... all anyone did was just package their own SWA into a self-contained browser that serves its own content. They continue to be websites, with all the pitfalls of them. I don't need to spend 2GB-4GB of RAM just to have a over-glorified IRC clone! Also, the native toolkits are fine. Windows has two toolkits, the ShellUI/MFC family (which does everything required, although it doesn't always get hidpi on legacy apps correct; it gets integration for blind people and also unicode/multilingual correct, and also works with touch interfaces), and WinUI does it more modernly (and ticks all the boxes). OSX has its toolkit, seems to nail everything correctly. Linux has Qt (lets ignore GTK for now, only reason you use GTK is if you want to appear Gnome-native), and Qt also does native++ uplifting on other toolkits (ie, native widget + additional feature expansion, plus perfect mimicry of native look for entirely new widgets), plus Qt does everything you need to do correctly and easily. There are also new UI toolkits coming up through the ranks that are trying to knock Qt off that #1 position. None of the WebUIs would even place in this race. Web UI toolkits always look non-native, are hard to interpret, often use low contrast (and frankly ugly) colorschemes, are easy to use in ways that do not comply with usability standards across OSes, and usually do nothing for A11Y. The opportunity to improve those toolkits was always there, and the ball was dropped.

arikrahman 3mo ago

I've decided on using a Clojure/Flutter hybrid that gets the best of all worlds. May integrate move from Bun to using Deno here https://codeberg.org/arik/clutter https://codeberg.org/arik/clutter

chem83 3mo ago
Care to expand on what this solution is? What is Clojure bringing to Flutter in this case? Ty.
- arikrahman 3mo ago
  Howdy, the Clojure dialects such as ClojureDart as well as Jank interop with the Flutter to provide a better development experience as well as more capable engine. This is inspired by Toyota's Fluorite implementation within flutter, which may be integrated into Clutter on its release.

wg0 3mo ago

I hope bun desktop is coming soon?

tonyedgecombe 3mo ago
I expect a poorly conceived and buggy vibe coded version will be available this afternoon.

DaanDL 3mo ago

I swear we're just going to end up with Java again.

mfru 3mo ago
At this point I think that would be a more sane outcome than whatever it is we have right now.
- tonyedgecombe 3mo ago
  We were writing and shipping desktop applications with it back in the nineties. Although many of the arguments against it were similar to the arguments against Electron today.
  - ivell 3mo ago
    I think the UI look and feel was very ugly for many users and that caused its demise. The cross platform skin was ugly. The native skins were in the uncanny valley. The framework was reasonably good for its time. By the time good looking UI frameworks came, the bad reputation was already set.
    - frou_dh 3mo ago
      Even the later JavaFX was a tasteless exercise. I opened some apps and you could tell within 1 second that something was wrong because all the text was using fugly non-platform-native (or somehow screwed up) text rendering.
    - tonyedgecombe 3mo ago
      I think SWT was the best option if you wanted native controls.
  - LtWorf 3mo ago
    Yeah back then a java application could take several minutes to open.
3mo ago

daft_pink 3mo ago

Is it going to support iOS/Android?

koolala 3mo ago
No customizable programmable browser runtimes exist for those.
- rbits 3mo ago
  What do you mean by that? Does this[1] not count? [1] https://capacitorjs.com/ https://capacitorjs.com/
  - koolala 3mo ago
    Correct, that isn't a browser it uses a webview. The limited webview version of Deno Desktop could work like that on phones.
bartlomieju 3mo ago
Bartek from the Deno team here. No promises yet, but we're looking into feasibility of it.
robtro 3mo ago
The docs say it's planned but no proper roadmap for it yet.

krawcu 3mo ago

Why did they describe electrobun as macOS only? I checked their docs and it has support for Windows, macOS and Linux https://docs.deno.com/runtime/desktop/comparison/ https://docs.deno.com/runtime/desktop/comparison/ https://github.com/blackboardsh/electrobun#platform-support https://github.com/blackboardsh/electrobun#platform-support

bartlomieju 3mo ago
Thanks, I'll update the docs. When we wrote them a couple weeks back, Electrobun was announcing Linux only support.

numlock86 3mo ago

How does this differ from electrobun, which they explicitly mention, but make no point about? I had a quick drive with deno desktop and don't see how it's better. If anything it's lacking in comparison in my opinion. But hey, we can build desktop apps with deno now, too. So they got that going I guess ...

actionfromafar 3mo ago
I think for a little while longer, you can catch bun anything, electro or not, refugeess just by not being bun.
bartlomieju 3mo ago
Bartek from Deno team hear. I'll love to hear what you feel is missing so we could improve `deno desktop` for more users.

leleat 3mo ago

> Shared CEF runtime across apps. Every app currently bundles its own CEF copy. A managed shared runtime would drop binary sizes to a few MB per app. On the roadmap. This[0] sounds interesting. I am not familiar with CEF, so I wonder how the versioning works. When different apps require different versions of CEF, do we just essentially end up with the electron model where every app bundles their own browser (just slightly less bad). Or is there still an advantage to a "shared runtime" in that case? [0]: https://docs.deno.com/runtime/desktop/comparison/ https://docs.deno.com/runtime/desktop/comparison/

tonyedgecombe 3mo ago
In case anybody else wondered CEF is the Chromium embedded framework. https://github.com/chromiumembedded/cef https://github.com/chromiumembedded/cef
- echelon 3mo ago
  The biggest weakness of a framework like Tauri is the choice to target system webviews instead of bundling a browser runtime. It seems great to be able to cut hundreds of megabytes out of your app installer, but the platform differences wind up being a complete and ongoing pain in the ass. Tauri support on Windows is phenomenal. Tauri on Mac runs into lots of WebKit/Safari issues, especially on older Mac machines that have an older engine that doesn't support modern web APIs. Your app can crash or be left non-functional. You'll find out about these runtime bugs in the wild randomly, and patching for some customers can take days, if not weeks. Linux support is hellish, and it's best to not even try targeting Linux with Tauri. Tauri is in the process of adding CEF support. It should probably become the default build target for all platforms.
  - oooyay 3mo ago
    I use Wails which is Tauri but for Go and I don't have the kind of issues you're mentioning. Maybe that is a difference between Wails and Tauri but I don't think the system WebView is a significant factor.

lwansbrough 3mo ago

Similar to something I'm working on for games: https://jumpjet.dev https://jumpjet.dev WASM you can bundle for Windows, macOS, Linux, Android, iOS and web. Unlike Deno Desktop, it doesn't rely on a browser engine.

ai_fry_ur_brain 3mo ago
Do you reccomend and resources for building w/ & learning about wasm?
- lwansbrough 3mo ago
  It's all so bleeding edge right now. It also depends how deep you want to go. An increasing number of languages support wasm as a compile target, which is helpful. Bytecode Alliance do semi-regular streams on Youtube. I think reading (recent) material on WASI (0.3) and the Component Model would be a good start. Understanding the relationship between a host and a guest is valuable. Learning what wasmtime is and how it works is also illuminating: https://docs.wasmtime.dev https://docs.wasmtime.dev
  - ai_fry_ur_brain 3mo ago
    Tyty
matharmin 3mo ago
Do you mean "Unlike Deno Desktop"? Deno Desktop definitely relies on a browser engine.
- lwansbrough 3mo ago
  Yes, thanks.
catears 3mo ago
Just FYI, when checking out jumpjets homepage, the white-dot airship in the background made the white text in the hero banner hard to read. Cool project!

unliftedq 3mo ago

[flagged]

LauraMedia 3mo ago

Maybe it is because it is still in development, but building and running the Hello World example just gives me a blank terminal and a white window that is not responding.

bartlomieju 3mo ago
Sorry to hear that, could I ask you to file an issue in our bug tracker?

pippoit 3mo ago

can i open a socket with these tools ? can i open an odbc connection for example ? Or have i need to have a backend ? On desktop usually you can do much more than in the sandbox of a browser . I ask because i don't know these technologies. On windows, even if i don't like it, if the interface and the logic are not too complex, powershell with winform make you create things without "anything" installed and you can easily interact with other windows programs ( office 365 suite, autocad and so on ) so for doing "fast things" in my opinion is a very strong alternative .

bartlomieju 3mo ago
Yes, you can do all that. You get a fully-fledged Deno program that can do all of this, _plus_ you get a frontend GUI app.

deleted 3mo ago

[deleted]

asim 3mo ago

Curious to know who is using Deno in anger most days and in production full time? It seems like the choice of JS runtimes exploded over the past few years with that, Bun, etc.

flexagoon 3mo ago
Why "etc."? Isn't it just node, bun and deno? Genuine question
- asim 3mo ago
  In case someone is using something we haven't heard of e.g some are running using cloudflare workers which also has some unique runtime properties. AWS has something called LLRT. https://github.com/awslabs/llrt https://github.com/awslabs/llrt https://developers.cloudflare.com/workers/runtime-apis/ https://developers.cloudflare.com/workers/runtime-apis/
  - syrusakbary 3mo ago
    We have created Edge.js that can run Node.js apps fully using your preferred JS runtime: V8 or QuickJS. https://edgejs.org/ https://edgejs.org/
- gr4vityWall 3mo ago
  There's QuickJS, LLRT, Rhino, and GameMaker is about to get TS/JS support.
steve_adams_86 3mo ago
I use it for several applications (frontend, backend, CLIs) in production settings, and it has been excellent. Caveat: I serve small internal teams mostly, some projects only serve < dozen users. One is around 500/day. No issues at all. I’ll definitely use Deno desktop for these internal tools. Their binary compilation (especially now that it can include other binaries) has been totally sound and I expect this to work well too. Worth noting is that the team has improved compilation features steadily. Every issue I watched last year has been completed and I’m not encountering blockers anymore.

liampulles 3mo ago

Having deno desktop do the framework handling for a bunch of popular options is an interesting choice. It seems deno is trying less to be an agnostic JS runtime, and more an "integrate everything toolkit" (not unlike Spring in the Java space).

taosu_la 3mo ago

Is this a new trend? Why are everyone starting to do desktop runtime? For example, I recently saw Bun Electron, and then I saw this project.

iagooar 3mo ago
I guess people are tired of each instance of an Electron-based app using 1GB+ of RAM.
- josephernest 3mo ago
  I just tried `deno desktop helloworld.ts` and the result is 442 MB. So it's not any lighter than Electron (see my toplevel comment)
  - iagooar 3mo ago
    Then it probably was wishful thinking on my side...
- yboris 3mo ago
  Why are people parroting this meme? For 8 years now, constantly updating to newest Electron, my Electron app has been using only about 150mb of RAM - (see Video Hub App)

HackerThemAll 3mo ago

https://docs.deno.com/runtime/desktop/#hello%2C-desktop https://docs.deno.com/runtime/desktop/#hello%2C-desktop Yeah, hello desktop. D:\source\DenoTest>deno desktop main.ts error: Module not found "file:///D:/source/DenoTest/desktop".

sippeangelo 3mo ago
deno desktop ships in Deno v2.9.0 and is not in a stable release yet. To try it now, run deno upgrade canary to install the canary build. The command, configuration keys, and TypeScript APIs may still change before the feature is stable.

mb2100 3mo ago

> Backend and UI communication goes through in-process channels, not socket-based IPC Are they running the frontend and backend in the same process? Sounds a bit dangerous security-wise?

whilenot-dev 3mo ago
How can in-process channels be more dangerous than a socket-based IPC? The frontend still goes through the "secure" JavaScript engine AFAICS.

shevy-java 3mo ago

I watched traditional GUIs for a while and used many of them, mostly via ruby as wrapper, sometimes also via java. I finally reached the conclusion not too long ago, that web-apps are the only real alternatives now. Too many things do not work when it comes to traditional desktop applications. There are even regressions, e. g. ruby-gtk4 barely works for me. And there is no real support for any problems really. People make fun of e. g. electron "soooo big so bloated", and WebAssembly is still not really in any breakthrough after almost 20 years. But traditional desktop apps are also even more dead. So I'll have to add JavaScript/TypeScript/Node now simply because there are no real alternatives to this anymore. I'd wish we would have a real "write once, run everywhere"...

calvinmorrison 3mo ago
Odd because I'm wrapping up an app that uses Xaw. It should run on the billion or so machines that support X11
zero-st4rs 3mo ago
> I'd wish we would have a real "write once, run everywhere"... Hi! I'm trying my best okay? Hokusai Pocket might currently be composed of wood and string, but one day he will be a real boy!

nottorp 3mo ago

Hmm suppose you have a node GUI-less application. What would you pack it in to have something reasonably self contained to deploy?

tones411 3mo ago
Look into Single Executable Applications https://nodejs.org/api/single-executable-applications.html https://nodejs.org/api/single-executable-applications.html
- nottorp 3mo ago
  Thanks!
bobajeff 3mo ago
Deno actually has had a built in compile to binary feature * I've used it before a few times. * https://docs.deno.com/runtime/reference/cli/compile/ https://docs.deno.com/runtime/reference/cli/compile/

jessinra98 3mo ago

what happens when two apps need different cef versions? doesn't that just mean you're back to bundling your own browser anyway. does the shared runtime actually save memory when the underlying chrome versions diverge?

catapart 3mo ago

Awesome! Looking forward to trying this out.

scirob 3mo ago

They had this before I used it to ship some stuff but binaries were big . How small did they get it with this update

G_o_D 3mo ago

I was just today morning thinking about some such idea, for mhtml to be embedded with light weight renderer so it does'nt have to rely on other browser

c-smile 3mo ago
> for mhtml to be embedded with light weight renderer so it does'nt have to rely on other browser That's Sciter (https://sciter.com https://sciter.com) and Sciter.Quark (https://quark.sciter.com https://quark.sciter.com) in particular, no?

T3RMINATED 3mo ago

[dead]

karol 3mo ago

Of all the content they put out I liked the comparison section the most. The last row says iOS/Android - Electron: no, deno: not yet. If they deliver on this it will get much bigger.

josephernest 3mo ago

> deno desktop is opinionated about those tradeoffs: > Small by default, full Node compatibility I tried `deno desktop index.ts` with the 5-line Hello world in the article. Result (Windows 10): 442 MB. Ouch. I thought it would be smaller than an Electron build, but it's far worse. Did I do something wrong? (libcef.dll: 247 MB) (deno-test.dll: 78 MB <- contains the hello world)

josephernest 3mo ago
IIRC Electron hello world is ~ 100-150 MB because it bundles a browser/Chromium runtime. So I hoped we could have a <= 20 MB solution by reusing the OS webview or similar. Having more than 400 MB is a bit deceptive for me. (Again: maybe I just did something wrong in the config: should I do something else than `deno desktop test.ts`?)
fny 3mo ago
libcef is the Chromium embedded framework[0], so your build isn't using a webview or maybe its using both. I just tried it on my mac, and I can't keep libcef out even with `--backend webview`. https://github.com/chromiumembedded/cef https://github.com/chromiumembedded/cef
undefined_void 3mo ago
Try the webview backend: `deno desktop --backend webview`
- IdiotSavage 3mo ago
  The docs say that's the default: https://docs.deno.com/runtime/desktop/backends/#webview-(default) https://docs.deno.com/runtime/desktop/backends/#webview-(def...
  - crowlKats 3mo ago
    apologies, this is inaccurate currently, will get things updated
- 3mo ago

omojo 3mo ago

Impressive work. This is going to be really interesting for vibe coding Desktop apps. I imagine this on Lovable, Bolt or v0 since they basically default to using Typescript for building web apps. I've been using Go/Wails for desktop projects rather than a bundled Chromium and Node in a small desktop app, Electron did a good job but that was a big No for me.

40four 3mo ago

Deno continues to impress me. It’s honestly been quite a while since I started a new project without it. It has fully won my support over Node.js, the ecosystem has really matured nicely. I don’t know how often I’ll use this feature, but it’s really nice to have the option!

liamgm 3mo ago
yes the big win from this is the Node API / NAPI support , if you write node_modules in nodejs , electron , raycast , edgejs you can reuse it . https://wasmer.io/posts/edgejs-safe-nodejs-using-wasm-sandbox https://wasmer.io/posts/edgejs-safe-nodejs-using-wasm-sandbo... "NAPI allows native Node dependencies to target Node without actually depending on a specific version of Node or V8. NAPI abstracted the V8 JS engine away, by providing JS-like APIs for: creating an object, declaring a property, etc. NAPI is the contract that all modern native Node modules use to interact with Javascript." [1] 1: https://wasmer.io/posts/edgejs-safe-nodejs-using-wasm-sandbox https://wasmer.io/posts/edgejs-safe-nodejs-using-wasm-sandbo...
esperent 3mo ago
I'm still using node/npm and it's... fine. Every so often I read these posts and think I should change but node/npm is already a low friction part of my workflow. However, what I have seen is that a lot of other libraries I use have switched to Bun. I haven't seen any that switched to Deno, and so I've been under the impression that Bun is becoming a strong node replacement candidate while Deno is not, or at least that the community is making a strong preference for Bun. Anyone have more insight into this?

undefined_void 3mo ago

Deno Desktop supports two backends as of now: CEF (Chromium) and Webview You can get your app sizes as low as 15mb with `deno desktop --compress` (in canary) A tiny "raw" windowing backend exists for WebGPU rendering as well

SpaceL10n 3mo ago

I think the last time I tried Deno for desktop it didn't allow for fullscreen webview apps. that was a showstopper for our kiosk apps. I'll have to revisit that issue and see if it's resolved now. I'm glad to see Deno continuing to march on.

zamadatix 3mo ago
You may have played with a 3rd party/unofficial solution or similar in the past as Deno Desktop has only just now become available in the Canary branch.

jesse_dot_id 3mo ago

This is kind of exciting. I have a lot of web development experience but every time I've tried to write a desktop app in the past, it just feels like a very clunky and unintuitive experience. Smart move from the Deno team to get me to try out their ecosystem. I probably wouldn't have bothered prior. I've been mostly fine with npm, as its been much faster of late, and the security features recently released are good.

bobajeff 3mo ago

I'm happy to see this I see that this provides CEF, Webview and Raw * backbends but it would be nice if there was also a launch in browser option (like WebUI has). To me that has the best tradeoffs if you want to avoid the mess that is webkitgtk but still not ship (and be in charge of updating) a chromium engine with your app. * https://docs.deno.com/runtime/desktop/backends/ https://docs.deno.com/runtime/desktop/backends/

echelon 3mo ago
> I'm happy to see this I see that this provides CEF, Webview and Raw They beat Tauri at their CEF support. Webviews are a mistake in most cases. They're too platform-specific, and certain Webviews (Safari/Webkit) are buggy as hell, making platform support a nightmare. (Linux, ironically, is even worse due to how underbaked webviews are on the major desktop Linuces - Tauri is barely functional on Linux.) Deno Desktop could be a real contender in this space. It's good to see more Electron alternatives.
- c-smile 3mo ago
  I think that my Sciter is better option when you need HTML/CSS/JS native application running on Windows (XP and beyond), MacOS and Linuxes. Sciter SDK [1] contains scapp[.exe] - standalone Sciter engine that can be attached to HTML/CSS/JS bundle making standalone (single exe file) and portable executable. https://quark.sciter.com/ https://quark.sciter.com/ tool allows to compile such apps. Size of "hello world" is a size of scapp.exe binary + size of compressed HTML/CSS/JS bundle. On Windows scapp.exe is of ~14 Mb. On Linux ~18 Mb. Linux version at startup detects GTK4, Wayland or X11 and uses those as windowing backends. On all platforms Sciter provides out of the box: HTML/CSS/JS runtime, libuv based Node.JS alike runtime, GPU accelerated rendering, WebGL 3D runtime, JS built-in persistence (NoSQL DB). It does not have TS compiler built-in as Deno, but that TS-to-JS compiler is better to be outside anyway as it is used only once - at app loading. [1] https://gitlab.com/sciter-engine/sciter-js-sdk/ https://gitlab.com/sciter-engine/sciter-js-sdk/
  - shunia_huang 3mo ago

seego 3mo ago

Neat! Is there any "bundle/integrate with existing native application" story like Tauris sidecar [0]? [0]: https://v2.tauri.app/develop/sidecar/ https://v2.tauri.app/develop/sidecar/

gabeidx 3mo ago
From what I understood, what you want is `deno desktop --include […]`. > Includes an additional module or file/directory in the compiled executable.
- steve_adams_86 3mo ago
  This works well. I’ve been using it to bundle other binaries with my applications and so far my users have had no issues on Windows, Linux, and macOS. I’m still a bit surprised given how new it is
  - seego 3mo ago
    That's great to know, thanks! Will look into that.

kettlez 3mo ago

Great, another way to make shipping bloated javascript apps easier. Just what we need.

puskavi 3mo ago

No matter how good they get, I still hate everything about js desktop apps

epistasis 3mo ago
I'm truly curious about running another desktop environment inside via WASM, honestly...
ozim 3mo ago
No matter how much you hate everything about js desktop apps — there are no proper alternatives. The web is probably the closest thing the software industry has to a truly universal, open application platform. There is corporate influence, but it is substantially more vendor-neutral than any other UI platforms. The web stuff mostly uses licenses such as MIT, Apache 2.0, and BSD. GPL-licensed projects exist, but still many more on permissive side. Web is based on open standards developed through organizations and specifications are publicly available, royalty-free, and implemented by multiple independent browser engines rather than being owned by a single corporation.

opem 3mo ago

Deno desktop supporting other backends using raw is crazy!

deleted 3mo ago

[deleted]

qudat 3mo ago

> Bindings are not IPC. The Deno runtime and the rendering backend run as threads / processes inside the same address space (CEF) or coordinated process group (WebView). Calls go through in-process channels, and the backend dispatches them from its run loop. -- https://docs.deno.com/runtime/desktop/bindings/ https://docs.deno.com/runtime/desktop/bindings/ I don't understand how the coordinated process group works. Doesn't that mean in this multi-process mode it must be IPC? Maybe the claim "shared memory space" is more an architectural description than an OS-level claim?

jankiel 3mo ago
this is what I wonder as well.
whilenot-dev 3mo ago
My guess is that it's not using IPC on OS level, like D-Bus on Linux, but rather a supervisior process starts and orchestrates child processes as needed. And all these processes use a shared memory model. Here's the CEF docs on processes: https://chromiumembedded.github.io/cef/general_usage.html#processes https://chromiumembedded.github.io/cef/general_usage.html#pr... EDIT: ...and the CEF docs on IPC: https://chromiumembedded.github.io/cef/general_usage.html#inter-process-communication-ipc https://chromiumembedded.github.io/cef/general_usage.html#in...
billywhizz 3mo ago
from what i understand after a quick look at the source is it uses a C ABI to communicate between the WebView/CEF "host" application and the deno runtime which is loaded by the host as a shared library. marshalling of values back and forth between the JS/C++/Rust layers still has to happen but these are just straight C api calls in process under the hood so much less overhead than having to do serdes across a socket/pipe. - https://github.com/denoland/deno/blob/main/cli/rt_desktop/lib.rs https://github.com/denoland/deno/blob/main/cli/rt_desktop/li... - https://github.com/littledivy/laufey/blob/main/webview/src/main_linux.cc https://github.com/littledivy/laufey/blob/main/webview/src/m...
- billywhizz 3mo ago

mococa 3mo ago

Another Chrome wrapper...

doodlesdev 3mo ago

The overall feature seems really solid, but I'm impressed they couldn't reduce the average package size further from 40MB even when not using CEF. I guess that wasn't a huge focus when developing this feature? Tauri and Dioxus can easily hit less than 5MB for package sizes. I find the feature matrix comparison to be extremely well done and the sections beneath explaining advantages and disadvantages to be some of the best docs I've read recently. https://docs.deno.com/runtime/desktop/comparison/ https://docs.deno.com/runtime/desktop/comparison/

eric-p7 3mo ago
Deno Desktop is bundling the V8 JavaScript runtime so it can have JavaScript on the backend. Tauri uses rust for the backend and your browser's JavaScript engine for the frontend.
- deleted 3mo ago
  [deleted]

xgulfie 3mo ago

Funny how Deno desktop supports prompt(), which electron refuses to implement

pier25 3mo ago

So how much does a hello world weight?

holistio 3mo ago

I'm very inexperienced with regards to "JS on the desktop" environments. Does this mean any kind of improvements for Electron apps? Is it possible to port them to Deno?

umvi 3mo ago

So I guess this is a competitor to Electron?

OhMeadhbh 3mo ago

Any indication when v2.9.0 will be released? I'd love to play with this, but the install instructions (at least for linux) don't seem to work. Is it working in Windowsland or on macOS?

microflash 3mo ago

This is something that can bring me back to Deno. Binary size is still pretty big IMO. If they can trim down runtime based on the specific uses of standard library (sort of treeshake Deno runtime itself), it would be revolutionary. Java promised this with `jlink` but sadly failed to deliver for wider adoption.

sharts 3mo ago

Why this and not rust or go?

api 3mo ago
That would give us efficient desktop apps that don’t need a JavaScript runtime.
ifh-hn 3mo ago
Literally the first question in TFA.

elwebmaster 3mo ago

Enough with web trash! Isn't vibe coding enough to build a proper program?

auraham 3mo ago

For me, the best about Tauri is that: - We can embed an existing application using a sidecar [1]. - Now, we can also use Elixir in the backend, embed the BEAM, and deliver a single binary, see ElixirKit [2]. As far as I know, LiveBook Desktop [3] is using Tauri for building binaries for MacOS and Windows. If Tauri works for the Elixir team, I think it works for me too. Also, I know that Tauri is not bullet proof. WebView can be limited for some use cases, see [4]. There is some effort to use CEF to mitigate those problems, though [5]. I'd like to know how Deno Desktop compares with Tauri in this context. I know it is a new product, not sure if we could bundle an existing binary in Deno Desktop, like in ElixirKit. [1] https://v2.tauri.app/develop/sidecar/ https://v2.tauri.app/develop/sidecar/ [2] https://elixirkit.hexdocs.pm/tauri.html https://elixirkit.hexdocs.pm/tauri.html [3] https://github.com/livebook-dev/livebook/blob/main/rel/app/tauri.sh https://github.com/livebook-dev/livebook/blob/main/rel/app/t... [4] https://www.youtube.com/watch?v=vmslGvxObvM&t=621s https://www.youtube.com/watch?v=vmslGvxObvM&t=621s [5] https://github.com/orgs/tauri-apps/discussions/8524 https://github.com/orgs/tauri-apps/discussions/8524

gabeidx 3mo ago
There's a comparison page: https://docs.deno.com/runtime/desktop/comparison/ https://docs.deno.com/runtime/desktop/comparison/ And you can embed anything on the binary with `deno desktop --include […]`.

acimen101 3mo ago

[flagged]

baliex 3mo ago

This is pretty cool, I have an interest in running admin interfaces (think web CMS) for non-technical users locally. I tried out the most basic possible example, from the linked page: Deno.serve(() => new Response("<h1>Hello, desktop</h1>", { headers: { "content-type": "text/html" }, }) ); It worked, after a little wrangling to get a 2.9 preview (deno upgrade canary). Amazing! So, so, so simple! There's a downside though... that "Hello, desktop" app weight in at 308MB on macOS. Now, I don't know how that compares to an electron app, or the most lightweight app possible handcrafted specifically for macOS, and there are many, many layers of abstraction between my 1 line of code and the resultant but that is enormous!