Is it possible to have some kind of electron/tauri/,.. based runtime, but without the actual app? The users would need to install this runtime only once. The apps would need to be installed separately. The apps could be just the plain html/js/css/assets maybe packed within a zip, with a dedicated extension. The runtime would take care of the installation. That way the devs could develop with their FE-stack of their choice and ship just the small packages. Does this make sense?
This doesn’t work. Developers move on to a next version for reasons out of their control. Now a user has a version hell, just like c:\python{all, sorts, of, versions}, and probably a versioned file extension. Bundling tens of megabytes is not a problem for the last ten years. Having everything you need right in your backpack is a good thing for everyone.
It could be feasible if software communities didn’t tend to underimplement features and then solve them by intertwining all sorts of dependencies and their maintenance policies. For example, for as controlled thing as typescript, there are at least four popular ways to “just run” projects, all with different quirks and issues (tsc & node, ts-node, swc-node, tsx). Although it was obvious that people would want to run and watch .ts files based on tsconfig.json, without an explicit compilation step.
I guess that sounds like the normal web/progressive web apps/web archives (especially with the push to more platform APIs in browsers)? Also, Tauri uses the system's WebView2/Webkit runtime, so it essentially works like this already.
This is a pretty standard type of architecture, it's essentially how anything that runs on a virtual machine works. Back when visual basic was popular, it actually surprised me that Microsoft never ended up bundling the VBDLL files with the OS itself allowing developers to ship significantly smaller installation bundles.
It does sound a lot like what Progressive Web Apps (PWAs) are supposed to be. It's very close to how the original Manifest.json worked when given an html/js/css/assets list.
Only a couple of browsers supported that version of Manifest.json. Chrome developers thought it was too much of an 80/20 solution and decided to get deep in the weeds of the 20% instead of delivering the 80% solution while they worked. That's what got us the way too low level and hard to reason with Service Worker APIs for PWAs. It's over-engineered for the 20% of use cases in a way that makes "easy" 80% so much harder than it ever should have been. Chrome developers still randomly promise the web that the "easy high level API" will arrive any day now, but looking at the mess that is Workbox (their team's supposed-to-be high level building block library for Service Worker PWA APIs) it still doesn't look like it will happen any time soon.
It's more the shame because we briefly had a simple JSON manifest format for assets. That JSON format should have been easy to emulate in the Service Worker APIs if those APIs truly were meant to solve the problem, not just solving more interesting problems in a related space that a minority of use cases needed. Google doesn't currently have enough incentive to make PWAs easy to build, and as long as Chrome is the majority browser, Google is the major obstacle.