In early October, there was an article discussing the constant toolkit churn in the Javascript community covering all of the dependencies and issues and libraries needed to start developing in Javascript with a quality toolchain — all to illustrate the amount of churn in the ecosystem. Lets call this phenomenon toolchurn.

I saw many, many comments on this article and much back and forth. Then recent I read an article on HackerNews about a school shutting down its IT department to replace their staff with lower cost workers. Some of the comments began to cover ageism in the tech industry, when it dawned on me:

#Toolchurn isn’t a bug, its a feature!

This article isn’t necessarily about the Javascript community, but it presents it as a good example as shown in Jose’s article — and I’m sure there are plenty of languages where such behaviour exists.

Constant replacement and upheaval of a language base destabilizes developers and encourages companies to churn staff as the languages churns out new tools.

Not long after the original article came out, Facebook announced the release of Yarn a new package manager for Javascript.

Now good or bad, Facebook holds enough clout to make such announcement stick. And from my admittedly limited experience server-side Javascript experience, npm is (was) a fundamental requirement to development — until Yarn showed up.

The advantage here for any development companies is that by working with Yarn the developer pool has now has flattened — whereas someone may have had 5 years experience with npm, by jumping to Yarn the best and the worst developers are now equal (at least with respect to package deployment). Skills will always be transferable, but experience is still important.

We can see similar behavior in Angular vs React vs HotNewFramework.

There will always be people with spare time learning HotNewFramework to see what else there is or simply because Google/Facebook released it and they want to keep up. Whereas many career programmers will be working on projects in OldBoringFramework and not have the time to keep up. In effect we are now trading limited relevant experience in a new tool, with long term experience and possible skills transfer.

When this happens, if the community keeps jumping from Framework to Framework producing constant toolchurn there is no room for developers to become deeply trained in any given language which will only damage at best, the given language and at worst the whole profession.

This isn’t to say that stagnation is the key, but there must be a middle ground, that encourages innovation without constant upheaval.

This post also available on Medium