Except they cannot, Chromium (or is it Blink?) changes too frequently to reliably code for one version and expect backward compatibility of future releases. Electron versions could be shared libraries... except again BC breaking releases proliferate.
Why can't it be based of Chrome's version number? If you know the version number at the time of release then you can say only use the same runtime if there's only a revision version difference, else you can use it's own run time. That packaged with auto-updates for the app to that developers can push updated builds every month or so should be fine.
Except they chose not to, preferring to allow for frequent breaking changes. This makes it easier for devs to make these rapid changes with all the cost/overhead payed by you.
With their multi-process approach, you'd have separate processes even when sharing the runtime to the point that sharing the DLLs likely has minimal benefit. It's the equivalent of running firing up Chrome twice w/ two different user profile dirs...shared libs, but no obvious perf advantage over two separate Chrome installs.
I imagine the different electron versions and different Chrome versions would make this hard without breaking things. Maybe a config option for "allow chromium between versions x and y" would solve this.
Most electron projects I've seen have used webpack targeting ES2017 or earlier anyways which makes this unlikely, but if you compile for ESnext (or don't compile at all) and use a new V8 feature, you wouldn't want Chrome 69 running your app and getting stuck on old V8 not being able to use the new feature.
Maybe it should, but it's not always the case. As a front end dev I have to fix issues related to bugs introduced by browser uptades every now and then and usually it's Chrome.
On the web it's easy, deploy a fix and it's live. With a desktop app I can't even imagine the logistics involved.
Is that really possible? I feel like it would only work with considerable engineering effort, and even then, probably only if the bundled Chrome instances were all exactly the same version.
This is literally how every gui library on planet earth works. Developers all build against a particular recent released version with all apps in the system expected to build against a small number of recent versions.
If this is hard maybe its because the browser isn't a very good runtime to build against.
Right, but those systems are set up from the get-go with that usage pattern in mind, where you have an expectation of ABI compatibility and the underlying libraries as a shared resource.
The expectation with Electron has always been that you bundle a copy of it with your app, so that you're always targeting exactly that version.
That one is true though. Different Electron apps could at least share the runtime.