Ask HN: Why is everything in JavaScript changing so fast?

Brendan Eich initially designed JavaScript in an infamously short time--he coded and designed the first prototype of JS in just 10 days.

It quickly became the only programming language you can use in a web browser, with multiple vendors, including Microsoft, owning mostly compatible implementations. Due to trademark disputes they couldn't even call the language standard "JavaScript," so the language standard is called "ECMAScript."

Microsoft didn't want/need JavaScript to change or grow at all. Once Internet Explorer 6 became the dominant browser on Windows, (which was and still is the dominant PC operating system,) they stopped releasing new major versions of IE for five years (2001-2006), and IE7 wasn't a very big upgrade, especially in terms of JS language features.

Mozilla unilaterally released new language features that only worked on Firefox, so nobody could use those language features in practice on the web; in many cases, new language features wouldn't even parse in IE.

In 2007, there was an attempt to build a major new JavaScript version (ECMAScript 4) with a ton of new features, (classes, a module system, optional static typing, algebraic data types) but it was scrapped due to disagreements between Mozilla and Microsoft. They wound up implementing a much more modest upgrade (ECMAScript 5) which shipped in IE9.

In all this time, there was essentially no interest in running JavaScript in command-line tools or on the server side. That changed in a big way in 2009 with Node.js. It used V8, Google's JIT engine for JS, and it was surprisingly fast.

This is when the language really started to unthaw. IE declined in dominance as Chrome rose, and the demands of server-side development started to be felt more strongly in the JS community.

ECMAScript 6 started to add back in a number of cool features, and by this time, JS developers were desperate to use them. This lead to the development of "6to5," (now called "Babel") which allowed you to write code in ES6 and "transpile" it into older JavaScript versions, so developers could experiment with new language ideas without pushing them through the standardization process.

Languange evolution kicked into high gear at that point. There are a bunch of interesting pluggable transpilers out there, including TypeScript, JSX, and Flow, and countless non-standard plugins for Babel.

And that's just the language itself! The "standard library" for JavaScript for years was just "whatever IE6 could do" and that wasn't very much. IE6 was pretty buggy as well. jQuery became popular as a library to smoothe over differences between browsers, but mostly to work around bugs in IE.

Client-side frameworks were tough to implement on IE6, not least because IE6 was just so darn slow. As newer, faster browsers came out, it became possible to trade off some performance to improve developer productivity.

And everybody has their own ideas about what those trade-offs might be like!

At the same time as IE6 started to decline in popularity, the mobile web on iPhone and Android rose in importance. Smartphones include a bunch of new sensors (GPS, orientation, camera) and new limitations (RAM, slow/unreliable network). This spurred on browser vendors to "compete with native apps," adding features to the browser platform, inviting developers to respond to these with new frameworks.

As for the JS server-side, Node.js is still a relatively young platform as these things go, and so it's not surprising to see a lot of churn in server-side libraries/frameworks, especially given how much churn the language itself is undergoing.

Node.js is also the first major platform to be born in github, which IMO encourages experimentation (and flame wars) via forking.

Node.js's standard library is designed to be small, (they call it the "core" and resist Python's "batteries included" philosophy,) forcing folks to rely on libraries and frameworks to keep the lights on. Even most libraries themselves need to take dependencies on other libraries, because of this "small core" philosophy.

I think it's going to be at least a few more years before things start to cool off a bit. Enjoy the ride, if you can!

Perl has Larry Wall. Python has Guido van Rossum. PHP had Rasmus Lerdorf and later Andi Gutmans and Zeev Suraski (Zend). Ruby has Yukihiro Matsumoto, and Rails has David Heinemeier Hansson. JavaScript came from Brendan Eich, but it was like a work for hire, wasn't it? Microsoft and Netscape just kind of ran with it.

Then I guess it did have a shepherd, the W3, and all the browsers followed its standard, except the one that had 90% of the market. At long last, in the past few years, market share has passed to companies that are much more willing to follow open standards.

But at the same time, the user base is huge, a churning mass of millions of programmers of every level of ability, and each one of them can now publish their framework on Github. Plus there are several large web companies that are competing with each other.

Thankfully at least the language itself has a single standards track. Cross-browser agreement isn't perfect, but it's much better than it used to be. It's just that we don't have a standard library, like Perl's CPAN. Instead we have NPM.

I wasn't paying enough attention when Perl and these other languages developed, so I don't know for sure why they're different, or even if they were that different at this stage. Even they have their different web frameworks to this day.

Compare it to say, creating a new operating system. Sure the world could benefit from a better OS, so why not make one? The perceived benefit is small (why do this when Linux exists) and the cost is large (it's hard and you need a lot of knowledge).

Also a lot of half baked ideas. The number of js writers is huge but on average very inexperienced compared to other languages.