This time it’s a static-file-driven, mobile-app-like blog. And the tooling I made should be usable on any simple WordPress blog! But… WHY???
Some background
I made a simple, app-like, completely static-file version of this site! It’s super-fast and pretty lightweight and it didn’t take very long. It’s here:
Here’s some of what I was trying to achieve and why…
Keeping it simple
I find myself rebelling a lot against the complexity of modern web solutions. I’m a use-the-platform guy who firmly believes that the simple solutions are better, easier to make and maintain, faster, cheaper, etc.
Proving things to myself
I’m working with a lot of complexity at work: mostly building a headless site with React and Next.js and highly-scalable headless solutions involving many layers of caching and integration. This is right (maybe?) for the context of the work.
But I’ve found myself wondering if a much simpler solution could achieve the same benefits – to some extent, at least.
I wanted to prove that there was a “headless” solution to websites that didn’t require node.js or a ton of heavy JavaScript framework code and a zillion dependencies.
Yes, I’m (probably) reinventing the wheel
If I build a tool that scrapes all the content from the WordPress API and dumps it to some static format for serving as a static site, am I just making a poor-man’s Gatsby? Or Astro. Or… Next.js – the thing I’m proving that I don’t need? Or Simply Static? Is it not just what the JAMStack was doing all along for so many years?
Well, maybe. And one of the main reasons for using such a tool is that they handle all the complex edge cases that I’ve almost certainly not thought of yet and don’t have the constraints that I had. Probably the best reason I’ve been presented with for using Next.js for a web site (rather than a web application) is that if you start adding more and more code to handle features and use-cases, you end up with your own Next-like framework anyway, and it’s better to use a framework maintained by a framework expert! So I see the reasons you would do that.
But also, I wanted to show what is possible with a very simple approach. It seems to me that you should be able to get a long way building a static site with a simple scraper script and a basic template.
And with a bit of JavaScript, maybe using a small reactive framework, we can make it app-like too!
Statically hosting all of this on a CDN means free hosting in the best case, and enormous scalability, and global edge serving in the other best case.
What I won’t do
This approach had some hard constraints/limitations:
- It will be slow to generate a large site
- It will need developer experience and tooling to use
- It won’t be able to do anything that requires server-side processing without some third party service (e.g. forms, signups, etc – though I DID find a way to do search!)
- Template editing won’t be WYSIWYG – the resulting output will be pretty bland and made in HTML and CSS.
These are all limitations I’m happy to accept for my simple personal blog.
What I made
Here’s what I made… it’s not finished, but it’s 80% of the way there:
Ultimately the back-end is my regular WordPress blog.
The static version is built using a PHP-based CLI tool, using Laravel Zero to scrape the content, restructure it and save it. It’s pretty efficient – the slowness is in the API queries. It builds my 750-page/post site in about 80 seconds.
There’s then a simple HTML template and some AlpineJS scripting.
I was really glad to stumble upon PageFind – a tool that builds a static content index and that allows search. This makes everything a bit more dynamic.
Things I want to add in the future:
- History/back/forward navigation/URL updates
- Page listing
- Ability to re-use the scrape/build scripts across sites. They’re not quite site-agnostic yet, and I want to write some docs.
That’s a shorter list than I thought it would be before I started writing it! So that’s good.
Conclusions and thoughts
For many years I was pretty unimpressed by the JAMStack approach. I think because it always seemed to be querying some dynamic back-end anyway, so it felt like you had the complexity of a dynamic CMS AND the complexity of a dynamic front-end app, but without very much benefit.
Perhaps I misunderstood. But it seemed like you had:
- Static site generators: all static files, built at run time
- “JAMStack” sites: static templating, but pulling in dynamic content over an API
As I’ve been moving from a “Spin up a WordPress site for every little project” approach to a “Make some static HTML files and host them for free” approach, I’ve been thinking about how this model can be used more. It’s cheap. It’s secure. It’s fast. I love developing with it.
This is not what Next does. Next needs a back-end server and a zillion (ish) dependencies. And it’s better suited to applications that need lots of dynamic content, not a simple blog site. I remain that if you’re building a marketing site, the cost/benefit of Next is low if not negative.
It’s probably what Astro does, but Astro also has … checks notes … 450 ish dependencies!! (Astro looks really interesting, very nicely done, and has a guide on working with a WordPress blog/site!). There are probably other frameworks and site generators that can help too. I’m no expert in this area.
My site has 93 JavaScript package dependencies, which is still too many, but most of them are via TailwindCSS which is entirely optional, which I trust, and which rarely breaks.
My project also has a bunch of Composer/PHP dependencies. But most of those are to create the CLI tool that does the scraping. These are not problematic. This stuff just works. It’s stable. And when it’s broken you get helpful errors. It’s not a world of pain like I find npm to be.
So I proved the concept. I achieved my goals. I like this. It’s not perfect. But I will take it a bit further and see where I get to.