Published
Thoughts on LAMP vs JAMstack content management systems
Chris Coyier recently published a CSS-Tricks post titled “WordPress and Jamstack”. It’s a great rundown of the pros and cons, and I’m in agreement on the whole.
The most important point for my own use cases is from the section titled “CMS and End User UX”.
Sometimes, we developers are building sites just for us (I do more than my fair share of that), but I’d say developers are mostly building sites for other people. So the most important question is: am I building something that is empowering for the people I’m building it for?
I really enjoy working on JAMstack (JavaScript, APIs, Markup) sites, the dev environment can be spectacular. It’s wonderful to not worry about deployment, HTTPS, caching. BUT. I haven’t yet found a JAMstack content management system (CMS) that I love, so it’s not something I feel super comfortable reaching for in the majority of my client work.
In my experience, the main reason a website eventually “dies” is because the person that has to work with it every day editing content has had enough. Sometimes it’s an external factor such as a personnel reshuffle or shifted priorities, but often it has something to do with the CMS being painful to use in one way or another. They put off editing content and interacting with their site, slowly falling out of love with this thing that they once excitedly commissioned. Eventually they just resent it and just want to start over again.
So part of my responsibility as a web developer is doing my best to make sure that doesn’t happen. I do that by being selective about the content management systems (CMSs) I work with, by configuring them logically, by carefully writing instructions, and by ensuring those instructions are exactly where they need to be, not siloed away in some separate document floating around in the cloud.
Eleven of the last fifteen websites I’ve built have required CMSs. Of the CMS-driven websites, five used Craft, five used Kirby, and one used WordPress. All of these are on the LAMP stack (Linux, Apache, MySQL, PHP), though Kirby doesn’t use MySQL. And they’re all very easily and extensively configurable IMO. WordPress a bit less so, but it was extremely appropriate for the job at hand, openschooleast.org. All of these CMSs have a strong, mobile-friendly UI that I feel comfortable handing over to a client. They all have strong developer communities (though I have *opinions* about which one is the most welcoming). And very importantly for my clients who are mostly working in the cultural sector, some relying on finite public funding: the total cost of the services involved both at the time of development and in the future is manageable and straightforward to project.
Important to note: I don’t usually create heavily JavaScript-driven or application-style sites (as in, most of what I develop is not underpinned by a framework like Vue, React, or Angular). If I did, it would make the dev experience with these LAMP stack CMSs clunky or potentially impossible, so my priorities would be very different!
Of course there are plenty of headless CMSs or CMS-like options that are appropriate for a serverless JAMstack site (see jamstack.org/headless-cms). I’ve dabbled with a few. Most have left me wanting in one of the above areas (configurability, UI, dev community, or pricing). But again, it is a dream to just forget about the server, so I’m still searching for the right fit. Here’s a few summaries of past JAMstack CMS experiences.
I used Netlify CMS for the Host of Leyton website back in late 2018 (more on this). We agreed on it for the project since the client had some experience with GitHub so could wrap their head around the stack, and it had an appealing cost (free!).
The experience was fine, but the UI was a bit meh (note that it has probably changed since then) and I definitely ran in to a few surprising bugs and snags. Ultimately, it felt like the CMS was a bit too early in its life for use on larger scale sites. There were too many instances where I had to over-explain to the client how the CMS should work as opposed to it just working. And media management is a concern. By default AFAIK, media uploads are added directly to the repository. That works for a bit, but eventually site updates will slow to a crawl as the Git repo gets bigger and bigger, causing deployments to be slower and slower. Uploadcare is an option (see docs), but I personally don’t feel that I can suggest it anymore since the new Uploadcare pricing puts it way out of reach for most of my clients.
This underlines one of my classic worries with newer CMSs and tech in general: the common pricing model is hook ‘em in on the free tier while it’s new, then bump up the cost down the line. I don’t think that this was at all nefarious on Uploadcare’s part, they probably just decided to target enterprise users such as Airtable and at any rate, a good service should always cost something! But it ends up pulling the rug out from under the littler guys using the service like my clients. These sorts of experiences make me sweat a bit when suggesting newer platforms.
I’ve also worked with the Airtable API here and there, using it + Vue to populate an old SB-PH portfolio microsite and helping Sam configure his bookshelf using Eleventy alongside our shared books database.
I actually love the dev experience of building an Airtable-driven website but again, I’m not sure I could suggest it for most client sites. I’d use it for a site that has a central archival component, particularly if it requires user submission. Their forms are pretty sweet. For example, we might use it for a future version of the Open-weather site, though those satellite images are enormous and would probably quickly surpass the 2GB free tier.
The one thing that would make me hesitate to reach for Airtable as a CMS again is their Attachment file management using Uploadcare (this is part of Airtable’s pricing, not an external cost). I’m not totally convinced by it, all of the media is siloed away and there’s no way to review all of it at once. If you reach your pricing tier limit, how do you go about batch deleting the images you’re no longer using? Or how can you resize them for use with srcset? Could combine it with an image CDN like Imgix, but then you’re layering on another cost and moving part.
If I use Airtable on a client site in the future, I’ll want to be sure that the client is pretty tech-savvy, comfortable with how it works and how it interacts with their site. I’d also probably need to write some extensive documentation that lives separate from the actual Airtable base (and hope that the client doesn’t forget about that documentation…). And finally, I’d want to be fairly sure that the client is either unlikely to surpass the free tier or is willing to take on the next pricing tier up if they eventually reach it since it’s a bit of a jump, not pay-as-you-go.
And then we have the big guns, the more fully-featured headless CMSs that can fully replace something like WordPress, Craft, ExpressionEngine, Drupal, etc. In my mind, there are currently three main players in the JAMstack CMS game: Sanity, Prismic, and Contentful.
Sanity is the only one that’s open source to my knowledge, which is one of a few factors that makes it more attractive than Prismic and Contentful for my purposes. I like being able to poke around, and I find that an open source product tends to have a more open and welcoming dev community.
Also, Sanity started its life as the CMS solution for the OMA site created by Bengler and NODE Berlin Oslo. That history alone makes it immediately relevant to my use cases since a good portion of my clients are creatives (architects, designers, artists, etc.) that need to share a structured data-driven portfolio in a curated, considered fashion.
I experimented with Sanity for a client’s portfolio site back in 2018 when it was still pre-release. It was exciting, but I ultimately had to move to Kirby for that site due to two blockers. At the time, there were no “singletons” which was essential for some of the global content, and it was non-trivial to delete a document if it was referred to elsewhere. More on this in an old GitHub issue, it was more of a misunderstanding on my part really and they quickly tweaked the docs for clarity. The other concern was the error messaging, it was a bit jargon-y which is understandable considering it was the early days of the product. That particular client isn’t the best with tech though—and she would be the first to admit it—so I was a bit worried about setting her up with something that might confuse her. Because of all this, I decided to set Sanity aside for the time being.
It’s absolutely time for me to revisit it. Even in the early days, Sanity’s dedication to their dev community was clear, welcoming and friendly. As for my main blocker, the lack of global/singleton content, Sanity introduced singleton-like capabilities back in late 2018, and I would suspect that their error messaging has become a little more friendly than it was when I last gave it a go. I’ve also seen it used on a lot of sites that I really like such as heresy.london developed by Rupert Dunk.
The only thing that I still have reservations with is the pricing. Most of my clients prefer to pay one-off for a license and renewals as opposed to subscribing long-term. Again, this relates to finite, sometimes project-specific budgets. There are many ways to argue for subscription pricing though, particularly since Sanity could either partly or fully replace a client’s traditional web hosting setup. And it is a huge plus that they have granular options if you happen to go over the free tier allowances, you don’t just have to jump from the free to the $199/mo tier. I wish all SaaS platforms were so reasonable. Looking at you, Adobe…
There are a ton of other headless CMSs I’d like to explore, on top of the other thousand+ things on my list.
The main driving factors in what I reach for next will always be what works best for my clients and collaborators, and what I believe is best for the web on the whole. That will never be any one tech stack, CMS, or framework, it will always mean comparing and contrasting, balancing the cool new options against the old stalwarts.
It can feel like a lot to keep on top of but honestly it’s way more fun, who wants to keep playing in the same sandbox every day anyways?
Edited on 26 and 27 Oct to fix typos, improve phrasing.