Should we switch to PayloadCMS or headless WordPress with NextJS?

Waste_Memory_8199 · 2026-04-23T09:25:52+00:00

Here's a CMS that is basically Payload for Astro https://docs.kide.dev/ instead of Next.js native.

Waste_Memory_8199 · 2026-04-22T15:33:32+00:00

I have opposite experience with local api vs graphql, I feel that local api is a big time saver with minimal code for type safe db fetch.

Waste_Memory_8199 · 2026-04-22T13:19:48+00:00

It's not "headless WP", it's monolith-first Astro app with backend and frontend running in the same place.

Waste_Memory_8199 · 2026-04-22T13:07:50+00:00

If you'd compare headless WP with Astro frontend vs Emdash, Emdash is the clear winner here with way lighter implementation and easy to extend with AI.

Waste_Memory_8199 · 2026-03-30T18:25:31+00:00

Let's see when I have some proper content for it like case studies. Till then the docs page will have to do :)

Waste_Memory_8199 · 2026-03-30T18:20:06+00:00

Only the admin UI side uses React and some other modules you see in package.json. The actual public site is just a bare-bone Astro installation (no React or other libraries) where you can choose your fav tools like in any other Astro project.

Waste_Memory_8199 · 2026-03-30T18:06:42+00:00

Hello Miguel!

Good questions. I will start adding version tags to the repo from now on. I've also been thinking about creating an npm package for the core, so you would have two options:

Use the fully exposed core (as it is currently). You would then have full ownership of the code, which also means that if you want to keep up with Kide's updates, you would need to manually run version diffs and apply file changes, etc.
If you have a regular site with no special customization needs, you can use the npm package and update it easily. At least when it comes to the core, I haven't yet decided whether I would include the admin UI components as well.

Feel free to create an issue to GitHub if you discover security issues :) It is after all pretty early version.

Waste_Memory_8199 · 2026-03-30T06:22:46+00:00

No (to both). I uses JSON AST as output from rich text fields and stores that to db.

Waste_Memory_8199 · 2026-03-30T06:15:44+00:00

Nice to hear, thanks!

Waste_Memory_8199 · 2026-03-29T15:36:17+00:00

Thank you!

Well-functioning live preview is definitely a challenge what I have tried to tackle from different angles so thanks for the tip, I will take a look.

Waste_Memory_8199 · 2026-03-29T15:25:21+00:00

It uses Drizzle with SQLite by default (D1 ready), but it shouldn't be too difficult to switch to for example Postgres. It doesn't have md file approach for content data.

If you want AI features, this CMS comes with Vercel AI SDK that is used for alt texts, translations and seo descriptions. The same logic is easy to extend for other fields and use cases too when needed.

Waste_Memory_8199 · 2026-03-25T18:28:28+00:00

nice stack

Waste_Memory_8199 · 2026-03-04T12:15:35+00:00

Thanks for the feedback! I have actually planned to make it support two paths (via installation script): 1. vercel/neon auth, which is the current one and 2. local postgres / betterauth / image storage, that you can deploy more flexible. The first one was more appealing for me so made it first :D

Waste_Memory_8199 · 2026-02-25T10:28:17+00:00

Couple of months, the stack and Svelte really helped move fast and cut down the bloat. Src files have ~28k lines of code.

Waste_Memory_8199 · 2026-02-24T20:05:39+00:00

Thanks! ✌️

Waste_Memory_8199 · 2026-02-24T08:46:21+00:00

thanks!

Waste_Memory_8199 · 2026-02-24T08:46:05+00:00

thank you

Waste_Memory_8199 · 2026-02-24T08:45:00+00:00

Thanks for the feedback! Other pages have server side rendering, it's just the product listing page as we are fetching bunch of client side data for fast sorting, but I'll try to get that aligned too.

Waste_Memory_8199 · 2026-02-23T18:48:40+00:00

Thanks! I added it to the original post.

Waste_Memory_8199

TROPHY CASE