I don't think this is a software problem. It's a general legacy systems problem. Think of self-driving cars. It seems plausible that one day all cars on the street will be self-driving, at which point the existing system -- which was designed for humans -- is a legacy system that is not efficient for the current users. If you were to design an autonomous transportation system from the ground-up I doubt, for example, you'll put in stop signs that cars have to read via machine vision. You'd probably have that information somewhere on the internet (or better yet, design something from the ground up that doesn't require stopping).
You can see how this translates to computing. The reason why I still have to deal with a `document` object while building apps in JavaScript is because we built an application distribution platform on top of a document viewer. There is no centralized planning here -- we're just riding a wave of distributed innovation and making the best out of it. (Nor should you expect centralized planning in technology to emerge unless a superintelligent AI system takes over).
Javascript is the app distribution platform that won, because the others were worse.
ActiveX? Too much lockin, no sandbox. Java applets? Too heavyweight. Flash? Nice tooling for the producer, terrible security record. ClickOnce/Silverlight? Never really got out of the gate and would have been MS/Win only.
The next generation of app distribution is "app stores" with arbitrary refusal policies which take a 30% cut of sales. A success for Apple.
Javascript mostly delivers "write once, run anywhere", albeit through a vast shifting layer of shims. Its sandbox is pretty reliable. It's not owned by anyone and they can't stop you shipping JS apps. Thus it survives.
I agree with most of what you said but you're conflating languages and platforms. JavaScript as a language says and does nothing about sandboxing. It's the browser that does that. It doesn't even specify anything about concurrency (up until promises maybe) or the event loop. The event loop is a feature of the host environment. When Netscape put JS on the server they used in CGI mode.
So I wouldn't completely remove the browser from the picture. Had it been Lua or some other simple general purpose programming language that was the language that ran in the browser I'd say it would've been the JavaScript of today.
(I think one other component of this is "worse is better". JavaScript was easy to copy and implement, although not elegant or the best designed language)
For whom? The author of the post says that the only thing that matters is the end user, and I would bet my life that almost all users of browsers think it is great to be able to do "almost anything" on it. The rest is indifferent except a minority which is people who are in your category.
"Almost anything" has come to mean "display so many ads I need a brand new computer to have enough CPU left to see the actual content", "spy on my every behavior", and "install five kinds of malware on my system" for many users.
Maybe the time will come for another document viewer. Resurrect gopher? Reuse epub? Steal from Xanadu?
It should at least fix some mistakes of the web. The core challenge is to define what was a mistake and what was not.
Built-in micro-payments, so we don't have to rely on Ads? This did not work out anywhere so far. Maybe with Bitcoin it is different today? Alternatively, should all information be free and everybody just pays with bandwidth?
Should links be uni-directional? Or bi-directional? And can we fix link-rot then?
You can see how this translates to computing. The reason why I still have to deal with a `document` object while building apps in JavaScript is because we built an application distribution platform on top of a document viewer. There is no centralized planning here -- we're just riding a wave of distributed innovation and making the best out of it. (Nor should you expect centralized planning in technology to emerge unless a superintelligent AI system takes over).