Morley Zhi in javascript, frontend

Working on OkCupid "in production" with Webpack and localhost

Let's be honest: you should probably be working now. If you're anything like us from a year ago, you ended up here while waiting for your dev machine to start up, or for Webpack to build files for you to try out.

For me, waiting a mere five extra seconds for a page load was enough to push me to Hacker News "for just a minute." Then, 20 minutes later, I had forgotten what the hell I was doing.

Here's how our frontend dev environment is set up now, which has made development more responsive, more accessible, and more fun to work with.

How we worked a year ago

When you visit an OkCupid URL, the OkCupid web server (okws) generates HTML and sends it to you over the internet.

Each dev has a local machine running a development build of okws. The development build's HTML points to the local version of Javascript:

<script src="//morley.dev.okcupid.com/flat/synced/desktop/js/vendor.min.js?v=1a7a5f9563d3f27"></script>  

okws runs on Linux, and the templating files need to be in the same directory as the okws files. That means each frontend engineer on a Mac (read: all of us) needed a separate development machine on the same network.

Our Javascript source files were stored on those machines, and we compiled them with Webpack. We had to jump through lots of hoops to compile changes:

  1. A developer connects to their dev machine through AFP, which mounts the okws directory into /Volumes/devName/.
  2. They cd to that directory.
  3. They start the Webpack watcher.
  4. Webpack reads in the source files over the network.
  5. Webpack builds the Javascript bundle, which takes at least 90 seconds the first time.
  6. Webpack saves the compiled files to the right directory on the dev machine.

Every file we compiled (including all dependencies in node_modules) had to make a cross-office trip from our dev machines to our local computers.

Sometimes, if you refreshed the page before Webpack finished compiling, you'd have to refresh the page again to see your changes. Refreshing a page twice to see your changes in 2015 is only slightly more advanced than getting it faxed to you.

How we work now

There were two root problems with our old setup:

  1. Storing source files on our dev machine means a lot of network round-trips during compiles.
  2. Webpack only compiles files. We have to (gasp!) manually reload pages.

The first problem was "easy" to fix. it didn't matter where our source files were, since okws only ever served compiled JS. So we moved our Javascript source files out of the main OkCupid Git repo (and thus, off the dev machines) and created a new Git repo, okfrontend, cloned on our Macs.

The second point wasn't a problem, per se; it was just something we shouldn't have to deal with. I would enviously read articles about other teams using webpack-dev-server to locally-build their single-page apps.

If you've never used webpack-dev-server, it's a miracle: it keeps file references in memory, so your rebuilds are faster; it reloads the page for you on changes; and if you change CSS or React components, it'll reload those assets without even reloading the page.

At first, I thought webpack-dev-server would only work for single-page apps: it serves up a single static HTML file that points to your compiled JS files. But those compiled JS files have URLs just like anything else. There's no reason we couldn't point our servers to those URLs.

okws outputs Javascript paths that point to our local machine:

<script src="//morley.dev.okcupid.com/flat/synced/desktop/js/vendor.min.js?v=1a7a5f9563d3f27"></script>  

We can change that domain to whatever we want. We could point it to whitehouse.gov if Donald Trump wanted to host our Javascript files. So we added a staff privilege that points those paths to the magical domain localhost:

<script src="//localhost:8080/flat/synced/desktop/js/vendor.min.js?v=1a7a5f9563d3f27"></script>  

Then, we used webpack-dev-server to compile serve those files from localhost.

Since we weren't making those round-trips over AFP anymore, our initial build times cut in half (from 90 seconds to 45 seconds). Not perfect, but much better than before.

An unexpected side effect of this setup was that developers could now work from anywhere in the world, without even needing a VPN connection. As long as they had staff credentials and a local checkout of okfrontend, they could start up Webpack and instantly see their changes. And they could do it on the live site!

Conclusion

Since we've moved to working on localhosted Javascript, day-to-day development has gotten a lot easier and smoother.

  • Build times went from "interminable" to "still long, but better."
  • Working out of the office went from "absolute torture" to "a pleasure from the start".
  • Working on new Javascript features went from being "fun, interlaced with torture" to "a pleasure from the start".

If you want to help us fix problems like this, we're hiring Senior Frontend Engineers! And if you don't, feel free to send us your feedback or ideas!

Thanks to Melissa Huang, Jessie Walker, Michael Geraci, Dale Markowitz, and Ben Brittain for giving notes on this post.