Sure we have WASM on the horizon but too much needs to be worked out before we can say that Javascript is no longer necessary.
But what if all the browser developers come to an agreement to natively support another language as a first class citizen.
Which language would get your vote?
I have often wondered why Javascript was so widely used instead of Lisp to begin with.
Why did such a syntax get into every browser? The Wikipedia has a synopsis of the well-known story:
> [Brendan] Eich started work at Netscape Communications Corporation in April 1995. He originally joined intending to put Scheme "in the browser", but his Netscape superiors insisted that the language's syntax resemble that of Java. As a result, Eich devised a language that had much of the functionality of Scheme, the object-orientation of Self, and the syntax of Java.
Java was a hot buzzword around that time.
So one way we can look at it is that it was developed too early. Eich eventually became CTO and then CEO of Netscape. Had he started hacking on a Scheme in the browser at that later time, there would be likely be no vapid "Netscape superiors" who could push the bullshit Java syntax.
Had Eich put Scheme in the browser, it would have had (let ((var ...)) ...) from the get go. Instead, the world had to wait until 2019 (or whenever it was) to get "let var = ...;" that is properly block scoped rather than function scoped.
I think if we had Scheme in the browser instead of Java, we would still have other syntaxes via "transpilation" anyway, just the same.
Transpilation would be nicer because you can use macros to develop a more ideal target language for your syntax, so the transpiler has less to do.
E.g. suppose you want pattern matching. It would make more sense to make pattern matching in Scheme, and then just a syntactic sugar for it that looks Java-like, than to implement the Java-like syntax and the pattern matching expansion in the transpiler. Plus it would be available to more transpilers: different syntactic sugars could easily share the same pattern matching sublanguage. The semantics would be documented just once; to go from one surface syntax to another, you'd just learn how the new one maps onto the semantics you already know.
Personally, I wish we had more of a .NET style model, with a unified runtime that different languages can "compile" to. People who like a Basic-style language can use that, others can use C#, etc.
As a web dev, I don't dislike JS as much as I dislike the DOM. It's in the very name: the DOCUMENT Object Model. But so many modern web apps aren't documents anymore. Even a word processor like GDocs isn't a document. HTML makes sense only for a very specialized type of UI: things resembling articles or blog posts. It's a poor fit for anything else, requiring a lot of CSS to get something as simple as basic responsiveness working.
I wish we had a proper cross-platform UI markup language instead, something that can read and edited by humans directly but is also simple for higher-level languages to directly manipulate. It can be XML based (lke JSX) or something entirely different, I don't care, but it should have a good standard library for common interactions (e.g. validate this form, try to send this API request up to X times, parallelize these requests) and a good set of UI primitives, not just a simple <button/>, but say, <fullscreen_modal/>, <serverside_autocomplete/>, <loading_indicator/>, etc. that can be styled differently, but whose internal logic is handled as a matter of language standardization, with additional features being supported by plugins.
It doesn't even have to be a browser. If Android apps could work across platforms, for example, I'd just learn that stack instead. I think that's the reason people reach for Electron. .NET tried that but failed to gain any mindshare on non-Windows desktops or phones. Java did that in the very early days but then the Web won.
Sadly, I think anything this mass-market (how many billions of users now?) will always trend towards the lowest common denominator, not the best possible developer ergonomics. That's too bad, but also... it's prob more important to reach the users where they're at (with their semi-modern browsers, which is already a lot better than the IE days) than to try to make something better for the coders alone.