4 ms·

JS's syntax wouldn't seep through (backward?) into the compile-to-JS language, which would treat it as safe assembly. You're right that semantic gaps in JS coul

JS's syntax wouldn't seep through (backward?) into the compile-to-JS language, which would treat it as safe assembly. You're right that semantic gaps in JS could make the compiler for Blub fall into the Turing tarpit, needing costly runtime -- see Babel's "spec" vs. "loose" (I hope I have those right) modes. The answer here is to fill semantic gaps in JS, which we're doing in TC39. Evolution can fill gaps in JS, and has: typed arrays are one example; generators another. More to do, but it's not as if the distance x cost to suffer in filling gaps is greater than the distance x cost of doing a de-novo VM among all browsers, on top of keeping JS going. It's much, much less.

WorldWideWayne 12y ago
Slowly evolving a huge platform to keep backward compatibility at all costs is how Microsoft runs many of it's properties. At some point I think an Apple is going to come along and take a byte out of the HTML/CSS/JS hegemony by introducing a new type of browser that is easier to build applications with. At least I hope so! As long as the web remains a broken mess of designed-by-committee compromises, I think there will, at least, always be some motivation to invent a replacement. Maybe you disagree that what we have is broken, but maybe you also know too much to think that building something new is a good idea. Many people have succeeded though, by being ignorant of the fact that X seems like a bad idea to the experts.