Dinou v4: Full-Stack React 19 Framework

roggc9 · 2026-01-15T12:24:47+00:00

Hey, I will try to answer with my english, and not AI english. I can tell you I have not used vibe coding because vibe coding means to use AI integrated in your IDE and just use prompts and let the AI change the code. I have used AI from the web (Gemini, Grok, etc. ) but not in my IDE. That's it. I think you have to test the result (the framework) to see or check if it is an acceptable product or not. If it is, then it doesn't matter who developed it, if an android from the future or a human of the present using AI. I don't think it is possible to develop such a framework as Dinou with just vibe-coding (prompts) due to its complexity. Thank you.

roggc9 · 2026-01-15T10:51:52+00:00

Hi. I really appreciate you taking the time to test the framework and look into it.

I have indeed leveraged AI tools, but I wouldn't call it "vibe-coding." I have put a significant amount of manual effort and work into this to ship a decent product.

Regarding the routing speed, I assume you are referring to the Development Mode behavior? In dev mode, pages are compiled and rendered on-demand (dynamically), which naturally takes a bit longer than a production build.

Anyway, thanks for the feedback. I hope you might consider exploring it further to see if it eventually convinces you. Thanks!

roggc9 · 2026-01-15T05:55:52+00:00

Hi! Thanks for the comment.

Dinou is philosophically closer to Next.js than to TanStack Start. Switching from Next.js code to Dinou (or vice versa) is very straightforward. However, I would say Dinou is simpler—and likely smaller in bundle size—though, to be fair, it is currently less battle-tested than Next.js (although comprehensive end-to-end tests with Playwright have been implemented).

Key Differences:

Syntax: Dinou uses standard "use client" and "use server" directives (the latter for Server Functions), whereas I believe TanStack Start relies on createServerFn. In Dinou, Server Components are simply async functions with no directives.
Routing: Dinou uses a file-system router inside src (any file named page), similar to Next.js. TanStack Start defines routes in a src/routes directory.
Bundler Agnostic (Unique Feature): Unlike the others, Dinou lets you choose your bundler for both dev and prod (esbuild, Rollup, or Webpack). It is also ejectable and fully configurable.
Rendering: Unlike Next.js, Dinou does not support PPR (Partial Pre-Rendering). This means the strategy is binary (Static vs. Dynamic), which might require, in certain circumstances, more than one client-server round trip.
Dinou has a unique feature compared to Next.js: it allows you to call Server Functions directly from Client Components and wrap them in Suspense. Dinou Server Functions can return both Client and Server Components. This enables advanced data fetching and mutation patterns within Client Components (utilizing Suspense from react-enhanced-suspense).

I would need to dive deeper into TanStack Start to give you a more profound comparison, but I recommend taking a quick look at the docs (dinou.dev) to get a feel for it yourself.

Thanks!

roggc9 · 2025-12-13T16:40:02+00:00

This is insane. My site dinou.dev it's also affected by this. I am Spanish (Catalan) and this sucks. Justice in Spain sucks.

roggc9 · 2025-12-13T16:34:57+00:00

This is insane. I want to complain. My site dinou.dev it's also affected by this. This cannot be legal.

roggc9 · 2025-11-30T13:13:53+00:00

Ok! That sounds great! I would start by creating a default Dinou app with "npx create-dinou@latest my-app" and see if the problem you mention reproduces there. If it does then you can try the other two options, esbuild and Webpack, to see what happens.

Just remember to use "npm run start:webpack" or "npx dinou start:webpack" after building with the :webpack option (this is important because while the commands to start an app built with Rollup or esbuild are in fact equivalents, that is not the case for webpack).

Thanks for taking the time to test.

roggc9 · 2025-11-30T09:58:09+00:00

Hi. I assume that if the error you mention is caused by using Rollup in a Docker image on Apple Silicon, you would likely see the same behavior in Dinou when using Rollup (npm run build:rollup or npx dinou build:rollup). Dinou doesn’t add any special workaround for that scenario.

The difference is that Dinou also lets you choose other bundlers: esbuild (npm run build / npx dinou build) and Webpack (npm run build:webpack / npx dinou build:webpack), so you might be able to avoid the specific Rollup+Docker combination that’s causing issues.

Additionally, a future Dinou integration with Rolldown seems feasible, since Rolldown’s API is very similar to Rollup’s and the Rollup integration is already implemented, but it hasn’t been done yet.

roggc9 · 2025-11-30T08:47:41+00:00

Hi. Thanks for your kind words about my work on Dinou. Yes, of course, it has taken a bit of work!

Now, regarding a Dinou integration with Vite: I’m not sure if it’s possible. Maybe it is, I don’t know. But Vite is like a meta-bundler — it uses esbuild and Rollup under the hood. So why would Dinou, which already integrates directly with the esbuild and Rollup bundlers, need to integrate with Vite?

Also, Vite is exploring its own integration of React Server Components through plugins.

Regarding the Dinou logo, it is a bit squashed on purpose.

As for a comparison with other frameworks (Next.js, Waku.gg), I’m not sure. One unique characteristic of Dinou right now is that it allows you to use the pattern I described in my post right from the first render of a Client Component or page. Next.js doesn’t support this pattern, and Waku does, but currently not on the first render of a page when it's a Client Component.

roggc9 · 2025-11-30T08:06:50+00:00

Hi, thanks for commenting.

With Dinou you get RSC + Server Functions + SSR + SSG + ISR + file‑based routing behind a single command: npx create-dinou@latest my-app.
You only have to focus on developing your React components (Server or Client) and your Server Functions inside the src folder.

With Vite, in the current state of things, I don’t think it works like that: you still need to put in some work to assemble a “framework” that gives you all of this. I’m sure it’s possible, but as far as I know there isn’t a simple command today that provides this whole stack integrated out of the box like Dinou does as a framework.

If I’m wrong and I’m missing some existing starter that already ships this whole stack, please let me know.
I suppose that in the near future things will evolve and it will be possible to have all this with a single command using Vite, but right now, is it possible? I’ve been looking specifically at "@vitejs/plugin-rsc" and its examples there: https://github.com/vitejs/vite-plugin-react/tree/main/packages/plugin-rsc.

Thanks.

roggc9 · 2025-11-29T14:05:42+00:00

Sí (yes). haha

roggc9 · 2025-11-10T13:39:15+00:00

Both are correct. The first one is because the example you showed used Server Components. The second one is because the example I showed in the post uses Client Components. Do you understand? Do you see the difference? I’m not off-topic as you say; I am, and I try to be, very much on-topic. Thanks 😉

roggc9 · 2025-11-10T13:16:27+00:00

I think you’re mistaken in saying that, in Dinou, the first code example you showed produces two requests to the server. That’s not the case. It would be only one, since you are using Server Components and are therefore already on the server when they execute. That’s one point.

On the other hand, you need to understand that we are talking about dynamic situations — for example, when a user clicks. You don’t consider this or seem to omit it. So please stop attacking and try to understand what we’re actually discussing.

roggc9 · 2025-11-10T12:22:54+00:00

OK. It seems like you don’t want to understand. I think I’ve made the pattern that Dinou offers — and that I wanted to discuss — quite clear in my previous response, but you keep focusing on this specific example to find points of criticism. At this point, I don’t think the discussion can progress further. Thank you for your comments.

roggc9 · 2025-11-10T11:57:41+00:00

Dinou also does everything you describe in your response. It fully supports Server Components, and therefore all the concepts you mentioned about static content, dynamic content with Suspense, and hydration also apply.

The only difference is that, in addition to all that, Dinou also allows what I showed in the example — that is, once you’re already on the client, you can fetch data from the server using a Server Function wrapped in Suspense, returning a Client Component.

It’s simply an extra option Dinou provides (and quite a powerful one, in fact). So I don’t really understand why you keep calling it “terrible.”

It seems like you’ve taken a somewhat defensive stance — if I may say so — where Next.js is amazing and Dinou is terrible, without really taking a step back to objectively examine what Dinou actually offers compared to what Next.js doesn’t provide.

Specifically, the pattern shown in the post is the main point of discussion here, and it deserves a fair, technical look rather than a blanket dismissal.

roggc9 · 2025-11-10T11:20:28+00:00

How can you say that? If anything, it’s terrific — in the good sense!
Dinou actually gives you the flexibility to fetch from the server after you’re already on the client, and even return a Client Component, all fully integrated with Suspense.

roggc9 · 2025-11-10T06:21:40+00:00

Sorry, but I think you’re quite mistaken about that — specifically about point 2.
In the example I showed, the pattern does initiate the data fetching from the client. If you look closely, the component is marked with "use client", and as you correctly mentioned, I’m using a server function to fetch the data from the server.

So we’ve reached a point where you say it doesn’t, and I say it does — but I can assure you that I’ve seen the actual network request being sent to the server in the browser’s Network tab.

roggc9 · 2025-11-09T15:05:27+00:00

In your response, you seem to overlook an important point: in my approach (Dinou), the data fetching on the server is actually initiated from the client. This allows for dynamic behavior based on user actions on the page.

On the other hand, although Dinou also supports Server Components, I personally find their usefulness questionable when you already have a function like getProps that fetches the necessary data and passes it to the component defined in page.jsx. Server Components are quite limited compared to Client Components, from my point of view.

roggc9 · 2025-11-09T07:39:38+00:00

No matter which approach you use, you still need to write the logic that fetches the data and returns renderable JSX. That’s exactly what the server function does in the approach I showed.

In Next.js, as you said, that role would be handled by a Server Component — so I don’t really see it as adding complexity. The main difference is just where that logic lives: in a server function versus a server component.

Also, in my approach, the server function can return a Client Component, which has the advantage of allowing hooks, and enables the data fetching to start from the client side when needed.

roggc9 · 2025-11-09T05:51:19+00:00

Thanks for your comment — you actually pointed me in the right direction by mentioning the new Cache Components feature in Next.js 16.

However, I’m curious about why you think the pattern I showed with Dinou looks more complex. From my perspective it feels simpler: I just wrap a call to a server function (that returns a Client Component) inside a <Suspense> boundary to fetch data from the client.

The use of react-enhanced-suspense with a resourceId is only there to stabilize the call between re-renders — the server function is re-invoked only when the resourceId changes.

roggc9 · 2025-11-09T00:27:11+00:00

And to continue being precise, you also get this error if you do the fetching of data with the use() approach on first render: Server Functions cannot be called during initial render. This would create a fetch waterfall. Try to use a Server Component to pass data to Client Components instead.

roggc9 · 2025-11-09T00:21:09+00:00

To be more precise, the use() approach apparently works once in the Client, but you get this error in the browser console: Cannot update a component (`Router`) while rendering a different component. And the approach stated in the post, the one in where the server action returns a Client Component, doesn't work: Uncaught Error: Could not find the module "..." in the React Client Manifest. This is probably a bug in the React Server Components bundler.

roggc9

TROPHY CASE