The Big Headless CMS Lie (James Mikrut)

preview_player
Показать описание


The idea of the headless CMS got popular because of its decoupled architecture, separation of concerns, and ability to bring your own frontend. But is that really it? Let's be real. People just wanted to build Next.JS sites with a CMS. Payload is looking at moving from Express to Next's App Router, so we can once again give the "head" back to "headless CMS" without compromising on its API-first nature.
Рекомендации по теме
Комментарии
Автор

You can tell this bru has alot of experience. So many similar pain points.

djSeakDigital
Автор

Great presentation. I totally feel your pain points as I currently feel them too. Building websites driven by CMSs used to be fun, now with the headless approach, I feel way more stressed when it comes to deployments, I gotta spit types all over the place and can't easily share them, I have this ugly separation of concerns between the front and backends, which was meant to be a developer's dream, but instead that dream has become a nightmare, for content editors and marketing users too. Broken or sub-par previews and ultimately, going headless was pointless as no one else actually needs access to the content from outside of our website. Going all in on Nextjs makes perfect sense. As you say, you get everything in a single repo, shared types, local API which can be utilised with server actions etc. and with REST & GraphQL access to the data should anyone else need it, it sounds ideal to me.

bioburden
Автор

Oh yeah, James, if you bring Payload into Next.js natively, I will rewrite all my Remix and Astro applications back into Next.js 14 again.

buzzeins
Автор

About to recommend a headless solution to my company, payload is my top choice. Incredible work!

Dharsto
Автор

it sounds like a traditional CMS for next js folks

leonardshayo-uu
Автор

6:51 “if you don’t even build with an API” — exactly — What year is it? … Asking a hypothetical question on stage of a service paddling server-client rendering and coupling like its the 1990s PHP again.

dinoscheidt
Автор

I started to learn code 1 year ago. I’m stop trying to get past the cli errors. Maybe one day I’ll start to write code instead of being shunned by it.

AtomicPixels
Автор

It's decoupled for a reason. Not every web app has monolith and horizontal scaling needs.

adventurer
Автор

The real lie in CMS is that people still think a backend is a defendable requirement for hosting something where the content changes only a few times per day and the only dynamic functionality is a contact form.

NextJS and other things that for no reason valid reason at all require a backend is a perfect way to get Vercel customers to pay more for stuff they don't need, when most customers would do just fine with their whole site hosted without functions in a CDN and use Decap or something - without cloud - to get that much liked wysiwyg to edit json or md files on git.

skaramicke
Автор

We've been doing wp + next at a place where I work, and I can see these pain points, the majority of the problems we see are not in building the project, but rather from handling the decoupled setup that we created.

My current idea to try to combat this is to go back to just doing custom wp themes, but with twig, htmx and alpine, I get a decent SSR/CSR FE DX with a declarative syntax in a traditionally server first environment, I use twig for separating the components, handling their props and doing templating logic on the server side, on the client side I have alpine for any client side logic and htmx if I want to talk to the server without refreshing the page. Oh, and I just turn on a good caching plugin and I effectively have incremental static regeneration, static assets hosted on cdn with very little setup and maintenance.

lukasmolcic
Автор

Really like the thoughts being put into Payload!

ruchernchong
Автор

To put things in proper perspective, I'd say small-scale websites that don't require much user interaction are typically Monolithic in nature and can do very well without requiring its services to be decoupled. However, when you go enterprise and you're dealing with a front-end that communicates with several 3rd party services all at the same time with a high user interaction, you'd probably see that Headless is far much more important & crucial than what is presented here.

badassWP
Автор

a few hundreds Ks of JS is actually a big thing, most web pages don't serve a 10 MB video, the tech should scale from simple static content to complex UI or big content, a simple page should not load and parse big scripts if it's not necessary, it should be mostly static and use very few CPU resources.

raph
Автор

It’s hard to take someone seriously when he claims “I’ll say everything to get money”

avwie
Автор

I think the problem with selling headless is it's still too complicated and costly. Many of us can run wp cheaply without all the concerns of will this plugin work? Does memberships and woocommerse work? Added subscriptions etc. I am running a startup and just looks way too complicated. It would be great if we could get to a point where there is a clean and affordable solution, that has no compromises....

thebuildreview
Автор

People peddling headless cms tryna tell people the whole thing going to have to go through a build step to see your content updates 😂 and then the build fails 😂

cotyhamilton
Автор

Counterstrike actually works on Mac. I speak from experience.

hannesrossler
Автор

4.0 will probably be like what happened for tanstack, payload becoming a framework agnostic core

alvesvaren
Автор

What people need isn't "headless" but "serverless" CMS. If they actually wanted headless, no UI, they'd edit the source files for the content manually. But that's not what they want, they want the head. But stuff like this trick people into thinking they need a server, which they don't.

If they need a server, it's not for the CMS part of the website, it's for any dynamic interaction with users like shopping carts or what ever the website is about. The content is unchanging, non dynamic, statically generated at build time, so why would that require a server? Makes no sense. The CMS only needs to do work when an editor saves updated content, once per edit, not continually waiting to re-generate the content for each unique end user of the website like some stupid Wordpress blog or something.

The industry is moving in the wrong direction and it's frustrating to watch.

Please prove me wrong so I can stop being frustrated.

skaramicke
Автор

Thank you. I thought im only one who struggled with deploy

aleksandrkobelev