Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- 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
by krawcu - Thanks, I'll update the docs. When we wrote them a couple weeks back, Electrobun was announcing Linux only support.by bartlomieju
- As much as I like cross-platform stuff, I also really like native UIs that follow native UX patterns, etc.by lillesvin
- 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.by deely3
- In practice it's much harder to maintain a native app. I am noticing this with ChatGPT Mac app vs. Codex Mac app. ChatGPT on Mac is constantly behind compared the web ChatGPT while Codex is shipping features at a much higher velocity.
Also ChatGPT hangs and has more weird bugs compared to Codex.
by mohsen1 - 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.
by poisonborz - 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.
by lwansbrough - Do you reccomend and resources for building w/ & learning about wasm?
- Do you mean "Unlike Deno Desktop"? Deno Desktop definitely relies on a browser engine.by matharmin
- Just FYI, when checking out jumpjets homepage, the white-dot airship in the background made the white text in the hero banner hard to read.
Cool project!
by catears - 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.
by doodlesdev - Deno Desktop is bundling the V8 JavaScript runtime so it can have JavaScript on the backend. Tauri uses rust for the backend and your browser's JavaScript engine for the frontend.by eric-p7
- > 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.
by jorisw - 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.
by pjmlp - > 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.
by utopiah - > They consistently miss the mark in adopting UI patterns from their host OS.
What you suggest is a disadvantage is one of the key advantages of Electron to me. I precisely do not want my things to look different on different OS. I don't have the resources to test my apps on all devices, and knowing that whatever I test on one system looks the same on another is A+.
by m-schuetz - Since when did anyone ever complain that youtube, google maps, roblox, or any other web sites didn't have native buttons and UI patterns?
Are you implying that the Windows, Mac, and Linux native desktop user interfaces don't all totally suck??! Or that there wasn't a huge celebration when Alan Dye finally left Apple for Meta? Or that users are clamoring for Jony Ive's infamous shallow superficial visual elegance over affordance and discoverability and usability?
Is it just too confusing for people to use youtube because the buttons don't look and feel exactly like native Mac buttons on the Mac and native Windows buttons on the Windows and whatever the kids are using on Linux desktops these days, therefore nobody uses youtube, and that it will only ever get popular if it just had a native look and feel?
by DonHopkins - 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.
by smackeyacky - 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.
- 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
- 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).
by Culonavirus - > 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?
by qudat - this is what I wonder as well.by jankiel
- My guess is that it's not using IPC on OS level, like D-Bus on Linux, but rather a supervisior process starts and orchestrates child processes as needed. And all these processes use a shared memory model.
Here's the CEF docs on processes: https://chromiumembedded.github.io/cef/general_usage.html#pr...
EDIT: ...and the CEF docs on IPC: https://chromiumembedded.github.io/cef/general_usage.html#in...
by whilenot-dev - from what i understand after a quick look at the source is it uses a C ABI to communicate between the WebView/CEF "host" application and the deno runtime which is loaded by the host as a shared library.
marshalling of values back and forth between the JS/C++/Rust layers still has to happen but these are just straight C api calls in process under the hood so much less overhead than having to do serdes across a socket/pipe.
- https://github.com/denoland/deno/blob/main/cli/rt_desktop/li...
- https://github.com/littledivy/laufey/blob/main/webview/src/m...
by billywhizz - 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.by bobajeff
- 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.by zamadatix
- > 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.
by echelon - 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.
by bel8 - > and you get a reliable rendering engine
How is it more reliable than Tauri - aren't they both using the system webview?
by swiftcoder