Nuxt 4.5 launched last month and it's really neat. One of my most favorite features is the experimental SSR streaming. With one simple change in th...
For further actions, you may consider blocking this person and/or reporting abuse
Quick one on the part about the response being committed. If the slow boundary throws after the shell has been flushed, the browser already has a 200. Does Nuxt render the error into the stream somehow or does the user just get a page that stops halfway?
It should complete the web page. But what do you mean by error?
By error I mean an exception in the async part, like a useFetch or async setup that throws inside the Suspense boundary after the shell already went out, so the server can't send a 500 anymore. I checked the experimental features docs and found the answer and it looks like Nuxt sets payload.error, still emits the closing tags so the document is well formed and the client swaps in the error page during hydration. So the page does complete but the user lands on the error page with a 200 status which is worth knowing if a CDN is caching by status code.
the 16ms first byte number is the part that sells it. we did something similar with Next.js App Router and Suspense boundaries about a year ago, and the architecture decision that matters is where you draw the boundary, not whether streaming is on.
put it too high and you're streaming one big chunk, same as before. too granular and the hydration graph becomes a debugging exercise. the sweet spot for us was boundary per 'user facing section with its own data dependency', not per component.
have you tested the nested layout case where the parent has a slow data fetch? that was the hairiest edge in Next.js streaming.
I have not, but worth testing.
Just wondering - in which ways is this similar to (or different from) React Server Components (RSC's)? I have the impression that the concept and architecture behind RSC is so specific and unique (and complex), that competitors (like Vue/Nuxt, Solid, Svelte etc) are not copying it literally, but are looking at other ways to create similar benefits ...
This streams the SSR response in. With SSR/Universal mode it compiles the initial page on the server, then sends it over. Then hydrates the rest of the APP, so it turns into a SPA app. With RSCs, the server compiles just the RSC component, then the rest hydrates. Anytime you hit a route with an RSC it's always compiled on the server side. The client side components are sent over like SPA. In SSR, after the initial load, they are all just SPA routes, is my understanding.
What do you like about Nuxt?
I guess it confers the same benefits as Next.js but then for Vue?
Ha yes!
streaming does not shrink the 2.5s server work. it only changes what the browser can paint while that work still runs
Yes, that's a good point