Innovation is great, but this kind of churn rate seems excessive. It’s just not possible for developers to make large, upfront investments of time in getting to grips with new frameworks and technologies when there’s no guarantee of their longevity. Programmers want to program – they want to build things, and be masters of their craft. But how can we get anything done when we’re spending most of our time learning? How can we feel like craftsmen when we’re scrabbling in the dark with unfamilar tech?
Once, corporate sponsorship or the backing of a large organization might have provided a beacon. We could look at a framework built by Google, Adobe or Microsoft, and believe that their support meant a long lifespan and careful stewardship. After the crises of Flex and Silverlight, that time is past.
It’s not just the prospect of our tools being deprecated that’s worrying, though. It’s the idea that we might make the wrong bet; get in bed with a technology only to discover that something new and substantially better is coming over the horizon. If it’s now ‘obviously’ a non-starter to use Grunt, or Backbone, or Require, who’s to say that it won’t be ‘obviously’ a non-starter to use whatever tech we’re considering today six months’ down the line?
By using small libraries – components with a dedicated purpose and a small surface area – it becomes possible to pick and mix, to swap parts of our front end stack out if and when they are superceded. New projects can replace only the parts that matter, whilst core functionality whose designs are settled – routing APIs, say – can stay exactly the same between the years.