Hacker News

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.

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.

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.

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.

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.

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.

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.

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.

> 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.

> 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).

Ah, that's a new systemd module now.

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.

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.

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.

[1] https://gitlab.com/sciter-engine/sciter-js-sdk/

Their comparison page shows some savings, but not in every case (~40 MB / ~150 MB) https://docs.deno.com/runtime/desktop/comparison/

gstreamer is not that complicated

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)

> 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.

Live reload. GUI development in compiled languages is a pain compared to web development.

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 ;)

> 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'm not part of the Apple world, but I thought they gave a damn?

Consistency is a large factor in any good design, UI design more so.

That's an advantage to you. Not necessarily to your users.

> Make it a PWA if you want it in its own window.

Seems like I'm part of a shrinking minority (in this thread at least) who believes that web[sites/apps] in a browser, and apps running on the host platform, are different things in terms of UX expectations.

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.

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.

When I can modify my desktop/theme (KDE) with css I will happily start doing it since that sounds easy.

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.

I change clothes all the time too, still match the pieces of clothing each time.

There's aesthetic value to coherence. There's also design, usability value. I have Telegram, Steam and Firefox opened right now and each one of them displays different minimize/maximize/close buttons on the top right. That's not ideal.

Change over time is something different from apps looking vastly different at any given time.

I have used Blender just a bit, but it was very jarring when I first opened it and discovered that it has its own menu bar within the window, rather than at the top of the screen. It has its own save/open window rather than using the system-provided one, as nearly all truly native Mac apps do. I doubt most Mac users like this.

I have somewhat more experience with QGIS. It has a standard Mac menu bar, but the icons are inelegant and Windows-ish, window layouts are Windows-ish, dialogs don't behave correctly in Mac full screen mode. It could use a MacOS glow-up.

I think Visual Studio Code (native menu bar, native save/open, but a core UI kind of unto itself that is consistent across Mac and Windows) does a better job of balancing cross-platform vs native.

And then there's the approach taken by Adobe and Microsoft Office. These apps do a much better job of adopting native platform appearance and conventions (sometimes at the expense of application consistency across platforms).

Tauri is a good way of packaging offline PWAs. It kind of sucks for building proper applications. The entire model for integrating with a local backend is just bonkers (no, I don't want my local application to pretend to be a web server - it's not a web server, I want to give you actual host bindings and share memory).

Indeed. Even Qt isn't native, in the most purist sense.

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.

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.

Good to know. Does it also preclude features like enums?

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.

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.

Yes, thanks.

It's all so bleeding edge right now. It also depends how deep you want to go. An increasing number of languages support wasm as a compile target, which is helpful.

Bytecode Alliance do semi-regular streams on Youtube. I think reading (recent) material on WASI (0.3) and the Component Model would be a good start.

Understanding the relationship between a host and a guest is valuable. Learning what wasmtime is and how it works is also illuminating: https://docs.wasmtime.dev

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.

> 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.

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...

Did they run out of tokens? Why don't they ask their agent to update the mac version?

Java may be good, but it's boring. No joy comes from programming in Java.

I need to enjoy my work to be engaged and productive.

I have nothing against java. But for some reason in my experience all the developers using it are low quality, and gave it the reputation it has.

There's Compose Multiplatform if you are willing to switch to Kotlin. Only caveat is that it uses Canvas rendering on web.

We were writing and shipping desktop applications with it back in the nineties. Although many of the arguments against it were similar to the arguments against Electron today.

This works well. I’ve been using it to bundle other binaries with my applications and so far my users have had no issues on Windows, Linux, and macOS. I’m still a bit surprised given how new it is

What do you mean by that? Does this[1] not count?

[1] https://capacitorjs.com/

The docs say that's the default:

https://docs.deno.com/runtime/desktop/backends/#webview-(def...

In case someone is using something we haven't heard of e.g some are running using cloudflare workers which also has some unique runtime properties. AWS has something called LLRT.

https://github.com/awslabs/llrt

https://developers.cloudflare.com/workers/runtime-apis/

There's QuickJS, LLRT, Rhino, and GameMaker is about to get TS/JS support.

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.

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.

Thanks!

I just tried `deno desktop helloworld.ts` and the result is 442 MB. So it's not any lighter than Electron (see my toplevel comment)

Why are people parroting this meme?

For 8 years now, constantly updating to newest Electron, my Electron app has been using only about 150mb of RAM - (see Video Hub App)

In WinForms?

Is that supposed to be a challenge?

WinForms is incredibly easy and simple to use...

Doesn’t mean you should use it for new things in 2026, but for building a chat app with? Yeah, it’d be very easy.

I’d know, because I’ve done it (granted it was over 15 years ago at this point, but I’ve done it). Was used internally, with a PHP backend. Worked great!

Yes, native UI toolkits are not perfect, even though I consider Qt very close to one (I'm sure naysayers will find nitpicks). In the end, the choice is between the apps that eat 1GB of your RAM and learning to deal with some idiosyncrasies of native toolkits.

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.

Even if SwiftUI, Qt and whatever Windows uses this morning were absolutely perfect, developers would write web UI slop to not have to write three frontends. That, and familiarity with JS are the whole reason.

RE: Tauri not having cross-compile... There's a GitHub action that compiles for Linux, Windows, and Mac. So practically it does have it, just not out of the box.