I kind of wonder why it took this long for someone to try this approach. It just makes a whole lot more sense on the surface.
Interesting thing I just thought about: since users don't get to choose their system webview, I wonder if this has the potential to broaden browser diversity a little bit?
On Windows the default webview engine is still not the new Chromium but old Edge (WebView2 has to be installed separately), Safari has a fair amount of issues and gtk-webkit can be very quirky as well.
This is not so significant if your app has a web version and you have to deal with it anyway , but thereare a fair amount of Electron only apps. Or even with a web version, the desktop app often has special features not present on the web.
But webviews are as much a moving target as browsers and often behave differently from the regular browser version in a myriad of ways, so you need an even bigger testing matrix.
Webviews are also hard to properly secure and don't provide the extensive APIs of Electron, which you often have to bake yourself in a wrapper written in, eg, Rust or C++.
I say all this as someone who hates how resource hungry Electron apps are and groans each time about yet another one on my machine, but I understand why it is so popular.
> Webviews are also a moving target so you need a big testing matrix
I say this as a front-end web app dev who would most likely be affected by this kind of shift: it might be slightly less convenient, but I wholeheartedly think it's worth doing, on several levels.
People built web apps 15 years ago in the dumpster-fire that was web standards at the time (and frankly, web tooling too). Browsers, even the good ones, didn't update themselves automatically. Most of the world was still on IE which was actively hostile to web standards for the sake of lock-in (and users weren't even on the same version of IE!). There was nothing like Babel to smooth over the rough edges, there were no polyfills. And even the standards that existed, when you got the opportunity to use them, mostly sucked.
I think, given all that, we can deal with supporting recent-ish Chromium and the latest Safari, if it means bolstering web diversity and saving an order of magnitude in RAM and storage.
For example, Slack-the-Electron-app and Slack-the-web-app are fundamentally identical, aside from likely some platform integration features and so on. That means that, likely, a lot of these Electron apps would already work in, for example, a Safari or Edge webview, since the web version has to anyway. I sincerely doubt that they're taking the time to strip out that compatibility, since the only reason to do so would be efficiency and if you're using Electron that's not a priority.
IOW, for many applications, there's a near-100% chance that everything would function with little to no extra work, and for most of the rest it would likely take very little.
You and I both know that one person can write UI in a vacuum, but there's a litany of other challenges that come up when positioning an application across platforms - sharing code, resources, etc. If all you look at it on is a technical level, you're doing the problem a disservice.
It's not that they cannot afford building 10 native AppleTV apps in parallel and pick the best one.
Call me when Microsoft actually ships WebView2 with the OS.
"This is literally what Slack moved from years ago, because it was very problematic, let me tell you why since I'm the one who did it.
* We could literally do fuck-all for people running old versions of macOS - you can't upgrade Safari on old machines, you just Get What You Get. For awhile, every YouTube video on older macOS versions had a pink shade to it. Users write in, "This is clearly wrong!" "Yep, but we can't fix it. Sorry."
* And big spoiler - WKWebView uses _basically_ the same amount of memory give-or-take a few MBs as Chromium. It's the content that sets the memory usage bar, not the host. "
Coincidentally, Slack doesn't fully work in Safari or traditional Edge. Video calls only work in Chromium-based browsers, and in the Electron app which is of course also Chromium.
This is actually the thing that finally got me to switch back to Chromium last week, after using Safari and Firefox for the better part of a decade. The Electron app sucks, I don't like switching between browsers for usability reasons, and I need to make Slack calls for work.
I am not sure what the point is of Electron: a shitty-resource hungry app that literally is a wrapped web-app. Instead of writing platform specific apps that leverage the power and capabilities of those platforms, we get a jack of all trades and master of none. Electron is a business decision, not an enlightened technical one.
What value does electron add to the user? I would argue none. That Slack can’t find the resources to write actual Swift for a Mac App is just amazing to me. Instead we are essentially interacting with a lowest-common-denominator web app. Is a chat app that hard to write natively? We’d get better performance, a smaller footprint, and a more polished, platform-specific product.
You've answered your own question as to why people write then.
> What value does electron add to the user?
It adds a lot of value to Linux and to a lesser extent Mac users: before a electron a lot of apps didn't have a version for these platform at all.
What value does _this_ add over a web app?
I've been an exclusive Linux user since college so I'm aware of the disadvantages of app/service unavailability (I remember the dark days of running Netflix in a windows VM that I barely had enough RAM to run...).
But what's the advantage of using the Slack app over a browser tab? This is a sincere question, since enough people reference the benefit of faux-native wrapped webapps that I assume there's some value.
I seem to be the only one in my company who doesn't use Slack's app, and I'm always shocked when I see a colleague's computer freeze and have them say "ugh it's almost definitely the Slack app". I work in autonomous vehicle engineering, so these are _monster_ machines I'm talking about, capable of running the entire car's stack locally. The only advantage I can think of are desktop notifications, but 1) I'm pretty sure browsers support those and 2) is that really worth using an app that's amateurish enough that it freezes your computer regularly?
I prefer web versions of those apps on Linux than electron.
Sorry, I want to run just one browser and it is not Chrome based one.
And for sure Electron apps don't allow that ease of cross platform development as one thinks, I would argue that it is on the same level as a native app with good abstraction library (see Telegram client source on github).
It is more that they don't want to hire desktop developers (or just ones that want to learn something else than JS).
The current state is, you either use something that looks like Windows 95 in all platforms, or web app.
What the web made possible is to anyone to create a decent custom UI with little effort. I still remember how messed up was to create a custom component for Java Swing, which I believe is still one of the easiest to do. How would you do that for QT? GTK? WxWidgets? etc
Actually even WinForms supports them, even though too many are happily doing fixed canvas positioning without using them.
However, I think the Telegram Desktop client is not Electron either, it is just regular C++ compiled on different systems.
So a cross-platform is quite easy, Electron one would need to be tested for different webviews on each system.
Is it crazy bloated and resource hungry for what it does? Undeniably! Does it matter? Not for me.
Electron resource use can be painful for apps that are running constantly, like Discord, VSCode and Slack. For utilities like Etcher, who cares.
I do wish they had a command-line version that just ran node without Chromium, but there is a use-case to have a simple foolproof application like this; these days there are a lot of people who need to image drives like this and would be best not to mess with dd on their first time.
And dd doesn't exist for Windows so you've got to use some tool or another like this.
It might be because it is slower and doesn't overheat my usb sticks, I don't know, but if nothing else works you can try etcher.
(Not sure how I found out, can have been something I read or a recommendation by a colleague 3 a 7 years ago or something.)
My 6 year old MacBook runs slack, Xcode, android studio, safari, chrome, messages, vs code, vim, iterm2, preview, battle.net and hearthstone all the time without issue, really.
I think for the average user, they'd rather have more features across platforms more quickly than a smaller resident memory footprint and install size.
The point is that its effectively a web app.
They have a desktop app faster than if it was being built natively.
If you just package an existing website into an Electron app that is a waste of time and user resources. Electron is intended to combine a web-based presentation/UI layer with a Node.js layer that supports access to native resources, unlimited storage, persistence outside the browser, etc. If you are not making meaningful use of these capabilities a PWA would be sufficient.
Overall, I do prefer native apps, although there are examples out there such as VS Code that have achieved UI excellence without it. Although, I really only like that on macOS... on Windows I prefer the older Windows Forms style rather than the new Modern UI, and on Linux there is a bit of style mismash between Qt and GTK apps already.
Exactly, one can look at Telegram app, it is clean, polished and open source client written as a native app that works across many platforms (and one of few that has Linux client).
These two viewpoints cannot be reconciled.
Every month when this Electron discussion comes up there are so many who dismiss the egregious resource usage outright on the basis that it's trivial for modern computers. I'm one of those people who use Thinkpads in 2021 for my personal computing and have no problems with it. I will never buy a Mac, and I don't want to unnecessarily spend hundreds of dollars on a modern system when refurbished ones from a decade ago work so well. I avoid Electron apps on the basis that they flatten my battery quickly. I switched from using vscode to vim on my x200 and my battery life tripled, I'm not even exaggerating here either.
The environmental issue doesn't make sense IMO, but increasing hardware requirements does have real impact on accessibility.
Sure, your ceiling lights use less energy than your fridge. That's not a justification for everyone to completely ignore turning them off when not needed.
> affects the global climate in a negative way
If electricity consumption of all computers in the world doubled because of Electron apps, the total annual electricity consumption would increase by 0.01%. So probably false.
Problem is: how to test that? Even with the most straightforward tests, there are cheaters. Appliances have a special "eco" mode to meet the specs that most people won't use because it barely does the job. And for cars, well, VW have shown us how far companies are ready to go.
On my tablet, a number of current websites don't run even on Chrome, because the tablet isn't particularly new, so it doesn't have current Chrome. It's still great hardware in perfect condition though, everything that does run on it is perfectly smooth and so on, and I still use it. Youtube in particular is fine. Literally the only reason to buy a new one would be to satisfy the software treadmill.
My old phone didn't run Chrome (or Safari). It had Firefox. The only reason I switched to a newer phone, using Android, was because of sites that gradually didn't run well on Firefox any more. That was annoying, having to ditch a perfectly great phone and replace it with something better for the web but worse for other things.
I have a Macbook Pro at home. I'm pretty happy with it, it's still a fine machine, I use it for work every day. It runs the latest Safari that's safe to run on it, but that's not the latest Safari, because it would have problems running the most recent OS.
This brave new world of "I'm sure we'll be fine supporting recentish Chrome and latest Safari" is a world of exclusion. I don't like the memory usage of Electron, but I prefer it to applications that are a bit broken!
Also, to be honest, I've been looking at memory usage. Electron uses much less than any of the three big browsers. You may know that Chrome famously starts a new process for each tab, and Safari does too. Firefox isn't far behind. As a result, the memory saved by running a new page in an already running browser compared with Electron isn't as much as it was long ago, back in the days when tabs shared memory. This is visible with Safari, as the website name shows up in the system utility for viewing process memory.
I know, that feels wrong somehow, but it's true.
Finally, when using a system WebView, will that save memory if it's opening a separate instance of the system's browser? It must be separate in some ways, if opening an application that uses a WebView doesn't open all your saved tabs from last time the browser was open. (And it's a horrible experience if opening an application does open all the other tabs.)
More like: A lot of corporate users mandated a specific version of IE and wouldn't allow anything else to be installed.
I have never bought a prebuilt Windows PC, so this is pure speculation, but I am wildly guessing that the dominance of Chrome is because computers are now coming with Chrome preinstalled and configured as the default, and most people don't care, and just stick with the default.
Now the reason everyone uses it is because it's psychologically the new "default", whether it is on the actual system or not. Everybody knows that's just what you do when you get a new computer: you go install Chrome. And the irony is that even now, with Edge being basically the same thing, most people don't bother to re-evaluate that default assumption that "the windows browser is bad". They just use Chrome.
That's one way to look at it.
Another way is to say that Microsoft has lost customer's trust and now has to work extra hard to earn it back.
IMO they've learned their lesson, at least for now, but it would also be great if others could learn from Microsoft's mistake too.
I'm not aware of any Windows machines shipping with Chrome pre-installed. But as soon as you use any website that's owned by Google you get spammed with install links for Chrome.
So yeah, the situation is without doubt much better now. I think people tend to forget (or aren't aware) that Microsoft actively said "there's no more work to be done here" and stopped all progress for 7 years. There's been some progress on the web since 2014, as a point of comparison.
IEDevToolbar, which Firebug was pretty much a clone of, came out a year before Firebug. And it took Firebug years to catch up in feature parity, as far as I remember.
So, firebug didn't make it the dev tool of choice. We all just hated microsoft. And tabbed browsing was great.
I used that IE toolbar setup for years, and it _never_ worked as well as Firebug did.
I have heard that mobile safari can be a bit more unruly than the rest, though it isn't really relevant to the question at hand
At the time, jQuery was a big help in this, especially in hiding the event model mess. Things are a lot better now. Although I do wish we had a strict compatibility-checking layer that'd warn you if you used any feature of the web platform that wasn't supported by everything you wanted to support.
Even worse, an OS update after you ship your app can spontaneously break it on end user's machines without you knowing or being able to do anything about it.
At least with the web, when new browser versions come out, you can fix your site since users essentially "install" it every time they refresh the page. But an installed app that runs on top of a spontaneously updated framework is the worst of both worlds.
Or you would need some common runtime which is shared across the OS, and somehow use IPC to it. Then you can potentially save some more memory. But I don't think this exists. And I'm also not sure how much you really would save.
The advantage of using the system webview is that you can update this component, in case there are any vulnerabilities or so.
Slack used to use so much memory on Linux that I couldn't afford to run the desktop app and ran it inside a Firefox tab for years... seems to have gotten better somehow.
Good, then developers might start to develop against standards instead of handpicked browsers. Or if they use a future (unstable) standard that is their own headache (as opposed to user’s; which are subsequently in practice forced to use chromium derived browser).
An app developed against a single browser (as opposed to the web standard) should be considered what it is, an ugly hack, and developers that do it should only do it for their own private apps never to be published until it is standard compliant.
On the desktop you are developing against a runtime that the developer of the app gets to choose, so why not choose one that has less potential for quirks?
Especially on macOS, where Chrome/Chromium have historically been extremely inefficient, swapping the Chromium engine for WebKit2 WebViews would mean battery, memory, and CPU savings which would absolutely be worth the effort IMHO.
That Slack, the poster child of bad Electron apps performs so badly must therefore have different reasons. Exactly the same way you can write websites in a way that is more or less efficient you can write Electron apps of varying degrees of efficiency.
To me, develop for Electron is more fun than normal web because I don't have to check whether the new web feature I am using is available everywhere (especially Safari) yet.
Many Windows installers package one or more Visual Studio Redistributable packages into the installer. Is that not possible for these installers?
Give up pixel-accuracy and fine-grained control of your app's UI layer, and just treat it how people like Peter Norvig and Chris Lattner treat their home pages.
There isn't any browser with even 0.1% share that can't render those things.
You also don't really have to go as far as those guys do, leaving the font 14-point Times New Roman and using HTML 1 tables. You can add some style, fonts, etc... just don't add anything that would make it _not work_ if somebody opened it in Netscape Navigator 4.
There is definitely a big downside, in that your app won't look all dope and modern. For many apps that is a deal breaker. Also, some UIs really do require a higher fidelity UI. Not all UIs are just like, buttons and menus (although a lot are).
But there is also a big upside: durability, in the sense that your app's UI will work on most 10-year old computers, and most computers 10 years from now.
Old one is, of course, kept for compatibility reasons.
It's slightly absurd, and you should direct the "WTF?" to Microsoft for this.
That way, you're building with cross-platform in mind but still have the option to pick a stable target if you need it, compared to solutions like Electron where you don't have that choice.
I guess you can ship an electron version for these platforms where native webview sucks. Chances are that once you do the electron app you start doubting the benefits of shipping a webview based app.
Somehow I doubt the ideal solution is to bundle a web browser with every app. Electron feels like a prototype that went out of control.
That doesn't mean we shouldn't try and improve on things given the opportunity, but it's not an indictment either
As someone who doesn't write GUIs often, I just don't want to have to worry about it at all. What's the cost of electron over webviews? 100mb hdd space? On the other side of the trade, never having to worry about cross platform concerns again? Not having to support or test on multiple platforms?
Seems like a no brainer to me. But it's entirely possible, even likely, that I'm putting too much faith in electron, or that there are better options I just don't know about.
I really hate electron apps, for example you have teams, that is written in electron, in linux is somehow better than the web version but is just way worse than the windows/mac versions, in web you can view 2 cams, linux 4 but in mac and windows you have more cams at the same time and also a lot of features that are missing in linux, so I don’t see too much the benefits of electron here, just pure laziness of microsoft not willing to invest in a better cross platform app.
Efficient software is great, the cool parts of the projects I work on are efficient. In my case, the GUI doesn't need to scale in the same way, and I'm pretty confident the customer would rather have better cross platform support (at a lower cost than if we had to test a bunch of OS web views) than 100MB of their disk back.
But yeah, there are plenty of examples of software I use where I disagree. Although this is often based on my aesthetic dislike for an inelegant system, than on any kind of resource constraint.
And in doing so you're prioritizing your needs over all of your users'. I think it's fair to claim that a minor convenience to you, at the cost of inconvenience to all your users, might be something you may want to deal with.
I would prefer to live in a world where I didn't believe the last sentence to be true, but in the current world I still think it is :)
In my experience, unfortunately it isn't true that apps work with very high reliability. This is why I use multiple browsers. I don't want to use Chrome, and I encounter new websites with functionality that don't work properly in Safari or Firefox quite regularly. Some of this is even quite basic functionality.
From things like shopping carts where the final payment button doesn't work in Firefox (nothing happens), to video conferencing that sort-of works in Safari but then the audio breaks while it is reliable in Chrome.
Even GitHub doesn't render properly in Safari occasionally (the page is full of weird size text and giant rectangles). But that's almost certainly a Safari bug.
I like development in Firefox too. When I was doing it intensively (just ~2 years ago), I found some of the CSS I was using behaved differently between Gecko, WebKit and Blink, though (and differently again in Android's pre-chrome browser), so I reconfirmed that I do need to test some things across all browsers. By differently, I don't mean prefixed browser-specific CSS (although there is that), I mean standardish things like table row height calculations showed up significantly differently, certain border highlights, and a number of WebKit rendering bugs that Gecko did not have. Key-event based text editing and wheel events are also significantly different, even more so when you include the common mobile browsers.
There were problems with internal off the shelf applications whose user interface was built for IE6 only. The funny thing is those applications still worked well with the Firefox of the time, but IE9 broke compatibility with them and the applications didn't work on IE9, but IE10 got released and was compatible with them again.
Historically, it worked terribly on Windows.
On Windows, if you used the OS WebView, your Windows 7 users would be forced to use IE11 to run your app, even if they had a newer/better browser installed locally. On Windows 10, you'd get whatever random version of Edge was installed, or the new Chromium-based Edge.
In 2021, we're in a new era for Windows WebViews, thanks to Microsoft shipping WebView2 at the end of 2020, which ensures that the OS-provided WebView will be a modern version of Chromium. https://docs.microsoft.com/en-us/microsoft-edge/webview2/ Tauri supports WebView2 and I bet it will work a lot better than historical approaches.
Support is still pretty dicey on other platforms, though. macOS doesn't have anything like WebView2, so if you want to support a five-year-old version of macOS (which isn't that old in desktop terms), you'll be forced to support and test your app on a five-year-old version of Safari. (The user might have upgraded to a two-year-old version of Safari, but they might not, if they prefer Firefox or Chrome, and that's now your problem.)
The easiest and best way to improve the user's experience on old OS versions is to provide your own copy of Chromium, like Electron does.
At that point, if you've shipped an Electron app for macOS and Linux, maybe you just wanna ship an Electron app for Windows and call it a day?
Having said that, if you can keep your OS-version support matrix tight, Tauri might work OK for you.
Really depends on your market I guess and how much legacy webview browser support you need.
Or really how much you'd need to add polyfills like `@babel/preset-env` to keep the JS equal.
We use WebView2 on Windows, Safari on macOS and WebKit2GTK on Linux. Not shipping a whole Chromium installation on each install and update reduces the installer and on-disk size a lot!
I see issues here!
> Apple Silicon (M1) is not yet supported.
And on Linux,
> you may install Kreya by downloading the tarball. Note that both libgtk-3 and libwebkit2gtk-4.0 dependencies are required. Install them manually if they aren't present on your system.
libwebkit2gtk is, itself, _an embedded browser_, 44MB installed size, plus dependencies.
It's convenient that you can make Snapcraft install it for you, but that's not really different from making Snapcraft install Electron and running that.
Linux does not have a core WebView out of the box, so libwebkit2gtk is the closest alternative. Not optimal, but it works. Looks like Tauri uses libwebkit2gtk too.
Like other replies have mentioned, it's not a new idea
DeskGap uses the native OS Webviews. https://github.com/patr0nus/DeskGap/
Electrino (4 years old) was an experiment where they forked Electron and removed Chromium to replace it with the native OS Web views. https://github.com/pojala/electrino
Quark is a fork of Electrino: https://github.com/jscherer92/Quark
There's also a way of building desktop GUIs using Deno, which uses Deno Webview, which is a binding for the same webview library that Tauri uses.
System webviews will always have different features, break things, and are entirely uncontrollable by the software distributor. This means your software will not be resilient to the future.
You cannot access the JS engine the same as you can V8 in most webviews. This means you can't interop with C libraries without some performance destroying hack like copying everything into the JS space through sockets.
Electron develops patches that make chromium more performant and feature ready for desktop.
Electron conjoins the chromium and node v8 event loop to take advantage of libuv - again a performance improvement.
The decision of webviews and electron is based on what you're trying to do. If it's simple html/JS that's pretty much self contained then sure.
The current generation of web developers who grew up within the Chrome ecosystem has zero interest in spending time on cross browser support.
Even if the user had to install 4GB of chrome runtime they'd still argue it's better than them making it work in Chrome, Edge-Chrome and Safari WebKit.
Not saying everyone, maybe my companies hiring process is screwed but every developerbar 1 that I've worked with over the past 4 years has been the same and even getting them to test in one other browser than Chrome is honestly like pulling teeth.
Infuriates me as someone who's first job was CSS+HTML supporting IE 5.5-7.0, Firefox, Opera and Safari.
The amount of times I've heard "Can't we just tell them to use Chrome?" when talking about users is getting absurd.
The lack of understanding that a few hours of their job being slightly more difficult can add up to saving literal lifetimes of time saved or entire data centres of disk space when you extrapolate the savings across your user count. I know its maybe cheap to roll out a Steve Jobs quote but this one still resonates with me.
"Well, let's say you can shave 10 seconds off of the boot time. Multiply that by five million users and thats 50 million seconds, every single day. Over a year, that's probably dozens of lifetimes. So if you make it boot ten seconds faster, you've saved a dozen lives. That's really worth it, don't you think?"
The scary power of Google.
While investigating this, I have deep sympathies for whoever has to work with that taskcluster silliness because yikes that is some A++ grade obfuscation as compared to a .gitlab-ci.yml or .circleci or even the .travis.yml they migrated off of
As others have mentioned, this is not the first time someone has tried. As for why people might not go for it:
- Electron is Chrome. Webview is: Cocoa/WebKit, gtk-webkit2, and Edge (or is that Edge and Edge/Chrome). Yes standards have progressed a ton but there's still inconsistencies and it's nice not having to worry about them.
- Electron is JS, so your app is 100% in a single language. In Webview. With these alternatives you now have to use 2 languages. Not the end of the world, but again, nice not having to deal with.
...has a fairly long history. It's great for extremely small application packages (when I tinkered around with it on macOS a few years ago I brought it down to 26 kilobytes).
The usual argument against the idea is that Electron gives you a fixed Chromium version to work against, while the system webviews are a moving target with different underlying browser engines.
Perhaps a similar approach to https://github.com/webview/webview ?
"Tiny cross-platform webview library for C/C++/Golang. Uses WebKit (Gtk/Cocoa) and Edge (Windows)"
I'm left wondering why take over a project if they're going to ditch it. For lack of a better term.
One significant difference regarding webviews is Neutralino on Windows is using an outdated WebControl (MSHTML/Trident based) and this one seems to be using at least WebView (EdgeHTML based) or even WebView2 (Edge-Chromium) if available, both of which are a major improvement.
You can find a bunch of different approaches in lists like "alternatives to electron." There's some on GitHub.
Which is why many many people tried this approach long before Electron came along. Electron has been successful largely because it deviated from this: it swallowed the bitter pill of bundling the heavy duplicated webview in order to ensure a consistent development target.
I believe there are dozens of projects using Webview and market themselves as a lightweight "Electron". The development for these apps takes longer (as you need to test for different webview versions/vendors) and the end product is worse as some features are shimmed or you just choose to not support them due the effort required. Of course this depends by project.
I've developed a media player and considered webview. Soon enough I've found the limitations of safari, ie webview and even firefox webview on audio/video codecs is a blocker. Next was indexeddb and some random performance issues. It didn't took long to realise that it's hard to compete with native apps using Electron but its even harder using different webview versions.
The BS of the browser tech world compounded over time and a million edge cases eventually eats up all the one-codebase, cross-platform savings.
Or something that compiles to the compatible HTML code for those platform with 100% accuracy.
Unless that happens, you are dealing with godzillion number of edge cases in hundreds of different System Browser.
But even if such language or subset of feature exist, it will still not be as good or as be limited compared what is possible on top of current Electron. Which means from a user perspective, the Dev is optimising for something they rarely cares about; download size. Given memory CPU and Memory usage to electron.
What we need is a subset of HTML features that are known to work across all major browser. From Firefox, Safari /WebKit on other MacOS, and Chrome.
Elevating a new stack is a good consolation prize.
it didn't - there is already a few projects like that, with Neutralino being the most notable.
On Linux it's going to pull in GTK which means a not great experience on KDE (even though KDE does have WebKit hooks like GTK does).
Right now many web apps can brush off doing QA in Safari (and Firefox for that matter). Most regular websites don't have issues, but most of those don't need any vendor-specific fixes in the first place. I've used multiple complex web apps that just break unceremoniously unless you're using Chrome.
If web apps that are complex enough to warrant a desktop app are forced to support Safari, that lifts awareness for the entire web/JS ecosystem. That's a win, if it plays out that way.
> having all the fun of web development against multiple browsers
The difficulty here has gone sharply down since all major browsers are evergreen now (and IE is all-but-gone). Not to mention the availability of tooling like Babel.
There's billions of active iPhones out there & they ALL use WebKit for webviews as no other browser engine is allowed for iOS apps. MacOS desktop apps are a fraction of that number of users & web view apps are a fraction of that. I just I don't follow this reasoning unless you're saying that this might gain traction across developers who might go & fix the bugs. That might help WebKit (although questionable). It's never going to help Firefox which is the sole remaining engine that doesn't have a strategic play to try to encourage compatibility.
> The difficulty here has gone sharply down since all major browsers are evergreen now (and IE is all-but-gone). Not to mention the availability of tooling like Babel.
If that were actually true, would you be concerning yourself with getting devs to do more QA on Safari or Firefox?
The truth is that it's still hard to write web apps cross-browser and will likely remain hard indefinitely as long as there are > 1 web engines. The point of the web was to make you OS agnostic (ironically recreating the same pattern in desktop development of 2 or 3 major engines as with 2 or 3 major OSes) but with this tech you're combining both dealing with the browser-specific issues & OS-specific issues. Additionally, you're now not only having to maintain compatibility across 3 engines, but all the various versions popular versions of the OS distribution will have shipped. I really struggle to see the value of this approach if I'm concerned with shipping the app & lowering my development costs & increasing velocity to shipping useful features.
As far as I know that's not accurate and the default webview on Windows is still the old Edge based one, not Chromium.
The plans here are somewhat unknown I think, but right now you have to force the user to download and install (or bundle an installer) for WebView2 or Edge beta channel if you don't want to support old Edge.
Gtk-webkit is also quite different from Safari, you can't assume they are just the same.