> It's deployed everywhere and that will not change.

Firstly, why do you assume I use x86? I spent a good chunk of last decade programming against PowerPC, Cell, and ARM in my day jobs. From what I am seeing WRT to x86, there is a small but increasing chance that it might change long-term (or needs to). But pulling your leg aside.....

Anything can, will, and does change. People seem to think the browser belongs to the people, but history has spoken to the contrary. The browser is in the hands of a few large companies, some more benevolent than others. There are also committees, and those are often stocked with people from companies as well. The average person has little say over the progress of the web itself, just like they have little say over the OS. We have literally said what you said about <pick any technology> since the 60s.

I'd argue that the browser is not in fact deployed everywhere and does change with great friction. The browser has a terrible record with regard to universal compatibility and deployment. Every time they improve, they get worse again in some other way. Go look at MDN and the cross-browser tables they list for certain features like video. Further, browsers have a long record of making dramatic changes, and APIs with new or breaking changes. There are also a long list of technologies with regard specifically to media experiences that are effectively no longer around or won't be long-term: ActiveX, Applets, Flash, Silverlight, VRML, the list goes on.

Additionally, tons of people are still using ancient browsers, and probably more on at least out-dated versions which introduces lots of inconsistencies, incompatibilities, security holes, and performance issues among other things. There are just as much if not more problems in this regard with compatibility vs. popular operating systems. Writing compatibility with older apps/standards/formats for an operating system is also miles easier as worst case, ancient stuff can be run pretty readily via emulation or simply ported. Obviously it is by no means easy, but generally time and individual efforts are the main obstacles rather than corporations.

There are things about the browser I like, for example that it allows content to easily be network accessible (in conjunction with http/servers). But we have an entire Internet and huge set of people to come up with other solutions too. I'm not saying the browser can't do many things, of course it can, but rather it is a sinking ship that we pile more baggage on and we refuse to stop. While speed is a concern, I've been more bothered by things such as development experience, access to hardware, security, threading (VLC author directly mentions this), rendering, graphics API, and many other things. If the browser is just going to be a frame around something that could run more directly in the OS, I am not sure if I see the point long-term. People make fun of Emacs for far less.

I obviously understand the needs of the archive, but with all due respect I think they overestimate the range of their audience is when it comes with regard to browsing MODs and such (i.e. not your mom/pop 99% of the time). This is a bigger discussion. I could just as easily pull something down from a web server via a native app like Kodi for arguably a better experience, though I am not suggesting that as a solution. What I am saying is I am disappointed by the lack of creativity and the pigeonholing of the internet as a browser-only experience, when as of a few years ago, 1960s/70s/80s problems such as aligning text reliably was seemingly out of the grasp of the average website. "This time we got it right" is not a good attitude either and rarely, well, right. The browser track record is not a good one and saying "a lot of people use it" has never been a good excuse for much of anything and hinders progress. A lot of people supported a lot of bad things throughout human history, but that doesn't change the fact they are bad. I get pragmatism, but for something like an archive I think we can do better and have more time to do it. Write what you can today in JS if you must, quickly and get some experience to the users, but don't move mountains to do it. If the effort to pigeonhole something takes as long as just developing a more correct solution, what is the point? There is also a larger issue with is more upstream to the issue of where it is viewed and involves things more on the level of how they are browsed, searched, preserved, and served to the end-user; the browser is just one end-point of that.

With regard to WASM, I don't care if it is fast or slow. I am more concerned with the development experience from feel to debugging to maintenance. Having worked with multiple architectures and more direct experiences, I am not filled with confidence when attempting more complex things. Even writing code for lets say Cell or 32 vs 64-bit architectures on your PC and then hoping it works is not without its flaws. If anything, we have proven we are really bad at "write here deploy there" style development as computer scientists, even if the write-side is compatible or the same as the target. But again, the problem isn't so much WASM in of itself, it is the ecosystem it has to exist inside and thus be limited by.

I'd answer the rest of these replies, but my main, much better written response was lost between writing it, being rate limited, and posting it. I zoned out and shut down. Neither OS nor browser helped :)