> It should load quicker compared to traditional React apps where the browser loads the HTML, then loads the JS bundle, and only then renders a loading skeleton while likely triggering more requests for data.

Then your JS bundle is broken.

Promises exist. Modules exist. HTTP/2+ exists. You can load data while you are loading a small amount of JS required to render that data while you are loading other parts of your JS.

If everything is sequential: load giant JS bundle -> fetch -> render, that's because someone architected it like that. Browsers give you all the tools you need to load in parallel, if you don't use them then it's not the browser's fault.

You do not need SSR or rehydration. That's just Vercel propaganda. They saw that people are doing a stupid thing and decided to push a complex solution to it. Why? It makes them money.

▲

user34283 4 days ago | parent [-]

You cannot load any data in a regular React application before you loaded both React and your React components that trigger the fetch.

If you use code splitting, your initial bundle size can be smaller, yes. That's about it.

I guess in theory you can hack together static loading skeletons that you then remove when React loaded your initial bundle, but that's certainly far from a common approach. By that standard, the vast majority of JS bundles would be "broken".

	▲	zarzavat 3 days ago \| parent [-]
		> You cannot load any data in a regular React application before you loaded both React and your React components that trigger the fetch. You totally can! Don't call fetch directly from a component - it's brittle. Write a hook to abstract that into one place. In your hook you can support prefetching by awaiting the promise you fired before you loaded your JS bundle (if you don't want to modify the server), or else take advantage of the browser cache. In this way your data and code can load in parallel. Is it common? Not really. But it's a technique that is in the toolbox of a conscientious webdev.