[beetwenty]

I've been working on a fantasy console, which touches on this "design down" space. It's the kind of endeavor that lets me iteratively redesign to go deeper and deeper into the stack, by starting off with "scripting plus some kind of I/O", gradually extending the concept, and then, more recently, to shift towards using WASM, memory maps, a BIOS layer, and an emulator UI layer, giving me more spec clarity.

The I/O boundaries and resource limits are the really important bits: A web browser is ultimately just a bundle of I/O functions buried inside specialized feature APIs, with only some very specific "patch this" limits for maximum resource consumption. This has allowed the size of web apps to creep upwards indefinitely while not being able to actually do every task, because the feature APIs sandbox in a haphazard "intended for the average consumer" way. When you add in comprehensive limits, the design and the software built on it are able to last: it's the lack of limits that has always created software crises.

One could imagine, instead of the browser as a lowest-common-denominator sandbox, a fantasy system specialized "for text editing", which has a different spec from one specialized "for 3D graphics": This would narrow the scope of sandboxing, make it easier to task-optimize, and yet also create the need for a Lisp or Smalltalk type of system that needs flexibility "for prototyping". It's not an unreasonable path, considering how broader trends in computing are leading towards hardware specialization too.