Why is the JavaScript ecosystem evolving so rapidly?

The JavaScript ecosystem has progressed significantly faster than most other programming ecosystems over the last decade. The number of frameworks and tools that rose in popularity then lost mindshare is remarkable. I want to explore a couple of reasons why JavaScript has evolved faster than other languages or platforms.

There were four different factors that I think came together to start the JavaScript library revolution. First, there was significant churn on the browser side. Second, broadband penetration increased significantly. Third, AJAX became a common way to construct more interactive pages. Finally, an increasingly broad set of server-side technologies for generating web content also rose in popularity. Let me walk you through these factors and how they impacted JavaScript’s evolution.

When Firefox initially started to increase its marketshare, it started to put pressure on IE, and to a lesser extent, Safari. This led to a significant proliferation of browser compatibility issues, which itself led to the development of a series of JavaScript libraries to try and mitigate these problems. The underlying web technologies (XHTML, CSS 2.1 etc) changed at this time causing, people to want to try to adopt the new functionality. But, a slower end user update cadence for browsers meant that developers had a much wider variety of what needed to be handled under feature detection to ensure your site functioned under all supported browsers. This brought about an early generation of libraries to try and paper over all of the browser differences.

The rise of broadband and AJAX combined to cause a significant increase in the amount of JavaScript being used. Broadband allowed page sizes to increase without harming load times and AJAX took advantage of this to fill up the increased page size with JavaScript. This increase in hand-rolled JavaScript also created new places to try to build more libraries responsive to the new need. It also created a need for more framework-style libraries to guide developers toward newer ways to implement more complex architectures.

The broadening of server-side programming technologies brought a number of different perspectives to people interacting with JavaScript. PHP programmers would have a different view from Java programmers, and both would have a different view from Perl programmers. Everyone brought their perspective to the development of even more JavaScript libraries and promoted them in their individual communities. This also helped foster a number of different perspectives on what you should do with JavaScript and how to do it.

These factors combined to set the scene for the explosion of different JavaScript tools and frameworks we’ve seen in the past 10 years. We’ve also seen the browser wars got increasingly active, with Chrome taking share from IE and Firefox. Browser technology also continued to advance leading to HTML5 and CSS3 adoption. Broadband adoption continued to spread, and speeds picked up. Mobile added a new dimension to creating standards-compliant pages that look good at many different resolutions and screen sizes. AJAX was taken to its conclusion in single-page applications and their associated frameworks. The existing frameworks have also been cross-pollinating ideas and getting recombined in interesting ways.

All this movement has created a lot investment into JavaScript engines. For example, Chrome got a 5x performance increase between 2008 and 2012, and Chrome’s JavaScript engine was considered fast before that happened. The result of all of this investment was reaped by node.js, which  continued to create even more JavaScript libraries most of which could be included in the browser too. And that, of course, back more capabilities into the browser. This enabled even more client-side functionality and continued to feed the JavaScript ecosystems growth.

Stacked on top of all of this are the tools to help manage tools, e.g., grunt and gulp for running tools on the server side, and require.js to help load all of these libraries on your page. These tools, plus minification and linting tools now written in JavaScript, help bring JavaScript into a fully-tooled ecosystem.

I expect the different libraries to continue to recombine and evolve as time progresses. Assuming the underlying browser technologies stay as incremental improvements, like ECMAScript 5 to 6, I think we’ve crossed the largest period of flux in JavaScript libraries. There has even been backlash against frameworks as part of the zero framework movement, which, if its adherents succeed, should slow the growth significantly.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s