Deno Desktop apps
42 points by geoffb
42 points by geoffb
Small by default, full Node compatibility. 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. Opt into the bundled Chromium (CEF) backend when you need identical rendering across macOS, Windows, and Linux.
Sounds less bad than Electron, but please just use native toolkits and embrace the platform’s capabilities and differences.
"Just" is a comically load-bearing word there. It takes a lot more resources to embrace each platform and you'll likely end up with fewer platforms supported overall.
You get the similar trouble with devs then who are either unable or unwilling to actually support platforms like Linux.
The amount of Electron-like projects that advertise "cross platform support" but then use WebKitGTK (notorious to have various rendering issues, no shade to the maintainers, they're doing their best) makes me want to claw my eyes out.
And none will call either the framework projects or the downstream devs out on it because they can just pass the buck back to the library. I'd rather you just use Electron if you can't do native, it mostly works and the rest of issues are well known.
People got blinded into believing that Electron applications are a curse and eat all their memory. But I think we should be thankful that it exists as otherwise, maybe we wouldn't have gotten as many apps on more "niche" platforms.
If you're embracing something like this, you probably never even cared about performance, being native, or even security (to an extent since doing javascript at all will very probably mean interacting with NPM and the terrible javascript ecosystem).
The amount of code surface required to run an electron app or any web app as a make-believe desktop app is gargantuous. The fact that this is normalized should be feared not embraced.
Looks like there is also a "raw" backend that lets you do the gui stuff yourself. I'd be curious to see if that can hook up to something like gtk on my Linux machine.
What's particularly interesting is that WebGL/WebGPU are mentioned in that context… so it would be potentially really cool for porting web games to desktop, skipping the web engine entirely.
Yes! This is the most interesting aspect for me as I'm very keen on the idea of TypeScript + graphics API binding for games and don't care as much for DOM, etc.
There have been Gtk bindings for Deno for awhile at this point, and they worked well. (In fact, the only issue I remember hitting at all was some text encoding issue that ended up being a PEBCAK on my end.) I didn't do anything serious with them, though, because the resulting bundles were something like 120 MB. That made it dwarf even Python Gtk apps, which (for me) defeated the point. I doubt deno desktop improves much there, but it shouldn't hurt, either.
It sounds a bit like Tauri, where, AFAIK, you can also embed node in the Rust backend. Hope they're at least providing enough shims for the desktop integration beyond the window, e.g. media keys/status, menus etc.
And yeah, I wish people would do more native stuff. But apparently even the vendors do more and more web-tech stuff. Either because they can't find developer willing to "taint" their CVs with MFC/Cocoa or because their human and/or robotic overlords tell 'em so.
I used to have the same sentiment, but slowly shifted away from it as especially GTK gradually became worse. Qt is okayish but somehow there are very few toolkits that don't explode in scope. And when I learn that not even tray icons are simple anymore and have issues outside of whole desktop environments it's quite saddening. We talk about things that were a given 20 years ago.
Electron is a mess but maybe the "not exactly a browser" and "not even a webiew" solutions still allowing for something like HTML and CSS bring a much needed fresh breath.
Also a bit sad that TK and wxwidgets don't see much use.
Somehow the developments meant to make things easier seem to have led people to run whole - often outdated - browsers, but I do think at least part of it is that existing native toolkits turned into a mess. And I know it was all good intentions. I will choose any native alternative over an electron app every time, but when they struggle with simple use cases for both devs and users... well, you can have that with electron too.
But I'm excited about every new approach and if the way is to remove as much of the bowser as possible then I think the direction might be a good one.
No thanks, that might be good for techy purism but results in worse product every time. I love this pragmatic approach that we are seeing here. I'm tired of Linux tools looking like they are the Dollar General knock-offs of real applications, I want the tools I spend hours staring at to have good design.
There’s a bit of bait-and-switch here. At first they’re all “small by default … OS's own WebView for small binaries … or opt into the Chromium backend”. But later in the feature comparison they’re treating the Chromium backend as the default and touting its compatibility and in-process transport. While in the fine print it seems that backend has more size overhead than Electron (150MB vs 100MB, per the chart.)
Just tried it with a small web app that still works fine locally on Deno 2.9 but the deno desktop index.ts throws type errors which I find a bit odd. Adding --no-check fixes that.
Then it downloads 125 MB of stuff (on a mac) and builds correctly. I get a window with a web view that seems to do its job. The resulting blob (.app dir, really) is 296MB, the original source code was 400 LOC (the HTML output of the single page is like 50 lines, it's not an "SPA"). Memory is at 70MB.
So it seems better than electron at least, but I'm a little unimpressed. Your app can't get more basic than this, it's a hello world on steroids.
In-process bindings instead of IPC. Backend and UI communication goes through in-process channels, not socket-based IPC. Values are still encoded as they cross the call boundary, but there is no cross-process round-trip between your Deno code and the webview.
That's actually a really nice feature and concrete improvement over Tauri. Not every application is a web browser, sometimes you really do want to tear down the walls between your app and view...
As someone who worked a long time making intranet web apps looks more like desktop apps (ExtJS especially), I'd be interested to know what people consider to be showcase web GUIs – preferably something closer to traditional form-based elements for comparison's sake, not basically "chrome-less" things like Miro. Figma? VS Code? Teams?
I either see a lot of "programmer GUIs", just replacing Visual Basic with something bootstrap-ish, or material design (which seems half way between web and "proper" GUIs, "thanks" to the general design on one side, and lots of library support on the other).