Javascript build tool quagmire

The last couple of days I’ve been diving into the crazy world of frontend build tools. This post isn’t a look into those individual tools, or my requirements for them; it’s just a quick observation on the state of the industry.

The JavaScript world has millions of tools and libraries, in a range of different categories. Each of these categories seems to go through the same cycle. They start off with a few very clever and very innovative libraries that drive the JavaScript map into new territory. These are followed by an explosion of similar and / or supporting libraries, of varying quality and usefulness. The sector gets saturated with too many options, making it very difficult to make good choices.

From this quagmire, a small number of top performers rise from the pile. The sector slows as the number of new additions slows dramatically, and a lot of the lesser performing libraries go stale, or get archived completely. Most of the focus shifts to stabilisation and improvement for the remaining stars.

These stars often create little ecosystems around themselves, until some very clever and innovative developers find a whole new way to use them, and the cycle begins again.

The sector of JavaScript build tools seems to be in the quagmire stage, and it’s very frustrating. JavaScript projects have needed to be built for many years now, so it’s surprising that there are still so many options, all of which are volatile and unreliable.

That might be a little unfair. The tools available today are all very clever, but their use cases are still quite limited. Each seems to be developed by one of the big players in the JavaScript world, and seems to have started life as a tool to build that player’s libraries or sites. The tools have been shared with the world, and are slowly starting to evolve to support a wider set of use cases, but this is taking time.

In the mean time, if we have a slightly unusual build requirement, us lesser mortals are faced with either trying to shoe-horn one (or one stack) of the existing libraries into a shape we need, or writing something new from scratch. The something new option is very tempting, but is ultimately short-sighted. Very soon after you’re finished your custom solution, one of the big players will handle your use case, and you’ll find yourself with a build system that can’t keep up with the latest industry improvements. No, frustrating as it is, it is a better choice to make do with what is out there as far as possible, and only customise what you have to.

Still, frustrating.