| I looked through it earlier but missed the "continue this thread" > SSR can be done correctly, even with React This stands out to me, and I agree completely. I dug around in devtools and found a few interesting things looking at the static-tweet.now.sh (Next w/ Incremental Static Regeneration). It seems like the performance is more or less on par with domvm as far as network usage EXCEPT for the initial bundle (which is mostly react & dependencies). For subsequent visits, this is cached and performance is great, but devtools tests with a clean cache so this is hidden. Admittedly, that's a huge qualifier. It doesn't seem like Next is doing anything wrong with SSR other than using a framework with a huge bundle. As a result, the huge bundle ends up getting sent even for a page (or entire site) with no interactivity. In theory, it might be possible to avoid sending the bundle for routes that don't need it, but this ends up being a fundamental limitation of react afaik. Vercel (the folks behind Next) put it really well > React at Facebook is…
> …unlike React at ${anywhereElse} The large initial bundle pays off for a site like facebook or a web app which really takes advantage of all React has to offer (wether that's performance, tooling, or dx), but definitely deserves more second guessing than it recieves. |
perhaps it's possible with Preact|Inferno + SSR, i dunno. but this [1] seems to use babel/webpack and a bunch of other stuff. it's not clear to me from that post how minimal the end result can actually be.
the thing is, React's ecosystem is also to blame, it is so full of ready-to-go-do-everything popular components with inefficient code that cannot be tree-shaken, that lack of care in bundle evaluation is absolutely rampant. every imaginable feature is just some burned-out dev's `npm i` away, node_modules be damned.
[1] https://www.digitalocean.com/community/tutorials/build-a-ssr...