Many[citation needed] electron-ish apps are also available over the internet (vis: slack, atom, vscode, discord being examples I've personally used).
In the case where your software development practices require static bindings to exact versions, you're correct, but your app is participating in the "IoT anti-pattern" of deploying baked code which may or may not be updated based on the long-term viability of your company / product.
I think this offers a great leap forward in transparently keeping local software up-to-date. Your argument boils down to it being better to ship an entire Windows95 VM with your app so you "have control".
In most cases, better to ship your own app and integrate properly with the external operating system / runtime provider (or hide: "Use bundled chrome.exe" as an advanced checkbox).
Ideally it'd be possible to select puppeteer/firefox as the target runtime environment as well.
While I am not a fan of Electron, the problem with using the system-wide install of Chrome is that while Chrome and your online web-app are both updated, the installed app might not be. So then the installed app could break in the future when Chrome is updated.
VSCode and Atom are available over the internet? I've seen online cloud-IDEs based on some of the work in them (Cloud9) but wasn't aware the vanilla versions could run in the browser.
>On the other hand you have more control over your app. The app will work and look as the author intended.
Sure, but it's just the age old argument of static vs dynamic linking. General opinion has settled firmly on the side of dynamic evergreen dependency management for software on the web because exploits are so common and fast moving.