All About Headless: A Fireside Chat with the JavaScript Developers of WP Engine

This week I had the pleasure of sitting down with four WP Engine employees who have created a JavaScript front-end for their WordPress websites. I wanted to pick their brains on the subject that has the WordPress community captivated. Why JavaScript? What framework do you use and why? And most importantly: How did you do it?

Meet the Developers

First, let’s meet the developers we interviewed:

Jason Stallings: Long-time JavaScript developer and advocate, Jason started in L2 Customer Support and is now a Software Developer on the Performance Intelligence team at WP Engine. He develops primarily in React.

 

 

 

Nate Gay: Nate works on the Customer Support team at WP Engine, and has been developing with JavaScript for about two years. In that time he has worked with jQuery and React/Redux. He has created a WordPress theme and plugin for his JavaScript front-end using React.

 

 

Ben Moore: As Business Intelligence Developer, Level 2 at WP Engine, Ben Moore creates internal tools for the Customer Experience team. Ben, better known as BMO, is a huge Angular advocate and a proponent of JavaScript apps built off of WordPress.

 

 

 

Jay Hill: Jay works as a member of WP Engine’s L2 Customer Support team and serves as Amazon Web Services Subject Matter Expert. He has been working with JavaScript for a few months. He is currently creating Progressive Web App by making a Headless WordPress site using React.

 

 

Libraries and Frameworks

I asked our developers, why do you use the framework or library that you use? As it turns out, three of our four developers choose to use React and the Redux framework, while one is strongly in favor of Angular. For those who may be unfamiliar, Facebook created React while Google created Angular.

For Jason Stallings and Jay Hill, React is the library their team and projects tend to use. Jason Stallings says of React, “It seems to be the framework that has “won” the framework war. Last year I attended the Chrome Summit and Google themselves spent the whole time talking about React. I like the amount of power behind it. I like the developer workflow as well.” What does he like about it?

“It’s declarative, functional, and forces good standards and principles.”

Nate Gay found his way to React as a solution to the jumble his original jQuery project had left him with. He uses Redux to manage state, and Axios as his library to make REST API calls.

Ben Moore, by contrast, uses Angular. His reasoning is simple:

“I love opinions and hate options.”

He says, “It just makes my life easier when I don’t have to think about the best way to do it when one of the best companies in the world already told me how they’re doing it.” Not only this, but Angular coupled with Angular CLI offers him the power he needs to work with large amounts of data in the Business Intelligence tools he creates. He does admit though, “for a website, you probably shouldn’t use Angular–it’s just overkill.”

Since our room was split for Angular and React, I asked our developers–was there any project in which you’d prefer to use another framework like Vue instead? All four agreed that for themselves in most cases, the answer was no. Ben Moore, as a proponent of Angular, does say, “I would look into it for smaller-scale components. I keep looking at a back-end dashboard or a plugins page, where you’re plugging into an existing project or site. Angular isn’t very good at piecing or piping into other things.”

As a user of React, Jason Stallings simply says no. “They solve similar problems. Vue might be a bit quicker to get the project up and running because it requires less “up front” transpilation and minification, but any modern framework should have that anyways.” All of our developers agreed that Vue is certainly the right choice for many users, even if it wasn’t their own framework of choice.

Why build a JavaScript app?

I also wanted to know the “why”– why make a JavaScript app? What’s the value for you? Nate Gay loves the performance aspect. “When I request information from the REST API, I can get very specific about the kind of information I want, and that allows me to load a very fast and efficient website.” He notes that a lot of problems he sees in sites in his work on the Customer Support team stem from incorrectly sized images. “In JavaScript I can grab the height and width of the image to be loaded, so when I create that element on the page, I can create it with the exact resolution.

“I find that it’s really easy to make a fast and efficient mobile-friendly site using JavaScript.”

Jason Stallings by contrast was drawn to the static nature of a JavaScript front-end. “To me, they’re very attractive. You build it once, put it somewhere, and then there’s no updates, there’s no login, you don’t get hacked, no server to maintain, no upgrades. You just “set it and forget it.” As long as HTML is still a thing, your website will still be valid.”

For Jay Hill, the answer was more, “Why not?” It was a new language to conquer on the road to becoming a full-fledged AWS-certified developer. Curiosity drove his continued interest. “I didn’t realize how big JavaScript is these days and how it’s changed from like, 1998 to today. Back then JavaScript was like malware, and everyone just turned it off in their browser. But today you have companies like Facebook and Google doing things with it. It’s exploded, it’s a huge industry.”

And sheer power was the driving force for Ben Moore. Building tools that query hundreds of endpoints for data in a quick and efficient way was key. “Everything that I’ve built is highly dynamic and I needed the least impact on the server as possible… I think I pull in hundreds of thousands of rows a day. I needed something more dynamic that can distribute those resources to the browser, and generate things on the fly instead of refreshing the page each time.”

Integrating with WordPress

One of the biggest problems in developing a Headless site is simply figuring out how to do it. Everyone seems to have a different answer. So I asked our developers: How have your apps have integrated with WordPress? Ben Moore uses a combination he likes to call “Brainless” WordPress. In that, he means “I use WordPress for back-end functionality on initial page requests. So it handles authentication and user management, and enqueueing assets. But the only HTML I want it to spit out is scripts, styles, and Angular instantiation. From there, Angular takes over.” On the front-end,

“As you click around whatever I build out, it’s straight API calls. It looks like you’re going from page to page, but it’s really a single-page web app.”

Similarly, a plugin and a theme are how Nate Gay chose to implement his JavaScript project. Of his plugin, he says “I get a nonce and then I use the token in my calls back and forth between WordPress. It’s an Admin interface so it has to use the login token. And then I have a theme, and I just load a single file on page load, which is the magic piece for me.”

Jay Hill is creating a Progressive Web App. “I’m using the REST API to query data. It’s pulling the data and serves through my menu component through a plugin I’m using. My front page is just a list of blog posts, and in the menus it passes a slug as a query argument to be able to navigate each page.”

GatsbyJS has been the tool of choice for Jason Stallings. GatsbyJS is a static site generation tool that integrates with WordPress. That means, “You use React to structure your site the way you want, and then Gatsby is in charge of “sucking in” the data and rendering it as static HTML. GatsbyJS has a WordPress source plugin where it uses the REST API to pull your posts, pages, custom post types, and makes it available to you as a GraphQL server. You can then preview that data from your front-end. Google and Facebook work together so that it beats their Lighthouse test–any website built with Gatsby gets an instant 100.”

Challenges and Surprises

Since our developers are using WordPress in a non-traditional way, I wanted to know: what are some of the challenges or surprises you faced in working with the REST API and building your app?  Jay Hill has run into a lot of issues, as a developer working with JavaScript in a new way. He says for him, “knowing the structure of the data that’s being returned has been a big hassle for me to troubleshoot. Console.log has been a huge help in that aspect, as well as this Google Chrome React dev tools extension.”

As someone who has worked with JavaScript for a long time by comparison, Jason Stallings says the biggest challenge he faced was that,

“Shortcodes don’t always work correctly when you’re pulling them through the REST API.”  

By that he means, “a lot of shortcodes include HTML and JS and CSS on the page, and the shortcode itself spits out a div that has classes and IDs that the JS can use to recognize it and fill in the content. If you’re pulling the data from the REST API to render on another front-end, that JS and CSS doesn’t exist on the page. That was a big hurdle to get around.” He ended up using an HTML parser to look for those divs, strip them out, and replace them with a matching React component.

Ben Moore has very dynamic and data-intensive tools built on JavaScript. One of his largest projects was built pre-REST API and pre-components. He says, “the biggest challenge I had was building custom endpoints and also creating a system where six other people on my team could also build their own endpoints to contribute.” He says collaborating, mapping endpoints, and rendering out filters were by far the hardest parts. “Trying to go between PHP and JavaScript and try to keep the same configurations and same mappings was… fun.”

What does your development workflow look like?

There are a lot of conflicting opinions in the community over what the “right” development workflow is. I asked our developers what their workflow looks like, and got surprisingly different answers from each.  For Jay Hill, it’s mostly trial and error at this stage. He reads documentation, tries a new task, and uses his diagnostics tools and resources to troubleshoot. Laughing, he says “If I still can’t get it, I ask Stallings for help.”

For Jason Stallings, working on a team means he uses Continuous Integration tools. “I develop locally, push to Github, from there TravisCI picks it up and does tests to make sure it loads in the browser, ensures I can click around, can I load a post, and then it does unit snapshot tests to make sure the components are rendering correctly too. Once all those tests pass, TravisCI pushes it to my live site on static hosting.“ His process is all automated. But that development pipeline does take longer than it would to just publish a new post on WordPress.

He says with this kind of workflow you should also consider,  

“when you’re publishing content in the backend it has to go through this big pipeline, and that pipeline takes about 5 minutes from hitting publish to when it actually shows up on the front end.”

Five minutes may not sound that long, but for a publisher that can be quite cumbersome. Imagine noticing a typo in one of your posts. From when you click “update” on that post, it still takes another five minutes until it’s fixed on your site.

Nate Gay uses the Create React App for his development process, which means changes show up right away in his browser as he works. In his local environment he has an mu-plugin that disables authentication so it doesn’t interfere with his workflow. Of the deploy process he says, “My build tools for my plugin aren’t very pretty. It’s just a bash script that does the React build and takes the minified JS, zips it up, and then I can deploy it to my site.”

Ben Moore is an advanced JavaScript developer, but he doesn’t work on a team. That means for him, automation isn’t quite as important. He utilizes Angular CLI heavily in his development process. “I am loving the Angular CLI. It has its own Node built in servers so I can do Angular front-end work and I put placeholders so I can pull in something dynamic. When I’m comfortable with what it’ll look like I can send it to my vagrant, then push it up when I’m happy. I push to Github so it saves, then push to WP Engine staging. If it works as it should, I push to live.”

How did WP Engine help?

I was also curious how WP Engine came into the picture for our developers. Did the WP Engine platform prove to be beneficial in the development or hosting process? Jason Stallings says it does, particularly when it comes to caching requests to API endpoints.

“As long as you’re making GET requests to those endpoints then they’re cached, and they’re automatically purged from cache when you make updates to posts.”

Nate Gay also points out the benefit of WP Engine’s CDN for static file caching and geographical distribution. And great servers as well, says Jay Hill.

Conclusion

It was certainly a compelling conversation to lead. Four very different developers, all in their own niche and with their own workflows. The best way I could summarize Headless WordPress after speaking with them would be, “there is no one-size fits all.” No matter which methods you choose, it will be a learning experience. But as our developers and many others have learned along the way, developing with JavaScript presents opportunities for great advancements in user experience, power, and agility. And with tech giants like Google and Facebook backing JavaScript, it is quickly becoming the future.