Cancel

Sarah Gooding

Wallace: A Free WordPress Theme Built on the WP REST API and Angular

Bradley Kirby released version 1.0 of his Wallace WordPress theme today. The theme is built using the WP REST API and Angular 2. Kirby has been working on Wallace for the past two years and has rewritten it several times in order to keep pace with changes in the REST API and Angular.

If you view the Wallace demo, you’ll notice that the theme is super fast because the interface is rendered on the client side with JavaScript.

“It really opens a whole new world of possibility for WordPress themes,” Kirby said. “For this release I’ve primarily focused on smooth page transitions. That’s just not possible with the traditional server-rendered themes. But I think there’s a lot of really cool customization techniques that the API allows for, too. That’s what I’m hoping to explore next.”

Although React has emerged as the most popular JavaScript framework for front-end development in 2016, Kirby said he chose Angular mostly because he learned it first.

“I really like the prescriptive nature of Angular,” Kirby said. “There’s a ‘right’ way to do things that you’ll find in example projects and all the functionality comes with the framework itself. With React you have to use a collection of third-party libraries with various maintainers. With Angular, it’s all Google, and all one repository. I think React is a perfectly fine framework, and they actually share a lot of concepts.”

Wallace currently only supports posts, but Kirby plans to implement more core WordPress features, including pages, comments, searching, and category filtering. He said those features shouldn’t be too difficult to implement now that the frame is there.

“From a programming perspective, this was way more difficult to create than a PHP-rendered theme, because you get so much ‘for free’ with the PHP theming API that you don’t get when you’re just making raw requests to the REST API,” Kirby said. The primary advantage of theming with the API is more instantaneous interactions with the content, but creating API-driven themes is not yet as easy as the old way of theming.

Kirby said he is actively exploring the idea of submitting Wallace to WordPress.org, but the Theme Review Team does not permit the use of Twig templates.

“I’ve brought it up with the team that approves themes, and they didn’t like that I was using the Twig templating library on the PHP side,” Kirby said. “So I’d have to maintain two versions of the theme if I were to submit it to the directory.” Kirby hasn’t ruled it out yet and said he will probably revisit the idea next year.

“Twig templates mirror Angular templates really nicely,” Kirby said. “It cuts down on the maintenance burden quite a bit, because I have to exactly mirror the templates on the server side and the client side. That would be more difficult if I had to construct PHP echo strings, the typical WordPress template way.”

Wallace is integrated with the Customizer and will disable its JavaScript when it detects the Customizer is open, reverting back to a “normal” theme. Currently the only option users can customize is the site icon and site title. Wallace does not yet offer support for setting a static front page.

The next items on Wallace’s roadmap are adding more core features into the theme. Kirby said he is also exploring the idea of creating a commercial magazine theme in the future.

“I think the real killer use case for this way of developing themes is e-commerce, but I want to get a good solid magazine style premium theme done before I tackle that,” Kirby said.

Category: ,
37

37 responses to “Wallace: A Free WordPress Theme Built on the WP REST API and Angular”

  1. When I read “smooth page transitions”, I guess I translate this—right or wrong—as “lovely page transitions”. Here, they’re technically competent but there’s no sense of the movement being designed beyond “shift from A to B”.

    It’s stated the page transitions are a primary focus for the theme, so I feel much of the argument for presenting content this way is undermined by a lack of nuance in the transitions.

    Create forum topic from comment

  3. From a programming perspective, this was way more difficult to create than a PHP-rendered theme

    This is the main drawback for me at least. I mean, I understand how the REST API is excellent for integrating WP with apps, but what’s the point of coding a theme from the ground up using it?

    Are the speed differences so great that they outweigh all the extra work that would going into developing a theme purely based on the REST API?

    What’s the benefit of building themes this way? Kind of fuzzy to me…

    Create forum topic from comment

      • The situation with performance is not that straightforward or linear. Loading WP core is relatively heavy operation. If you manage to switch context in a single API request then it comes ahead.

        But for any use case which takes multiple requests (and there is often way more than one thing going on a WP page) the cost of spinning up multiple core loads will add up very quickly.

        In my opinion current REST hype overblows performance benefits for content sites, while downplaying development and maintenance costs (like doubling up of templates in this case).

        Create forum topic from comment

        • This is exactly the main issue with using REST for this purpose.

          Wallace theme is very simple, so it shows one post and runs a single REST request.

          What happens on a typical page that has widgets, related posts, comments? The number of REST requests can be 10, 15 or much more. Each request will run a full instance of WordPress. So, to generate a page using REST, instead of a single WordPress instance for normal PHP theme, REST theme will run 10 or more WordPress instances, taking significantly more system resources than normal PHP theme.

          REST is a great tool, but using it to fully replace PHP theme with JavaScript only theme will increase server usage tenfold for typical websites.

          REST call is not some magical unicorn that will solve speed problems just like that, it is server performance killer if not used properly.

          Create forum topic from comment

  6. (a) there’s nothing wrong with using Twig on the PHP side to keep design and data better separated – no idea why the theme Jedi council would disallow that and (b) Nice job Kirby – but man if this is what the future of doing theme development is (literally hundreds of .js files and having to re-create everything you get ‘free’ today within PHP) — then I’m going to find another hobby.

    Generally, I find that a well designed PHP project that uses .js to make the UX better, is a nice balance. I just don’t understand the push to completely abandon PHP. Again, all this is a hobby for me so I am probably missing some key point somewhere.

    Create forum topic from comment

  8. I really do not understand why this push for js (such as for themes). I loaded this theme up in my local test site and the front-end blanked out; try doing a theme check (longggg list of errors)…

    As for speed, that is subjective considering many sites will have a ton of plugins, media like videos, images, graphics, and other forms of content. Don’t forget, a lot of end-users customize their themes; expecting a person who has limited coding skills to handle a JS theme? I think not. Sorry, but I think this whole thing about JS is a fad unless you are creating website applications and/or plugins. PHP themes will not be disappearing anytime soon.

    Create forum topic from comment

    • Don’t forget, a lot of end-users customize their themes; expecting a person who has limited coding skills to handle a JS theme? I think not.

      On the contrary, no one expects a person with limited coding skills to handle a JavaScript theme. Look, any development that makes it harder for end users to customise (read: mess around with stuff they have zero knowledge of) their sites is very much welcome! A large part of WordPress’ woes comes from catering to end users who have no business “designing” or customising themes. Starting, running and maintaining a website requires time, dedication and a certain level of skill that the vast majority of WP users outright lack.

      WP’s legacy code and its insistence on backward compatibility stems from having to support users who do not or cannot update their sites nor administer their server infrastructure.

      I completely agree that JavaScript frameworks are hype. With that being said, I look forward to WP embracing these (relatively) new technologies. That means the reigns will be handed back to folks who actually know what they are doing! Folks who do this for a living. Folks who have spent a considerable amount of time learning about web tech. How anyone with a basic understanding of HTML and CSS thinks they can successfully start and run, say an ecommerce site (I’m looking at you WooCommerce), is beyond me.

      This unfortunately is the narrative WP has mostly marketed to beginners; that anyone can start their own website with some help from the community through themes, plugins and the support forums. This is the furthest thing from the truth! Yes, using plugins and themes, coupled with Google and some elbow grease, one can learn and successfully run their own WP site. Although that may be the case, most users want convenience over spending time learning about WP. I will concede that WP is still hard for beginners to learn. Most users want to earn revenue from their site but aren’t willing to cough up the upfront investment in time i.e. learning to code (see page builders and all-you-can-eat multi-purpose themes) and money i.e. purchasing sustainably priced theme and plugin licenses (see race to the bottom pricing).

      If we’re being honest, most users only need to publish and update their content. Buying a theme from ThemeForest does not a designer make.

      Please, let’s quit this empty rhetoric about the end user. Let’s leave the work to skilled practitioners i.e. designers, developers and devops people!

      Create forum topic from comment

  9. I find it interesting seeing how few people understand the point of themes like this.

    Performance is always important, and theoretically themes like this will always outperform and outscale something which has to do a complete page render, both client and server side each time. Even if the HTML is cached, it’s still going to be faster to just grab some cached JSON than to haul in a complete dump of HTML.

    As to whether it’s a good idea to double up on templates and create a huge increase in complexity … well that’s a different question altogether, and I guess somewhat dependent on the particular project in question. I can only think of a few of projects I’ve ever worked on which I think would have been suitable for this sort of treatment.

    I think the double template issues inherent in this type of theme will be key to Node JS’s thrust to dominate server side development in future.

    Perhaps this is the beginning of the end for WordPress’s dominance of the web publishing?

    Create forum topic from comment

    • I guess I understand it as an experiment – but not from a practical perspective. Again, I don’t live this stuff as much as you guys do – but I can’t remember ever hearing someone discuss “man this website is slow and won’t scale. let’s rewrite the whole thing as Javascript”. There are so many variables that go into site performance. Especially largely static content sites like most WP sites are.

      Again, I agree JS where/when needed. If I’m doing typeahead, I’m using the Twitter library. Interactive photo editor…JS all the way. Drag/Drop calendar entries…JS.

      Business logic and the overall MVC – sorry I want that on the server not in the client. Maybe for a greenfield development and if not doing it in Java, then something like Node.js could be interesting.

      I think PHP has (rightfully) been slated by mature programmers due to the body of evidence of very poorly written PHP code (some of which is in legacy WP). I weep whenever I see a .php full of ‘<?' excursions littered among HTML. This is why I really like Twig. I also namespace everything and use 100% OO design. So for me WP and PHP is like an old comfortable shotgun and I know I will hit the clay target every time.

      The most disconcerting part of this entire discussion, to me, is "what the heck highway are we on right now?" There are hundreds of thousands of plugin developers and theme developers out there who see PHP code in their sleep. Now we have these signals from WP (Matt) and others that PHP is persona non grata and we all ought to "learn Javascript deeply". I guess if you want to really pivot and abandon your base for a new direction, that's the way to do it. Most small shops do not have a team of programmers at the caliber or the bandwidth of Automattic and can't simply stop doing their normal duties and suddenly become JS gurus.

      So. Where are we and where is this going?

      Create forum topic from comment

      • You seem to be conflating many different issues.

        Using JS to dynamically load content directly instead of forcing complete page reloads has nothing to do with MVC, OOP or PHP.

        Individual users may not complain about performance, but how they use a site can be analysed statistically, and it’s quite clear that fast page loads are beneficial. It’s also quite clear that pulling in some JSON is less resource intensive on both the server and clients bandwidth than forcing entire page reloads.

        Whether this is worth the effort for something as basic as a blog, is another question entirely. But it doesn’t nullify the benefits obtained in doing things this way.

        Create forum topic from comment

        • Using JS to dynamically load content directly instead of forcing complete page reloads has nothing to do with MVC, OOP or PHP.

          This makes my point, exactly. So then why the (seemingly) forced-march to JS?

          And your music play example – agree 100%. But those use cases are the tiny minority compared to the rest of the WP instances out there…

          Create forum topic from comment

      • There are also situations in which this is 100% necessary. Sometimes it’s impossible to do things any other way.

        This post has come up at a particular pertinent time for me, as I’m currently writing a theme which needs to display a music player at the bottom of the page, and the music needs to seamlessly keep working between pages. I can’t do that if the pages aren’t loaded directly via JS. Forcing page reloads would cause the audio to break up mid song.

        Create forum topic from comment

      • I guess if you want to really pivot and abandon your base for a new direction, that’s the way to do it.

        That’s the thing, WP is dead set against moving forward on PHP scale. So JS became for WP an idea of future bail out out of legace issues. Because if WP said “we are moving on towards modern PHP” then devs would say “ok, let’s start” and later “so were is the progress?”.

        But saying “we are moving towards modern JS” (itself a much more moving and volatile target) can be said indefinitely, without actually doing it. Realistically WP will never abandon legacy PHP core, will never require node.js on server, and will never deprecate PHP themes.

        JS narrative became WP’s convenient way of talking about being modern without being modern.

        Create forum topic from comment

        • Whew. Now I feel better :-)

          Being ‘modern’ for the sake of modern is a fool’s errand. I really hope the power base within WP understands this.

          Well managed, large SW projects do well through evolution, and fail spectacularly when an attempt at ‘revolution’ is made. Evolution need not be slow or boring, either. It’s a conscious choice the project leadership has to make.

          Create forum topic from comment

  10. The main thing that impresses me about this theme is that it it is “linear” meaning FINALLY a theme comes that way as a default. Twenty whatever themes have always defaulted to a sidebar which makes little sense in a mobile world where sidebar stuff goes to the very very bottom of the page. So why have a sidebar?

    Create forum topic from comment

  12. Thank you for doing this. It’s exactly the sort of tool I need to help me learn how to use the API in a powerful way and finally figure out how to use Angular, too. Everything I’ve learned about WordPress I learned by tinkering with someone else’s code, so this is an awesome way for me to keep learning.

    Create forum topic from comment

  13. I can certainly see the benefits of creating a theme using ReactJS and the WP REST API, however, using the WP Rest API to fetch the data for the theme doesn’t quite make sense as the WP Rest API is self consuming (the end points live on the same server that the theme is served from) and I can save myself the round trip requests from the browser to the server and then back down to the browser again.
    Perhaps using a GraphQL wrapper with the WP Rest API could cut down the number of data requests?

    Create forum topic from comment

You may also like

Newsletter

Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.