> 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.
I understand historical usage of the term with regards to desktop, but im unsure how you could consider HTML, CSS, JS, and runtime as anything other than a UI toolkit. They control the layout, styling, and actions of a UI.
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.
This ship has long, long sailed. If you don't spend your all your 24 hours as an office worker using Microsoft software, or you're locked in with a PC from 30 years ago, chances are almost every single UI you use will look differently, besides some microscopic agreements, like back button or a burger menu.
We just got used to it. There is some very vague thin layer of "commonly accepted patterns and symbols", but otherwise users just get through it.
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".
> 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.
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.
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.
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.
The same set of reasons anyone made desktop apps before Deno desktop launched. Deno desktop is not the reason desktop apps are made. If someone really wanted a desktop app made before, deno desktop isn't going to suddenly make new ones start appearing. It will just be a new choice among the many.
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.
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
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 ...
> 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?
> Because we can’t differentiate between a legitimate sign in and a MITM attack on these platforms, we will be blocking sign-ins from embedded browser frameworks starting in June
Granted this was years ago, maybe the situation improved? I had to abandon my CEF project because of this.
83 comments
[ 0.17 ms ] story [ 32.3 ms ] threadPoor 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 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...
We just got used to it. There is some very vague thin layer of "commonly accepted patterns and symbols", but otherwise users just get through it.
Sounds like a similar architecture to Tauri, but your business logic is in typescript instead of rust.
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.
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.
The same set of reasons anyone made desktop apps before Deno desktop launched. Deno desktop is not the reason desktop apps are made. If someone really wanted a desktop app made before, deno desktop isn't going to suddenly make new ones start appearing. It will just be a new choice among the many.
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.
- 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.
Especially if to consider that I've added native D support to Sciter [1].
[1] https://terrainformatica.com/2026/06/05/ai-assisted-developm...
https://docs.deno.com/runtime/desktop/comparison/ https://github.com/blackboardsh/electrobun#platform-support
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/
> Because we can’t differentiate between a legitimate sign in and a MITM attack on these platforms, we will be blocking sign-ins from embedded browser frameworks starting in June
Granted this was years ago, maybe the situation improved? I had to abandon my CEF project because of this.
WASM you can bundle for Windows, macOS, Linux, Android, iOS and web. Unlike Deno Desktop, it doesn't rely on a browser engine.