> 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.
How is it a poor choice of words? It might not be "native" UI, but they never claimed as such.
I've always felt that native UI on Linux always looks incredibly ugly and I'd much rather use a nicely styled HTML+CSS layout instead.
In my experience, Electron mostly gets flak for being bloated and slow, it not being native is sometimes a secondary point people add on top.
I've always wanted to build a direct-browser integration that could use HTML+CSS for the layout, but avoids needing a JS runtime. Idk how lightweight servo is but one day I hope I will see my idea come to light
I don't mind the idea of using HTML components and widgets to style desktop applications. CSS and the DOM are widely known and reusing those for desktop apps is probably a good idea.
The problem, as you've pointed out, is that electron apps are bloated and slow. If they became the default and my editor, chat client, terminal, and everything else that I keep open were just thin layers around web applications, I'd rather figure out a way to move things into a browser rather than pull a piece of the browser out to wrap these applications.
Every time I use Zed across Linux, macOS and Windows , I'm amazed stable and performant it's GPUI framework is. As a user, I'm very happy with it; of course some basic features like accessibility is missing but I'm sure it will be implemented soon.
As a developer, I'm not sure what's the barrier for entry is apart from Rust then again it's the USP as well.
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.
> Runtime permissions for desktop apps (a permission prompt on every filesystem / network access, i.e. Deno's permission system applied to desktop sandboxing).
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.
> Deno can run true TypeScript directly and not just strip types like the current Node implementation
Deno also just stripts the types when running TS code though for performance reasons. Typechecking is a separate feature (deno check), but this doesn't run the code.
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
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.
> 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.
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".
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.
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 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.
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.
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.
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
> 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.
How is it a poor choice of words? It might not be "native" UI, but they never claimed as such.
I've always felt that native UI on Linux always looks incredibly ugly and I'd much rather use a nicely styled HTML+CSS layout instead.
In my experience, Electron mostly gets flak for being bloated and slow, it not being native is sometimes a secondary point people add on top.
I've always wanted to build a direct-browser integration that could use HTML+CSS for the layout, but avoids needing a JS runtime. Idk how lightweight servo is but one day I hope I will see my idea come to light
I don't mind the idea of using HTML components and widgets to style desktop applications. CSS and the DOM are widely known and reusing those for desktop apps is probably a good idea.
The problem, as you've pointed out, is that electron apps are bloated and slow. If they became the default and my editor, chat client, terminal, and everything else that I keep open were just thin layers around web applications, I'd rather figure out a way to move things into a browser rather than pull a piece of the browser out to wrap these applications.
Every time I use Zed across Linux, macOS and Windows , I'm amazed stable and performant it's GPUI framework is. As a user, I'm very happy with it; of course some basic features like accessibility is missing but I'm sure it will be implemented soon.
As a developer, I'm not sure what's the barrier for entry is apart from Rust then again it's the USP as well.
Live reload. GUI development in compiled languages is a pain compared to web development.
Try dioxus, it has live reload but it's a work in progress.
Yeah, it is mostly laziness and cost cutting at the expense of users.
Nowadays there isn't even an excuse anymore, just vibe code it away in native frameworks.
When I can modify my desktop/theme (KDE) with css I will happily start doing it since that sounds easy.
Good news!
https://9to5linux.com/kdes-new-css-based-style-engine-union-...
None of that changes whether it's a UI toolkit, which it surely is.
> 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.
Consistency is a large factor in any good design, UI design more so.
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.
It's more like developers decided - nobody asked the users.
ironically the only group of users I've found that actually care about native UI, are other developers and Mac purist.
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...
> 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).
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.
> Deno can run true TypeScript directly and not just strip types like the current Node implementation
Deno also just stripts the types when running TS code though for performance reasons. Typechecking is a separate feature (deno check), but this doesn't run the code.
> Why would I use Tauri now?
You’re “backend” isn’t JavaScript.
> and you get a reliable rendering engine
How is it more reliable than Tauri - aren't they both using the system webview?
Deno Desktop can bundle CEF (Chromium Embedded Framework) according to https://docs.deno.com/runtime/desktop/comparison
Deno desktop can use system web view OR embed CEF. Tauri is just system web view.
This is a smart thing to ship. For me it would totally be a consideration when deciding on a platform to use.
agree, small footprint & cross-platform looks like a nice alternative to electron or tauri..
Their comparison page shows some savings, but not in every case (~40 MB / ~150 MB) https://docs.deno.com/runtime/desktop/comparison/
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
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.
As much as I like cross-platform stuff, I also really like native UIs that follow native UX patterns, etc.
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.
Is it going to support iOS/Android?
> 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.
> Opt into the bundled Chromium (CEF) backend when you need identical rendering across macOS, Windows, and Linux.
Sound more like Electrobun
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".
Webviews have always worked since MSHTML, the issue is being comfy helping Google's market share instead of writing portable Web code.
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.
Is it not a web view? With nodejs capabilities from the “backend” half of the app for normal desktop app filesystem access etc?
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.
I hope bun desktop is coming soon?
I swear we're just going to end up with Java again.
How is this better than Electron?
This web page stole my scroll liberty
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.
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.
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.
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.
would be cool to have a comparison with tauri.
They really did their best comparing it with other tools here https://docs.deno.com/runtime/desktop/comparison/