Introduction: The Headless CMS Lie
Not going to lie, I'm pretty pumped up to be here right now. Geo had a slide with the payload logo on it and that makes me feel very special. Um, but yeah, I'm James. I'm half designer, half developer and I've been building big digital products for I don't know, like 10 years. I'm getting old.
But today I'm going to talk about the big headless CMS lie. I am a headless CMS, that's what my company does. Um, but I've learned a lot over these past couple years since this idea came out and uh, I'm going to try to transition that lie into something actually what I think is my personal Utopia.
So fun fact, back in the day, I actually built my own server-side rendered React framework when Next.js was still on the Pages router, obviously, but it didn't even have Dynamic route slugs yet. I don't even know what the technical name is for that but it was in the early days. So I built my own and um, yeah, Next.js had a glow up and uh, they made mine look like a kid's toy. So good job Next, you win. You win that round.
The Classic Headless Pitch
Anyway so I've been pedalling headless websites for quite some time. When I say that I kind of feel like a drug dealer. You want to buy some websites? Like, it's a little strange, but um, I've been doing it for a long time. I've built like native apps and everything. This one was on my own SSR stack, we home-rolled it. It's still live. I'm still like pretty happy with how this one turned out. Um, but it was just headless WordPress at the time. And then we did Claro's corporate website. That one was on Next.js. So like it was getting easier. Building massive Enterprise websites was becoming um, maintainable and effective and efficient, but it was still powered by WordPress.
And then I started building like actual native apps and big projects. This was one that we built with payload actually, it's a native app, but payload handles all the auth and all the back end and the stripe and everything like that. That one was pretty fun. Things were getting a little better. Um, but every time I pitched this stuff to my clients at my agency, I would like, I would tell the biggest story. I'd be like, 'oh, you're going to love it, separation of concerns. The back end is separate from the front end. This is how it should be done.' And I just go to town just preaching to them.
Omni-channel content, you can use content across many different apps like a headless CMS, like it's all API based and the dream is like one central source of content, right? Um, migration is easier because if you want to change CMS's, you don't have to rebuild everything, you just rebuild the back end. Same thing with the front end. You go through a rebrand, you redesign the front end but you don't have to change your CMS. Those are all real quotes I actually said all that in my youth when I was, you know, trying to get clients and I will literally say anything to get money.
The Unspoken Pains of Headless
So, um, did anybody ever care about this stuff? Like my clients, did anyone, a single one of them ever care about any of this? No, they did not. At all, 0 percent.
Um, did separation of concerns ever really make my job easier as a developer? No.
How often did anyone actually use that single source of content across different projects? Literally never, not once.
Um, did they suffer with broken preview every single time? This is like, I don't know if anyone has wired up WordPress preview with a headless website, it is not fun, it is my tragedy. It's like just my downfall.
Um, and did they always hate the extra devops? Like deploy the CMS, deploy the front end, make sure that your future features are deployed in parallel, like there's a lot of heartache that goes into that and we always hated it.
Um, and did we ever get tired of wiring up the same thing over and over again? Especially in an agency setting. Every website needs redirects, every website needs metadata, every website needs forms, every website needs the same things over and over again and it got like monotonous to be frank.
The Real Reason: We Just Wanted to Use Next.js
I'm old, I'm tired of it. I want something better and it doesn't have to be this hard. As engineers I think we do this to ourselves a little bit. I mean, the end result always is a great website, that's because of Next.js and that's the reason why I was pitching so hard for so many years to go to headless because I wanted to just use Next.js.
So that's the big lie. Like I pitched this stuff for years and if I could have just told him, 'hey I just want to use Next.js in the front end', that's like the real reason there. Um, you know there's a time and place for all of those benefits and if you're Bloomberg, yeah you might want like a composable cloud and all this stuff, but like nine times out of 10 they didn't know what I was talking about, they didn't care. Um, yeah, and that's the lie.
So you know, there's a million headless CMS's out there. You pick your poison, a lot of them are pretty good. A lot of them are here today and I respect all of them. But I just want to build Next stuff.
My Personal Utopia: A New Vision
And I'm going to tell you a little bit about my personal dreams, my Utopia. This is something that I've thought of for years. Doesn't have anything to do with Windows. Nowadays I just use Windows for Counter Strike, but that's about it.
So number one, I need to get out of microservice hell. That's a real thing for me. Like I don't want to go sign up for a thousand different vendors just for a website. Like that feels strange to me. I'm kind of done with it.
Um, I want a combined CMS and a front end. I want to deploy everything with one server. This is like weird, like reminiscent of traditional CMSs. I don't know how many of you are familiar with like headless versus traditional, doesn't matter, but I want them combined again so that when I deploy a new feature, I don't have to sync changes from the CMS and the front end at the same time.
I want to deploy on Vercel. I just want to have it deploy when I push code, have it build fast, and have it get on the internet and then be able to roll back and all that stuff. And bonus points if I could get all the boring stuff out of the box for free so that I don't have to manually wire up metadata and redirects and rewrites and all this stuff. I mean, that's good that Next.js provides that, but it should be easier. It should be almost automated to be able to get all this stuff out of the box.
I just want simplicity, and Geo mentioned that this morning, and I think that's like critical, you know? Like when I first got bought into the Next.js ecosystem, it was because it just worked. You didn't have to learn a lot. You just jump in, you figure it out, you go to town, you do your thing, you get paid, you go home. And that's what I want.
Right now there's a lot of friction between CMS's and websites and it's kind of like navigating a maze of baloney. And I just want to restore a little bit of love back in the equation. Like if we connect these two things, are we still talking about headless? Is that word even relevant anymore? If you're building something that that doesn't have an API, like what year is it? What are you doing? Headless is implied at this point. There is not a big difference between headless CMS's and traditional CMS's. Even WordPress has a rest API and lots of GraphQL plugins and everything. I mean, Payload will always be API first, no matter what, but um, and it could work with any front end, but I just want to restore a little bit of that love there.
Introducing Payload CMS & Its Local API
So how do we get there? Um I run a headless CMS. I think about this every single day. Many of you are getting on the AI train and you know, I'm admittedly a little bit behind in that because I still write TypeScript like for my product. But um, yeah I uh, Payload is cool. Like I'm pretty proud of it. We're a little seed stage company and we uh, we've got some big clients. We're making magic and um, it's got a lot of nice stuff. Live preview, we're MIT, we're open source, we're not another SAS app that you have to sign up for, pay a subscription for. And you can extend the hell out of it. It's all completely composable and extendable.
But you still have to deploy two separate things. We're an Express server. So we have a vanilla React app, we have an Express server and you have to deploy those two things separately. And it's not, it's not like my Utopia yet.
Um, but Payload is very modular. And at the, like bare bones of it, we have a local API, which is what I call like the way to go directly to your database. There's no HTTP layer here. It's not a REST API, it's not GraphQL. You hit your database directly. It's almost like an ORM. And we actually exposed the ORM that we use to you. We just added Postgres support with Drizzle. Drizzle is fantastic by the way. I really really respect that team. They're doing God's work.
But this local API is portable and it can run anywhere. So what if we could ditch Express? What if we could leverage the app router, get rid of Express, open up all of our API endpoints as uh route handlers and just like write a small, thin abstraction over top of Next.js and build payload into Next.js? I think there's a lot of potential there and we could completely eliminate the need for deploying two separate services for a website. Like this is a website we're talking about. You can get more uh like extensible and more like separated if you want always. You can always do that, but we could ridiculously simplify, and that's my personal goal.
Just imagine it: one repo. You've got your your website, you've got your custom route handlers, and you've got all the payload stuff just sitting next to it in the same repo. You could share code, type safety from end to end.
Payload's Technical Pains & How Next.js Solves Them
But before I go any further, I just want to talk about like we have some gratitude to owe the Next.js team. They do a lot of hard stuff and I used to try to do this hard stuff with my homegrown like monstrosity, but, um, Webpack is hard, Turbopack 10 times harder I can only imagine. Server-side rendering, static rendering on an opt-in basis, um, redirects, rewrites, middleware, everything is out of the box. It's got all the bones that we need and they take care of it for us. And that's very complex if you ever think about all the Webpack magic that happens behind the scenes, like every one of your functions is being bundled separately for a separate serverless function, and that is very difficult. I'm just very grateful for all that work that they do.
And right now I'm going to air some of my dirty laundry on the technical side. Going to talk about some of the things that payload has to solve in the coming months. First up, this is like my personal least favorite thing with payload. The payload config is isomorphic, which means that it's used on the server and it's used in the browser. And you write server-side code in the payload config and you write custom React components for the admin panel, but it's the same file. And to get rid of the server-side code so that it doesn't blow up the webpack gods, we have to use webpack aliases. And that is basically like, 'hey if you see this import don't actually import that server code, import this mock file instead.' And this is a pain in my ass. It's not fun. All the plugins have to wire up their own aliases and bundling is very difficult. And if I had my way we would just completely remove this from being a necessity.
Oh wait a second, Next.js solved this with server components. Um, that's what they're for. At first glance you might think like, 'why are we trying to save a couple hundred kilobytes of JavaScript? Like that's not that big of a deal. I'm going to serve a 10 megabyte video to my user.' But that's not the point. The point is a clear separation of client and server and that's a hard thing to do. So we're going to try to solve this problem on our own, but Next.js already solved it with React and it's a perfect pattern.
Um, I personally am very, very tired of the bundler ecosystem. We just released 2.0. We added Vite support and Vite is impressive, but I don't think it's the end all be all. If you want to cry with your browser, look at your network panel when you load up a Vite app just watch the requests pour in. And in production it uses a different stack and now I got to manage Webpack and Vite and I'm just tired of it. I don't think we have like the end state in sight. Maybe we do with the nextjs compiler though because wait a second, I can just offload all of that to nextjs and then I could actually focus on my product which is a pretty wild thought to me.
Um last thing on like what we're trying to solve right now. We use Nodemon which is a relic from 2014, um, and uh, it restarts the server every time you make a change, right? But that's not server-side hot module reloading. That's like the full thing restarts and then it reinitializes, reconnects to the database. We want to solve that more gracefully. Could we do it? Yeah we could. We could monitor files for changes and then rebuild the models and do all the stuff. But wait a second, that was already solved by Next.js. We would get that for free out of the box.
The Vision: A Native CMS for Next.js
Um, honestly, I think that Payload is a perfect case study of like a real world example about why all of this stuff matters. And you know, you might not need all this complexity if you're just building a portfolio website, but I can tell you from deep pain that all of those things that we're trying to solve are very hard, but Next.js already did it.
And that's why, this is why, um, we are an isomorphic app. I'm tired of Webpack gymnastics. This is new, but it's sorely needed. If I ditched Express and I went to the app router, Payload would instantly get significantly better. We could make some magic happen. We could optimize the developer experience. I'm a huge proponent of simplicity. I want to get things done fast. I want to be proud of the code that I write. I want it to be clean. And this could optimize that. We could separate the server and the client. It would be a logical boundary that's well-defined and semantic. We could make devops easier. We could give a head back to the headless CMS optionally, you know, if you want to use Astro or if you want to use SvelteKit, you could still do that with Payload, but if we move to Next.js it would just be seamless. And you know what, a lot of my customers are building with Next.js anyways.
End-to-end type safety. Payload is TypeScript. We generate types for you, very strongly typed, everything. And you can reuse those types in your front end. So imagine for your React components, all of the props for the content models inside of the CMS, you don't have to write those types yourself. They're just given to you, and you could have end-to-end out of the box.
So what about other Frameworks? Like am I going too hard? I'm a headless CMS and I can't like you know people like headless, like I said, because you want to pick your front end of choice. But um, this would still be possible. We're always going to be API first. You could still deploy as an Express app if you wanted to, because the Next.js custom server completely supports that. We use that all the time with Payload because we are an Express app. So that's not going to change. And over time, we could add more connectivity like handling redirects and handling metadata and all that stuff for other frameworks out of the box. So I want to be clear. Like I don't think that if we move to Next.js, this would be a bad thing for other frameworks. I think everyone would unanimously benefit from this.
Um, the cool thing selfishly for me is that I would be able to concentrate on the things that make us great. And as Next.js, as they improve, we just get all that for free. And I don't have to do a damn thing. And that sounds really nice. I might be kind of lazy, I'm not sure.
Cool thing number two is that if you do use Next.js for your front end, your life is going to get way easier immediately. You can simplify, you can have like the most beautiful codebase imaginable and you don't have to go to a SAS vendor for another separate service. You just get it, it's free.
Drawbacks, The Big Question, and Call to Action
So what are the drawbacks? Like, I'm on this kick right now of like relational databases versus non-relational and I see benefits on both sides. And in tech, nothing is ever like a universally good idea or a good decision. You have to make decisions based on your problem. But I think the biggest one would be that we just released 2.0, so this would come with breaking changes. Um, and the express-style connect middleware would not be compatible because the app router has the browser... or the, I don't know what you would call it, the request-response that's like native and there's no Express magic there. And uh oh, ESM. I, depending on who you are, you might like this, but I think we should probably move to ESM if we do this and pull the bandaid off. And like, you know, I don't want to talk about that anymore.
So uh, Next needs a proper headless CMS. It needs a native Next CMS. And my question today is: should we be it? Um, should we make the jump and should we refactor and go hard on the app folder and uh embrace serverless components?
And um, I want to hear from you. I want to hear from our community. For those of you that are coming from our discord and everything watching this, um, I'd love to see if you can vote on this. We are open source. Community is everything to my entire company. It's crazy how helpful they all are. The PRs that we get blow my mind every single day. Someone will come in, build a massive feature and just hand it to us on a silver platter. And so I need buy-in on this one. I need people's opinions. I need some, I need to beat up this idea. We're not going to take it lightly, but I personally think it's only going to benefit everyone.
So if you can vote on this poll, that would be great. And um, I want your feedback in general. We are a new company. Um, I'm big on this ecosystem and uh, I don't get out there much with my opinions, but um, I want to hear from you and I would appreciate any thoughts you have. And I have two minutes left. Wow.
Thank you.
[Applause]
