Same as It Ever Was — EmpireJS 2018 Talk
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?
This talk is titled “Same as It Ever Was: An Oral History of Modern JavaScript.” We’re going to dive into a common sentiment I see at work and online, and that’s that the JS ecosystem is moving too fast and changing for seemingly no reason. There’s a new tool every week that you feel like you need to learn, and it’s impossible to keep up. We’re also going dive into pop music history while we’re at it.
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.
This puts webpack squarely in the “tool” category. This is a piece of software that makes the developer experience better, while doing no harm to the customer experience. There is nothing preventing us from writing all of our JavaScript in a single, large file. This would have the same benefits from a webpack-compiled bundle albeit with a miserable developer experience.
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 webpack.config.js.
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.
As legend has it, JavaScript was written in 10 days by Brendan Eich in 1995 while at NetScape. It was to be a language included in the release of Netscape Navigator 2.0.
Brendan Eich was 34 when he wrote JavaScript. Although the language has its warts, this conference would not exist were it not for him. Funnily enough, the language he created outlasted the company he was at.
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…
Gangster.
Now between 1995 and 2004, not much happened with JavaScript. The industry was concerned with other things, like seeking financial viability. This web thing was so new, that giving a great experience wasn’t at the top of the list of priorities yet. We were just fighting for survival.
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.
It looked like JavaScript was done for, until…
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.
Sites like digg popped up and redefined what was possible on the web using HTML and JavaScript. It was an era full of optimism. We were all saying…
“Yeah!”
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.
These libraries essentially had the same promise: Write JavaScript once and have it work the same in all browsers. We were putting entropy back in its box.
All of these libraries embraced the $. They bolted on functionality to it as if to say, “Here. Here is the JavaScript standard library.” Code looked like this.
But we were quickly creating balls of mud, and we were paralyzed by choice. You could say JavaScript developers at the time were having a…
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.
This is when we see frameworks like Angular, Backbone, Ember, and React2 be created. These took a radical stance that JavaScript should handle the whole page, not just little bits of interaction. Web pages went from looking like this:
To this:
And this was pretty neat! There were a few problems with performance, but things were good! Unfortunately, we didn’t stop there…
But this was all fine-and-well. Folks were starting to take single-page applications and the future of JavaScript seriously. You could say we were…
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?
This is where we need to ask ourselves some questions. This feeling of rapid change is not new to our industry. In this talk we saw it happen with Unix and early JavaScript libraries.
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?
We need to get comfortable with some technologies winning. You would be hard-pressed to find someone writing software for an Solaris system today. Most JavaScript developers are not starting new projects with scriptaculous.
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.