How We Moved From Wordpress to React and Raised $80 Million

Yoav Ganbar
Jan 25, 2019 · 13 min read
Image for post
Image for post

$80 Million got you to click through, didn’t it?

That’s just a knee-jerk reaction from my old days as a marketer.

  • The rest of the site was migrated progressively thereafter.
  • We had a re-brand / redesign at around April — which was easily facilitated thanks to React (and being greenfield)
  • Series B — $80 Milion — Apr 24, 2018
  • V2 launched around May 11th which also marked most of the transition was complete

Image for post
Image for post

Why React?

Out of the top 3 front-end libraries/frameworks list, in my view, there are only 3 major contenders: Angular, Vue and React.

Image for post
Image for post
Image for post
Image for post
  • Reusability: Components can be reused anywhere, take your lego block and just stick it somewhere else
  • Quick learning curve: Any developer who knows Javascript can start writing components pretty quickly (more on this later).
  • Proven at scale: Lots of companies use it (Facebook, Netflix, Twitter, Uber, BBC, Airbnb, Dropbox to name a few…).
  • Awesome community: It’s open source, there are many 3rd party libraries and tools out there, also the React team keep on improving the library (version 16 brought a major improvement and they relicensed React to MIT).
  • SEO friendly: We can render React server side (one of our key requirements).
  • Great developer experience: It’s just fun! (Shameless recruitment plug — want to work with this tech stack? check out our open positions)

The journey…

Before I dive into the code and technical talk, I think it’s important to share my journey on how I like to start something like this. A lot of technical blog posts dive in straight away and miss out on some of their process, which IMHO is one of the hardest parts when approaching any project.

  • Fast load time
  • Keep the same design (for that point in time)


With today’s abundance of tutorials, articles, videos, and websites you get exposed to a mass of information and it is important to be able to curate your sources, so you can have a reference to them later, you may never know when you might just write a piece yourself… :-)

  • React on WordPress
  • WordPress extract post data as JSON
  • WordPress API
  • WP REST API has a CLI tool and a JavaScript client (WP-API)
  • People have done stuff with Angular and WP REST API
  • Using React to render Front End was possible
  • Detaching the front end from WP is possible.

How I decided on the stack

I’ve worked with React before, but I’ve never implemented server-side rendering. Naturally, working at a start-up, I did what you’re supposed to do in this situation and iterated on my research process:

  • Read
  • Try



  • Easy setup
  • SSR out of the box
  • Routing out of the box
  • Great developer experience — especially if you already know React
  • Growing community
  • An established company behind the tech — Zeit


  • Understanding when lifecycle hooks get called when you start adding HOC’s and more complicated patterns
  • Custom routing outside of what is provided by the framework can get complex
  • Am I on the server or on the client? Confusing at first, even later.
  • Overwriting Webpack config is a bitch.

Check out my talk about Next.js

I think they say it best on their site: “The React Framework For SEO friendly React…”

Image for post
Image for post
The Pages directory is the only thing that Next.JS add — it’s basically the routing.
Image for post
Image for post
Index.js is your entry point, e.g. => `/` route;


IMO (and for the sake of this post) the core of Next.js is this method. Basically, it’s another React lifecycle hook that runs before componentWillMount and on the server. So any data fetching or business logic you would want to do on the server is what goes on in this method:

Sometimes there is no way around `dangerouslySetInnerHTML`



  • Simplicity in state management.
  • Observable reactive pattern (or change detection): when something happens to data I want to watch -> do something.
  • Tooling.
  • Declarative and readable


  • Unopinionated store structure — you will need to make decisions
  • Hidden “magic”
  • Using MobX with SSR is a challenge — when and how to hydrate stores
  • When some React component doesn’t re-render — annoying to debug (at least in V3.4.1)
Shout out to Alex Ilyaev, my good friend ;-)
Simple BS generator

Styled Components


  • Modularize your CSS into a component
  • Easily extendable.
  • The full power of JS inside CSS
  • Declarative nature
  • Themeing
  • SSR support
  • Auto Prefixing
  • Preprocessor like functionality; support nesting, etc.
  • VScode / WS plugins


  • Putting too much logic into styling
  • How to structure Styled Components? One element with only its style or a React component with declarations in the length of an old school CSS file?
  • Sometimes shit breaks just because you forgot a semicolon and there is no error or way of knowing even with the tooling.
  • Formatting template strings is a bitch — also copy/pasting them inside certain IDE’s is annoying.
  • or a React component with declarations in the length of an old school CSS file
The beauty is the declarative way of naming your style “blocks”
const fontSizeMap = {
S: `10px`,
M: `20px`,
const Header = styled.h1`
font-weight: bold;
font-family: Helvetica;

// pass in a "size" prop to the component:
font-size: ${ {(size) => size && fontSizeMap[size] } };
// Then we can use it in some component:const DemoStyledComponent = () => (
// pass in the size prop to our component
<Header size={ 'M' }>
Use Styled Componets - They're Awesome!



  • Easy to set up and extend
  • PHP based templating system (prior to project Gutenberg)
  • Has user roles, permission and authentication built-in.
  • Plugin system — you can find a plugin for almost anything.
  • WP Engineers — people who only use WP tend to be too confined to the WP ecosystem, and sometimes are missing basic web development knowledge.
  • Extending themes may cause a very big overhead.
  • A lot of WP wizardry.

Bringing it all together

Let’s recap… We have our stack: Next.js, React, MobX, Styled-Component, WordPress, back end REST API. We know what we want to achieve and we know where to start — The article page.

  1. Our Next.js (node) server calls our BE API with the URL address the client entered (something like sitePath/articles/some-slug ).
  2. Back end REST server returns a response with the post content and metadata to Next.
  3. Next.js uses the response to SSR the HTML needed for the client.
  4. The client browser renders the HTML and bootstraps the JS.


What did we cover in this post?

  1. My journey, research, and workflow.
  2. Why I chose to use React for CT’s front-end.
  3. Basics ofNext.js,MobX andStyled-Component.
  4. Connecting WordPress to our modern front-end stack.

What can you take with you? what is in it for you?

I hope I was able to be clear enough on why you would care about switching a WP site to have a React front-end and why we had to make the change at Culture Trip.

Thoughts about the future.

With Wordpress coming out with Gutenberg soon and rewriting to work with Node.js (project Calypso), there might not be a reason to go down the route we did.

If you’ve enjoyed this post, please give me some claps and a follow!
Also would love to know if you’d like to read any of my future post ides..

Ideas for future posts:


The Hamato Yogi Chronichels

A Personal Blog By Yoav Ganbar