>> Hello?

Hello, hi!, oh, my God, oh, my God, oh, my God, I'm so excited!

My coworker, Salem, is about to come up on stage and tell you about the migration process

of moving to Webpack and what a kind of disaster that was.

But it's a really interesting disaster, I promise.

So Salem gave me some fun facts but I'm going to go totally on my own and tell you my fun

facts and favorite things about Salem.

The first thing that you need to know about Salem is he gives the world's best hugs, literally,

so all of you need to be good-enough friends with him by the end of the conference so that

he could give you a hug and trust me, you will, like, love it for the rest of your life.

The other thing that you need to know about Salem is that we have regular Etsy-wide smash

tournaments, we had one the other night.

I was not there, but my husband went, and apparently do not let him play at duck hunt

because he will hide in the corner and throw beans at everybody.

All right, so everyone, gave it up for Salem Hilal.

[applause]

Oh, my gosh, that was the nicest thing that anyone has ever said about me.

It's also very bright up here, everyone's right, everybody said that already.

Thank you, Katie, I'll say thank you so much to everybody who has organized JSConf, it

is unreal to be up on stage.

I can hear my voice echo.

That makes it sound like I'm in a stadium, that's so cool.

My name is Salem, if you know about the cat, and my pronouns are he/him, and I work at

Etsy and we're hiring.

This is my very first conference talk, as well, so if you have any feedback for me,

please do not withhold it.

I would love to hear about it.

So.

OK, cool I wanted to talk about how we migrated from an in-house system to Webpack and specifically

I want to talk about why it took us so long to do that.

I work at a team at Etsy called the web platform team.

If you've ever worked at a place that has a front-end infrastructure team it's probably

very similar.

This talk is essentially about how we moved from one build system another, but this doesn't

mean I'm going to talk about -- my goal here is to talk about the weird problems that we

unearthed and how we fixed them and where all my hair went.

[laughter]

So this talk is like about five parts.

I'm going to first tell you about a little bit about Etsy and our old build system that

we called Builda, and then this really weird rolling it out.

So that's going to be a fun one, so if the beginning parts are boring, at least stay

till the end.

So before I get into it, there are two caveats that are worth mentioning, number one, the

decisions that we made were true at the time we made them.

JavaScript as you all probably know changes very quickly, which is the whole reason that

we wanted a really flexible build system in the first place and No. 2, all of the things

that I'm going to talk about today are big team efforts.

I know a whole lot about how Etsy's front end infrastructure on behalf of my whole team

that kind of collectively built and researched all the things that I'm going to talk about

today.

They kick ass, and I really love working with them.

I think Joe is right up there somewhere in the front.

That's my teammate Joe.

There's also John and Natalia who are not here but they're great to work with.

It's hard to tell you about a migration process without giving you a little bit of context.

So here it is, this is Etsy's codebase, it's like anyone's codebase at a medium sized company.

Some.

That is to say, the code that makes Etsy show up in your web browser from the API all the

way down to the CSS lives in one.

We call our mono repoetsy web, it's worked surprisingly well for us, it has helped us

facilitate.

One thing that did not scale very well when we moved was the JavaScript part of our codebase.

And.

So this system is something that we named Builda.

For those of you who may not be familiar with JavaScript build systems, a build system is

something that takes our files, resolves their dependencies, bundles them together, makes

them as small and efficient as possible, and (audio is breaking out).

we got to hit play on this part.

It's going to be like a carnival game where I have to aim on the screen.

Boop?

One more time.

Yay, there it goes, so when BBuilda was first written, it wasn't this sleek interactive

home page that you see here, complete with cool animations and a responsive navigation

bar and a really cool branding.

It looked more like that.

Having one file depend on another was pretty infrequent and when that did happen it was

usually for large globally scoped libraries, like JQuery ...

Production builds took very little time.

At Etsy, this is pretty important.

We deploy code dozens of times in a single day and slowing down deployment is something

we'd try to avoid at all costs.

So developing JavaScript was similarly pretty simple.

That's supposed to be me.

If we load a page in development that requests some JavaScript, that JavaScript file would

be built from our source and sent back inside of one request.

To keep track of all the possible files that we might need to request, we kept a list of

all of them which we brilliantly called the build list.

When we served a file we'd make sure it was in that list somewhere.

The build list was used in production then later to determine the entirety of what we

needed to build when we deployed [inaudible] in development if a requested file was not

the build list we'd respond with some JavaScript that threw us an exception.

This ensured that we could essentially build any file we wanted on demand.

We used require.js to manage our delinquencies.

Maybe you haven't even heard of this because it's a relatively old library but we still

used it and it was pretty simple up until we moved to Webpack, that is.

We'd follow it down with some of our own code.

Require.js then allows our own code to use any style module definitions as you can see

here.

For some of you this might sound out of the stone age but for us it was pretty cutting

edge when we did this.

Async ... We defined an array of imports which require

then resolve for us.

All of our code goes to the body of one of these callbacks where it has access to all

of the imports.

Builda's job was to make sure that all of the necessary modules were bundled into one

JavaScript file so that require.js has access to everything it needed in the browser.

At some point, React came along.

React is just a library that makes writing large, client-side applications a lot easier.

Sometime around 2016, we decided it would be a really good fit for some of our seller

tools.

Everyone was excited.

React, however, strongly relies on a syntax that looks like HTML controversially aligned

into JavaScript.

If you want to be able to use this syntax, we need to make a build system that it can

do more than just build files together.

So we used an old version of.

(Audio breaking out) So it's a stapler.

I added the staples last night.

There was one problem with this setup, however, because we built every file only when it was

requested rather than when some part of it was edited we had no way of knowing if it

had changed or not since the last time it was requested.

So we had to rebuild every asset every time we wanted to use it.

Transpiling JSX into JavaScript -- so React heavily ended up taking a good bit longer

in order to be served.

But JSX was new, so few few people felt the pain of long rebuild times in development.

Besides, it's just JavaScript, right?

We know it didn't last very long.

All of these quirks together meant that loading something large, like a single-page app implied

rebuilding the entire thing from scratch every time the page reloaded, plus our codebase

was only getting bigger, we had over 1,000 separate JavaScript assets to output.

React code was use in a lot more places and it started to take the better part of a minute

to show up on the page in development which made iterating very, very tedious, on top

of this, developers were starting to ask for the ability to use ES6.

It felt like a nonstarter for us, React support was difficult to implement and when it worked,

it certainly wasn't sustainable.

We knew we needed to do something.

This is where I've told myself that I'm going to drink water and you all are going to take

15 seconds to introduce yourself to the people next to you so that you don't hear me gulping

over the microphone.

All right, time's up.

I'm going to test all of you later so I hope you all paid attention.

OK, I gotta hurry up because I'm already running behind my schedule.

(mic is cutting in and out.)

Can you hear me OK?

>> Can you still hear me OK?

All right, awesome.

OK, cool.

So I drank my water and it is now time for me to talk about the solution to every one

of our problems.

People started talking around this time about this brand new open source build system, it

was called Webpack.

You might have heard of it.

These are all the GIFs for my entire presentation, they are just right here.

All right, any new developer that we hired, asked if we could use Webpack and the internet

made it sound like every tech company that used JavaScript also used Webpack.

It sounded a lot like Builda in that it built stuff, but it also sounded very different

in that it had a robust development experience, it was highly extensible and it had a bunch

of built-in performance optimizations for our code.

Most of all it was supposed to be very fast, especially for development.

So we did a little research.

I wanted to point out, this is a fast chicken.

[laughter]

It's a recurring motif, so keep it in mind.

So we did a little bit of research, we evaluated a bunch of alternatives and we decided that

going down the path of building our JavaScript with Webpack instead of Builda was the right

path.

We had two requirements for any new system that we wanted to adopt.

Number one, it would have to take care of development builds without too much interacts

from developers, one of the nicest things about Builda, you could navigate the entire

site without having to worry about how the Builda requirement looked.

Etsy deploys code to production dozens of times in a day.

If our builds took longer than five minutes, Etsy's deployments would slow down, which

is not a good thing for us.

So Webpack, what was cool about Webpack for us, well, it's highly configurable.

Instead of a build list, Webpack uses a configuration file usually called Webpack.config.

From how you'd like to support templates, if any, to what sort of performance optimizations

you'd like to make.

This oftentimes means really large really scary config files, which isn't always the

right idea for small projects.

But having something that could adapt and fit to our code was very invaluable.

We spent a while writing out a really nice Webpack.config file and also different features

that Builda currently supported which at the time included everything from transpiling

templates.

After spending hours, setting things up just right, we finally got Webpack to build our

whole codebase, but it wasn't quite what we expected.

It took about a half hour to do.

It ate up 20 gigs of our servers' memory and maxed out every single one of its cores.

This is a real screenshot.

And it had the unclear progress indicator that everyone has come to know and love.

[laughter]

This made it exceptionally hard to figure out why it was so slow.

So we definitely had a lot to learn about improving Webpack's performance but at the

end of the day we needed to change a lot about how our codebase worked and how Webpack worked

with it if we wanted to use it with Etsy.

All right, I'm drinking water again, so tell the person next to you what your text editor

of choice is without trying to convince them that yours is the right one.

[laughter]

OK, how we doing?

Good?

All right.

I gotta hurry up.

I am, like I said, not on schedule.

I hope the answer was vim, but that's OK if it wasn't.

[applause]