When I first joined Tech in Asia (TIA) about seven months ago, the engineering team was a small team; just the four of us working on the web portion. Six months later, we are still a small team of less than 10 people, but have accomplished so much, especially on the front end stack.


Back then, TIA’s main website was powered by two separate platforms: a web application built using Laravel for the company/investor database (formerly known as Techlist), and WordPress for the rest of the pages. Each of the platforms’ front end was served respectively by the platform itself; using Laravel’s views and the Blade templating system, and a custom-built WordPress theme for the WordPress side.

While that worked for a while, we started encountering numerous problems when it comes to optimizing assets between the two platforms. They were using fundamentally different systems; Browserify versus WordPress’ script loader (wp_enqueue_script) for scripts, SASS versus traditional CSS for stylesheets.

The redesign was an opportunity to rebuild the front end from scratch.

Having the front end served individually for each platform is a maintenance nightmare when it comes to shared content. For example, if we had to update the styling of the navigation bar, we had to apply it twice; one on WordPress, the other on Laravel.

Re-working our web architecture

The redesign was an opportunity to restructure our entire web architecture and rebuild the front end from scratch. We would continue to use WordPress to manage editorial content, maintain the existing company/investor database and build future functionalities using Laravel. All content will be sent to our front end and mobile application via REST API.

Transitioning PHP applications to serve as a REST backend is a growing trend:

  1. WordPress 4.4 saw the REST API infrastructure integrated into core as the first step of a multi-stage rollout.
  2. Automattic, the company behind WordPress.com, released Calypso, a redesigned admin interface powered by React, still using WordPress as a backend via REST API.
  3. Recent Laravel releases saw new features with more emphasis to assist developers in building RESTful applications using the framework.

The front end stack would be separate from the two platforms, powered by a front end JavaScript framework. This means that knowledge of PHP is no longer required for this stack, increasing our options when hiring engineering talent.

React became a no-brainer choice for the front end framework. Its advantage over rendering performance over other frameworks like Ember and Angular was a natural fit for pages that involve a lot of DOM changes, like the article page with infinite scroll and the “live” commenting system.

Building a custom Bootstrap theme

One of the main disadvantages to using Bootstrap is framework bloat. But, we love Bootstrap. So how do we solve the bloat problem?

We built a custom Bootstrap setup by downloading the SASS source of Bootstrap 3, disabled unused components / scripts, override the original variables to our needs, and wrote new styles for each of our new components. By ensuring all original and custom SASS code go through the same compilation process, we solved the problem of having duplicate / unused styles in our previous setup.

We have also structured our SASS files based on the 7-1 pattern. By having a separate SASS file for each custom component and page, we will be able to lazy load the styles like what we are doing now for JavaScript files via webpack.

Re-learning JavaScript

Building the front end under React was an interesting challenge for all of us at the engineering team. Most of us are primarily PHP developers, and swear by the JQueryframework. We started picking up React back in September 2015, and at the same time, started figuring out the “new” Javascript language. The sixth version of the language specification, known as ES2015 (or ES6) was finalized in June 2015. That provided a lot of #til moments for us: Promises, const vs let, class syntax, deconstructors, rest + spread and fat arrow functions. Babel came into the picture for us to transpile JSX and ES2015 code back to ES5, compatible with our current web browsers. webpack became our module bundler, which comes with hot reloading; extremely useful during development.

For React / ES2015 coding styles, we followed the one by Airbnb.

Growing Flux

React is not going to be sufficient by itself for more sophisticated setups like an web application. Like many others before us, we used the Flux architecture to handle data and the various UI states. We started using the traditional Flux architecture for our first React application that did not go live, and made some minor tweaks to it when we built the front end application. Most of the tweaks, such as higher order components that map stores data to a component as props, are heavily inspired by Dan Abramov. Moving from traditional Flux to Redux would be something that might be possible in the future, but for now, Flux works for us.


For routing, we used react-router. The examples in the library and flux-react-router-example provided a great base on how to structure our front end application. We started development for the front end application on the day right after react-router 1.0 came out. :)

Abstracting “Components” in React

While ES2015 introduced classes as syntactical sugar over JavaScript’s existing prototype-based inheritance, the JavaScript community, in general, didn’t exactly find them awesome. We were inspired by the following Medium article and have been creating higher order components to abstract common functionalities.

Moving forward

There are a lot of areas that we are still figuring out: making sure our React code works for both server-side and client-side rendering (also known as Universal JavaScript), optimizing our components so that they do not re-render unnecessarily, and optimizing our API and front end response times.

We may not be the best engineers around, but what made us great was the willingness to learn new technologies and our commitment to work together to build great web applications for our audience. We hope you look forward to the improvements and new features. :)

For me, I would like to thank the product team and fellow engineers in giving me the honour to take lead of the front end application, and helping out to make the rebuild a success. Thank you!