Recently, we started looking for a front-end dev at Cushion to take some weight off my shoulders. We published a job listing that describes the position and how we work. It also includes the steps for our hiring process. After a short interview to simply discuss the applicant’s background and interests, we invite them to do a paid “assignment”. The assignment is to have them build one of our existing AngularJS components in Vue.js, which we’re in the process of migrating to. The assignment reveals if they can 1) code, 2) communicate, 3) match a screenshot, and 4) learn on-the-go. I created a private repo for the assignment, so there’s also 5) know how to use version control.

At first, I intended for the repo to be a sandbox for the applicant—a place for them to start coding with minimal setup and remain outside of our top secret repos. In setting up the sandbox, I took the opportunity to start with a clean slate. If we were to start building Cushion now, what would we use for the dev environment? Three years is a long time in the modern dev world, and even though our current stack isn’t “old” by any means, certain areas of it are collecting cobwebs—specifically the front-end and its build script.

Aside from using such a heavy framework like AngularJS, one of my bigger regrets is writing the front-end in CoffeeScript. *gasp* CoffeeScript is easy to write fast, but at the expense of a lazy and loosely structured codebase—AngularJS didn’t help with that either. Fortunately, JavaScript is catching up with most of CoffeeScript’s more appealing features, so we’re taking the opportunity to migrate to ES6 during our Vue.js switch.

As for the build script, Cushion is currently a combination of Gulp and Browserify, which isn’t ideal for quickly developing small parts of a large app. After reading up on the latest tech stacks, it seems like Webpack is the way to go. Vue.js even has a wonderful CLI for quickly starting up a new environment with everything we need. A few tweaks here and there and our assignment repo was ready for use. There was only one problem—the environment was too nice. I grew jealous. With Webpack’s hot reloading, the code updates almost instantly. With Cushion’s build script, I’ll make a change and stare longingly out the window, watching the world go by.

I also hated the idea of the repo being a throwaway. If we were to finish, I imagined copying over the components manually. That’s 2014 Jonnie’s way of thinking. 2017 is a new me. I decided to turn the assignment repo into Cushion’s new component library. Since the applicants would be recreating Cushion’s existing components in our new stack, why not build them to be production-ready? That would make the assignment even more worthwhile.

I styled a page to house the new components and created a “Hello World” component as an example. From there, we could add each new component to the page and interact with them in a sandbox environment—separate from the app.

For the applicants who really wanted to make an impression, we even had a test harness that came with Vue.js’s dev environment. Components could be unit tested in isolation, so we really knew that they worked (and would continue to work if anyone needed to make changes). With proper unit testing, the component page’s would no longer be used for testing behavior. Instead, it could be used to ensure that the components’ interactions are up to par with the rest of Cushion.

We currently have six components in the sandbox with two more on the way. Once we reach a point where we can start using these in production, I’ll package the library and install it as a dependency. Whenever we need a component, I can simply import it and know that it’ll work as expected.