Zach Leatherman :11ty:
Reading this blog post from @dries (creator of Drupal) about the post-pivot definition of Jamstack.
https://dri.es/the-new-old-jamstack-and-mach-journey-towards-traditional-cms-concepts
Dries rightly notes that Jamstack 2.0 shares *more* in common with monolithic/traditional stacks.
For me—I read this as a huge indictment of the broadened definition—it’s not a healthy evolution of the term if we must sacrifice technical clarity and simplicity to do so.
Eaton
@anniegreens @zachleat @dries Same. @karenmcgrane and I have been saying for years that the enthusiasm around Headless CMSs was shining light on some really great products *and* obscuring a ton of hard work orgs have to do to rebuild functionality they thought was table stakes.
Apple Annie :prami:
@zachleat @dries Quite a spate of 'CMS' opinions in the past week and they've been interesting to read. I wonder what prompted this, other than "one person wrote one, so others followed by writing their own."
I worked in Drupal for nearly 15 years so this is great to read Dries' take. Haven't read anything of his in a while. Thanks for sharing.
Chris Coleman
@zachleat @dries My work is building a medium-ish site using Next.js/Sanity with Algolia and Salesforce integrations to replace our 2007 vintage Coldfusion site.
We've had least four developers on it the entire time. I could have built 90% of this single-handedly with Drupal in about a year. We just spent a ton of effort basically recreating Drupal's Views.
The end result will be nice, but I can't wait for the retro where I get to mention I originally proposed using Drupal.
Eaton
@Chris @zachleat @dries It’s incredibly easy to underestimate the amount of time and energy that’s gone into the Views/FieldAPI/Entity system over the past *checks watch* NINETEEN YEARS. Starting fresh gives orgs that need a small subset of that a lot more agility from a code perspective, but it’s easy to compile a “critical feature list” that takes 2x as long to build and just as much to maintain…
Eaton
@tanepiper @zachleat @deadparrot @dries “Headless CMSs are spicy domain optimized databases, change my mind” was one of my favorite LI shitposts
Tane Piper ⁂
@zachleat @deadparrot @dries Over on LinkedIn...
By what they (the MACH Alliance) term it I guess it's all the right letters and they are in some order, but really it's a database with a GraphQL API, an integration layer, some orchestration and another GraphQL layer. But the big thing is it's domain specific and in the end most MACH are just distributed monoliths.
There's no magic frontend either.
Stefan Baumgartner
@zachleat @dries My problem with both the terms MACH and Jamstack is that they don't describe architectures but marketing vehicles for early/mid-stage startups. Especially MACH can be very adamant about this: Don't run your own service but pour money into SaaS subscriptions.
Zach Leatherman :11ty:
@deadparrot @dries have to agree with you there
Stefan Baumgartner
@eaton @tanepiper @zachleat @dries 😂
But then again, what isn't?
What would make a CMS "complete" in your opinion?
Eaton
@deadparrot @tanepiper @zachleat @dries “tags” and “the ability to put content in a hierarchy” are some examples. The issue isn’t that they are impossible with most headless systems, but that teams are left recreating CMS features from first principles with data primitives — along with the editorial interfaces to manage them.
Sometimes that’s what a team *wants*, but often it’s an unexpected shock.
Eaton
@tanepiper @deadparrot @zachleat @dries YYYYYYUP. For dedicated teams/orgs with engineering resources, I think those decisions have clearer tradeoffs — go headless to get a cleaner foundation, then invest your time building more of the flow/experience on top of it.
It's smaller organizations, or ones that work with agencies that are only there for the design/build/launch phase, that can be really screwed by the gaps if they buy into a simple “Headless === Faster/Better”
Tane Piper ⁂
@eaton @deadparrot @zachleat @dries hah bingo - the first features we built in the CMS we have are:
* Knowledge Graph taxonomy selector
* AutoID components for providing a hierarchical identifier (e.g tag/type/slug)
* Rewrote their asset selector for fields to inline the asset editor instead of have it be another popout or page
I expect it'll be more like this, fixing the missing things we need
Eaton
@tanepiper @deadparrot @zachleat @dries about a decade ago I gave a talk at a conference @deane was organizing — “The Page Is Dead.” I’m pretty sure that was overstating the case a bit, and Deane has rightly argued that page-ness matters in a world where the web is a primary point of discovery, but I think the idea of “assembly” is a critical one to provide useful tools and models for, both at the abstract level and the concrete artifact level. Otherwise, people have to hack it together…
Tane Piper ⁂
@deadparrot @eaton @zachleat @dries This is exactly how it should be done - omnichannel demands it - the same content can be structured for web, mobile, GenAI, or printed to a PDF.
This is the current mindset shift - getting people away from page level thinking an towards modular content as a unified content strategy.
Stefan Baumgartner
@eaton @tanepiper @zachleat @dries Agree! I have seen situations where the content team used a CMS to structure/organize their content independently of what design or development wanted to create in the end. Often even months in advance. The CMS was strong enough to put everything into hierarchy, and flexible enough for all outputs.
GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.
All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.