I finally made sense of front end build tools. You can, too.

From: Https://medium.freecodecamp.com/making-sense-of-front-end-build-tools-3a1b3a87043b#.nvnd2vsd8

Front End build tools can be confusing even to experienced developers like me. The solution is to understand what they work-and work together-on a conceptual level.

This article presents my opinionated approach to making sense of front end build tools. Instead of diving into code, I'll walk you through my mental model of how these tools work and what they accomplish.

Don ' t be intimidated by the state of the art

Node, NPM, Grunt, Gulp, Bower, Webpack, browserify, Yeoman, brunch ... there, many front-end build tools out there It can seem impossible to keep up.

The key is not being intimidating. All of these projects is designed to make your life easier.

To understand the "why," and how of these tools, you just need to grasp a few concepts.

Concept #1-the Core dichotomy of build tools is "Installing vs. doing"

Build Tools do things:

1. Install Things
2. Do things

The first question to ask yourself when confronting a new build tool was: "Is this tool intended to install things for me, Or do things for me? "

"Installing" tools like NPM, Bower, and Yeoman can install pretty much anything. They can install front-end libraries like angular.js or react.js. They can install servers for your dev environment. They can install testing libraries. They even help you install the other front end build tools.

In short, they install the most any code-related things you can think of.

The "doing" tools like Grunt, Webpack, require.js, brunch, and Gulp is much more complicated. The goal of the "doing" tools are to automate all the menial and error prone tasks in web development. The things they do is sometimes called "tasks."

To does these "tasks" they often use their own ecosystem of packages and plugins. Each tool writes the tasks in different ways. These tools also don ' t all do the same thing. Some "doing" tools try to handle any task you throw at it (Grunt, Gulp, etc). Others focus on one thing, such as handling Javascript dependencies (browserify, require.js, etc).

Sometimes you end up using several of these tools in the same project.

Here's a short list of "Tasks" I ' ve automated with these "doing" tools:

1. Replacing a string of text in a file
2. Creating folders and moving files into those folders
3. Running My unit tests with a single command
4. Refreshing my browser when I save a file
5. Combining all my JavaScript files to one, and all my CSS files into one
6. Minifying my concatenated JavaScript and CSS files
7. Modifying the placement of <script> tags on an HTML page

Once you understand this tools install stuff or do stuff, categorizing them becomes much easier:

Build tools sorted by whether they primarily install things or does thingsconcept #2-the grandparent of all build tools are Node and NPM

Node and NPM install and run all these build tools, so there are always a trace of them in your project. Because of this, many developers try-to-use these-tools as much as possible before they resort to installing an Additi Onal tool.

Node and NPM fall into our ' build ' and ' do ' dichotomy. Node is the ' do ' tool, and NPM is the ' Install ' tool.

NPM can install libraries like angular.js or react.js. It can also install a server to run your app locally for development. It can even install tools to does things like minify your code.

Node, on the other hand, "does" things for you, like run JavaScript files, servers, and so much more.

If you need a place-to-start learning, start with NODE+NPM, and stay there for a while. When your project gets large enough, you'll reach the limits of what Node and NPM can automate for you. At the point you can organically incorporate another build tool.

Concept #3-A build is just a production ready version of your app

Developers often break JavaScript and CSS out into separate files. Separate files let's focus on writing more modular chunks of the code that does one single thing. Files that do one thing decrease your cognitive load. (If you think separate files is more confusing than one large file, try working in a the line file, and you'll quickly Change your mind?? )

But when it's time to move your app to production, have multiple JavaScript or CSS files isn ' t ideal. When a user visits your site, each of the your files would require an additional HTTP requests, making your site slower to load .

So-remedy this, you can create a "build" of our apps, which merges all your CSS files into one file, and does the same W ITH your JavaScript. This is the number and size of files the user gets minimize. To the Create this "build," the "Use a" build tool. "

Below is a screenshot of the app in development. Notice How does it have 5 <script> tags and 3 <link> tags? If you look at the left side, notice the development folder has ten files inside of it?

Your app in development

And below here are the same app after a build tool have worked its magic.

Notice How we just has a single script tag and a single link tag? And now the PRODUCTION folder have just 4 files, compared to the development folder ' s 10.

The app is a line to line the same. We ' ve just compacted it into a neat small package we call a "build."

Your app in its build form

You might wonder what a build is even worth it, if the it does is save your users a few milliseconds of load time. Well, if you ' re making a site just for yourself or a few other people, you don't have to bother with this. Generating a build of your project is only necessary to high traffic sites (or sites so you hope would be was high traffic s Oon??).

If you ' re just learning development, or only making sites with very low traffic, generating a build might not be worth R time.

Concept #4-the lines between "Install" and "do" can blurry

No tool only does one and not the other. They all does some mix of "install" and "do." But generally, a tool tends to does more than one than the other.

Sometimes an "install" tool would run files. NPM often does this. NPM can run commands and scripts as Well-not just install files. A tool like Yeoman installs pre-built boilerplate apps on your computer, but it also dynamically generate new files as Nee Ded, blurring the line between install and do.

Concept #5-there is no one right combination of tools

The combination of tools you use can is completely up to you.

You can choose to use no tools whatsoever. Just Keep in mind so copying, pasting, minifying, starting servers, and everything else involved can quickly become over Whelming.

Or you can just use Node and NPM together with no additional tools. This was great for beginners, but as your project grows it might the start feeling like too manual of a process.

Or you can choose to use a few other tools on top of the Node and NPM in your project. So your app would use NODE+NPM as it's core, and then maybe grunt+bower or Webpack or gulp+bower.

Using Some combination of tools like these on top of the NODE+NPM lets you automate a lot of the tasks in your project. The price these tools has a steep learning curve.

Build tools in order of increasing complexity, but decreasing tediousnessconcept #6-build Tools has a steep learning CU Rve, so only learn what ' s necessary

Building an app are hard enough. You might is working with a new language or a new framework. Or you might has really tricky business logic. So incorporating a build tool can add a whole additional layer of complexity to your project. This is especially true if it's a project where someone else wrote the code associated with the build tool.

My advice is to the only learn exactly, and nothing else, need to do your job.

The best-of-learn new things is, and you had a real world task, you need to accomplish. For example, don ' t learn what to copy files with Grunt for the sake of it. Instead, wait until your project actually needs, and then figure it out.

Remember:premature complexity'll slow you down.

Concept #7-all build tools share the same goal:to make your happy by automating a lot of menial tasks

You ' re using the your build tool to it full potential if you reach what I called "build tool Nirvana." That's when after you save a file, or run a single command, and tons of the tasks happen "automagically" for you.

If Your build tool still requires you to manually move files, change values, or run commands to get a new build and then you Haven ' t reached build tool Nirvana yet.

One of the biggest benefits of build tools is this by just saving a file, you can trigger a new build of your app and send it to your browser. This can dramatically the speed up your front end development workflow.

So what much effort should you put into the configuring and setting up your build tool? Simple:stop when you're happy with what it's doing for you.

Concept #8-it ' s not just. The documentation often is terrible.

It's not for you, I promise. For many of these tools, the documentation is quite lacking. Sometimes figuring out how to do basic tasks can is hard.

Keep in mind that there is very few predefined recipes for build tools. You'll see people get the same results in wildly different ways-sometimes all as answers to the same StackOverflow quest ion!

While the is annoying, it's also presents you a opportunity to flex your coder muscles and implement something Crea tive.

After all, isn ' t so why did we do this?

I finally made sense of front end build tools. You can, too.