Now that we have compilers and transpilers like Babel and Typescript, it means we can effectively code how we want (even with different languages like reasonml, ocaml, purescript, or ESNext), and in theory browser venders can simply make a new target language or version of JS that these compilers can target.
Also, it's hard to call any language like (Q)BASIC or Javascript a "toy language" when it is used to build so many real world practical applications. The esoteric programming language is full of some truly interesting toy languages. Both Javascript and almost every flavor of BASIC has powered real world applications for decades. The underlying fundamentals/foundation of JS is sound enough that many things have been accomplished with the language, even if it isn't aesthetically pleasing to some (or sometimes betrays its very rough, "quick and dirty" development origins).
(Then there's of course the digression in whether or not WASM is also building a sound VM option for languages that really don't want to work with JS directly on the web/in web browsers.)
Can we stop conflating "it's popular because we had no choice but to build web apps with it for two decades" and "it's a good language", please?
Mud bricks also saw huge usage thousands of years ago. Still doesn't mean they were a good building material for houses.
But mud brick (AKA adobe) actually is a good material for building houses in certain climates, and it's still being used to this day.
If it's the case that Javascript being necessary doesn't make it good, it's also the case that Javascript being old doesn't make it bad.
That's not the argument at all. It's all the quirks and widely accepted strange behaviours that JS devs grew a Stockholm Syndrome for. And that you can do without if you used another language on the browser.
Javascript is an interesting language on the evolutionary chart with genes from Scheme and from Self. While those genetic traits are sometimes obscured by the last minute bolting of an ALGOL-like syntax on top (by way of Java, and thus the odd name), they are still fundamentally there. There are some really smart (albeit quick) decisions underpinning the language that have helped it to survive multiple decades of (ab)use on the web and elsewhere. It has had its flaws, its evolutionary dead ends, its quirks, but show me any language without those (and I'll sell you a bridge).
If there is a risk of a conflation problem here, I'd suggest it has more to do with people conflating "easy/accessible" and/or "populist" with weak or bad. BASIC is "bad" because it was made to be easy and welcoming to beginners. (But it still got a lot of serious work done in almost every field, by just as many [domain] experts as language beginners.) JS is "weak" because it was made for being embedded in browsers. (But the web browser became one of the most important forces on the internet for better and worse, and most of its weaknesses have been scrupulously filed off in daily usage and security audits and the pendulum swings between market competition and monopoly.)
I never said that and never will because it would be quite naive. Let's not resort to strawman.
I don't mind languages being "easy/accessible" -- if I did I wouldn't make Elixir my main language. There are many, valid, well-documented, warts of JS, so much so that an actual book called "Javascript: The Good Parts" had to be written. (I find that quite amusing.)
> I think it is a good language under the hood, and it remains in browsers because it is popular.
You might be mistaking what you said with "we literally had no choice for 20 years except use JS on the browser" (VB, ActiveX, Java Applets et. al. had game-breaking problems, cross-OS compatibility included, so they fell to the sides). "Popular" is the consequence of having no choice for a long time, not a function of any perceived high quality of JS.
Google's efforts with Dart failed simply because Google has a short attention span and their numerous cancelled products can attest to that much better than any argument I could make.
There's absolutely nothing preventing any corporation adopting any language and slapping a small DOM access library on top of it. This is not being done for HR reasons: the companies want to choose from a singular pool of devs so its operations are easier and quicker. A valid business decision which has zero correlation to JS being good.
JS survived because it was "the least bad" at the time when everyone needed a browser language. Everyone is too busy making a living so we just rolled with whatever the browser vendors and corporations half-begrudgingly (and rather urgently) settled at. Assuming you hated JS, can you tell me with a straight face that you'll sacrifice all your free evenings and weekends to produce another browser language? For like 2 years?
> It has had its flaws, its evolutionary dead ends, its quirks, but show me any language without those (and I'll sell you a bridge).
It will have them for a looooong time still though. Even if many will stop supporting IE11 soon-ish, there's still a ton of baggage left that will never get fixed.
The much more likely scenario is people will just start compiling language X to WASM and will go with that when hiring frontenders. And we will see the return of the full-stack role when you actually can work on the entire stack only with Rust, D, Nim, C++, or your language of choice. It is very probable we'll again start seeing web shops proudly touting themselves as "we only do C++ (or PHP, or Pascal) here".
To put anything on the screen in an accessible fashion, you will still need JS with your WASM.
You can draw to a canvas with minimal JS, but lose text search, highlighting text, copy/paste and screen reader compatibility, to name a few.
The tools aren't always perfect, but they get better all the time. It's also a spectrum of choice for which stack you feel comfortable with. Babel and Typescript do increasingly less transpilation with major browser releases. In many cases Typescript today really is just JS with Types. Certainly options like ReasonML and Purescript exist on the opposite end of the spectrum, very little resemble JS, do a lot of more work in transpilation (and do sometimes make JS interop intentionally hard by treating it as an FFI or equivalent boundary). The added "indirection" has trade-offs in productivity, developer "comfort", project aesthetics and synergies.