Also, Emacs windows vs tabs. Think of having each tab be a non-overlapping window within the browser window.
Finally, most browsers don't let JS code modify the browser itself. If I suddenly decide I'd like Firefox's menu completely rearranged, I don't think JS will give it to me.
A specific language is not the point - to implement anything similar to Emacs, you'd need a homoiconic language or at least a language that gives you live, reflective, late-bound image with code-as-data. Without that single aspect tons of things simply and inevitably (as history shows) will get complicated.
Why we have not seen such differentiator with VSCode? Because of their design choices - the extension language and the editor internals live in different worlds behind an API boundary. Emacs essentially has no such boundary. That's the power, and also a consequence of the image + homoiconicity combo.
I've got that. It took 6 years but I developed a comprehensive homoiconic layer for Javascript
People iterating on a problem space over time is the best way we have found to improve things.
The JS ecosystem is not that old and also attempts to solve hundreds of unrelated problems like running software without peoples consent.
And... yeah the consent thing is messy. There's a kind of implicit consent in knowing that a user that does not consent can block scripts. But then it can quickly become coerced consent if there's some IRL reason you need to use the page and it absolutely does not work without JS.
That said, I'm a JS-webapp UI guy. Partly that's just what I've built my career on, largely because it was the new field emerging as I was coming up. I could learn things quickly and convert what I learned into a salary. But the second reason is that I'm disillusioned with HTML as the wire format for the web. If you choose to render HTML on your server, you're centralizing costs in a way that will eventually force you towards an extractive relationship with your users. Not only are you centralizing the cost of rendering and transmitting the HTML, but you're also centralizing the cost of building and maintaining the UI layer.
This is (partly) because HTML failed at being a semantic language. There was a brief flicker of hope with XML and XSLT -- for a hot second you could write a compact semantic document and send it over the wire. No longer...
I hate to tell ya this... LiveScript was renamed to JavaScript in 1995, and the first ECMAScript standard was published in 1997. So not 40 years old, but 31 years old.
NodeJS (liberating JavaScript from the browser) was first released in 2009... so again, not 40 years old, but old enough to have a drivers license.
I agree with you on the other side though: despite the language being relatively old and stable, it feels like the wheel's getting reinvented over and over again and "this will be a good enough pattern for the next decade" hasn't ever really shaken out, unlike Lisp or even Python.
But I understand this particular horror. I might even agree... :D
What it could at least let you do is view JS code using more "Pythonic" syntax rendering. The semantics would still be JS, but you could get rid of the curly braces while you were reading it if you just preferred semantic indentation, for example