Probably OK for some uses, like when you publish as a web app anyway, but for others it burdens you with keeping up with the aggressive release cycle of browsers.
I didn't see any sarcasm tags on your comment, so I'll take it at face value and disagree. Two quick examples:
Google Chrome went from proposing a new WebAudio method called "start" to deprecating and removing the "noteGrainOn" method it renamed in the span of 12 months. Any sites using the original spec stopped working, some within a year of being released with the latest and greatest spec, one of which was Google's "WebAudio Playground" demonstration site. (There's a fun bug on file where that team had the browser team push back the method deprecation by a release so that they could fix that one website).
Google released Polymer in 2015 or so. Apps written using the latest version of that in late 2015 stopped working at some point in 2017 on Google Chrome.
Web browsers stopped being even a little bit backwards compatible around 10 years ago.
You are right, of course: if you use new proposals that have not yet been standardised, you are at risk of them breaking in the future. (I've been bitten by this at a previous employer that insisted on using Polymer as well. Don't get me started on that.)
When you stick to standardised features with multiple implementations, though, I think in the vast majority of cases you would've been fine. (This is also one reason why I was against using Polymer.)
(Obviously this does not cover all Electron features, which is why I don't consider browsers to be a replacement for Electron, at this point. I'm merely stating that it's very much possible to target browsers without having to concern yourself much with their rapid pace of development.)
Gah, Polymer. Glad to hear I'm not the only one bitten by that...
(Did a single site with it, worked for a year and then for 6 months only in Safari/Firefox, and then we ported it to sit atop another Google project... ¯\_(ツ)_/¯ )
Favorite recent example, Chrome's audio blocking solution pretty much broke every HTML5 game in existence. 1000s of sites are still broken. To just name some easy categories, every Pico-8 game exported to HTML5, Every Unity and Unreal game exported to HTML5. Even 100s of Google's own Doodles, examples, promotions, etc ... until they pre-whitelisted every domain they own.
The worst is Apple. Trying to do anything game related in a webpage on iOS Safari is a nightmare and is pretty much guaranteed to break with each new iOS release. "minimal-ui" (nope, took that way), "user-scalable" (worked but they keep changing the conditions so old games break and have to reverse engineer under what conditions it's respected). I recently noticed one of my sites broke for audio. No errors, no mention of what changed that I can fine, worked 6 months ago, stopped working, Safari only. Note it's a site about audio and it doesn't start that audio until the user clicks the "Play" button. It's using the "resume" api but no sound comes out. Still works in Firefox and Chrome (after having to update it last year for Chrome's breaking change)
You're right that there's some risk - especially using API's that can also be abused. However, percentage-wise, the vast majority of works targeting browsers continue to work unmodified (at least in terms of interacting with the browser), making it a very stable platform and definitely not breaking as often and as likely as implied by the words "aggressive release cycle".
That said, it's definitely not yet feature-rich enough to fully displace Electron.
> Agree, but it isn't like OSes also don't change their API space or behaviors.
They change, but more slowly with better backward compatibility, but more important is when they change. In a corporate environment they might update the OS once a decade and on a schedule you control which is much more manageable than relying on a layer that updates itself every 6 weeks.
> Unless one only cares about fossilized UNIX and Win32.
Stability is good, but not when it becomes an obstacle for advancing the state of art in OS development, as many cling to the ways of yore and we get CLI apps with coloured terminals as improvement or WinForms database frontends in bigger screens.
If you bothered to read the link I posted, you would see that PWAs are native apps in UWP with full access to the same APIs as .NET and C++ have, if distributed via the store.
Same applies to PWAs on ChromeOS (naturally given its nature), and Google is ramping up the same capabilities on Android with their initial release of TWA.
Yep, there are a few OSes currently left out, it is up to their masters to follow Microsoft and Google's footsteps.
So you're proposing a solution which works on only Windows and ChromeOS (considering desktop OS only), and has to be distributed via a proprietary store (which in all likelihood might take a cut of my revenues), as a replacement for something that works on Win, Linux, and MacOS, and does not require that I lock myself into an unfavorable distribution method?
AFAIK there's no such lock-in in PWAs, even if the app stores are probably going to be the most important venues for their distribution. PWA is a web app that gets more 'app-like' progressively when you need it to. You can use it like any other web application in your browser, but if it's okay to you, it can store data (and cache it's own assets) to your machine, start in it's own window from a launcher, use the filesystem and so on. Many web apps already have this sort of behaviors when you create a home screen launcher for them from your browser.
Per the parent comment I was responding to, PWAs will only have full access to native APIs if they are distributed via the store. And without access to native APIs things like window management, menus etc. become impossible to customize.
This won't meet requirements either. Desktop apps require full system access. Either they get that, or it's another API that'll be deprecated sooner than later.
