All posts by Marie Schmidt

In the quickly evolving world of front-end development, it can be overwhelming to choose from the multitude of frameworks. It is, by extension, downright baffling to build a whole project from scratch – which is exactly what we did for Kenzan.io.

In this article we’ll walk through the technologies we chose, why we chose them, and what we thought.

Kenzan .IO Scope
Before diving in, let’s take a look at the scope of the project. We needed to build a fast, sleek, and responsive website that could integrate with other Kenzan sites. The website also needed to be easily updated by our marketing department. Kenzan.io was simple in terms of business logic, with very little state maintained, and most of the complexity held in the views.

Front-End Architecture
This leads into our first design decision: React for our front-end view library. React gave us the scaffolding we needed to design component-based views within a single page application without weighing down the project. Most importantly, React’s one-way data binding paired with the virtual-DOM made our image and animation rich site run with impressive speed on all browsers. We styled our views using Sass, to take advantage of variables, mixins, and other advanced CSS features. The Sass was compiled down to CSS in our build process and vendor prefixes were added using Auto-Prefixer. These few pieces led to fast and aesthetic pages.

Since React only handles our views, we needed a way to handle the model and controller portions of our front-end. We decided to use React Router for our SPA routing, jQuery for advanced DOM interaction and HTTP calls, and ES6 for all other business logic in the site. React Router has quickly gained steam as the widely accepted routing package for React applications, and we found it easy to learn and incorporate. We combined React Router, jQuery, and vanilla JS to build a scroll based navigation for the website, called scroll jacking. This feature is often handled with CSS and HTML sections but we decided to incorporate it into a single page application architecture by pairing scrolling with view routing. We also used jQuery to handle our AJAX calls because the library was already present in the project. For the sake of learning, a dive into Fetch or Thunk would have been interesting, but ultimately would have added unnecessary weight to our application. Finally, we chose ES6 over ES5 for all the new features including JavaScript modules, arrow functions, and classes. With the help of the very opinionated AirBnB style guide, we found ES6 syntax to be more concise when compared to ES5. We compiled our ES6 using Babel and handled module loading with WebPack streams in our Gulp build process. Both libraries had fairly simple configuration and no work required once the boilerplate was assembled.

Back-End Architecture
With our front-end architected, we began looking at ways to integrate Kenzan.io with our other Kenzan sites and make it friendly for marketing updates. Since all Kenzan sites are WordPress sites and our marketing team is very familiar with the WordPress content management system, we decided to pursue the bleeding edge WordPress API. With the API, all data was entered, stored, and retrieved from the Word Press CMS, and we had access to data from all of Kenzan’s pages. Most importantly, we found the WordPress API extremely easy to use. The API had good documentation, was straightforward to integrate into a single page application, and updating content was quick and easy.

Testing
We saved the best for last with unit testing. This does not follow test driven development, but for the sake of time constraints, we wanted to get all content on the site before testing so we could evaluate time remaining before making a testing plan. When we found ourselves with a couple weeks left, we decided to branch out again and try a new test runner called Ava. The allure of Ava is the ability to run unit tests concurrently, each test with an isolated scope in a separate Node thread. This means no interference between tests with faster test suite execution. For pure JS, we tested with Ava and Sinon, used for spies and stubs. For React components, we paired Ava with Enzyme, an extension of ReactTestUtils, and BrowserEnv, for a virtual browser in Node. This trifecta allowed for quick and seamless testing of our React components, including rendering the DOM, testing lifecycle methods, updating the state, and re-rendering the component. All the testing libraries had very little boilerplate code to get started and were easy to work with when writing the tests.

Finally, we wanted to add a last layer of confidence with a suite of E2E tests. Prior to this project, most of our front-end development experience had been in Angular with E2E testing handled by Protractor. Unfortunately, Protractor is not friendly with React so this was another chance to learn something new. We found an E2E library called Nightwatch.js that integrated with React and ran off Node, making configuration and execution not too different from Protractor. The creation of these tests was handled by our QA team, and is a topic for another blog post, but their inclusion helped ensure no bugs made it out to production.

The Final Product
After six weeks, and many scrums we met our goal of delivering a responsive, performant website with a WordPress back-end and full unit and E2E test suites. However, our most important accomplishment was diving deep into new technologies and expanding our knowledge here at Kenzan.

To checkout the website, click here: https://kenzan.io


The author of this post is Marie Schmidt, at junior front-end developer at Kenzan. She’s featured as our employee spotlight.


We’re looking for some  talented developers, architects and engineers to help us build more cool stuff like the Million Song Library. Click here to see open positions.