Front-end development with WordPress

Although WordPress is created in PHP, nowadays, a lot of themes and plugins make use of JavaScript to create feature-rich, responsive, client-side sites. Some go as far as to use WordPress only as a store of data, making the whole site a single page (SPA) and everything in JavaScript. The WP REST API project, which simplifies the communication between front-end and back-end of a WordPress-powered site, helps this trend quite a lot. Although there are plenty of sites and tutorials describing how to create SPAs, for newcomers it is a jungle of tools, frameworks, libraries and other stuff. In this article, I’ll give you an overview of the current state of front-end web development and describe my story of how I got to use them. For more in-depth texts, follow the links and Google the technologies.

Communicating with the server (WordPress)

When doing client-side WP themes or plugins, we still store the data in a persistent server-side database (MySQL e.g.). Without the data, our application would be useless. There are two primary ways of communicating with the WordPress on the server so we’ll briefly talk about them.

admin-ajax — the old way

Admin-ajax¹ is a simple URL endpoint for Ajax requests which can respond with data. You hook actions, send an action and process it on the server. However, while it is quite simple to use it, you have to program everything yourself so have to spend a lot of time on the backend.

WP REST API — the new way

WP REST API is a rescue to our previous problems. It adds several useful URL endpoints to our WordPress installation allowing us to query and write data — almost everything we could do from PHP. The only and the biggest downside is that it’s not currently included in the Core² so users have to install a plugin to have it work. With it, we don’t have to concern much about the data, only with the way of getting it (learn to use the API). And if an endpoint is missing, we can just use their PHP API to program one ourselves.

Brief history of JS client-side frameworks and libraries (from my point of view)

When jQuery arrived in 2006, it revolutionized the whole web development. It removed the cross-browser incompatibilities and attracted many programmers who would not touch JavaScript otherwise (such as myself).

Then came Node.js, which is basically the JS engine from Chrome, which made it possible to use JS on the server-side. This hugely popularized JS as a language, making it the world’s most popular one as it can now run on almost any device (in a browser or on a server). This brought a lot of talent into the JS world and programmers started to treat it as a standard language. With that came the package manager (npm) which helped to manage libraries in an easier way (similar to Composer in PHP).

After that, new JS library was being published almost daily. And with that, the rise and growth of client-side JS frameworks for making single page applications came.

Popular front-end frameworks

In the next sections, we’ll be talking about some of the most popular JS frameworks and libraries I’ve used. An outline:

• Backbone
• Angular
• React
• Flux frameworks

Backbone³

Although I haven’t used it directly, Backbone was once considered the most widely used JS framework. It is very small (~7 KB) and is based on the MVC architecture⁴. Backbone is heavily used throughout WordPress administration screens. What is more, WP REST API client-side library⁵ is written for Backbone too.

AngularJS

Are you a Java programmer wanting to build a nice single-page application? Then AngularJS⁶ is for you. Started by Google, it’s a massive MVC library (~150 KB) which has the API for almost anything. When I first learned a bit of Angular, I was really excited about its features and abilities. However, I was later discouraged from using it because of its size, sluggishness and the fact that they almost broke their community into two parts as the new version of Angular was not backward compatible. Since then, I’ve jumped onto the React/Flux bandwagon, though I’ve heard that they changed their plans for AngularJS, made it backward compatible and polished its features. All in all, it’s one of the most popular and feature-rich frameworks for building big JS apps so check it out.

React

React⁷ is a medium-sized (~120 KB) JS library for building user interfaces. We simply define the interface declaratively in HTML-like language embedded in JS called JSX, supply it with data and React will render the HTML structure. When some of the data have been modified, React constructs the new interface in the memory (Virtual DOM⁸), comparing the old and the new one, finally re-rendering only the changed parts. One of the most CPU intensive tasks is rendering the HTML and this method proves to be much faster than rendering the whole HTML structure from scratch. This is the major difference from other view (as in MVC) frameworks because they usually remove and reconstruct the whole structure, killing the browser performance and making animations hard to do.

React can be combined with other JS frameworks (such as Backbone) but it’s best used in combination with Flux architecture. More about that later.

React Router

React Router⁹ is a JS library for routing in React-powered client-side applications. Instead of having to manage the transitions between React components yourself, you just specify the main routes of your site and React Router does the rest. It also manages the browser’s history¹⁰ using either the modern HTML5 approach (e.g. pushState) or with Hash as a fallback.

What is Flux, versus MVC

Flux¹¹ is a different architectural pattern for creating single-page apps. While in MVC data might flow in different directions, in Flux, it flows unidirectionally. It simplifies creating and maintaining the SPAs substantially (I have no data to back this up as I still haven’t created a bigger site in Flux).

Flux libraries

As Facebook unveiled Flux without a tangible implementation, many web programmers started to build their own. And so, Flummox, Alt, Fluxible and many other Flux implementations saw the light of a day. However, as Dan Abramov wrote in “The Evolution of Flux Frameworks”¹², each of them lacked something. Therefore, he decided to write his own — Redux — which aims to solve all of these.

Redux

Redux (not the WordPress Redux Framework¹³) is a JS library helping you to manage the state of your application in a Flux-like fashion. While I don’t know how to describe it better, I got that “wow” feeling after seeing how it works. An evolution! Full of functional concepts. (Almost) no global state. Full ES6 support. Works both on the client and the server. It quickly gained popularity among front-end developers and the version v1.0.0 with a revisited API was released a few days ago.

Redux is really a tiny library with no magic. Instead of managing the state of your application in React components (in the view), Redux manages it for you. It has a standard Flux-like dispatcher. The major difference is that in Redux, there is only a single store so no waitFor necessary. For better code management, you just write reducers which are then reduced to form the store.

I think you are safe to go with Redux — it will probably stay here for a while and is actively maintained. I’m even using it in my new SPA blog.

Major problems with single-page applications

There are two major problems with single-page applications, both of them being interconnected:

1. Google SEO
2. Loading speed

Google SEO

The last time I checked, it was not a good idea to have the content of your site rendered in JavaScript only as Google Search Engine won’t parse it properly. While they execute the JS on the sites, single-page applications (SPA) might have a worse ranking. I have experienced this first-hand when I was learning about AngularJS (as far as I can remember) when it came out — it was almost impossible to find a relevant piece of docs on their site through Google search, because their whole docs site was built in Angular as an SPA.

At the moment, I’m building a new blog for myself (yay) based on React and Redux with WP REST API. My greatest worry is that I’ll lose visitors due to the nature of the site. Fortunately, I have a fix in mind. It’s the same fix as for the second point so I’ll present it a bit below; read more.

Loading speed

Not having to do HTTP requests on each page load is incredibly convenient. SPAs tremendously increase the user experience of your site. But what about the initial load? The load during which all the resources (CSS, JS) have to be downloaded, executed and cached? It is not uncommon for SPAs to exceed megabytes in size so the initial load might be times slower than if you haven’t used SPA at all.

Solution for WordPress (and any PHP powered site)

The usual thing to do is to render the site on the server for the initial request and use the SPA for the next ones. When Google Search parser is detected, likewise, render the page on the server for it. Sites which can be rendered both on the client and on the server are called Universal JavaScript¹⁴ sites (used to be called Isomorphic JavaScript) — the same JS code is shared between the server and the client.

Those who use Node.js¹⁵ as the base platform for their site are in luck — it’s quite easy to convert and run the SPA on the server with it. But what about us, mighty WordPress developers? As far as I’ve researched, it’s not so easy. You need to install V8js¹⁶, a PHP extension which embeds the V8 Javascript Engine into PHP. This solution is not possible for shared/managed web hosts as you cannot install anything custom into them.

To be honest with you, I haven’t yet used V8js with WordPress. I’m planning to do so shortly and will write an article about my experience with it. All in all, you will still have to write the custom DB queries for your application because you use WP REST API with it.

Until Google will treat SPAs equally as server-side rendered sites, this is one of the biggest obstacles to building client-only themes and sites in WordPress.