The beauty of zero-configuration JavaScript builds

It’s undeniable — the JavaScript ecosystem got chunky, in no small part due to the abundance of mass configuration. What I’m getting at here is: start any front-end project with a framework (React, Angular, Vue…) and you’ll be working out how to get X loader working with Y filetype in Webpack. Or will you..?

Allow me to explain a little more about the problems encountered with the complexities that configurations introduce, and how to sidestep configuration (almost!) altogether.

The Problem

JavaScript frameworks and view libraries typically encourage us to shift a lot of logic from the server into the browser. I won’t focus on the pros/cons of this now, but let’s just accept this and understand that this shift is necessary to make web apps the dynamic UX treat that everyone craves.

Ask yourself this: when was the last time you worked on a React, Angular, Vue, <insert JS framework of choice> project without any kind of build process in place? It’s doable for sure thanks to CDNs and pre-minified framework builds, but it’s far from ideal for production-grade web apps and you’ll usually miss out on tons of error-checking as you build your apps.

So, build processes are basically a given in these projects. Today the most popular build tool of choice without a doubt is Webpack. Now we’re getting to the meat of the problem: Webpack requires a fairly verbose and oftentimes cryptic configuration (in particular for newbies) to be provided for the average project setup.

We can’t put all the blame on one tool, though. Considering that we also have a need these days for JavaScript features that aren’t readily available in all browsers yet, there’s also preprocessors such as Babel or TypeScript (along with their own Webpack loaders), which again require their own configs for the average setup.

Now that I’ve been exposed to all manner of interesting, bizarre and ugly configurations in the projects that I’ve worked on (with a fair few of those configurations being written by me…) I really feel I’ve had enough of going down that road again and again. Maybe you’ll be able to relate to this too if you’ve been in the JavaScript world for the last few years.

The Solution

If you’re an Ember developer, you’ll most likely already have had the pleasure of using the Ember CLI, a crazy useful utility for bootstrapping an Ember app, generating new components and running tests. Whilst I personally didn’t get along that well with the Ember framework when I last used it, I did think the CLI tool was truly ahead of the game in terms of how tooling should be provided.

Luckily for us developers, the teams behind the other popular frameworks took notes and slowly bought into the same philosophy that the Ember team follow:

Convention over Configuration

In my early days of easing my way into front-end frameworks, this tagline struck me as odd. I naively thought: “Surely the more configuration we have, the better we can make our apps?”.

Now let’s look at 3 of the most popular front-end frameworks today: React, Angular and Vue. All of the teams behind these frameworks/libraries now provide their own CLI tools to ease development and provide “zero configuration” setups for us developers.

ReactJS, react-create-app

React has its react-create-app CLI tool, here to give us a quick and easy setup for new React projects. It adds a pre-populated package.json file too, which includes NPM scripts ready to start your app in development mode or build your app to prepare it for a production environment.

And… that’s about it. It’s a pretty lackluster tool in all honesty, but at least it reaches the goal that we set out to achieve: a zero configuration app setup. You’re also free to eject from the CLI tool at any time, returning you back to complete and total control over the underlying Webpack and Babel configurations.

VueJS, vue-cli

Vue took a similar approach to the react-create-app tool and built on the idea by allowing the user to create or install an existing template project which gets used to create a new project ready to go. This means you don’t have to always use the same base project structure for every project. The configuration that it installs by default is fantastic, and assuming you’re going to use Vue’s proprietary .vue file format for self-contained components, selecting CSS preprocessors and language features is beautifully simple:

Which tells the Vue loader: pre-process this module’s CSS with the SASS compiler, and apply scoping attributes to all classes in the template output to avoid class name collisions with other components. This, my friends, is darn sweet to have without needing to touch a single piece of configuration. Arguably the vue-cli tool is one you’re least likely to need to eject from if you’re a fan of the .vue component files.

Angular, angular-cli

Angular has, in my opinion, the best CLI tool of the three. Not only does it share the bootstrapping ability to get a new app up and running quickly like the other two, but it also takes even more hints from the Ember CLI (the Angular team themselves credited the Ember CLI project for the inspiration) and provides code generation commands.

This means you can run 1 command to create a new component that includes skeleton source files, unit tests and even adds the new component into your app’s core module file. This helps to keep your app growing with consistency throughout.

However, the Angular CLI actually does include its own configuration (ugh…). But luckily it’s not too verbose, and you may never even need to touch it. One time that you might, however, is if you choose to apply a CSS preprocessor such as SASS or LESS because the default project setup is only set to understand vanilla .css files and syntax.

I would say in the case of the Angular CLI, the configuration it exposes is welcome and gives the average developer less of a reason to eject from the CLI by allowing control over some of the base parameters that the tool relies on.

The Conclusion

So there we are. The three big boys in the front-end framework world are all on board with the concept of Zero Configuration. For me, this is an absolute blessing and I see barely any reason now to spend precious time at work or in building hobby projects to go hunting for boilerplate projects on Github or attempt to understand another Webpack loader’s configuration requirements.

Of course, if you’re a developer who wants absolute control and has no gripes with spending time on setup and writing configuration, then this will all be irrelevant for you. But for those just getting started in one of these popular frameworks or those sick of endless configuration tweaks, I can’t recommend these CLI tools enough. And what’s more: the more people use these tools and find their strengths and weaknesses, the more the development teams behind the tools can adjust and improve upon them to get us all closer to the Zen-like state of total app source code and zero configuration.