I think the underlying motivation in this comment is that there are very many technical application development challenges which can be solved simply by web developers paying close attention to the fundamentals of their craft rather than relying on "fancy tricks" to speed up the development process. Plugins like Flash used to be one kind of "fancy trick" to offload into another layer, but there were many developers who stayed faithful to the process of working with everyday browser capabilities (and all of the politics that these capabilities entail), so that the wrinkles could eventually be ironed out. I think that so many who go the "Electron"-ic development route are afraid of getting their hands dirty with the question of in-browser client-side storage, ie, they want to be able to get their hands quickly on the files in the user's native file system.

There are, however, very stable in-browser ways of dealing with the question of client-side storage. IndexedDB is one. But there is another that I am quite partial to, called the File System API. I use it to locally store the files and code in the browser-based OS called Linux on the Web (https://dev.lotw.xyz/desk.os).

Even in the browser itself, there's a clear delineation between the set of components that change quickly, and the set of components that change slowly—a factoring of layers calling out to be done, that everyone is ignoring. There's no reason for a whole new web browser to be shipped if only the quickly-changing part has changed.

Analogy: why would you ship a new copy of X/Wayland just because your Desktop Environment has a new release? The new DE version uses the same old compositor, because the compositor doesn't change much. So why would it make sense for a compositor to be part of the DE and embedded in the release package for the DE, rather than just requesting the OS to make available to it the services of a compositor of a specific [ABI protocol] version? Even if the compositor and the DE have the same maintainers, it'd make far more sense for them to be two separate projects, with one just depending on the other.

Or, to put this another way: why should ChromeOS devices (= another build target of the Chromium codebase) replace the whole OS image every time some new namespaced CSS layout rule is being incubated? That stuff has nothing to do with running an OS. The parts of Chrome that are an OS—which includes a lot of the stuff that gets installed as "browser" on other OSes!—should really live as OS services, separate from "the browser" (really just the renderer + VM.)

Microsoft took a while but eventually learned their lesson about this, and these days Edge is just an app and updating it doesn't require a restart of your computer. Part of what enabled that was delineating the slower-moving parts of the browser (e.g. the network stack) from the faster-moving parts, and letting the slower-moving parts live in the OS while the faster-moving parts lived in the app. "Edge" is just a renderer+VM. So is Safari, for that matter—what you download when you download "Safari Technology Preview" on macOS is just a renderer+VM, which relies on the same OS-provided libraries for e.g. network caching that the system Safari installation does.

Did you even read the comment? GP literally addresses deficiencies in this layer when running multiple instances of the browser.

i did, and found them unconvincing

> 1. this would lose you the ability to develop for a particular version of the renderer

html and css are standards, if you are developing for a version, you are wrong. full stop.

> 2. this wouldn’t give you the benefit of Electron sharing service-memory with Chrome itself

there would be no electron so point is irrelevant

> html and css are standards, if you are developing for a version, you are wrong. full stop.

Who said anything about HTML and CSS?

Apps like VS Code create and manipulate a DOM directly in JS, or more often these days, WASM. To these apps, Electron is just a virtual machine with a lot of browser-like multimedia APIs attached. You pin the exact version of the renderer just like you pin the exact version of your dependencies in a server-side app, or the exact version of the OS in a virtual-appliance VM image.

Electron has nothing to do with "the web" or "web standards" other than borrowing technologies originally developed for those. Electron competes with things like Unity and https://love2d.org/, not with browsers. It's in a category of frameworks with the goal of giving the developer pixel-perfect control over what the user sees, where apps are separately developed, tested, and tweaked, for each target (e.g. each OS, each kind of display/interaction methodology, etc.)

With this category of framework, you don't build your app as generic code targeting a standard; rather, you build, and test, your product against a specific "engine." (Imagine for a moment that people could take Unity apps and run them against any old version of the Unity engine, or even against Amazon's Lumberyard fork of the same. Would anything work?)

> Electron competes with things like Unity

in much the same that sharpened sticks compete with power tools, yes

If your goal is picking your teeth, a sharpened stick is all you need, and any other tool you use is going to be being used as a glorified sharpened stick.

Similarly, if your goal is drawing the views of a CRUD app, any tool you use is going to be used as a glorified version of Display Postscript.