> 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?
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.
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.
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!
qudat
> 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/
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?
show comments
solarkraft
This is a smart thing to ship. For me it would totally be a consideration when deciding on a platform to use.
show comments
bel8
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.
show comments
jorisw
> 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.
show comments
doodlesdev
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.
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.
WASM you can bundle for Windows, macOS, Linux, Android, iOS and web. Unlike Deno Desktop, it doesn't rely on a browser engine.
show comments
liampulles
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).
paulbjensen
Actually, this would be amazing for distributing web games as apps for Steam or online purchase. I am going to give it a try.
lillesvin
As much as I like cross-platform stuff, I also really like native UIs that follow native UX patterns, etc.
show comments
DaanDL
I swear we're just going to end up with Java again.
show comments
krawcu
Why did they describe electrobun as macOS only?
I checked their docs and it has support for Windows, macOS and Linux
> 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.
show comments
pier25
So how much does a hello world weight?
seego
Neat!
Is there any "bundle/integrate with existing native application" story like Tauris sidecar [0]?
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.
undefined_void
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
karol
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.
jesse_dot_id
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.
omojo
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.
daft_pink
Is it going to support iOS/Android?
show comments
josephernest
> 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?
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.
show comments
G_o_D
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
show comments
utopiah
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".
show comments
puskavi
No matter how good they get, I still hate everything about js desktop apps
show comments
arikrahman
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
show comments
mb2100
> 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?
show comments
opem
Deno desktop supporting other backends using raw is crazy!
nottorp
Hmm suppose you have a node GUI-less application. What would you pack it in to have something reasonably self contained to deploy?
show comments
LauraMedia
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.
show comments
taosu_la
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.
show comments
catapart
Awesome! Looking forward to trying this out.
scirob
They had this before I used it to ship some stuff but binaries were big . How small did they get it with this update
pippoit
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 .
show comments
xgulfie
Funny how Deno desktop supports prompt(), which electron refuses to implement
wg0
I hope bun desktop is coming soon?
show comments
DiabloD3
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.
show comments
porridgeraisin
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.
numlock86
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 ...
show comments
shevy-java
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"...
error: Module not found "file:///D:/source/DenoTest/desktop".
show comments
bossyTeacher
How is this better than Electron?
show comments
m00dy
would be cool to have a comparison with tauri.
show comments
delduca
Another Chrome wrapper...
kettlez
Great, another way to make shipping bloated javascript apps easier. Just what we need.
jessinra98
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?
> 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/
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...
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/
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!
> 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/
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?
This is a smart thing to ship. For me it would totally be a consideration when deciding on a platform to use.
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.
> 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.
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/
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.
Similar to something I'm working on for games: 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.
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).
Actually, this would be amazing for distributing web games as apps for Steam or online purchase. I am going to give it a try.
As much as I like cross-platform stuff, I also really like native UIs that follow native UX patterns, etc.
I swear we're just going to end up with Java again.
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://github.com/blackboardsh/electrobun#platform-support
> 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.
So how much does a hello world weight?
Neat! Is there any "bundle/integrate with existing native application" story like Tauris sidecar [0]?
[0]: https://v2.tauri.app/develop/sidecar/
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.
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
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.
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.
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.
Is it going to support iOS/Android?
> 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)
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.
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
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".
No matter how good they get, I still hate everything about js desktop apps
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
> 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?
Deno desktop supporting other backends using raw is crazy!
Hmm suppose you have a node GUI-less application. What would you pack it in to have something reasonably self contained to deploy?
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.
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.
Awesome! Looking forward to trying this out.
They had this before I used it to ship some stuff but binaries were big . How small did they get it with this update
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 .
Funny how Deno desktop supports prompt(), which electron refuses to implement
I hope bun desktop is coming soon?
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.
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.
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 ...
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"...
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".
How is this better than Electron?
would be cool to have a comparison with tauri.
Another Chrome wrapper...
Great, another way to make shipping bloated javascript apps easier. Just what we need.
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?
This web page stole my scroll liberty