Let me begin with a list of usual suspects up to no good in the browser:<\/p>\n
I mean, because, you know, writing in HTML\/JS\/CSS is so 2000-late.<\/p>\n
All this 74 72 61 6e s p i l a t i o n.<\/p>\n
A typical layout. Something like this:<\/p>\n
\r\nassets\/\r\n css\/\r\n img\/\r\n js\/\r\n html\/\r\n index.html\r\nsrc\/\r\n coffee\/\r\n img\/\r\n jade\/\r\n less\/\r\nGruntfile.js \/\/ or gulpfile.js\r\npackage.json\r\nserver.js\r\n\/\/ ...\r\n<\/pre>\nYou\u2019re using Grunt<\/a> or its less-loquacious cousin, Gulp<\/a> or \u2014 mind-blown \u2014 npm<\/a>(!) for builds\u2026 I mean running tasks\u2026 I mean running build tasks.\u00a0Did I mention you\u2019re modularizing with CommonJS<\/a>? Well, in this blog post you are. We\u2019ll forego tests for brevity\u2019s sake. Because, of course you\u2019re testing\u2026<\/p>\n
The cadre of \/G(runt|ulp)\/ transpiler plugins: contrib-coffee, contrib-less, contrib-jade, gulp-coffee, gulp-less, gulp-jade \u2014 configured. I said CommonJS, didn\u2019t I? You might be tempted to use Browerserify, so multiply things by ^ify.<\/p>\n
And you don\u2019t want to repeat yourself. So you DRY-ly declare the chain of project directories in your Gruntfile.js or gulpfile.js.<\/p>\n
\r\nvar src = [__dirname, 'src'].join('\/');\r\nvar srcCss = [src, 'css'].join('\/');\r\nvar srcHtml = [src, 'html'].join('\/');\r\nvar srcImg = [src, 'img'].join('\/');\r\nvar srcJs = [src, 'js'].join('\/');\r\n \r\nvar dest = [__dirname, 'assets'].join('\/');\r\n\/\/ ...\r\n<\/pre>\n\u201cLike I said, you don\u2019t want to repeat yourself,\u201d he said, dryly.<\/p>\n
And maybe you want some hot\/live reloading? Maybe you didn\u2019t, but in this blog post, you do. Some client frameworks are more naturally suited than others (React and Flux) but at any rate, you orchestrate the delicate swan dance of watchers and reloaders in your package.json and build file.<\/p>\n
So you\u2019ve got at least six packages declared \u2014 at least \u2014 for this scheme, and at least a hundred well-formatted lines in your build file for the plug-ins alone, plus variable declarations. That\u2019s a lot of wiring for a modern web app dev environment.<\/p>\n
What if I told you you could get all of that in a cohesive manner? In a framework that will take care of all that wiring for you? Enter webpack<\/a>! Gone are the variable declarations! (Mostly) gone are the lengthy plug-in configurations, the watch and reload courtship! Imagine all the digital trees saved!<\/p>\n
webpack<\/h3>\n
webpack<\/a> is a module builder and runtime module loader (like RequireJS). It\u2019s not RequireJS. It\u2019s not CommonJS. But it understands both. It will bundle both. In its fundamental design, however, what makes webpack different is: everything is a bundle<\/strong>. Wait.. CSS? Yep. Fonts? Uh-huh. HTML templates? You got it. Images? Alright, now you\u2019re just being annoying.<\/p>\n
Yes, you will be \u201crequire\u201d-ing images. Of all the resources that become bundles themselves, in the webpack way of things, images are maybe the strangest, because their usage at runtime are in languages (HTML, and CSS by way of) that, in their DNA, expect to be served URL-y. So there are design considerations.<\/p>\n
For one, anything beyond a truly single-page<\/strong> trivial application, you will be using a client framework. For another, with the help of said framework, you\u2019ll be doing client-side routing, relegating the web server to a web service (and static asset directory, maybe). You see where this is heading: templating and JavaScript (transpiled-to). Be it a Handlebars template or, e.g., an Angular directive:<\/p>\n
\r\nvar angular = require('angular');\r\nvar img = require('.\/..\/img\/foo.png');\r\n \r\nvar app = angular.module('app', []);\r\napp.directive('bindImg', function () {\r\n return {\r\n link: function (scope) {\r\n scope.photo = img;\r\n },\r\n template: '<img data-ng-src="\/assets\/{{photo}}">',\r\n transclude: true\r\n };\r\n});\r\n<\/pre>\n(magic hands<\/strong>) And Bob\u2019s your uncle. I could\u2019ve even `require`-ed the HTML (as Jade) in the above `template` declaration.<\/p>\n
But I\u2019m off-point here. The focus of this post isn\u2019t a tutorial over webpack. There are some good ones out there. It\u2019s also not to document webpack. It has its own gh pages for that (decent, and hopefully gets better, more consistent, more in-depth and yet more accessible). No, this post is to convince you to offload your transpilations, your assets-building, to webpack. Drop the configurations and wiring in your build files. Where the building and wiring of assets are concerned, let webpack handle it. Forget the traditional bundling mechanisms of your modular frameworks.<\/p>\n
1. You lose all those brittle declared meta-variables.
\n2. You lose the Gulp\/Grunt plugins you fed them to.
\n3. See below<\/p>\nA webpack config file for this phantom project could look like this:<\/p>\n
\r\n'use strict';\r\n \r\nvar config = {\r\n entry: [\r\n [__dirname, 'src', 'js', 'Application.js'].join('\/')\r\n ],\r\n module: {\r\n loaders: [\r\n {\r\n loader: 'style-loader!css-loader',\r\n test: \/\\.css$\/\r\n },\r\n {\r\n loader: 'coffee-loader',\r\n test: \/\\.coffee$\/\r\n },\r\n {\r\n loader: 'html',\r\n test: \/\\.html$\/\r\n },\r\n {\r\n loader: 'jade-loader',\r\n test: \/\\.jade$\/\r\n },\r\n {\r\n loader: 'file-loader',\r\n test: \/\\.(png|jpg)$\/\r\n },\r\n {\r\n loader: 'style-loader!css-loader!less-loader',\r\n test: \/\\.less$\/\r\n },\r\n {\r\n loader: 'file-loader',\r\n test: \/\\.(ttf|eot|svg)(\\?v=[0-9]\\.[0-9]\\.[0-9])?$\/\r\n },\r\n {\r\n loader: 'url-loader?limit=10000&mimetype=application\/font-woff',\r\n test: \/\\.woff2?(\\?v=[0-9]\\.[0-9]\\.[0-9])?$\/\r\n }\r\n ]\r\n },\r\n output: {\r\n filename: 'bundle.js',\r\n path: [__dirname, 'assets'].join('\/')\r\n }\r\n};\r\n \r\nmodule.exports = config;\r\n<\/pre>\nDefining an entry point and configuring the loaders responsible for each filetype required (you will need to install these), plus an output directory\/file. Pretty simple and should feel conceptually familiar to RequireJS users. You can get more sophisticated with \u201cchunking<\/a>,\u201d or breaking apart, your assets as you see fit. Out of the gate, you get one file for non-binary assets and a file-per binary.<\/p>\n
The key thing is that the naming, wiring, and retrieval of all assets is handled by the webpack runtime, embedded in the output. Actually key number two (maybe I\u2019m a janitor?) is, it all goes in one directory (out-of-the-box). It\u2019s a blob. To you at runtime, it\u2019s a blob. To you at dev-time, it\u2019s a blob. To you \u2014 and this is the pudding \u2014 at build-time, it\u2019s a blob. Just declare your dependencies at the file-level. webpack simplifies things.<\/p>\n
So, you say, \u201cOK. That config snippet looks simple and kinda familiar. Not much configuration. My Grunt\/Gulp tasks become dedicated runners vs. builders\u2026\u201d (yes, I just put words in your mouth) \u201c\u2026but, I\u2019m a curmudgeon and it wouldn\u2019t be very curmudgeonly of me to just accept a streamlined and consistent approach to building projects and declaring all dependencies, now would it?\u201d Well, dagnabbit, if we din\u2019t up \u2018n fergit hot reload (slaps prospector\u2019s hat on knee<\/strong>)!<\/p>\n
webpack-dev-server<\/h3>\n
Although, strictly-speaking, not a part of webpack proper, webpack-dev-server<\/a>\u00a0is an easy-peasy-lemon-squeezy +1. Here is where the webpack runtime really flexes its muscles. Once configured, the runtime will serve through the dev-server (over a websocket) only the changed delta<\/strong>\u00a0in-page. If you think about it, it\u2019s a natural application of webpack\u2019s design choices: it\u2019s the runtime loader, it chunks and wires as it sees fit \u2014 substitutions in this model should be theoretically trivial vs. the watchers of old, binding file globs to tasks.<\/p>\n
And for the most part, it just works. Occasionally, you may have to restart the server or its buffer, eventually, after long periods of uptime, overflows. But you can easily set up, for dev-time, say, an Express server serving API, offloading static assets to the dev-server and be ripping through your style minutiae and route tunings, seamlessly and lickety-split-ily(?). Again, there\u2019s plenty of examples out there to guide you.<\/p>\n
Conclusion<\/h2>\n
I\u2019ve only touched the surface of webpack. Try it out.<\/p>\n
I\u2019m sure you\u2019ll appreciate the cruft removed from your task runner, webpack\u2019s minimal configuration, its everything-is-a-module boon to testing, and its rapid development dev-server (esp. if you\u2019re using React \u2014 its shadow dom, itself, a lattice-like state machine). Its maintainers have made it easier to suggest documentation improvements (where I think is its weak point \u2014 including plug-ins) so I\u2019m sure things will get better on that front (nudge, nudge<\/strong> YOU). But you can get going and do a lot in spite of it.<\/p>\n
Now, get packin\u2019!<\/p>\n
\n