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