Get the top HN stories in your inbox every day.
leleat
tonyedgecombe
In case anybody else wondered CEF is the Chromium embedded framework.
echelon
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.
jakelazaroff
This point of view always confuses me, because web developers already need to deal with platform differences. Especially if your app app also runs in a browser, like Slack and Discord — at that point, what issues do the differing system webviews cause that you don't need to deal with anyway just targeting browsers?
It's also funny to me as someone who's been building websites for 20+ years at this point, because the platform differences used to be much, much worse. Coincidentally, I just saw this article, which makes the case nicely: https://www.bram.us/2026/06/21/do-websites-need-to-function-...
synchrone
Regular Tauri app (aptakube) user on linux here: the experience is very adequate and smooth, I have no complaints. Speed benefits relative to Electron (similar app: K8S Lens) alone are enough to deal with many possible issues.
Could be attributed to app developers going the extra mile, but I suspect it's the framework choice.
DanielHB
> It seems great to be able to cut hundreds of megabytes out of your app installer
Your points are valid, but the big upside is that the default system webview is very likely to already be loaded in memory before your app starts. And if multiple apps use the default system webview all of them will load that same dynamically linked binaries only once.
I don think the RAM savings are that significant on modern systems, but it greatly speeds up app first-loading times.
oooyay
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.
cdud3
Or use QtWebEngine which uses Chromium under the hood, provides a stable and rich API and enables sharing rather then bundling the browser runtime + is Cross-Platform + security updates are handled too.
FooBarWidget
Web developers already have to deal with different browsers, versions and API coverage.
jauntywundrkind
Tauri's cef-rs is indeed quite good. I think it's available, ready, works: it's just that there aren't many folks using Tauri and only a fraction of them are aware/interested in exploring further. https://github.com/tauri-apps/cef-rs
Huge fan, this should definitely be the default. The user experience is incomparable.
One thing I'd like to verify: can the OS effectively use shared mem for cef across multiple different cef-rs apps? I really hope so. In this time of RAM being scarce, this optimization could be such a benefit.
v3ss0n
LOL , then back to electron. I raised that since day one of Tauri.
kodablah
I used CEF for a project and Google is detecting CEF via some opaque algorithms and not allowing logins from it. From https://security.googleblog.com/2019/04/better-protection-ag...:
> 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.
iancarroll
Most apps (on desktop or mobile) open third party auth flows inside the user's default browser, which makes this a non-issue. For one, if you embed the Google login flow into your app then I can't reuse my existing session in my browser. But it also exposes my full credentials to your app for no reason, which is a good thing to avoid.
qbane
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.
teaearlgraycold
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.
qbane
You could, but by targeting a specific Electron app the mindset would be much simpler. Just take a look of how many times does the dev behind VS Code decide to upgrade their Electron/Node.js version, and how many breakages due to them.
It is all about unknown unknowns.
troupo
> 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
Lucasoato
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...
chmod775
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.
gavinray
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.
crustaceansoup
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.
megacelebi
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.
atombender
Also Spotify. I believe Spotify was one of the earliest adopters of CEF, maybe the first major adopter?
The desktop app was originally a native C++ app, but they switched to CEF around 2011-2012. (It caused a very noticeable drop in performance!)
NekkoDroid
Both Steam and Battle.net use CEF for their UI as well. And IMO they are on 2 ends of the "nice to use" from the implementation side (Steam being a sluggish hell and B.net being nice). Though then again B.net is only for Blizzard games, so they can also optimise for the limited set games.
socalgal2
> Steam being a sluggish hell
news to me. Been using steam since it launched. Never noticed it being sluggish
mannanj
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.
lwansbrough
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".
Someone
> 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.
coffeebeqn
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?
fwlr
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())
lopis
> 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.
DanielHB
Oh god I feel OLD reading this.
deeringc
I'd prefer if it just used the system webview rather than downloading and managing an embedded browser itself. Webview2 on Windows for example.
jitl
> Small by default, full Node compatibility. The default WebView backend uses the operating system's own webview for small binaries
andrewaylett
That appears to be the default, CEF is available if required (hint: it shouldn't be).
undefined
v3ss0n
A strip down version of electron TBH.
sheept
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...
tomComb
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.
sheept
That is true. I wonder if it could be possible to let the user supply and wrap the app around their own, trusted installation of Deno (rather than the one bundled in the app) to specify permissions.
minraws
Why not run it in a vm or container instead then, it seems a bit much imho.
hdjrudni
Then do `deno ./my_downloaded_deno_gui` instead. If you trust the copy of deno you downloaded, then hopefully it can be trusted to verify the permissions of random downloaded deno-apps.
Yes, it kind of defeats the standalone binary aspect but if you're really concerned about security, maybe it's a happy medium.
porridgeraisin
> 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).
40four
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!
liamgm
yes the big win from this is the Node API / NAPI support , if you write node_modules in nodejs , electron , raycast , edgejs you can reuse it .
https://wasmer.io/posts/edgejs-safe-nodejs-using-wasm-sandbo...
"NAPI allows native Node dependencies to target Node without actually depending on a specific version of Node or V8. NAPI abstracted the V8 JS engine away, by providing JS-like APIs for: creating an object, declaring a property, etc.
NAPI is the contract that all modern native Node modules use to interact with Javascript." [1]
1: https://wasmer.io/posts/edgejs-safe-nodejs-using-wasm-sandbo...
esperent
I'm still using node/npm and it's... fine. Every so often I read these posts and think I should change but node/npm is already a low friction part of my workflow.
However, what I have seen is that a lot of other libraries I use have switched to Bun. I haven't seen any that switched to Deno, and so I've been under the impression that Bun is becoming a strong node replacement candidate while Deno is not, or at least that the community is making a strong preference for Bun. Anyone have more insight into this?
solarkraft
This is a smart thing to ship. For me it would totally be a consideration when deciding on a platform to use.
sjeno
agree, small footprint & cross-platform looks like a nice alternative to electron or tauri..
franz899
Their comparison page shows some savings, but not in every case (~40 MB / ~150 MB) https://docs.deno.com/runtime/desktop/comparison/
merelysounds
To be fair the ~150MB is for the CEF scenario (when chromium gets bundled); and eventually they want to introduce a shared CEF runtime across apps.
bobajeff
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.
zamadatix
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.
bobajeff
No. As I understand it, the Raw backed just gives you a Window with input handling and you have to embed something like Skia, WebGPU for the graphics. So basically you have make your widget library yourself.
Now you can just start a server with deno pretty easily and serve a website. But WebUI will actually also manage opening the browser window for you as well a make the communication between backend and frontend just like using a Webview or electron.
zamadatix
Raw still exposes access to Deno APIs & ability to call native code but it doesn't seem to assume it should give you a window out of the box or anything based on my testing (AFAICT you have to orchestrate most all of that yourself, Deno just won't get in the way with packaging other stuff like CEF automatically). If this is just some issue on my machine with the canary build though, the existing "Deno compile" should accomplish the same goal for a binary version without any GUI components at all.
Outside making it so you don't have to call to open the link yourself, I'm still not sure what could be integrated in the scenario. Deno can integrate with WebView because the WebView APIs were designed to allow external applications to have full control of the session. CEF (the Electron-like) approach works because Deno packages CEF & the APIs as part of the app itself, having even more control of everything. Browsers are meant to be in control of themselves or the user, and have had a long history of fighting malware trying to act otherwise.
echelon
> 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.
c-smile
I think that my Sciter is better option when you need HTML/CSS/JS native application running on Windows (XP and beyond), MacOS and Linuxes.
Sciter SDK [1] contains scapp[.exe] - standalone Sciter engine that can be attached to HTML/CSS/JS bundle making standalone (single exe file) and portable executable. https://quark.sciter.com/ tool allows to compile such apps.
Size of "hello world" is a size of scapp.exe binary + size of compressed HTML/CSS/JS bundle.
On Windows scapp.exe is of ~14 Mb. On Linux ~18 Mb.
Linux version at startup detects GTK4, Wayland or X11 and uses those as windowing backends.
On all platforms Sciter provides out of the box: HTML/CSS/JS runtime, libuv based Node.JS alike runtime, GPU accelerated rendering, WebGL 3D runtime, JS built-in persistence (NoSQL DB).
It does not have TS compiler built-in as Deno, but that TS-to-JS compiler is better to be outside anyway as it is used only once - at app loading.
shunia_huang
While I'm trying to take a test it seems too much to start a Hello world application, or just to bundle my existing "dist" folder of a part time project.
Is it possible to install some tool, and give it a "dist" fold path and the application is generated all alone?
I'm stupidly lazy, and I hate work with graphical UIs to start a project and input that many fields, make me feel like visiting a 1990 web page requires me registering with tons of information and most of them are useless or at least I can provide later if needed.
bel8
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.
znort_
>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.
this is misleading. there is no "running true ts". you will always be running pure js (until someone actually develops a "true" ts engine), and deno does "type stripping" just the same. the only difference is that it bundles the tools and makes it transparent and config-free which is more convenient (although more rigid).
icholy
[dead]
aabhay
Tauri doesn't lock you in to one JS ecosystem. In fact, it doesn't require you to use javascript at all.
Also, we've had several developer framework startups get acquired -- Astro, Nuxt, UV, Bun, Vite. It doesn't exactly inspire confidence in a software that you want to last and give support for years.
thephyber
I don’t understand this logic. The acquisition doesn’t guarantee the project dies and staying unacquired doesn’t guarantee the project continues.
The state of OSS funding is precarious. The acquisitions at least guarantee some runway for the maintainers. Maybe the acquirer has alternative intentions than to simply bankroll the project’s the way it was, but at least someone is paying to keep the maintainers fed.
After having worked in the JavaScript ecosystem for over a decade, I don’t think _any_ project of significant size is guaranteed to last or have support. We need to be thinking about resilience (_when_ the framework stops being supported), not pretending like using OSS projects without paying them should magically give you some support contract/assurances.
flohofwoe
Deno also just strips the type annotations when running TS code - at least by default. To get type checking you'll need to run via `deno run --check`, or use the separate `deno check` subcommand. No big deal since type checking and linting usually happens automatically in the IDE during development.
bel8
Good to know. Does it also preclude features like enums?
Timon3
Huh, I was going to mention Node's `--experimental-transform-types`, but that was completely removed in v26: https://github.com/nodejs/node/pull/61803
bartlomieju
Bartek from the Deno here. Nope, we do support enums OOTB.
farco12
If you want desktop and mobile builds.
Tauri 2.0 added support for iOS and Android builds as targets.
jpace121
> Why would I use Tauri now?
You’re “backend” isn’t JavaScript.
jemmyw
> Deno can run true TypeScript directly and not just strip types
What exactly do you mean by that? Because no js engine carries the ts types into the runtime as far as I know. Deno and nodejs both use v8 as the runtime. v8's internal types are not connected at all to the ts types regardless of the wrapper. The only difference might be when/if static type checking is performed.
steve_adams_86
I think they mean deno handles transpiling for you so there’s no visible machinery for this aspect of the program. It’s just convenient.
jemmyw
I assumed they meant more than that because nodejs does the same since v22.18 and prior would do it with a flag. But they mentioned type stripping, which is really all transpiling of ts does for most code.
callc
Temporarily at a place with 10-15 mbps. 150 MB is around 1 minute.
I grew up on 30 mbps. >= 100 is all I need nowadays.
But 10 mbps and websites and downloads really start to take a while.
The more bits and bytes you save, the more people will be pleased with your stuff! Even if they don’t know what bits and bytes are, and just go based on impatience
swiftcoder
> and you get a reliable rendering engine
How is it more reliable than Tauri - aren't they both using the system webview?
bel8
Deno Desktop can bundle CEF (Chromium Embedded Framework) according to https://docs.deno.com/runtime/desktop/comparison
fiatpandas
Deno desktop can use system web view OR embed CEF. Tauri is just system web view.
aabhay
The benefit of Deno Desktop is it's like Tauri except for when you want it to be Electron???
qudat
> 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?
billywhizz
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...
billywhizz
also notable that deno has a very low overhead bindings layer for doing JS->C/C++/Rust/Native interop using v8 fastapi calls where possible.
whilenot-dev
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...
jankiel
this is what I wonder as well.
jorisw
> 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.
Culonavirus
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).
Levitating
gstreamer is not that complicated
veltas
Last time I checked there's a small industry of gstreamer contractors, so it's not that simple.
TylerE
It has a really really crappy security record, though.
kiicia
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)
taffydavid
Chrome OS is literally an operating system that's 90% through chromium
ignoramous
> 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).
conradludgate
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
noufalibrahim
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.
wiseowise
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.
djxfade
This is pretty much what Tauri solves. It re-uses the systems WebView. So the built apps are tiny (kb to a few mb)
nicoburns
> 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.
fireant
That's really nice. It would be really good for game GUIs too where the situation is quite poor and would work well with underlays/overlays/worldspace UIs. That said while binary size may be around 10mb, it still baloons to 500mb at runtime for your TODO list example which is more than some electron apps.
loaph
This isn't exactly what you were suggesting, but it made me think of https://hacks.mozilla.org/2026/02/making-webassembly-a-first... since that article is about not needing to go through js to use wasm.
Abishek_Muthian
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.
fny
Live reload. GUI development in compiled languages is a pain compared to web development.
eklavya
Try dioxus, it has live reload but it's a work in progress.
oblio
> 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.
Abishek_Muthian
I agree about the complexity, but the core developers understand that the accessibility support is crucial and that's where my hope comes from.
soanvig
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 ;)
Abishek_Muthian
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.
smackeyacky
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.
vintermann
I'm not part of the Apple world, but I thought they gave a damn?
yurishimo
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.
jabwd
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.
DonHopkins
Liquid Glass says no, they don't give a flying fuck any more.
DonHopkins
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?
jorisw
Basically you're saying websites are the same as apps, and whether they're used in the browser or as a desktop app, the UI is fine to ditch that of the OS. Fine if you think so. I'll be sad to see OS and apps diverge completely in terms of UI.
d12bb
YouTube succeeds for its content. Its UI is hot garbage both in the web and their apps. Google Maps is an atrocity and I’m very thankful Apple has decent data where I live. Roblox I don’t know, other websites I consume mostly in Reader mode.
m-schuetz
> 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+.
jorisw
That's an advantage to you. Not necessarily to your users.
m-schuetz
The alternative is not that users get a UI specific for their OS, it is that users get nothing since I do not have the resources to develop for multiple systems. So yes, it is also an advantage to users.
Klonoar
Users don't actually give a shit.
This is a techie complaint, and that's opting for a charitably nice description.
utopiah
> 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.
jorisw
Consistency is a large factor in any good design, UI design more so.
Gigachad
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.
gf000
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)
DonHopkins
A foolish consistency with terribly designed shallow superficial desktop user interfaces dreamed up by overpaid cocaine addled corporate boutique brand designers with not only no experience but actual burning contempt for usability and human factors and accessability and affordances is the hobgoblin of little minds.
p-e-w
That’s why HN users constantly advocate for Vim, a program in which every single thing works completely differently from every other modern application.
port11
OS-level consistency is also consistency. It depends what we value. A lot of apps’ design could’ve been basic, OS-like UI. Apps such as GymBook or WhatsApp are internally consistent while still adopting many elements from the system’s design, instead of reinventing the wheel.
eterevsky
Within OS consistency is much less of thing a thing than Web design conventions. Windows by itself has had several different UI frameworks over the years, so different "native" Windows programs can look completely different from each other.
oneeyedpigeon
There are two types of consistency in this context: consistency within an OS and consistency across them. I, too, prefer the first because I only really use one OS, but this preference varies. I don't think it's right to say that the first case = "ui toolkit", but the second case doesn't.
m-schuetz
Consistency is the reason why Electron is great. Consistency of the UI across operating systems.
pjmlp
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.
gf000
Which native framework?
Even in a "post-vibe code" era I wouldn't want to create multiple versions of the same app, and none of the "platform-native" GUI toolkits run on everything.
SwiftUI is apple-only, gtk has pretty bad compatibility on non-linux, qt is decent but requires C++ or python, and even so still not much for mobile. Don't even get started on "Windows frameworks", because as I write this sentence they may have left a new one in the ditch.
Flutter may be the closest, but why didn't they go with e.g. Java instead of a new language?
So yeah, if you want a truly universal UI then web is your best bet.
jorisw
> if you want a truly universal UI
Right. If you want your app to look the same, custom way, ditching what the OS has to offer.
Some developers still believe an operating system has useful UI components and patterns worth adopting. From this thread it's clear that there's plenty who don't. Personally I view that as a regression.
gen2brain
How about something like this https://github.com/gen2brain/iup-go? Still not released, but I plan to clean all todos in the next few weeks.
ogoffart
one missing from that list: Slint, which i work on. runs on Linux, Windows, macOS and embedded, with app logic in Rust, C++, Python or JS.
You can use JS but it doesn't ship a browser engine, it renders with its own lightweight toolkit.
pjmlp
The one which OS has to offer.
Web is bad everywhere outside of the browser.
kajman
I never thought I'd defend Electron, but I'd rather use the bloated web UI than a vibe coded Qt/GTK version I'm positive will not have seen any human QA.
DonHopkins
But GIMP! /s
ThatMedicIsASpy
When I can modify my desktop/theme (KDE) with css I will happily start doing it since that sounds easy.
d12bb
Styling every application independently because it’s all individual Electron UI without a shared toolkit is much better indeed…
m-schuetz
I have better things to do than spend my time adopting UI for various different systems. If Electron gives me the option to easily create a UI that looks the same everywhere, then I'll pick Electron over anything else any day.
LtWorf
I'm completely sure your software is an accessibility nightmare.
doodlesdev
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.
eric-p7
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.
lillesvin
As much as I like cross-platform stuff, I also really like native UIs that follow native UX patterns, etc.
poisonborz
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.
mohsen1
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.
hbn
The issues with the ChatGPT Mac app could also be reflective of the state of Swift UI considering not even Apple themselves can ship Swift UI apps that aren't janky.
https://daringfireball.net/2026/06/swiftui_only_makes_it_eas...
LtWorf
Did they run out of tokens? Why don't they ask their agent to update the mac version?
deely3
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.
kuekacang
Isn't all uses native OS UI widget? But since the brand need to be experienced the same across platform, it overrides the native rendering and use custom styles instead.
nicce
> As far as I know there no web engine that use native OS UI for rendering.
That sounds like a monster I would be afraid to touch.
auraham
For me, the best about Tauri is that:
- We can embed an existing application using a sidecar [1].
- Now, we can also use Elixir in the backend, embed the BEAM, and deliver a single binary, see ElixirKit [2].
As far as I know, LiveBook Desktop [3] is using Tauri for building binaries for MacOS and Windows. If Tauri works for the Elixir team, I think it works for me too.
Also, I know that Tauri is not bullet proof. WebView can be limited for some use cases, see [4]. There is some effort to use CEF to mitigate those problems, though [5].
I'd like to know how Deno Desktop compares with Tauri in this context. I know it is a new product, not sure if we could bundle an existing binary in Deno Desktop, like in ElixirKit.
[1] https://v2.tauri.app/develop/sidecar/
[2] https://elixirkit.hexdocs.pm/tauri.html
[3] https://github.com/livebook-dev/livebook/blob/main/rel/app/t...
gabeidx
There's a comparison page: https://docs.deno.com/runtime/desktop/comparison/
And you can embed anything on the binary with `deno desktop --include […]`.
krawcu
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
bartlomieju
Thanks, I'll update the docs. When we wrote them a couple weeks back, Electrobun was announcing Linux only support.
Get the top HN stories in your inbox every day.
> 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?
[0]: https://docs.deno.com/runtime/desktop/comparison/