The 5th point in this article is what makes me end up using Electron most of the time.
As much as I love Tauri (and Wails), WebView requires to make sure the application renders exactly the same across all platforms. Sure, Electron comes with its downsides like the article rightfully points out. But having a UI that renders and behaves exactly the same on all platforms (thanks to the version locked Chromium bundled in the app) is really nice to have.
I wish there would be the possibility to bundle a renderer (maybe a more lightweight one?) with Tauri or Wails instead of using WebView.
Browser engines these days aren't so bad, especially if all you need from them is basic CSS for the UI. You still have a fully-fledged native language underneath it, so you're not limited to what Web APIs can do.
CSS evolves and there’s always some new funky selector or effect coming, but the whole point is that you don’t need to follow this year’s latest hotness. If you slap rounded corners and box-shadow (very old by now) you have 90% of what Apple calls design lately. For Windows “metro” you don’t even need rounded corners :)
> but the whole point is that you don’t need to follow this year’s latest hotness
You might not have a choice. Sometimes even seemingly trivial APIs/features like SVG, flexbox, or audio/video behave slightly differently in different browsers, and it's easy to sink a lot of time into debugging these differences. I'm not saying the effort isn't ever worth it, and it's certainly better now than it ever was in the past, but I think you're underestimating the amount of work it takes to properly support a complex web app across all modern browsers.
With that said, if you're just using web technologies to throw together a UI to slap on your native app that does all the heavy lifting, then sure, maybe using something like Tauri is worth it. Even then, it might not be worth the QA burden of having to test all UI changes against every supported platform, and then the support burden of getting platform-specific bug reports.
> Fyi you need to optimize for two browsers only: chromium (edge) is the webview on windows, and webkit is the webview on linux and macos.
You're right, I keep forgetting that Microsoft has switched to Blink. It's still a pain if you're a Windows dev who needs to test on WebKit. Or is there an easy way to test that these days?
> I’m curious about the svg and flexbox issues you mentioned. I have not experienced any differences with those across systems and browsers.
To be fair, the differences I was thinking of were mostly between Gecko and Blink, so they're not really relevant to Blink vs WebKit. It's been many years since I've worked directly with SVGs, but I remember there being major differences between how different browser engines interpreted masks and some other features of SVG. I also think they scaled SVGs differently. The flexbox issue I'm thinking of had to do with how Gecko and Blink handled `height: 100%` inside a flexbox container that does not have a set height. I don't remember the exact difference, but I think Chrome assigned a height of 0 to the element, whereas Firefox greedily took up all of the available space, or something like that. Like I said, it's been a few years, so take all of that with a grain of salt. I just remember spending far too much time debugging those sorts of issues. :)
I’ve been writing web apps professionally for lovely browsers like IE6, Android 3.0, and Blackberry. I know when CSS can be hard to get working. 2022 WebViews are a walk in the park.
Yes yes, I don't mean to complain. :) Web dev these days is definitely a breeze compared to the "old days". I just don't like when people assume that cross-browser testing is no longer necessary at all, because there are still differences, especially if you use any of the newer or more obscure APIs.
Same here. Depending on the type of application being built, this can be a huge downside. E.g., if you want to store data locally using IndexedDB getting it to work properly on Safari (and to some extent Firefox) can be a soul destroying experience. See here for some examples: https://gist.github.com/pesterhazy/4de96193af89a6dd5ce682ce2...
Unless I'm building an app that also needs to work on the web, I'm choosing Electron.
I recently chose Electron over Tauri for the same reasons. Tauri would be a better fit for my app in some respects but it's a music player and Safari doesn't support all the audio formats I care about.
The downside of that control though is an application that's arguably a little too specifically targeted — it's understandable wanting to target the same engine but if your app breaks with different but reasonably recent versions of chromium I would say it's too brittle.
It also widens attack vectors considerably when your entire userbase is all on the same probably-outdated build of electron-bundled chromium.
But that's an Apple problem, not a "you" problem in that case. In Electron the security burden for tracking Chromium CVEs and sending updates out is entirely yours, whereas with Tauri you outsource it. In Electron, Chromium CVEs are your CVEs. In Tauri, Safari CVEs remain Apple's CVEs and technically entirely outside the scope of your application bundle. The trade-off for "old macOS webviews" is that it's not your problem other than general, basic old pre-Chromium hegemony HTML kindness of building web apps that gracefully fail if features aren't available, which is probably what you should do anyway?
Your users don't care whose fault it is. Your app isn't working. You can choose to cut those users off, and that's totally an option...sometimes.
Mac users are probably a little more tolerant of this than non-Mac users, because of the general upgrade treadmill, but whether you can get away with it is a question only you can answer for your app.
That's still a very different class of problem from a CVE break of a single-point-of-failure is the point. Someone decides to use your Electron app's old Chromium build and a known CVE in it as a target vector for infecting or remote controlling user's machines is a very different problem from "because we are using system webviews this small CSS/JS feature doesn't work in this version of macOS, please upgrade". Even if the user rightfully blames you the app developer for both issues and doesn't allow you to point fingers upstream, one is a severe security threat that can destroy entire brands and the other is "mere tarnish" on a brand. (I know which class of problem I'd rather deal with, given the choice here.)
This actually makes me think Electron will be a lot easier to support. Because at least you'd be able to control which version of Chromium your app ships with. If you're using Tauri, you'll need to support all the different versions of WebView that are out there.
As much as I love Tauri (and Wails), WebView requires to make sure the application renders exactly the same across all platforms. Sure, Electron comes with its downsides like the article rightfully points out. But having a UI that renders and behaves exactly the same on all platforms (thanks to the version locked Chromium bundled in the app) is really nice to have.
I wish there would be the possibility to bundle a renderer (maybe a more lightweight one?) with Tauri or Wails instead of using WebView.