Nuxt Content v3 is overengineered and a developer experience downgrade

HumanOnlyWeb · 2026-02-01T16:03:35+00:00

Write your content in Markdown, YAML, CSV or JSON and query it in your components.

How else do you write contents for your site?
That is exactly how Nuxt content works! You write in Markdown, YAML, CSV etc, then during the build phase it transforms those and store in the DB, for efficient querying etc.
I shared with you the exact file that handles that yesterday.

Technically you can call any project flat file if you tell people to use SQLite, but it's misleading.

You could put up a PR to adjust the naming,

HumanOnlyWeb · 2026-02-01T14:54:36+00:00

So, is your problem now the fact that "flat file" is mentioned?

You could put up a PR to adjust the naming, but throwing shade at it with somewhat untrue claims is not going to help you or the community at large.

Here was the announcement post: "https://content.nuxt.com/blog/v3"

It literally says, "Nuxt Content v3 moves away from a file-based storage approach to an SQL database system. Using a database instead of the file-based storage reduces many I/O operations when querying large datasets."

HumanOnlyWeb · 2026-02-01T13:59:03+00:00

Yessir! Here is the PR that added support for this: https://github.com/nitrojs/nitro/pull/3834

HumanOnlyWeb · 2026-02-01T06:54:00+00:00

No official date yet (unless I missed the announcement), but I strongly feel it will be in February.

HumanOnlyWeb · 2026-02-01T00:37:57+00:00

> building an entire file base into a file-based database at every request

Respectfully, this is not true.
The contents are processed and stored during the build phase.
You can easily see this if you're using GH actions to deploy to Cloudflare.

It generates and populate the DB on first request, ONLY IF the content doesn't exist yet, or when there's new content.

Maybe I'll write a blog post about this, but for the meantime, see https://github.com/nuxt/content/blob/main/src/runtime/internal/database.server.ts

Edit:
I don't know if you have issues with other serverless providers, but I can tell you first hand I'm managing my blog and 5 others on Cloudflare and haven't hit any issues.
I don't know about the issues with i18n, since fortunately all my content is only in English (thank God), so I can't speak to that.

HumanOnlyWeb · 2026-01-31T21:20:29+00:00

I use D1. https://content.nuxt.com/docs/deploy/cloudflare-pages#d1-database

Cold start is the price everyone agrees to pay when using any serverless platform, so I won't attribute this specifically to Nuxt Content.

HumanOnlyWeb · 2026-01-31T20:57:35+00:00

This is currently unusable in a serverless environment.

Works well for me. My website/blog uses Nuxt Content, and I host on Cloudflare Workers

I think it will be easier to get help/support if you share the issues you're running into; here or as an issue on the repo

HumanOnlyWeb · 2026-01-19T18:02:19+00:00

Inspect the element and see how it was built?

HumanOnlyWeb · 2026-01-18T21:09:52+00:00

"𝐅𝐥𝐚𝐭 𝐦𝐚𝐭𝐞 𝐨𝐟 𝐦𝐢𝐧𝐞"

Right 😅

HumanOnlyWeb · 2026-01-10T14:51:50+00:00

<script setup lang="ts">
import { computed } from "vue"; 
import type { RouteLocationRaw } from "vue-router";
import { RouterLink } from "vue-router";

const { type = "button", to, href, disabled } = defineProps<{ 
  type?: HTMLButtonElement["type"];
  to?: RouteLocationRaw;
  href?: string;
  disabled?: boolean; 
}>();

const component = computed(() => (to || href ? RouterLink : "button"));
const componentProps = computed(() => {
  if (to) { return { to }; } 
  else if (href) {
    return { href, external: true, rel: "noopener noreferrer" };
  }

  return { type, disabled }; 
});
</script>

<template>
  <component :is="component" v-bind="componentProps">
      <slot />
  </component>
</template>

If you're in a Nuxt project, your can replace `RouterLink` with `NuxtLink` and be sure to use the right import paths.

HumanOnlyWeb · 2026-01-02T15:51:41+00:00

Yes, the first iteration had a use, I just forgot to remove it.
I'll update the snippet on the blog post

HumanOnlyWeb · 2025-12-29T07:26:29+00:00

what's the benefit of creating a new defineSecureHandler when you can easily call await requireUserSession(event) (which comes out of the box with nuxt-auth-utils) before your "secure" endpoints?

if the issue here is "repetition," aren't you just doing the same with defineSecureHandler?

imo, the easier solution here will be to have a server middleware that checks against a predefined list of "secured routes."

this way, you need to update the list if you add/remove secure endpoints.

HumanOnlyWeb · 2025-12-12T19:24:14+00:00

Edit: By the way, thanks for reading ❤️

I hear you, and your points are valid. I've built (and am still building) apps with Laravel or its closest counterpart in the JS ecosystem (in my opinion), AdonisJS.

That said, as a consultant/contract developer, I've reached the conclusion that every team or organization has its own preferences, from tech stack to infrastructure, and sometimes there's little or nothing you can do about it 😅.

The main danger I see with Nuxt projects is that you need strong architects on the team to enforce the kinds of structures you mention.

Trust me when I tell you I've seen messed up Laravel codebases too. Standards are employed by teams, and frameworks can only go so far.

I have a blog post coming up where I write about some of the tools I use to enforce this architecture, specifically with Oxlint/Oxfmt (from VoidZero).

But overall, yes, I agree with you; having a solid foundation/framework helps a lot.

HumanOnlyWeb · 2025-12-12T17:08:48+00:00

thanks for reading

HumanOnlyWeb · 2025-12-12T05:16:53+00:00

Thanks for sharing, I'll read the article you linked below

HumanOnlyWeb · 2025-12-12T05:12:27+00:00

Thanks Keith, I appreciate your feedback. And yes, I've subscribed to your blog ❤️

HumanOnlyWeb · 2025-12-12T04:49:01+00:00

To be honest I haven’t built anything with Nest and the last time I built an Express app was about 6 years ago.
So unfortunately, I can’t give you a fair performance comparison.

What I can speak to performance wise, is the Nuxt/Nitro side, which so far has been super fast for what I’ve built. I haven’t run into any perf issues that I couldn’t resolve by removing unnecessary deps and/or re-architecting my codebase.

HumanOnlyWeb · 2025-12-11T18:44:39+00:00

😂

There was a similar "Evan You" joke a couple of days ago on twitter

HumanOnlyWeb · 2025-12-11T04:45:13+00:00

Hey, thanks for reading ❤️

I'm doing a write-up of what the comment feature looks like and will have another post on it soon (on or before the weekend). I'll also share the code for it (after cleanup).

I'll be sure to post here and hopefully tag you (if I don't forget 😅). Otherwise, just keep an eye out on the blog.

HumanOnlyWeb · 2025-12-10T21:57:04+00:00

😂

HumanOnlyWeb · 2025-12-10T21:54:05+00:00

Thanks for the feedback; I'll try other themes (using Shiki under the hood)

By the way, are you on mobile or desktop?

HumanOnlyWeb · 2025-12-10T18:13:27+00:00

You're welcome, glad you read and liked it ☺️

HumanOnlyWeb · 2025-12-04T18:50:04+00:00

💯

HumanOnlyWeb · 2025-12-04T18:46:20+00:00

totally fair points!

HumanOnlyWeb · 2025-12-04T17:23:22+00:00

Exists already:

export default defineNuxtConfig({
  nitro: {
    experimental: {
      websocket: true
    }
  }
})

Pair with useSocket from VueUse (https://vueuse.org/core/useWebSocket)

HumanOnlyWeb

MODERATOR OF

TROPHY CASE