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.
@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.
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.
@deadparrot@eaton@zachleat@dries Where it provided the features so a small company, or a single team didn't need to fire up an entire infra just to have a few pages, but that also wasn't page centric and had some flexibility to extend.
@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@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.
@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.
@tanepiper@zachleat@dries I totally forgot that MACH pushes GraphQL so hard everywhere. When you look at the members of the MACH alliance and see tons of GraphQL startups you realise why.
GraphQL is mostly a red flag for me. I haven't seen a single customer who didn't have problems either scaling that stuff or designing it. And FWIW I still think GraphQL Is a Conway symptom that Facebook just didn't want to solve differently.
@deadparrot@zachleat@dries My engineers semi-sold me on GraphQL - as we are reasoning over an actual graph, plus connecting with a CMS.
Yes, it's not great - but flattening a graph in a RESTful model isn't great either, and I really want to avoid HATEOAS because few developers really understand how to work with it.
@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.
@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.
Add comment