The following is text of the talk with some editing. It’s not an exact transcription. The talk was originally delivered at EmpireJS 2018.
And you may find yourself living in a shotgun shack…
And you may find yourself living in another part of the world…
And you may find yourself behind the wheel of a large automobile…
And you may find yourself in a beautiful house…
With a beautiful wife…
And you may ask yourself: How did I get here?
By looking into the history of JS and computing as a whole, we’re going to find that this is not the first time our industry has felt this way. You’re going to leave this talk with a better understanding of how this fast change is a feature, not a bug, and hopefully with a renewed sense of optimism.
Let’s dive in.
This talk was borne out of a recent chat I had with a new coworker of mine. It was his second day at Gusto, and he was getting his development environment set up. He came to me with a question: “What is webpack and why do we use it?”
I responded, “Well, webpack is an asset bundler. We use asset bundlers because…” and I quickly realized we were going to need to go deep down the rabbit hole. To understand why we use webpack as an industry or things like it, you need to understand the history of JS. To bake this apple pie, we were going to need to create the universe.
What is webpack? In broad strokes, webpack is an asset bundler. It takes all of your small JS, CSS, image and other files, and smooshes them into a small set of bundles to serve to the web browsers.
We want to serve fewer, larger bundles to the clients for performance reasons. Most browsers cannot handle loading many files in parallel efficiently.1 So we use asset bundlers to smoosh things into a few files.
But webpack is not without its critics. It’s known for being difficult and time-consuming to configure. Configuring webpack bundles does not add value to your application. The customer will never know that you’ve got a clean
To understand how we got here, we need to turn the clock back to 1972.
In 1972, computers looked like this:
This is the IBM System/360 Model 91 at NASA. This photo was taken some time in the 1960’s. We can assume NASA used this to compute flight trajectories and occassionally run payroll.
The OS/360 manual is also one of the earliest mentions of a “linker” and “linkage editors” that I could find. These tools allowed large teams to write in many different languages like assembler, FORTRAN, and COBOL, and eventually have their compiled files compressed into a single asset bundle load module.
This is pretty remarkable technology! It’s like seeing something for the first time. It’s fitting that the number 1 hit single of the year was Roberta Flack’s “First Time Ever I Saw Your Face.”
Now let’s jump to 1991.
In the early ’90s, Unix was hot. So hot, in fact, that there were multiple competing flavors of it. Large companies like HP, IBM, and Sun were all developing commercial versions of Unix. Being a Unix developer at the time must have been maddening. Which version of Unix do you build for?
It wasn’t until 1991 that Linux was released. Yet at the time, saying Linux was going to put all other Unix variants out of business was like saying “This npm package released last week is going to kill React.” You would be met with a healthy dose of skepticism. Linux gave rise to the open-source movement that we know today and popularized giving back to the community.
This makes sense, because the hit single of the year was…
“(Everything I Do) I Do It for You” by Bryan Adams. It’s actually a pretty bad song.
Now that brings us to 1995.
But at the time, you would not have guessed that. Imagine if a hackathon project didn’t just end up being successful, but ended up creating an entirely new industry. It was by no means a sure success either. There were several competitors in the form of Java Applets, ActiveX, and Flash.
But to create something with outsize impact is pretty cool. You could even call it…
Furthermore, there were other technologies that are now dead. Flash and to a lesser-extent ActiveX were the technologies to use if you wanted a rich experience. Bandwidth was limited so we instead would watch Flash animations on sites like newgrounds.net instead of videos on YouTube.
The introduction of XMLHttpRequest blew the doors open on the web once again.
This allowed for AJAX to be a thing. We had recovered from the hangover from the dot-com crash of 2000/2001, and Web 2.0 was here.
But things were still a little rocky when we get to 2006.
All of the browsers had slightly different APIs, and writing portable code was painful. To address this issue, libraries like Dojo, scriptaculous, Prototype.js, jQuery, YUI, and MooTools sprung up.
All of these libraries embraced the
So that brings us to 2011.
To take a stand against the Balls of Mud we had created, several folks got together to develop the first batch of single-page application frameworks.
And this was pretty neat! There were a few problems with performance, but things were good! Unfortunately, we didn’t stop there…
So that brings us to 2012, where we see the rise of asset bundlers and things like it:
Grunt, Gulp, Webpack, and Broccoli are all tools that came out around that time. They all provided the same thesis: Here’s a tool to help you wrangle your large single-page applications.
They’ll take the disparate assets that you’ve accumulated over the years with your growing teams and make sense of them. They’ll let different teams work in different languages seamlessly. But it feels like we’ve seen this before. You could say it’s…
So what is webpack, and why do we use it?
If we’re not careful, we may end up relearning the lessons of the past. Did we even realize that asset bundlers were ancestors of linkers? Are we recreating technologies and solutions of our parents and grandparents? What lessons are we relearning? What is actually new?
And just because something survives, doesn’t mean it will be around forever. Many folks in the audience are probably in the process of removing jQuery from your applications.
In some ways, we can only hang on for the ride. Let’s not get at each other’s throats when we have disagreements. Given enough time, everyone will be wrong. We can’t tell what will be successful ahead of time, and often the most surprising things are the winners.
And over time we’ll realize that it’s the same as it ever was…
Same as it ever was…
Same as it ever was.
Special thanks to Bria Fincher, Matan Zruya, Sheng Lei, Hector Virgen, Alicia Tran, Andrew Lee, Cody Watters, Kenra Lyndon, Jeff Carbonella, Nathan Pigott, and Amelie Meyer-Robinson for giving feedback on early drafts of this talk.
An extra special thanks to EmpireJS for letting me give this talk.
If you’re interested in receiving blog posts like this regularly, join hundreds of developers and subscribe to my newsletter.