JavaScript churn has become an emerging problem entering 2016.

The number of JavaScript frameworks and amount of tooling that has emerged recently has combined to create an overwhelming number of options available to the developers of software solutions. The result of this abundance of options is growing uncertainty and the legitimate concern of basing your technology stack on a technology foundation destined to fade quickly into history. At the same time is is unproductive to have to rewrite your site annually to keep up with the front-edge of web development.

Our advice: move carefully in 2016 until things start to shakeout, the increased rate of turnover in JavaScript frameworks and tooling can have a negative impact on your bottom line.

As JavaScript moved from 2015 to 2016 the development community has begun to recognize that things have incrementally reached a crisis point. There is now incredible complexity in the initiation and development of projects on the most current JavaScript technology stack. The buzzword for this is JavaScript Fatigue, expect it to come up frequently in the future. From frameworks to tooling to the language itself, this rabbit hole goes deep and we are starting to see the public face of the discontent (and discontent towards the discontent) concerning the churn rate for frameworks/tools and this increasing JavaScript hype fatigue turning into fatigue fatigue.

What is technology churn?

Technology Churn, as we are using it here, is the rate of change in release, adoption and abandonment of technologies.

In our case, we are speaking specifically of the frameworks and tooling around JavaScript based websites and applications. Churn is important because it affects the viability of technologies; the longer groups stay with a specific technology the more mature, stable and known it becomes. This results is more available documentation in its use, leading to better and proven solutions at lower cost. Technologies which have a faster rate of adoption and attrition in users result in generally lower quality solutions, as most do not get past the introductory phase of cursory knowledge of the platform.

JavaScript churn today

We are in a stage where many groups are all trying to create solutions frameworks to address the complexity of delivering web applications on a browser. It is the expansion before the shakeout: a period of rapid growth in solution possibilities emanating from the increasing adoption rate of the JavaScript language. This results in an overwhelming number of choices in frameworks and tooling including:

Frameworks: Angular, React/(*ux), Cycle, Ember, Backbone, Riot, Knockout, Vue, Polymer, Meteor…

Build Tools: Grunt, Gulp, Broccoli, Bower, Mimosa, Webpack, Brunch, RequireJS…

and there are more. This does not not take into account the other tools for linting, CSS, transpiling, or a multitude of other requirements. Besides the tools and frameworks, the options for modules is massive, as seen via the explosive growth of the JavaScript (NPM) module repository.

A long way from just having the <script> tag and jQuery isn’t it?

As frameworks have come into more common use the problems for which they are being used become the more common. You can now find them in large single page web applications and small brochure-ware sites. This framework churn is not just affecting the large web applications anymore. Things that were once simple are becoming more complex. This, in turn, increases framework proliferation and entrenchment. Having choice is a good thing, but too much choice leads to fragmentation.

The lines are getting muddled between what is the right way to go and what is just a shiny new thing. The result is churn as sites are being developed and redeveloped using new frameworks and tools in tighter and tighter iterations.

The reasonable question would be: why not pick one and stick with it?

JavaScript Churn in the 2000s

Coincidentally this month is the jQuery JavaScript library’s 10th anniversary. jQuery emerged as the winner of a very similar shakeout process which occurred with the first generation of the JavaScript client-side libraries. Little under a decade ago jQuery was one of a number of options for client-side JavaScript library use: There was Prototype.js, Dojo, MooTools, Scriptaculous, ExtJs, YUI… They eventually faded away and jQuery dominates as the absolute defacto client-side JavaScript library to this day.

This left a lot of sites built around tools that were no longer getting the development push to keep current. As more developers used jQuery, jQuery had more development and these other libraries faded faster. You do not want to be the developer keeping a site alive using tools nobody is supporting any longer. As the browser ecosystem itself is in an increasing pace of iteration your tooling must stay current. These sites, then, stagnate as it becomes more difficult to modernize, the browser base then modernizes beyond them and most importantly, less new developers understand their frameworks and tooling.

Part of the allure of the shiny new thing is that it may become the actual thing and should you not have some investment in it you may be left behind.

The situation in 2016

The situation entering 2016 is worse than a decade ago. Rather than having 4+ choices each created by individuals or small teams, there are 10+ with some backed by the largest companies in this business. At the same time JavaScript has become huge, with a proliferation of tools around the language. The ecosystem has become diverse, the ecosystem is getting difficult to stay current against, developers are starting to burn out on it, the ecosystem is fragmenting.

Technology churn and its impact on your business

The business problem is the impact this shakeout period is going to have on the codebases of companies for years to come. Developers come and go, but the foundational choices they make for your company’s technology systems have lasting effects.

 Legacy in regards to the web is unlike legacy as typically defined in software; we consider web legacy as between 3-8 years old. Often web systems are built by teams that have since moved on, but leaving sites that still need to be updated and maintained. Too often the “shiny new thing” becomes legacy software, which becomes more difficult to maintain as the foundational underpinnings are abandoned. Fewer developers are familiar with those systems and therefore the opportunities for and cost of the maintenance become crippling. Adding new and needed features and functionality becomes prohibitively difficult and expensive.

In our roles as Virtual CTOs, Web Developers and especially as technical mediators, we are exposed to both sides to this debate. The fear of choosing a platform destined to quickly become outdated verses the need to provide tangible and cost-effective value with the delivered product. Websites requiring constant re-writing to keep up with the new new thing do not provide good value for the business. Neither do systems which become too difficult to maintain after a short window.

2016 will be a hard year to make these choices.

The JavaScript ecosystem has yet to shakeout and there are many options available for systems being built today. You need to critically assess if a specific framework and toolchain makes sense, and if makes sense to use right now. Keep these principles in mind:

  • Does this add appreciable value to the site and its users?
  • Does it solve your problems of today, not the expected problems of tomorrow?
  • Can you afford to replace this in a year?
  • Can you wait longer before initiating or redeveloping?

If you have to use a rich client-side framework, try to minimize disruption if the site must eventually be moved to a new system. Rather than write a large single page application in a framework, break the solution down into multiple pages and try to isolate the framework components to only the necessary areas.

Most importantly, know what you are getting into from a long term support and maintenance standpoint.

Development teams, and the shiny new thing, can come and go, but this software ultimately becomes your responsibility to keep going, years after it ceases to use the Most Favored Framework of its day.