Honestly having trouble making a coherent strategy out of those words, despite knowing what all of them mean. Seems like at the least it is written with way more confidence than could possibly be appropriate.
"drop-in feature-parity with Chromium" == They want to be able to replace Chromium with their own engine, but it must be very compatible.
"duplication is becoming a significant performance drain" == Every electorn app bundles its own browser engine (as opposed to a single browser engine for the whole OS, like a shared library), which increases system RAM usage and hinders performance.
"They want to single-instance Electron with their own fork" == MS wants to support electron apps but they want to use a shared browser instance for performance.
They rightly believe that doing so with their own browser engine is a huge pain in the ass.
Might as well just use the real Chromium for all browser needs throughout the OS including electron apps instead of trying to reimplement it.
> which increases system RAM usage and hinders performance.
I can see that it increases disk space, but everything on top of that is questionable. I believe DLLs will share/reuse memory pages even if they were downloaded in separate bundles.
But how would that situation be any different in the presence of some kind of system Chromium install provided by MS?
Chromium updates often, so you don't want to run your client-side JS against any other Electron version than the one you wrote it for because they change APIs frequently, so you'll still have one set of DLLs for each needed Electron version.
Given that it's Chromium (and thus effort to get things running should be minimal), and most Electron app writers aren't pushing Chromium to the bleeding edge, why wouldn't they test on the one that ships with the desktop OS with the largest installed base out there?
Another thought: If the same browser shared library can be used for every process, the same RAM pages should be executed for each process, so the CPU should be able to keep more of the code in CPU cache, along with probably branch prediction statistics as well. To the CPU it is the same code running which has many performance impacts. Less code = faster.
I think it's referring to Microsoft's own Electron-powered apps, like VSCode. There have been rumblings in the past about MS wanting to fork Electron and replace Chromium with EdgeHTML in their fork, but it sounds like the strategy has changed to forking Chromium and using that in their future Electron fork instead.
I have no idea if this correctly interprets the SwiftOnSecurity tweet, but that's the best I can make of it.
That sounds fine, it just sounds unrelated to a decision to kill off Edge. You can maintain Edge as a web browser while using Chromium Electron. If you're Microsoft, your decision on whether or not to maintain Edge as a web engine is unlikely to completely pivotally depend upon whether you end up choosing Chromium Electron or Edge Electron. So the tweet doesn't make sense to me.
Off topic but I'll be that guy: I am continually blown away by just how good VSCode is and how it very much overcame two huge obstacles: being an election app, and its poisonous name.
I don’t know any anti-MS folks anymore. Those who were that generally stopped hating MS when MS stopped being a threat to the existence of their preferred platform, or to open source in general.
I think its more than just them using it for their apps. I think they want to turn Electron into a reusable Desktop UI framework for Windows and given the fact they now own GitHub they can force that for the Windows rendition of Electron. It all seems like almost a bad idea if it makes Edge too reliant on Chrome. I really was hoping Microsoft would instead have fully open sourced Edge. Edge could use some community love to make it a sweet out of the box Windows browser.
Perhaps Microsoft developers, with access to Windows' source code, can better optimize Google's upstream Chromium on Windows for the benefit of Electron apps using Google's Chromium? Otherwise, porting Edge to Chromium isn't going to anything for Electron apps.
The problem with electron is that every electron app is shipping with chromium, which means a lot of resources are being duplicated.
A way to solve this is to make the JavaScript/html layer part of the OS, so that electron apps would ship as thin layers on top of a the system’s engine (The same way that java applications are thin layers on top of Java’s virtual machine).
Apparently, the way Edge is built doesn’t allow for replacing chromium in electron apps. So they need their own version of chromium instead.
