Webpack is the best module bundler I've ever used. Just this week I used it to reduce the JS footprint of an app from 906KB to 87KB for mobile visitors. An 800KB difference!
Webpack's core premise is that you can require('./foo') your JavaScripts. That sea of <script> tags or concatenated code and variables injected into the global namespace is gone.
In theory we've had that for a while. RequireJS and its AMD have been out for a while, but it's always felt clunky. Don't think I've used it more than once in the wild. Too clunky.
Browserify was better. Using CommonJS it brought the same syntax we've had in node.js into the browser. Less clunky and easier to reason about. But to my knowledge, not all that popular in the wild.
The problem with Browserify is that, at least in my experience, it takes a lot of setup to work well. And it's kind of slow. Compile times run into the many seconds range.
Webpack is fast. Like super fast. Compiling a huge codebase rarely takes more than a second. Every time I change something it's already compiled by the time I refresh the browser.
Magic.
Lazy loading your code
Another great feature of Webpack is that it can perform a sort of minimal bundle coverage for your dependency graph. Instead of making one huge bundle that's got all your code, it makes a few smaller discrete ones.
Users no longer have to download all the code for /admin_panel when they're looking at /user_profile. Not only that, Webpack automagically downloads the required javascripts when needed.
This is called lazy loading and it is magic.
It's easy in theory, whenever you require a dependency like this:
require.ensure([], function () {
var more_code = require("./more_code");
});
Webpack will say "Oop, that's an optional dependency!". It will package everything that might get required by that require call into a separate bundle. In this case just ./more_code.js.
If your path includes a variable, Webpack understands that too and puts everything that could match in a bundle. So with require('./'+module_name+'View.js'), for instance, it will bundle all JavaScript files that end with View into one file.
Webpack splits your bundle on every require.ensure call. Then when your code needs something, Webpack makes a jsonp call to get it from your server.
This is great in development. Not great in production.
In my tests on a Heroku Rails app, doing a HEAD call to our app took some 200ms, while the same call to amazon's CloudFlare took only 10ms.
Our app is an order of magnitude slower than a proper static file server. Oops.
Lazy Loading with CDN support
First of all, you have to get Webpack working with Rails. The best guide I've found comes from Justin Gordon, here. He takes you through the whole process in detail.
The nutshell version goes like this:
- Use npm to install Webpack and its things
- Configure it in
webpack.rails.config.js - Add a call to
webpack -w --config=webpack.rails.config.jsto your startup sequence (I like usinggrunt startof some sort) - Remove all
//= requireinapplication.jsand replace with//= require generated/rails-bundle.js - Make an assets.rake task that looks like this gist
You can find the details in Gordon's long blogpost. It's really good. Although personally I didn't go as far as moving all my JavaScripts out of app/assets and I didn't set up hot code loading for local dev.
Now, to make Webpack understand that static assets should be loaded from a CloudFlare CDN, you have to change its output settings.
config.output = {
filename: in_dev() ? "rails-bundle.js" : "[id].[chunkhash].rails-bundle.js",
path: "app/assets/javascripts/generated",
publicPath: getCDN() + "/assets/generated/",
};
There's two tricks here:
- We tell Webpack to fingerprint files with
[chunkhash]unless we're in local development. This gives us long-term caching because of unique filenames - We prefix the
publicPathwith a CDN URL. This "tricks" Webpack into loading them from there
The in_dev and getCDN make the config easier to understand. They look like this:
function getCDN() {
var CDNs = {
staging: ".cloudfront.net",
production: ".cloudfront.net",
preproduction: ".cloudfront.net",
};
if (!in_dev()) {
return "//" + CDNs[process.env.RAILS_ENV.toLowerCase()];
}
return "";
}
function in_dev() {
return !process.env.RAILS_ENV || process.env.RAILS_ENV == "development";
}
They both look at the RAILS_ENV environment variable to decide which situation Webpack is running under. It works great, but does mean that we have two places to set the config for CDN. Here and the regular Ruby config.
Now, because our files are fingerprinted, Rails's asset pipeline no longer knows how to insert them. The filename 0.some_weird_hash.rails-bundle.js changes every time Webpack compiles our code.
The simplest fix I've found is to copy the file in that assets.rake task. Like this:
FileUtils.copy_file(Pathname.glob(path+'0.*.rails-bundle.js').first,
File.join(path, 'rails-bundle.js'))
Now the main bundle file will always have the same name in production and application.js will be able to include it so you don't have to hack the asset pipeline. Perfect.
Benefits
There are many reasons you'd want to use Webpack in your Rails application. My main motivation was that our users were just loading way too much JavaScript. They don't need the desktop homepage app when they're on mobile. And they definitely don't need the whole user dashboard when they're looking at the homepage.
For mobile users the change has been significant. From downloading all of 906KB before, to just 87KB. Sure, there's still some overhead on top of that for libraries, but we can load those from 3rd party CDNs now so they could already be cached.
The other huge benefit is that our code is easier to deal with. Instead of shoving everything into a huge carefully namespaced global object, we can just require what we need.
Life is better.
Continue reading about Webpack lazy loading on Rails with CDN support
Semantically similar articles hand-picked by GPT-4
- How We Used Webpack to Reduce Our JS Footprint by 50
- Migrating to Webpack 2: some tips and gotchas
- A dirty Webpack trick that reduced our gzipped bundle size by 55KB
- Is JavaScript really getting too complex?
- Arcane JavaScript knowledge still useful
Learned something new?
Read more Software Engineering Lessons from Production
I write articles with real insight into the career and skills of a modern software engineer. "Raw and honest from the heart!" as one reader described them. Fueled by lessons learned over 20 years of building production code for side-projects, small businesses, and hyper growth startups. Both successful and not.
Subscribe below 👇
Software Engineering Lessons from Production
Join Swizec's Newsletter and get insightful emails 💌 on mindsets, tactics, and technical skills for your career. Real lessons from building production software. No bullshit.
"Man, love your simple writing! Yours is the only newsletter I open and only blog that I give a fuck to read & scroll till the end. And wow always take away lessons with me. Inspiring! And very relatable. 👌"
Have a burning question that you think I can answer? Hit me up on twitter and I'll do my best.
Who am I and who do I help? I'm Swizec Teller and I turn coders into engineers with "Raw and honest from the heart!" writing. No bullshit. Real insights into the career and skills of a modern software engineer.
Want to become a true senior engineer? Take ownership, have autonomy, and be a force multiplier on your team. The Senior Engineer Mindset ebook can help 👉 swizec.com/senior-mindset. These are the shifts in mindset that unlocked my career.
Curious about Serverless and the modern backend? Check out Serverless Handbook, for frontend engineers 👉 ServerlessHandbook.dev
Want to Stop copy pasting D3 examples and create data visualizations of your own? Learn how to build scalable dataviz React components your whole team can understand with React for Data Visualization
Want to get my best emails on JavaScript, React, Serverless, Fullstack Web, or Indie Hacking? Check out swizec.com/collections
Did someone amazing share this letter with you? Wonderful! You can sign up for my weekly letters for software engineers on their path to greatness, here: swizec.com/blog
Want to brush up on your modern JavaScript syntax? Check out my interactive cheatsheet: es6cheatsheet.com
By the way, just in case no one has told you it yet today: I love and appreciate you for who you are ❤️