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-ajax1 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 Core2 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)
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:
- Flux frameworks
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 architecture4. Backbone is heavily used throughout WordPress administration screens. What is more, WP REST API client-side library5 is written for Backbone too.
Are you a Java programmer wanting to build a nice single-page application? Then AngularJS6 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.
React7 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 DOM8), 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 Router9 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 history10 using either the modern HTML5 approach (e.g.
pushState) or with Hash as a fallback.
What is Flux, versus MVC
Flux11 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).
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”12, each of them lacked something. Therefore, he decided to write his own — Redux — which aims to solve all of these.
Redux (not the WordPress Redux Framework13) 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:
- Google SEO
- Loading speed
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.
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)
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.
- AJAX in plugins ↩
- WordPress Core ↩
- Backbone ↩
- MVC (Model-view-controller) architecture ↩
- WP REST API client-side library ↩
- AngularJS ↩
- React ↩
- Why is React’s concept of Virtual DOM said to be more performant than dirty model checking? ↩
- React Router ↩
- History interface ↩
- Flux explained ↩
- The Evolution of Flux Frameworks ↩
- WordPress Redux Framework ↩
- Node.js ↩
- V8js documentation ↩