A big part of this browser creep was simply that there was friction and danger in native apps, but our demand for more kinds of apps was insatiable and the brow

A big part of this browser creep was simply that there was friction and danger in native apps, but our demand for more kinds of apps was insatiable and the browser was able to soak up that demand. When you ran Windows 95, a misbehaved, even well-intentioned app could wreck your hard drive with relative ease. Most did not, but there are horror stories. And when you went to download it, well, nobody wanted all the clicks of downloading and installing. As ever, the average computer user is undisciplined and impatient. The market provided for this by pushing the browser as far as it could go, because it did text, forms and images and when you have those and a CGI script, you have an app. But now we have gone full circle to the browser being the operating system, and unsurprisingly, it's really bad, being in the position of being a "terrarium" for sandboxing all kinds of software behind an API of some sort. Nowadays we have the alternative models of the curated package manager/app store and more extensive virtualization techniques available. Last night I wanted to try an old Windows 3.1 game. It took a few hours to gather and configure everything but I eventually got DOSBox and Windows 3.11 for Workgroups installed and configured with all the drivers, and the game worked. But the experience of installing this antiquated software reminded me of how Windows itself was a solution to a related kind of compatibility problem: Every program on MS-DOS had ended up in the position of shipping drivers for everything - printer drivers, sound card drivers, SVGA drivers. The solution of Windows was to build a ton of APIs to hide the hardware, just like the browser hides the native APIs. And this solution is a kludge, but a productive one for the near term. It's premised on I/O being bespoken enough that it doesn't have a standard, but not so much so that it can't be addressed in some standardized form. And emulators take that thought in the other direction, adapting new, more capable I/O to old. But I don't think more terrariums (new runtimes) are necessarily the productive way forward. This always comes down to basic theories in and around CS - digital signal processing, Turing completeness, structured programming, relational data. The runtime is a certain endpoint of data that formats to an I/O medium, but it develops the terrarium structure when we start accommodating all forms of media and saying "well, you can set it up in any configuration".