Beyond WordPress. Hello Jamstack
I’ve used WordPress almost daily since 2007. It changed my life and for over a decade it has been my sole way of building websites. I even added “WP” to my web design business name.
Over recent years much has changed both in and out of WordPress. I’ve changed too. I adopted an agile approach where we evolve sites based on ongoing user experience data.
It seemed a good time to step back and ask where and when WordPress is serving my client’s needs best and see what else is around.
It’s too soon to draw conclusions, but as I have some basic front-end code skills, the philosophy behind the Jamstack movement has resonated with me.
For my next web project I’m going to take that route, but here’s my thinking so far.
Making sense of WordPress after Gutenberg
I’ve consumed almost everything Matt Mullenweg has said and believe he sees “code-free” website building as the future for WordPress.
Leaving aside his approach, I think he might be right. The demand for code-free seems almost unstoppable in WordPress and this route is not inconsistent with what WordPress initially offered bloggers.
The problem for me is I’ve only ever wanted to go as far as “low code”. That’s what Beaver Builder represented for me.
I didn’t come to WordPress for code-free blogging. I came because it was a simple open source CMS with a growing number of developers sharing their code via the repositories.
I had already learned to build basic sites with HTML and CSS and WordPress offered me a way to explore the dynamic web when there were few services and APIs.
It was amazing. With minimal code hacking I was able to create a membership and an ecommerce site for personal projects.
Moving to client work
This was not my plan, but in 2013 a school friend asked me about WordPress. She was doing marketing work for a large international company and their US WordPress site was breaking.
I got the job rebuilding it and she fell in love with WordPress. This led to me rebuilding her other client sites which needed to go mobile responsive.
As most sites were essentially static, there were some concerns about using WordPress:
- The clients would have to maintain and host a LAMP stack and update WordPress.
- We had only just fixed a broken site due to abandoned plugins, and custom work being overwritten by updates.
We did it anyway because:
- Clients liked the idea of editing content and being able to add functionality via plugins.
- We liked not having to change every file to do common tasks like adding pages.
As WordPress was then largely unchanging and we limited ourselves to a few developer focussed addons like the Genesis Framework I wasn’t overly concerned about introducing this dependency.
It felt like we were still selling fully customised sites. WordPress was open source so we (perhaps naively) felt we were giving them full ownership.
Moving to “low code”
Beaver Builder became a key part of my stack for the same reasons it was built. The team behind it ran an agency and had clients asking for a more user friendly way to edit their content.
Back in 2014 few developers saw Page Builders as a serious professional option and they found nothing suitable for them.
They decided to make their own builder to give clients what they wanted, but still keep it simple, performant and developer friendly.
They then put this out commercially with the needs of other agencies and freelancers in mind, but also with enough that non-coders could build decent sites.
I had many reservations:
- It was the first clear introduction of a major business dependency.
- Page builders (like mega themes before) tended to get bloated and unstable as they met the increasing demand for more.
There were many deciding factors, but the main one was that most clients could not self manage even a basic WordPress setup. They got hacked and had hosting issues.
This could have been the point where I decided that many sites are not suited to WordPress, but even with project based work we did not feel we could abandon old clients.
Instead, we took on site management allowing us to also support the dependency of a page builder and offer its benefits.
The decision relied on my trust in the Beaver Builder team. I did my due diligence and believed in them. I was not let down.
Trouble in paradise
Obviously Gutenberg is a threat to all page builders, but being forced and complex has also changed how I view “community” in WordPress as well as its value as open source software.
It has been an incredible community, but without governance it has allowed one person to change it to suit his commercial interests.
The original appeal of WordPress was that it was a simple CMS where plugins allowed you to opt-in according to your needs.
This has been disappearing as WordPress developers sell their addons to large corporations focused on continuously adding features.
Being in competition with each other, my efforts now go into removing what has been forced on me and trying to limit the maintenance consequences of that (conflicts, duplicate features, performance, security risks and client confusion).
Matt Mullenweg’s recent call for “canonical plugins” shows he’s aware of the problem, but his solution of community plugins that stay close to WordPress core only gives him more control as the primary sponsor of that community.
Getting back to basics
I’m not against the pursuit of “code-free”, but feel the wisest shortcuts are those that allow us to evolve with the changing specifications of WC3.
(It was not insignificant to me that they dropped WordPress from consideration for their blog because of Gutenberg.)
I thought it was time to revisit the basic languages of the web HTML, CSS and JS. It’s been an eye opener.
HTML remains mostly unchanged. Holding true to the KISS principle, the foundation of the web remains a simple mark-up language. What was a delight was seeing how Emmet (baked into VS Code) does most of the writing for you.
CSS was my main interest as most of my work is about visual styling and layouts. I became out of touch having handed much of this to Beaver Builder.
All I can say is WOW!. What has been added and is due to come very soon to help visual designers is amazing.
After less than a week learning CSS grid I started to strip out all CSS from Beaver Builder on my starter site and begin replacing it with a “mobile first” grid layout system.
My old brain still struggles after going from table based layouts to floats and to (almost understanding) flexbox, but clearly grid is the way to do layouts from here on and more.
Note: This is not a Beaver Builder thing it would have applied to any page builder. CSS grid also makes designer addons for Gutenberg redundant to me. These looked appealing because they allow CSS customization without going the WordPress developer route of CSS in JSON files, but for static sites this seems pointless. For dynamic sites they are working independently of Gutenberg anyway.
This is a somewhat nebulous term. I only looked into it because Matt Mullenweg called it a “regression” and he only seems to get controversial when his business is threatened.
This means I can go back to where I started making HTML sites, but with knowledge that I don’t require a monolithic system to add in functionality, I can also choose the CMS that suits the project and retain control.
I can not hope to explain my planned set up in this post, but until I follow up, here is what it will probably look like:
- Beaver Builder (with my CSS grid system) will act as a prototyping tool for the design instead of tools like Figma.
- Astro (a Static Site Generator) will be added to VS Code where my HTML and CSS files live. It will take care of any templated areas for the HTML and allow the adding of any dynamic content in the distant future.
- Astro will send the build to Github. Its version control replaces backups in WordPress terms, but also allows any future developers to come in and branch off a version to work on. A better developer experience for most than working within WordPress.
- Github then deploys this (probably) to Netlify to go live to a global CDN. Being serverless the hosting is expected to be mostly free.
Avoiding having all my eggs in one basket
The Jamstack is relatively new and my coding skills are limited. It seems to be growing 50% every year where, in spite of the growth for 3rd party builders, WordPress seems to have stalled.
Nevertheless, I heed the warning from Matt Mullenweg who sees the Jamstack akin to a house of cards.
I’ve no plans to entirely abandon WordPress. My immediate job is to get my WordPress starter site to the point where I can design with it and have the option to either go live as it is or take the design a Jamstack route.
This is something for later posts as there is much to consider and explore. For example, with my agile approach clients have less to need to change content themselves.
On the other hand, there’s good sense to getting a MVP fast and sometimes WordPress could be the best way to collaboratively work on progressing a live site.
The main takeaway for me has been to keep working on staying up to date with essential skills and watch out for shortcuts that could be a far greater time waste in the longer run.
The commercial code-free movement in WordPress was there long before Gutenberg and mainstream conversations have become more about products than skills.
Part of the appeal of the Jamstack movement is that those who are a part of it (all the front-end developers I follow) don’t really class themself as such. They are not affiliated to any particular brand or movement and their focus is more on web spec.
I presently can’t imagine myself using Gutenberg as I can’t set it apart from any other hyped product.
I understand why the block concept was a technical revolution in the printing press, but in WordPress I can’t seem to see the Emperor’s new clothes. I can’t see the science.
Instead, I’ve seen an almost religious zeal from a minority wanting me to convert. This has pushed me out of WordPress networks, but I have to thank them, because without them the personal revelations in the post would not have been possible.