> I’m wondering whether it’d be possible to factor most of it out into a separate layer
We've done this. The layer is called a web browser. You deliver runnable code to it using something called HTTP.
We've done this. The layer is called a web browser. You deliver runnable code to it using something called HTTP.
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).
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.
> 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
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?)
in much the same that sharpened sticks compete with power tools, yes
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.