JavaScript could have had a better design without impacting adoption. Likewise if IE had fixed the language along with all the other improvements they added, it'd also be better by now.
IPv4 is vastly better than JavaScript for what it does.
I know this because I tried for a better design via JS1.2 in Netscape 4, enabled by opt-in versioning (<script type="application/x-javascript; version=1.2">). This was in 1997 while standardizing ECMA-262 Edition 1 (ES1).
And based on this JS1.2 experience (in beta, and it went to final in Netscape 4 when that dog finally released), I argued to the Ecma TC39 TG1 standards group that ES1 should incompatibly change == and != to work as === and !== do in JS today and since ES1.
Microsoft's JScript lead rejected this change as breaking, counterproposed the === and !== operators, and we all agreed. We also rightly decided not to impose opt-in versioning then, or ever after (1JS FTW).
(Irony: in 1996 summer, the same MS lead had mailed me privately to propose some incompatible changes to give JS "a better design", but I couldn't make them without breaking the Web even then.)
So almost 20 years later, asserting that something adopted widely and rapidly on the Web "could have had a better design without impacting [further] adoption" is easy to do but hard to prove. I did try, with == and !=, and that attempt bounced because of adoption-in-full (taking in versioning and backward compatibility).
Number-locked versioning and related protocols such as content-negotiation via the Accept: header have failed hard on the Web, over and over.
Sure, lots could have been better, but the time to get it right was 1995 May, not during standardization in late 1996 or 1997. At that point, "don't break the Web" prevailed, as it does still, among competing browser vendors.
In Firefox bug 988386, we started collecting telemetry on how often users see web content with JS versions. The hope is that we can remove some of non-standard language extensions like `for each`, old-style generators, and destructuring `for (var [k,v] in x)`. XUL is ignored for now because it defaults to JS 1.8.
So far, version telemetry shows that JS 1.7 and 1.8 content does exist on the web, but I'm not sure how or why people are using these language extensions. I hope to add telemetry for actual use of the extensions instead of just the <script> tag version. Maybe these <script> version strings were just cargo-cult copied code and the enclosed JS is actually not using the extensions. :)
If Brendan Eich wouldn't have rushed the JavaScript design, Netscape would've chosen another language which was already in the works (or complete?). It was apparently similar to PHP, and probably would've been worse than JavaScript.
Something got garbled here -- apologies if it's my fault, please cite your source and I'll try to fix it upstream.
The PHP (but much simpler) server side embedded mini-language idea was part of LiveWire, and would never have made it into the Netscape browser instead of JS. Rather, it was intended to do conditional server-side markup, string interpolation based on HTTP header values, etc.
Upper management -- Rick Schell, VP Engineering -- argued "we already have two languages, we can't justify three". The two were Java and JS. This killed the PHP-like exercise.
I rushed JS for many reasons:
1. Everyone at Netscape was rushing, because Microsoft was coming after Netscape and we all knew it. People were working around the clock. This was not healthy, but it happened.
2. There was little time to get the rest of the browser JS integration (AKA "the DOM Level 0") done in the rest of calendar year 1995 before the code froze for Netscape 2.0 final. The first public beta was in the fall, and code freeze in early fall or even late summer (my memory fails me here) meant critical bug fixes only after that point.
3. The Netscape IPO was coming up, which added to (1).
4. JS was called Mocha, then LiveScript, but Netscape marketing wanted to get the JS trademark, which required showing Sun that a VB-like companion to Java was viable. Some of the rushing was based on trying to keep Sun on board, in the person of Bill Joy (who eventually signed the trademark license for Sun, as "Bill Joy, Founder, Sun Microsystems").
5. LiveWire wanted JS frozen as its server-side language, and was on its own hard-charging schedule. I think it was trying to release with Netscape 2, but again my memory fails me. Anyone reading this who was there should weigh in.
IPv4 is vastly better than JavaScript for what it does.