3 ms·

ECMA standardized ECMAScript in 1997, only two years after Netscape Navigator first shipped Javascript. ECMAScript and Javascript are the same thing. I've never

ECMA standardized ECMAScript in 1997, only two years after Netscape Navigator first shipped Javascript. ECMAScript and Javascript are the same thing. I've never encountered a language level incompability in the different ECMAScript implementations. The same can't be said e.g. about the extremely commitee driven C++. The browser APIs are specced by W3C and WHATWG. For newer APIs there are usually differences in browser implementations, but these tend to get ironed out quite fast.

solardev 3y ago
While this might be technically true, my own (anecdotal) experience has been quite different. I've been writing JS since its invention, initially just using it (as a kid) for silly Geocities gimmicks and infinite window.alert() loops. I still remember how back in the day no two browsers had a totally compatible JS implementation (especially when Microsoft was busy trying to embrace-extend-extinguish), some things would be subtly different (like datetime handling, or window vs document, whatever)... it wasn't just me either, there used to be a lot of articles that discussed things like that. Here's one: https://burningbird.net/netscape-navigators-javascript-1-1-vs-microsoft-internet-explorers-jscript/ https://burningbird.net/netscape-navigators-javascript-1-1-v... In my memory, nobody really discussed ECMAscript back in those days. It was more about Netscape/Mozilla vs IE vs Phoenix's JS engines (can't remember if Phoenix used the same JS engine as Netscape), and then different versions of jQuery or early Angular, browser prefixes, early polyfills that you copied and pasted manually, etc. Even up till a few years ago, it was still quite common to have to check CanIUse to make sure a method was supported everywhere. It was ES6 that really brought ECMAscript into popularity... this Google Trends graph shows the correlation somewhat, though both are totally dwarfed by "Javascript": https://trends.google.com/trends/explore?date=2004-01-01%202024-01-10&q=%2Fm%2F019syg,ES6&hl=en https://trends.google.com/trends/explore?date=2004-01-01%202... (and it doesn't go back to the 90s, only 2004). And the ECMAscript core definition is very narrow, only dealing with core language features and not the greater JS ecosystem, which is how we end up with a bazillion runtimes, TypeScript, third-party libs for everything from components to deep copies to state and routing and testing etc. ECMAscript by itself is super barebones, maybe enough to make a simple serverless func with, but hard to write an entire app in without third party frameworks and libs. I can't speak to C++ (never worked enough in it), but even PHP by comparison had a wonderful standard library, and de-facto standards in the form of Symfony and Laravel that provided most of the missing use cases. In the JS world it wasn't until AngularJS that we really had something like that (but nobody wanted to use it), and now finally Next.js (which is thankfully super popular). Even then, you had to supplement those on the HTML side with something like Bootstrap, and on the CSS side with something like SASS or LESS. (Thankfully, CSS itself is also getting better these days.) --------- I don't know that this anecdote really disproves anything you're saying (and it's not meant to), just illustrating that even when standards exist on paper, the ecosystem is of a language is more defined by its real-world usages. And for both JS and its siblings (HTML, CSS, SVG, Canvas)... the journey to get to where we are today was very, very messy and full of a million incompatibilities.

solardev 3y ago

While this might be technically true, my own (anecdotal) experience has been quite different. I've been writing JS since its invention, initially just using it (as a kid) for silly Geocities gimmicks and infinite window.alert() loops. I still remember how back in the day no two browsers had a totally compatible JS implementation (especially when Microsoft was busy trying to embrace-extend-extinguish), some things would be subtly different (like datetime handling, or window vs document, whatever)... it wasn't just me either, there used to be a lot of articles that discussed things like that. Here's one: https://burningbird.net/netscape-navigators-javascript-1-1-vs-microsoft-internet-explorers-jscript/ https://burningbird.net/netscape-navigators-javascript-1-1-v... In my memory, nobody really discussed ECMAscript back in those days. It was more about Netscape/Mozilla vs IE vs Phoenix's JS engines (can't remember if Phoenix used the same JS engine as Netscape), and then different versions of jQuery or early Angular, browser prefixes, early polyfills that you copied and pasted manually, etc. Even up till a few years ago, it was still quite common to have to check CanIUse to make sure a method was supported everywhere. It was ES6 that really brought ECMAscript into popularity... this Google Trends graph shows the correlation somewhat, though both are totally dwarfed by "Javascript": https://trends.google.com/trends/explore?date=2004-01-01%202024-01-10&q=%2Fm%2F019syg,ES6&hl=en https://trends.google.com/trends/explore?date=2004-01-01%202... (and it doesn't go back to the 90s, only 2004). And the ECMAscript core definition is very narrow, only dealing with core language features and not the greater JS ecosystem, which is how we end up with a bazillion runtimes, TypeScript, third-party libs for everything from components to deep copies to state and routing and testing etc. ECMAscript by itself is super barebones, maybe enough to make a simple serverless func with, but hard to write an entire app in without third party frameworks and libs. I can't speak to C++ (never worked enough in it), but even PHP by comparison had a wonderful standard library, and de-facto standards in the form of Symfony and Laravel that provided most of the missing use cases. In the JS world it wasn't until AngularJS that we really had something like that (but nobody wanted to use it), and now finally Next.js (which is thankfully super popular). Even then, you had to supplement those on the HTML side with something like Bootstrap, and on the CSS side with something like SASS or LESS. (Thankfully, CSS itself is also getting better these days.) --------- I don't know that this anecdote really disproves anything you're saying (and it's not meant to), just illustrating that even when standards exist on paper, the ecosystem is of a language is more defined by its real-world usages. And for both JS and its siblings (HTML, CSS, SVG, Canvas)... the journey to get to where we are today was very, very messy and full of a million incompatibilities.