Javascript Tooling - The Evolution and Future of JS & Front-end Build Tools

CodeKit

The GUI

CodeKit and Grunt both came out early 2012 as tools to get your front-end assets web ready. They both helped compile & minify files, compress images, lint files, and assist with other tasks that would be handled by separate tools or the command line. The difference: CodeKit was GUI based.

CodeKit quickly caught on as it required no command line experience to use and became a must-have in any web developer’s arsenal.

Future of CodeKit 💀

CodeKit is still alive and now on version 3.0, but its popularity has been on a steady decline since 2014.

Grunt & Bower

The Warthog and Macaw

Grunt came on the scene as a command line tool that provided a single script to specify and configure tasks. Bower followed shortly after as a means to manage client-side packages. The two, along with NPM, seemed to fulfill the majority of automation needs and were used regularly in tandem.

The problem I quickly noticed with Grunt was the lack of freedom in terms of configuring more complex task chains and lack of parallelization. Bower promoted a separation of front and back-end packages, which ended up forcing most users to manage twice the amount of packages (bower_components vs node_modules).

Future of Grunt 💀💀💀

The warthog and the macaw are on their way out, but fret not, there are better substitutes. I recommend picking up Gulp or Webpack.

Gulp & Browserify

The Fountain Drink

A year and a half after Grunt, Gulp was released. It felt natural. Writing a build script in Javascript vs JSON gave freedom. You could write functions, create variables on the fly, use conditionals anywhere - not that this would make for a particularly good looking build script, but nonetheless it was possible.

Gulp still maintained a relationship with Bower, but the stronger adoption of Browserify allowed NPM packages (which are originally for backend Node servers) to be brought into the front-end, making Bower obsolete. This looks and feels better as well. One package manager for the front-end and back-end.

Future of Gulp 🔥🔥

Google Trends will tell you there's a dip in popularity, but Gulp isn't going anywhere at the moment. Gulp became strongly associated with the Angular crowd as they were two of the most popular players in their domains (tooling and frameworks) at the time. And now with Angular 2 & 3, Gulp will still have a home.

Webpack & NPM scripts

The Geometric Trip

Webpack, the new kid on the scene. All the JS cool kids are using React and Webpack these days. NPM scripts are coming back with a vengeance to the point where half of any package.json file might consist of configuration.

A minor detail, but instead of having gulp taskName you have npm taskName. npm install to get dependencies, npm prune to remove unused packages, npm build to build your production assets, npm start to start your server. The scripts are written in Javascript as well. Looks good.

Future of Webpack 🔥🔥🔥

Webpack, React, ES2016 - the hipster stack. This is the future. ES2016 is literally the next generation of Javascript. Whenever new technologies come out, they couple together and force you learn twice the amount to ramp up. They do this for survival. But if you have time to kill every evening like I don’t, take a dive.

Mention -Yarn

Yarn came out late 2016 and became a preferred package manager to NPM. From the user perspective, they behave exactly the same. The syntax is a bit different (maybe more intuitive), but the package installations themselves are much faster. Parallel vs sequential. Just use it.

Going Forward/TL;DR

Still using CodeKit? Spend some time learning one of the above.
Grunt and Bower are on life support.
Gulp is sticking around so feel free to learn everything about it. Angular will keep it alive.
Webpack is the future.

written by

We are a Toronto-based end-to-end digital innovation firm with a passion for building beautiful & functional products that deliver results.