Deno Desktop
docs.deno.com725 points by GeneralMaximus 9 hours ago
725 points by GeneralMaximus 9 hours 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/
I don't understand how the coordinated process group works. Doesn't that mean this multi-process mode it must be IPC?
> 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?
In case anybody else wondered CEF is the Chromium embedded framework.
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.
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.
Are any of your Mac users using an 10-year old WebView? We frequently ran into that. And there's nothing that can be done about it except engineering around it.
I also doubt it works well on Linux. The performance of webkitgtk is like running an emulator inside an emulator.
Just to let you know, CEF was used for Riot and League of Legends client as well [0]. The results haven't been nice, but I'm not aware if this was a problem with the CEF technology itself or other component/processes are to be blamed.
[0]: https://www.riotgames.com/en/news/architecture-league-client...
When the new client was built, microservices were the hot new buzzword.
The new client is some weird plugins/services based architecture. Things that'd barely warrant their own class in a boring OOP-based UI framework are instead now "isolated" services. The reality of this isolation being that if one piece breaks, the whole UI becomes unusable anyways. Dozens of things that in another app would've been just a simple synchronous call now behave like remote procedure calls and messages, forcing all the complexity of distributed systems into a local application for no reason.
That's why it runs like ass, breaks if you look at it wrong, and your CPU draws more power when using the client than when playing the game at 200FPS.
On the gaming side, last I checked Steam's client was using CEF too and it doesn't get widespread blame for anything.
No shortage of games using it for in-game browser stuff, too.
CEF is + has been the de-facto standard when you have a native app and want to do a web UI.
It's not the only option, but it's the most mature with the largest amount of docs + stack overflow questions, so it's a "safe" choice.
If you peek into the native resources files of most games/desktop apps, you'll find a good portion of them bundle + use the CEF dll.
This is more a function of how mismanaged the project was at Riot (the iron client days, choosing Ember, etc.) which led to the current state of the launcher.
I regularly install and uninstall the league client on Mac based on how I play that game (require fresh installs to raise the playing cost) and their client really sucks. Even freshly installing it, the client inhibits and hijacks mouse clicks from the full screen game when it's open. It took me months to figure out I would have to minimize the game, open and minimize the client (separate app) open, and then clicks would sometimes properly return.
Before that I was closing both and playing a game of roulette. By the the time my game was working, I may have already been reported for being afk and the game ended. Edit: other bugs have included starting to download the game and then signing in afterwards (their UI doesn't stop you) and then download progress disappearing, perhaps hanging, and you having no way to know it for a 40gb file unless over an hour has passed and you check disk size and then realize the client doesn't know how to load it. Start over and do a fresh install again, clear cache etc because their cache of the client still thinks somethings being downloaded even though it's not. Also having chat permanently off, results in weird glitches with friends requests and being unable to add new friends.
Horrible experience. But since the game is so optimized for addiction and dark patterns these days, and sunk cost, its a game I find myself returning to every once in a while.
I doubt the benefit. Practically every Electron app on a desktop uses different versions of Chromium and many are very out of date because of the risk of breaking when upgrading.
People build web apps for an array of browsers and huge ranges of versions. I think if you started using some tech to deploy an end user program and knew from the beginning the browser could be updated beneath you it would work just fine. But if you start with a golden version of Chrome and put off updating for too long you’ve let yourself get too comfortable.
> People build web apps for an array of browsers and huge ranges of versions.
en masse they don't. They just target the latest Chrome
I agree and disagree, you can't target everything, but most (not shit) devs will target at least Safari - 1 or 2, simply because the iPhone market is too good to miss out on. And Safari being, well, Safari, means targeting that is a pretty safe bet for anything else.
Depends on the region, no one where I work has an iPhone or a current Mac, so stuff gets tested on FF and Chrome, and Safari gets thoughts and prayers. We would test on Safari if it were simple, but alas.
Skipping testing on 15% of all devices to save $600? Sounds like a poor business decision.
15% of devices is not 15% of users. From my own experience having a web app that is 99% desktop windows users, why would I care about safari?
De facto they do because functionality built three years ago and tested then is running along side functionality they built yesterday and tested on today’s Chrome.
People also do seem to test on iOS Safari because that pain in my ass needs special care on my software. So if a site works on it they either got lucky or tested on an iPhone. It’s generally only other people’s weird tech demo stuff that doesn’t work.
Web devs are used to their target being evergreen, so I suppose you could opt in or out of that model: "just give me what you got".
True for this decade, but in the previous decade it was very much the opposite. Before you used any kind of browser api or nice language feature you would feature-detect it:
if (typeof Array.prototype.includes === ‘undefined’) { …
request.then(response => response.json())
> Web devs are used to their target being evergreen
I would think/hope web developers are used to “just give me what you got”. Any other mindset leads to “you must install <browser> to see this site”.
It’s Electron devs that are used to that.
I love how we’re now reinventing the browser as a much worse version of itself. What if instead of one or two general Web browsers we make everyone install 10 random versions that can only open one website?
> Web devs are used to their target being evergreen
Since when? The browser landscape is much better today than 10 years ago, but no web dev worth their salt assumes anything about the user agent.
I'd prefer if it just used the system webview rather than downloading and managing an embedded browser itself. Webview2 on Windows for example.
> Small by default, full Node compatibility. The default WebView backend uses the operating system's own webview for small binaries
That appears to be the default, CEF is available if required (hint: it shouldn't be).
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.
Wouldn't that just be "Raw"? I.e. start a webserver and ask the system to open the URL. There is no "special stuff" to do in this case like avoid sockets in favor of IPC to a well known webview or package CEF and no real integration to make with dev tools etc after - it's just open socket and serve from prebuilt binary.
> 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.
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...
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.
> 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).
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!
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.
You may be thinking of having messed with a 3rd party/unofficial solution in the past, Deno Desktop is new and only just this last week showed up in the Canary branch.
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/
> 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.
That is not why people use Electron. The goal is not and never was to just be a "UI toolkit" and "adopting UI patterns from their host OS".
Chromium has so much stuff packed into it, its insane. All that utility comes with Electron. And that's a good thing.
If you ever worked with video, for example, you know that having the full power of a modern browser in a desktop app is a game changer. Video playback (not to mention transcoding, which is also possible with modern web and webcodecs) is a complex beast, implementing that yourself is massive undertaking, not to mention in a desktop app that is supposed to work on win/mac/lin. I've built apps with Electron in tens of hours that would otherwise take me tens of days or more (and thats with AI because I'm not a video expert).
gstreamer is not that complicated
Last time I checked there's a small industry of gstreamer contractors, so it's not that simple.
It has a really really crappy security record, though.
Those issues are typically from the decoding libraries you choose. Which could even be ffmpeg if you wish. GStreamer just provides a nice high level API.
chromium is basically operating system at this point, it lacks kernel and ability to boot independently (added in chromium os), which is both good (from abilities standpoint) and bad (when copy of chromium is bundled with every app that renders webform with text field and button and nothing else)
when it goes about using webapps as desktop apps, native PWA support should be used, it would - in theory at least - lessen most issues electron apps have but will need extra effort and that's why we can't have nice things (like RAM free for other tasks)
> chromium is basically operating system at this point
I get what you're trying to say, but Chromium is far from being an OS. What you could say is, Chromium is as complex as an OS, or is replacing the OS in providing functional libraries atop devices (OS-provided application framework, if you will).
You are correct. Notwithstanding, people have been expressing the gp's sentiment for like a decade now [1] as is evident in this sub-thread [2], so it's a losing battle trying to prevent people from making such comparisons.
1: 24-core CPU and I can’t move my mouse https://news.ycombinator.com/item?id=14733829
2: https://news.ycombinator.com/item?id=14736498
> Just as a data point - Chrome has more code than the linux kernel -
> It's an operating system (pretending to be a browser).
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'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
Blitz (https://github.com/DioxusLabs/blitz) is exactly that. It's a new custom browser engine supporting standard HTML/CSS with a native Rust API (and optional integration with Dioxus which is a React-like UI framework in Rust). Baseline binary sizes are around 10mb.
We share a few components with Servo (Stylo the CSS engine (also shared with Firefox), and html5ever the HTML parser), but we've built a bunch ourselves too: notably we have our own layout engine, DOM tree and event handling. Servo is unfortunately tightly coupled with SpiderMonkey, and there is little prospect of removing that dependency in the short term.
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.
There’s a point where it stops scaling in the browser, whether it’s due to scale or poor practices. For example Slack is annoyingly slow to start up and work in my FF, but works OK as an Electron app.
This is pretty much what Tauri solves. It re-uses the systems WebView. So the built apps are tiny (kb to a few mb)
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.
Dioxus seems to be 'just' another way to generate HTML on the desktop. Electron but Rust? Is there a legitimate upside there?
We now also have a custom GPU renderer (Blitz), which makes Dioxus more comparable to Flutter or the other Rust GUI toolkits (GPUI, Iced, etc).
With Dioxus, program logic compiles to native code instead of running it through a JS engine, and it ships its own HTML renderer (Blitz) instead of bundling a whole browser. So it's a lot more lightweight and performant than Electron.
As a minor bonus, the live-reload is also faster than what frameworks like React do. It truly has subsecond latency, which isn't exactly a game changer but is nice when iterating on visual details of an app.
Sounds similar to Wails. It does the same but with Go instead of Rust.
For me it's not stable. After they change their renderer from one to another it freezes for me from time to time. But on the other hand I'm running Nvidia on Wayland so I feel no hate towards Zed owners - and restart is super quick ;)
Interesting, I'm on Nvidia in Wayland most of the time too and haven't had single freeze or crash in a very long time. Even the Windows is running inside the Qemu.
What DE? I'm on KDE.
> basic features like accessibility is missing but I'm sure it will be implemented soon.
Accessibility implementations frequently are more complex than the entire UI drawing bits. Most custom UI toolkits never implement accessibility, even decades after creation.
That hope is misplaced.
I agree about the complexity, but the core developers understand that the accessibility support is crucial and that's where my hope comes from.
That's good news, but I would continue the timer there. That issue is from March 2023 so the counter is at 3 years, 3 months. Let's see if they have anything decent before 10 years.
Looking native has long left the station as an objection about a UI.
Like 25 years ago. Nobody gives a damn since Microsoft stopped giving a damn.
I'm not part of the Apple world, but I thought they gave a damn?
Depends on the tool. We (mac people) tend to prefer native toolbars and settings menus, but I would say the days of relying on a "native" textarea or button are now behind us.
The other thing I find most Mac people appreciate is a shared understanding of hotkeys and if your app goes against the norm, one of the first feature requests will be to add configurable hotkey support.
Unfortunately, Apple has dropped the ball with their newest native apps in regards to UX and it will take years for them to go back and improve things. The new OS this fall is aiming to start that process, but it will still be a band-aid in some respect.
Nah they stopped caring as well. Developing an application for macOS is hell nowadays. I hate the state of things but both Apple and Microsoft dropped the ball. Linux is even worse, so yeah I don't see a reality out of this unless we actually create something that surpasses the web in all measures.
> 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.
Consistent like what? Like maybe a decade ago one could say that osx was consistent, but nowadays even SwiftUI and cocoa is visibly different, let alone every second app that uses electron. And people don't care.
Windows has like 4 frameworks available on a bare new, latest OS install, just go deep enough in the "settings" or whatever they call it, and you can reach down to winforms. And on top the start menu is a react element!
(And in Linux you have the gtk and the qt world, and everything else)
> SwiftUI and cocoa is visibly different
Do they render different looking buttons?
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 have seen users having trouble with pixel soup UIs. They may not think "This should be in a native toolkit", but they do think "How the hell do I subscribe to a folder in the new Outlook?".
Right, but bad UI's was not uncommon before webviews, if anything the spartan-ness of the web often simpified patterns whilst reliance on weird hotkeys in desktop apps isn't uncommon.
>reliance on weird hotkeys in desktop apps isn't uncommon
The only examples I can think of are actions that are intentionally not easy to reach. How exactly it's done is platform-specific, but the (mis)feature doesn't come from the platform and can be implemented in other ways on other platforms.
- Apple UIs hide some power user functionality behind obscure hotkeys
- Similar: Shift-Delete to permanently delete (Windows, KDE) - Similar: Shift-right click to "Open With..." (Windows, KDE)
- In desktop apps that FOR SOME REASON try to look more like web apps, the hidden menu bar can be restored with Alt or Alt-M (Firefox, KDE)
The problem in these usability cases is pretty much always layout and constant redesigns rather than the exact theme the button has. I've seen plenty of unusable native ui soup UIs and very clean and simple custom UIs.
You could call it the exact theme when a clickable UI element looks just like regular text (it was not inside any kind of button-like shape in the Outlook case that I saw), but it's super common to have that in web-based UIs.