The web also provides some of its own unique development challenges. For example, since webpages make a lot of asynchronous requests, your web app\u2019s performance can be significantly degraded from having to request hundreds of JS and CSS files, each with their own tiny overhead (headers, handshakes, and so on). This particular issue can often be addressed by bundling the files together, so you\u2019re only requesting a single bundled JS and CSS file rather than hundreds of individual ones.<\/p>\n
![\"Bundling](\"https:\/\/assets.toptal.io\/uploads\/blog\/image\/121261\/toptal-blog-image-1476209965834-ffc10bbd3f9342b632cee3642cd93875.png\")
<\/p>\n
<\/p>\n
It\u2019s also quite common to use language preprocessors such as SASS and JSX that compile to native JS and CSS, as well as JS transpilers such as Babel, to benefit from ES6 code while maintaining ES5 compatibility.<\/p>\n
This amounts to a significant number of tasks that have nothing to do with writing the logic of the web app itself. This is where task runners come in. The purpose of a task runner is to automate all of these tasks so that you can benefit from an enhanced development environment while focusing on writing your app. Once the task runner is configured, all you need to do is invoke a single command in a terminal.<\/p>\n
I will be using Gulp<\/a> as a task runner because it is very developer friendly, easy to learn, and readily understandable.<\/p>\n Gulp\u2019s API consists of four functions:<\/p>\n Here, for example, is a sample task that makes use of three of these four functions:<\/p>\n When The beauty of this is in the The next step to understand Gulp is understanding the array of task dependencies.<\/p>\n Here, Finally, we have In the above example, any changes to a file matching And just like that, you understand all you really need to know about When using the CommonJS pattern, bundling JavaScript files isn\u2019t as simple as concatenating them. Rather, you have an entry point (usually called The dependencies have to be resolved before the remaining code in Webpack<\/a> is a bundler whereas Gulp is a task runner, so you\u2019d expect to see these two tools commonly used together. Instead, there\u2019s a growing trend, especially among the React community, to use Webpack instead<\/em> of Gulp. Why is this?<\/p>\n Simply put, Webpack is such a powerful tool that it can already perform the vast majority of the tasks you\u2019d otherwise do through a task runner. For instance, Webpack already provides options for minification and sourcemaps for your bundle. In addition, Webpack can be run as middleware through a custom server called The major drawback to using Webpack is that it is rather difficult to configure, which is unattractive if you\u2019re trying to quickly get a project up and running.<\/p>\n I will set up a project with three different task runner setups. Each setup will perform the following tasks:<\/p>\n Our three setups will be:<\/p>\n The application will use React<\/a> for the front-end. Originally, I wanted to use a framework-agnostic approach, but using React actually simplifies the responsibilities of the task runner, since only one HTML file is needed, and React works very well with the CommonJS pattern.<\/p>\n We will cover the benefits and drawbacks of each setup so you can make an informed decision on what type of setup best suits your project needs.<\/p>\n I\u2019ve setup a Git repository with three branches, one for each approach (link<\/a>). Testing each setup is as simple as:<\/p>\n Let\u2019s examine the code in each branch in detail\u2026<\/p>\n index.html<\/a><\/strong><\/p>\n A straightforward HTML file. The React application is loaded into index.js<\/a><\/strong><\/p>\n This acts as the JS entry point of our app. Essentially, we\u2019re just loading React Router into the routes.js<\/a><\/strong><\/p>\n This file defines our routes. The urls index.test.js<\/a><\/strong><\/p>\n This is a series of unit tests that test native JavaScript behavior. In a real production quality app, you\u2019d write a unit test per React component (at least ones that manipulate state), testing React-specific behavior. However, for the purposes of this post, it\u2019s enough to simply have a functional unit test that can run in watch mode.<\/p>\n components\/App.js<\/a><\/strong><\/p>\nA Quick Introduction to Gulp<\/h2>\n
\n
gulp.src<\/code><\/li>\ngulp.dest<\/code><\/li>\ngulp.task<\/code><\/li>\ngulp.watch<\/code><\/li>\n<\/ul>\n![\"\"](\"https:\/\/assets.toptal.io\/uploads\/blog\/image\/121259\/toptal-blog-image-1476200326032-4b5cb6936909edc16573dd2018707e43.png\")
<\/p>\ngulp.task('my-first-task'<\/span>, function<\/span>()<\/span> {<\/span>\n gulp.src('\/public\/js\/**\/*.js'<\/span>)\n .pipe(concat())\n .pipe(minify())\n .pipe(gulp.dest('build'<\/span>))\n});\n<\/code><\/pre>\nmy-first-task<\/code> is performed, all the files matching the glob pattern \/public\/js\/**\/*.js<\/code> are minified and then transferred to a build<\/code> folder.<\/p>\n.pipe()<\/code> chaining. You take a set of input files, pipe them through a series of transformations, then return the output files. To make things even more convenient, the actual piping transformations, such as minify()<\/code>, are often done by NPM libraries. As a result, it\u2019s very rare in practice that you need to write your own transformations beyond renaming files in the pipe.<\/p>\ngulp.task('my-second-task'<\/span>, ['lint'<\/span>, 'bundle'<\/span>], function<\/span>()<\/span> {<\/span>\n ...\n});\n<\/code><\/pre>\nmy-second-task<\/code> only runs the callback function after the lint<\/code> and bundle<\/code> tasks are completed. This allows for separation of concerns: You create a series of small tasks with a single responsibility, such as converting LESS<\/code> to CSS<\/code>, and create a sort of master task that simply calls all the other tasks via the array of task dependencies.<\/p>\ngulp.watch<\/code>, which watches a glob file pattern for changes, and when a change is detected, runs a series of tasks.<\/p>\ngulp.task('my-third-task'<\/span>, function<\/span>()<\/span> {<\/span>\n gulp.watch('\/public\/js\/**\/*.js'<\/span>, ['lint'<\/span>, 'reload'<\/span>])\n})\n<\/code><\/pre>\n\/public\/js\/**\/*.js<\/code> would trigger the lint<\/code> and reload<\/code>task. A common use of gulp.watch<\/code> is to trigger live reloads in the browser, a feature so useful for development that you won\u2019t be able to live without it once you\u2019ve experienced it.<\/p>\ngulp<\/code>.<\/p>\nWhere Does Webpack Fit In?<\/h2>\n
![\"\"](\"https:\/\/assets.toptal.io\/uploads\/blog\/image\/121258\/toptal-blog-image-1476174229140-3890202f75d94c0692549af41f9d652a.png\")
<\/p>\nindex.js<\/code> or app.js<\/code>) with a series of require<\/code> or import<\/code> statements at the top of the file:<\/p>\nES5<\/h4>\n
var<\/span> Component1 = require<\/span>('.\/components\/Component1'<\/span>);\nvar<\/span> Component2 = require<\/span>('.\/components\/Component2'<\/span>);\n<\/code><\/pre>\nES6<\/h4>\n
import Component1 from '.\/components\/Component1'<\/span>;\nimport Component2 from '.\/components\/Component2'<\/span>;\n<\/code><\/pre>\napp.js<\/code>, and those dependencies may themselves have further dependencies to resolve. Furthermore, you might require<\/code> the same dependency in multiple places in your application, but you only want to resolve that dependency once. As you can imagine, once you have a dependency tree a few levels deep, the process of bundling your JavaScript becomes rather complex. This is where bundlers such as Browserify<\/a> and Webpack come in.<\/p>\nWhy Are Developers Using Webpack Instead of Gulp?<\/h2>\n
webpack-dev-server<\/code>, which supports both live reloading and hot reloading (we\u2019ll talk about these features later). By using loaders, you can also add ES6 to ES5 transpilation, and CSS pre- and post-processors. That really just leaves unit tests and linting as major tasks that Webpack can\u2019t handle independently. Given that we\u2019ve cut down at least half a dozen potential gulp tasks down to two, many devs opt to instead use NPM scripts directly, as this avoids the overhead of adding Gulp to the project (which we\u2019ll also talk about later).<\/p>\nOur 3 Task Runner Setups<\/h2>\n
\n
\n
git checkout <branch name>\nnpm prune (optional)\nnpm install\ngulp (or npm start, depending on the setup)\n<\/code><\/pre>\nCommon Code<\/h2>\n
Folder Structure<\/h4>\n
- app\n - components\n - fonts\n - styles\n- index.html\n- index.js\n- index.test.js\n- routes.js\n<\/code><\/pre>\n<div id=\"app\"><\/div><\/code> and we only use a single bundled JS and CSS file. In fact, in our Webpack development setup, we won\u2019t even need bundle.css<\/code>.<\/p>\ndiv<\/code> with id app<\/code> that we mentioned earlier.<\/p>\n\/<\/code>, \/about<\/code> and \/contact<\/code> are mapped to the HomePage<\/code>, AboutPage<\/code>, and ContactPage<\/code> components, respectively.<\/p>\n