I’ve been following Wes Bos’ Advanced React course, and it’s got me thinking:
Would it be possible (and indeed desirable) to continue getting the benefits of Sage, but using a client-side, WordPress API-fuelled site architecture?
Perhaps using Styled Components, Next.JS, WPGraphQL and something like Prisma?
If the answer to this is “Yes”, would (slowly) moving Sage itself (rather than starting a new WP theme) towards this architecture be the best way to go about this?
My reasoning for this proposal is that WordPress itself (starting with Calypso and now Gutenberg) is clearly shifting from a “back-end first” (jQuery / JS and PHP) philosophy to a “front-end first” one (React w/ API).
The benefits are obvious, in the form of super-fast loading (given that only JSON for each page is being pulled down from the server, and in many cases pages are pre-fetched) and the ability to create complex UIs.
It’s my view that moving Sage in this direction, early and ahead of the curve, would future-proof the theme, for years to come, whilst also retaining the awesome community, who I’ve found (purely anecdotally) to be lightyears ahead of the wider WordPress theme development world, in terms of their outlook and the technologies / approaches taken.
What are others’ thoughts on this suggestion / proposal? Even simply, is this good or bad? Are there downsides beyond the learning curve?
For the future of Sage, my vote is to continue favour building reactivity in spots, with an overall back-end-driven site.
Going with an all-reactive, single-page-app style, backend-hydrated, GraphQL-powered website sure sells for those who want to build a skill moat as a developer.
But that’s not Sage. That’s something else. Gridsome caught my attention in that category (go Vue!)
Sage can still take some nice aspects of all-reactive sites:
Like using Turbolinks for quick page transitions (if you’re going to build the whole stack to not work with Wordpress plugins, why not keep it simple and pick Turbolinks?). While you’re at it, why not use stimulusjs with it too.
Like serving the main css deferred and serve a minimal css inlined in the head of key pages. It could even be a per-template minimal inline style e.g. for single, for home, for archive, etc. That could be the Sage way too.
Like picking a default for lazy loading of content blocks, especially on story pages built with ACF flex modules or something similar.
Like providing optimized webpack configs and helpers for adding non-all-encompassing reactivity in spots with Vue or React for animated svgs, staff directories, filtering long lists, dynamic search results or live-updating infographics. One way to do this would be to bundle wp-graphql into bedrock by default.
That seems exciting to me, it seems more sane to me, and it seems more Sage to me anyway.
All really interesting points (and sources) there, thanks!
Just to address your central argument:
Why would “going all in” and committing to a Single Page App-type thing be undesirable, or even constitute a “skills moat”?
Could the same not be argued of learning any framework/theme-specific setups, like the front-end tooling of Webpack / Yarn, or Blade templates (etc.) of Sage?
In this sense, would whatever the specifics of the setup are just be the latest list of things to learn in order to ‘know how to do Sage’ – As happens with any major iteration/update of Sage?
EDIT: I see there’s a React equivalent of Gridsome called GatsbyJS. Exciting stuff!
Wow Gridsome looks neat. I have been playing with NuxtJS atm to make a test Headless WP site and am finding it reasonably straight forward.
But like you said this might be done better in the theme. At some point once you go headless you largely lose the point of using WP at all. Once you’re re-writing even just how forms work you wonder if it’s not worth just switching CMS at a point.
Edit: I think perhaps starting over in an SSG and adding in what you need is more appealing at times than activating a dozen plugins then trying to pry optimisation out of it piece by piece…
You caught me making a judgment on what motivates someone to build or jump on the Single-page-app phenomenon. In my view, I don’t understand its appeal, and came to the conclusion that people buy into it for job security.
But it might be that what baffles me is a disconnect in values. Getting to the bottom of things, understanding the basics and abstracting them, doing fewer things but doing them well, finding the one thing that matters and building on that, betting on what doesn’t change and being suspicious of trends; those are some of the things I value.
And I found those things in Sage and the Roots community. Sage wasn’t one of the earliest WordPress themes, but it was the one that took a principled stance to keep templates DRY, using accessible menus through Soil, and a good developer UX in general, etc.
Single-page apps build on those practices – they’re all table-stakes now – but because they take over everything with javascript, they seem to forfeit a few of the other values I think were foundational for Sage and Roots.
Maybe the SPA trend is here to stay. I still find it exciting to take some its good ideas and create something more minimal, incremental, more WordPress-like and more Sage-like.
It has always been my goal for the future of Sage presets to allow for complete overhauls of the entire front-end stack in Sage. So you’ll still get the blade template engine loaded, and you’ll still get the benefits of cache-busting and our build routine that integrates nicely with browser-sync, but I do envision user-contributed presets that, say, nuke the scripts and styles directories entirely and scaffold a completely different setup. Right now I’m working on porting the sage cli over to node.js, after which I’ll look into coming up with a better API for building presets and supporting third-party preset packages.
Since you mention following Wes Bos’s latest course, it should be pointed out that that course is using nextjs / node to run the back end server. This is a pure JavaScript server. Until wordpress ditches php completely you’ll never see something that closely resembles what you find in that course.
Wiith that said, you can already get 90% of the way there today with Sage the way it is. I integrate react in many of my projects. I typically set up a shortcode wrapped in an action hook bound to init which lets me inject a body class before the page is rendered.
Ex. add_action(‘init’, function() { add_shortcode(‘xxxx’, function( $atts ) { Add_filter(‘body_class’, function() { # add body class here } Return ‘<div id=“react-app”></div>’; } }
(Forgive the formatting, typing this on an iPad )
Then I use a route in main.js based off that body class and spin up a react app on that page. You can use react router which works off the base path of the current wordpress page. I’ve used redux as well.
From there you can make calls to the wordpress REST api to pull out data, provide pretty slick user interfaces and always fall back to standard sage / wordpress when it makes sense.
There’s nothing keeping you from using GraphQL as well provided you set up a separate GraphQL server somewhere. Having data split could be a bit overly complicated but may make sense for some projects. So far I’ve been created my own endpoints and using wp_db to store data in my own database tables. I started looking at WPGraphQL but haven’t had the time to really evaluate it yet. It would be neat to use it to replace the wordpress REST api… I like having an ORM layer—but I’d have to test extensively before I would trust WPGraphQL with the data on a production wordpress site.
In my opinion all the tools are there already for you to do almost all of this—no it wont be clean cut like the example in the Advanced React course, but that will be the case as long as wordpress core is based on php and we’re stuck using Nginx / Apache.
@Simeon – Fair point there! But then again, is there a benefit of switching away from WP at that point? Surely it’s still a great CMS option?
@pascallaliberte – All good points! I’d actually argue that a lot of what goes on in many (good) SPAs that I’ve seen is the same sort of thing as what you’re describing here:
Lots of abstraction
DRY principles / heavy re-use
Simplicity where possible
The only “crime” of the SPA is its relative youth, which naturally attracts the accusation that it’s a trend… So perhaps there’s an obligatory waiting period that SPA-style architecture needs to endure, before it is afforded the same respect of Sage.
Generally speaking, I hear you though; I’m normally quite conservative with technologies, and suspicious of newness of the sake of newness. It’s just, I strongly believe in the benefits of the SPA architecture.
@QWp6t – This is great to hear! Will you post the progress?
@jgarib – You’re right about the use of technology there. But it’d be quite easy to have a similar setup interfacing with a headless WP site, no?
re: The code + other info you’ve posted:
I’ve done similar things myself before, but this isn’t quite as elegant as Next.js which allows basically the same code on the front + back end.
The really big one for me is being able to sparingly serve CSS and JS where it’s needed. For CSS, Styled Components mean that only the relevant CSS is inlined and served to the user, avoiding the massive CSS files (and even multiple CSS files) we see on the average WP site. Repeating CSS can still be delivered via a site-wide CSS file.
I suppose the other big benefit is not having to do any full reloads for when only a small part of the page is changing (like page transitions).
)