Comment by leleat

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.

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.

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.

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

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’) { …

And if it wasn’t there you would define it yourself, it was called “polyfilling”. This was so commonplace that we built significant tooling like babel to standardize feature detection tests and fallback implementations - for a few years you could write

    request.then(response => response.json())

And behind the scenes the Rube Goldberg machine would turn this into something that would run in a JavaScript environment that had neither arrow functions nor promises.

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