WebAssembly: a binary format for the web

That doesn't sound like an improvement.

As far as the intersection of (innovation in web technology) and (innovation in programming languages) is concerned, I think the focus on performance is like going backwards in time, perhaps to the mid 90s.

I feel like these innovations are being turned into a kind of "social media spectacle" with relatively little discussion of what innovation really means in this context.

For example: I don't understand why Python, JavaScript, Java, Ruby, and so on have not delivered tools that ease the path for those who wish to write applications designed to run code from untrusted sources. I think this would make the web a lot more competitive and overall healthier as an independent institution.

(Yes I understand JavaScript is code from an untrusted source that runs in a sandbox on your computer, the browser client; in this context I'm referring to the ability of a JavaScript web app to load objects (from a JavaScript source code file hosted on ANY domain, in defiance of XSS dogma) which the browser client guarantees does not exceed the bounds of a specified "sandbox" built to spec, a "security envelope" for loading and evaluating code. For example the ability to tell the client, "execute procedure P with arguments A, but kill it if it runs for more than 0.5 seconds of CPU time or allocates more than 500 MB of memory" or "only load this source code as long as the global variables it uses is on this list: ..., the names of properties is uses is on this list: ..., and it refrains from using the following syntactic keywords: ...)

Python put up a warning against its own "restricted execution" a long time ago: https://docs.python.org/2/library/restricted.html

In the age of GitHub, why is there no interest in building infrastructure that allows programmers to define such "security envelopes" for JavaScript, Python, C, and so on and create systems which are composed of mutually distrusting modules which would, I think, simplify reasoning about their security characteristics?

Because they shackle implementations too much. Every time you increase restriction glanularity, you make someone else's life harder. With every restriction or policy you introduce, you've actually increased the implementation's own attack space: you can't stop worrying about validation mechanisms further down the stack, but you now also have to maintain a new set of validations. That's a lot of extra work; given that security is a trade-off, the trade-off in this case is likely not worth it.

Not sure if serious... This comment translates to "except without garbage-collection, and with a loose set of inconsistent and constantly-changing interfaces instead of One Sanctioned Spec."

Java applets were slow to load because fast loading was never made a priority. WebAssembly is prioritizing small size and fast loading.

Java Applets were completely isolated from the surrounding web page, and vice-versa. I tried writing XEyes as a Java Applet back in the day, but the eyeballs could only follow the cursor while the cursor was directly on top of the applet's rectangle. WebAssembly operates on the single unified DOM and its event model.

Because it uses the DOM, the text and widgets are real. The text is selectable, looks like regular text, etc. Java Applets had their own GUI/widgeting system that looked bad and behaved differently.