Another Electron app, another thread full of people complaining about Electron.
The solution is to build a common Electron runtime that all Electron apps can use. But it seems nobody is working on it despite all the complaints.[1]
I really don't understand why there isn't anybody working it. If that got implemented, it would put a swift end to the biggest complaints about Electron.
Web widgets require a hybrid codebase. It's not "web developers not getting native," it's web developers preferring the Node.js APIs to writing C++ code to read and write files to the filesystem.
All the options you listed require two or more programming languages. Electron apps can be written entirely in JavaScript, requiring zero context switching between multiple programming languages, as well as sharing code on the backend and frontend. Hence the popularity.
Then we are back to HTML 5 APIs, which any browser can already do.
If they need to interact with the host OS, someone needs to write those native plugins, and that won't be in JavaScript, as the Github repository for Electron clearly proves.
In the end is all about using an hammer for everything.
No, that isn't the case. The Node.js APIs bundled with Electron expose considerably more functionality to JavaScript than the HTML5 APIs that Chromium exposes. And the Electron framework exposes even more native OS APIs that Chromium and Node.js don't provide.
Look, you can call it "using a hammer for everything" pejoratively if you want, but it's popular for a reason, and that reason isn't the moral decay of society. It offers real utility that reasonable people find valuable for rational reasons.
So because open(2) is implemented in C in the standard library, I should only call it via C, and never invoke the wrapper function open() in python or whatnot?
“Hybrid” does not mean what you think it does. The platform may be built on code in many languages, but to program for that platform, you only have to know one.
> All the options you listed require two or more programming languages.
You can write Qt apps entirely in C++ or entirely in QML (of course you can mix and match both... in my experience whatever the environment you always need to resort to native modules at some point anyways, eg numpy, opencv, etc and Qt makes exposing them to Javascript dead easy).
I don't think that is correct. The extent to which Electron uses resources today is as if you install five copies of Node.js and five copies of Chrome and launch them all.
A common runtime would be as if you ran five Node.js apps using the same runtime and opened five tabs in a single instance of Chrome.
I'm not super well versed on the low level implications there, but I find it hard to believe that wouldn't save a lot of resources.
I mean, do .NET apps load up a full copy of .NET and all its libraries into memory for each app you open?
Yes, and that would be the case with Electron too, but in the case where n apps share the same version of the runtime, I assume it saves a lot of resources?
The web browser for UI drawing is only part of what Electron does. It also bundles Node.js and all its APIs, which web browsers don't ship. And Electron also provides APIs for native OS integration, e.g. native macOS menus and whatnot.
I'm not familiar with Electron myself, however it's relatively easy to identify which applications are using it.
I know Discord doesn't support using a keybind for push-to-talk whilst the (Chrome) tab is not in focus with their web application whilst their Electron app supports this. Something vital to PTT users whilst playing games.
The solution is to build a common Electron runtime that all Electron apps can use. But it seems nobody is working on it despite all the complaints.[1]
I really don't understand why there isn't anybody working it. If that got implemented, it would put a swift end to the biggest complaints about Electron.
[1] https://github.com/electron/electron/issues/673