Imagine if time travel was possible and we could go back in time and avoid this :-)
Be careful what you ask for.
Microsoft of the 1990s seemed to never be able to decide whether they want to follow "Embrace, Extend and Extinguish" or NIH, so they usually both implemented slightly-incompatible versions of popular technologies, and then shoved in their own in-house technologies alongside.
That's how you got both ActiveX Controls and Java Applets (both sucked). That's how you got both Visual J++ and Visual Basic (J++ was superior), and later both J# and C# (this time C# was superior, but could you expect anything less from Anders Hejlsberg?). That's how you got both VBScript and JScript running on JScript (a little know fact that made it possible for me to script Windows 2000 machines without running through a decade's supply of vomit bags).
If there was no JavaScript, I think Microsoft would have gone with something like ActiveX, instead of rushing to deliver their own a quick and dirty implementation of a scripting language. But we wouldn't get an almost-decent scripting language embedded in every windows machine, and I would have had to automate all these machines using BATCH files!
- language features like module loading, async, classes arrow functions etc. would be unnecessary or trivially implementable within the language
- libraries like React et al would be much simpler
- plenty of FP libraries would be either unnecessary or much simpler
- things like "hot reloading" during dev time would be much simpler and actually work out of the box
- simpler parsing and more cross pollination in terms of runtime performance
- type annotations could be implemented trivially in user space, the runtime could evolve into respecting them for performance gains
- tooling complexity would be much reduced because of all of the above
In the end, JS has been a net good for the industry. I don't work in it, but it's turned into something decent over the years though the frameworks around it are insane. But it took 15 years to get to this place and become a "grown up" tool, imho partially because of some odd choices early on.
Scoping: Especially initially, the scoping rules were really wonky.
OO: I am actually a fan of prototype inheritance (Self & LambdaMOO FTW) but the form implemented in JS was confusing for most people and they never understood it, esp given Java was ascendant at the time with its very strict and boring class-based model. I think some clarity was needed here. Lack of standardization around how to do objects, inheritance, encapsulation led to a total bizarre mixture of approaches and misunderstandings.
Essentially I just think having it passed over by some more sober minded language designer types who had research background in e.g. Scheme, Lisp, Self, etc. would have been good.
Going all in on JS instead of wasting time with the ill-fated Java applet stuff would have been good for the industry. It's what the industry ended up doing eventually anyways, but it took until the 2000s before this really clicked for people and they finally gave up on the various half-baked dynamic plugin solutions (Flash, ActiveX, Java applets, etc).
The "Java" in the name was/is a problem and led to a decade of stupidity. I understand how it happened, but it shouldn't of.
That void never really existed. There was the right way to do it, basically the same way that ES6's class syntax actually works today, and then there were a bunch of people fooling themselves into believing that the impedance mismatch that resulted from writing code against their own derpy metaprogramming system they'd devised themselves was acceptable. The attitudes associated with that mindset never really went away—it's what drives the demand for stuff like Webpack, along with NodeJS's CommonJS-inspired approach to modularization infecting everything and the README for create-react-app providing list of steps to get someone up and running requiring them to download half a gigabyte of packages to their disk before they can successfully complete the Hello, World exercise, not to mention the abstraction (and resulting boondoggle) that is React itself.
Actual "serious" uses of JS didn't really ramp up until the end of the decade, and by then people were doing what you're saying, yes.
Netscape releasing a style guide with the language, and a set of standard libraries that used them, that would have helped.
But everyone back then was too distracted with "Java is the Future of the Browser" (Narrator: It Wasn't)
Nobody could've known how bad things would become after Js was inflicted on the world... right?
Did you ever tried implementing a desktop UI using an object-oriented multi-platform toolkit like SWT or QT or GTK? There are good chances that all the dependencies you will need are already "there", you learn the widget toolkit bindings for your preferred programming language and you can start. It's so much more productive and fun (at least for me) and most of the time you don't need to mess up with colors, styles etc. etc. because you will want the operating system to take care of that.
On the Web you have so much more freedom, because the web page is almost a canvas, but at the same time (for me at least) it looks way less productive and everytime I think of it, I always wonder why nobody is proposing anything better for the Web and the industry keeps on building layers of complexity on top of JavaScript/DOM/CSS.
For a very loose definition of "need".
> Did you ever tried implementing a desktop UI using an object-oriented multi-platform toolkit like SWT or QT or GTK?
There's an abundance of desktop application code written in JS from the GTK+ folks themselves. They embraced SpiderMonkey (the Mozilla JS engine) years ago and have been shipping stuff on it for just as long. Anyone who has booted into the default desktop on Ubuntu—or any other installation running Gnome—has already come in contact with it, perhaps even today. That doesn't get a lot of attention, though, because it's not "squeaky": it isn't plagued by the same problems that people (stupidly) associate with "JavaScript" despite the fact that what they're really thinking of are problems with the NodeJS/NPM community in particular and its spectacular tooling + other webdev-oriented accomplishments. I.e., all the things it insists are requirements for the Modern Programmer—a mission which their detractors assist them on by perpetuating the story themselves (cf "need")...
And it sounds totally legit to me. If instead what you are referring to is something similar to Electron, that is something I "hate"; I understand it's a cheap way for a Web Developer to reuse the skills and build a desktop application, but the result is typically buggy, bloated, slow, and does not integrate properly with the desktop environment (fonts, colors, clipboard, accessibility are just the first things that come mind).
The things you're complaining about are not a JavaScript problem. They're a programmers-who-have-their-feet-firmly-planted-in-the-world-of-NPM-and-modern-webdev-tooling problem.
> something similar to Electron[...] is something I "hate"
Wait till you find out how Firefox itself (i.e. the UI and other application logic) is implemented: "DOM, CSS and plain JavaScript". Mozilla was doing Electron-style apps before Electron ever existed. Somehow it's a higher quality app than the sorts of things you had in mind when you brought up Electron. Again: that's because it's not a JavaScript problem.