How would you feel about Electron projects if Electron was instead:
1. a single shared runtime install, installed transparently by the first thing to need it (similar to how the Adobe Air first-use experience worked), rather than a vendored dependency?
2. a shared VM that ran its apps in separate V8 execution contexts (like how browsers isolate tabs), but with a lot of shared resources so that each Electron app didn't end up with a GB of (mostly redundant) memory consumption?
I find that most people don't object to HTML5 apps per se; they just object to the way Electron handles things. The above was going to be the strategy of Chrome's "app-only runtime" mode, until they just killed off Chrome Apps altogether. I still think it's a decent strategy, all-said.
I would feel marginally better but still hate it. I don't like the web as a platform anyway, especially not one for applications with cancerous amounts of JavaScript. HTML is not a platform for desktop applications. It shouldn't be a platform for almost anything.
I've always thought that HTML made a pretty amazing platform for applications when you have the specific goal that the application should be an enhancement (of editing controls + toolbars + whatever) on top of a clean, semantic, static HTML document. Because then you get all the advantages of having a "document" even though you have an application. (These arguments don't apply to "native-ized" apps like Electron apps; only to actual apps-at-URLs-in-a-browser.)
You can, for example, print your application's interface (i.e. your document), without having to implement your own print-layout logic, because that logic can just be the browser doing CSS @media(print) to the DOM. (Which can, with a few @media(print)-scoped rules, hide all the toolbars to just leave the document.)
Or, users can use User-Agent stylesheets (think "forcing high-contrast" or "disabling serif fonts") and browser extensions to customize your application [or, more importantly, anyone's old closed-source abandonware application that's never gonna make an accessibility update ever again], because your application's interface is guaranteed to exist in the intermediary state of a DOM tree, where those things can get to it to munge it†.
† (This is also true in various ways for each OS UI framework—and you can create native "extensions" like screen-readers that use the OS accessibility APIs of each OS—but you have to redo this work. WebExtensions are cross-platform.)
Also, with web-apps, users get final control over how the application is sized and shaped on the desktop, and so apps are forced to be at least semi-responsive—which is easy, because the default layout algorithm for any container, if you don't override it, is a reflowable-text algorithm. Web-apps are the only apps where I'm (nearly) guaranteed to have the ability to adjust the em-widths of blocks of text so that they're actually comfortable to read.
And, as an added benefit, as long as you ensure that you really are serving a static HTML document at each URL that is progressively-enhanced into being your app—then your web-app can double as a programmatically-accessible infobase. Google can't index a native app. You can't scrape a native app. You can't embed microformats into a native app. Etc.
Actually, I wouldn't mind it that much if it was as you described.
I believe that a web-based UI would still be slower than a native application, if only because of the huge number of abstractions in-between, but I'd say it's something that can be overcome by (a) newer hardware, (b) better development i.e. careful profiling and optimization, (c) advancements made by the browser engine developers, and (most likely) a combination of all three.
There's also the issue with the Web as a platform, but honestly, it's not as bad as purists on HN make it. No technology is perfect. I used to be a very loud opponent of using Web technologies for applications, but I realize that ship's pretty much sailed, and we could have had a much worse outcome than this.
My main gripe with Electron has always been the inability to share resources between instances. If firing up Slack or VSCode would have the same net impact on my memory use as opening a new Chrome tab, I'd gladly run them and quit complaining.
I would still hate it. When it comes to UX I care a lot about the little stuff, and with all web-wrapper apps I've ever used it's death by a thousand cuts. Lots of little things that work in native apps don't work in Electron apps.
Let's take Slack as an example. All the keyboard shortcuts use weird modifier keys like option instead of command, and I can't discover any of them by looking through the menu bar like I can in a native app.
Or for another example, the Services feature of macOS doesn't work correctly with Electron apps. In any native app I can select some text and then trigger a Service on that text (for example, I've defined a service to be able to select a bug id and hit a keyboard shortcut to view that bug in our bug tracker). No such luck in Slack.
1. a single shared runtime install, installed transparently by the first thing to need it (similar to how the Adobe Air first-use experience worked), rather than a vendored dependency?
2. a shared VM that ran its apps in separate V8 execution contexts (like how browsers isolate tabs), but with a lot of shared resources so that each Electron app didn't end up with a GB of (mostly redundant) memory consumption?
I find that most people don't object to HTML5 apps per se; they just object to the way Electron handles things. The above was going to be the strategy of Chrome's "app-only runtime" mode, until they just killed off Chrome Apps altogether. I still think it's a decent strategy, all-said.