| This sounds great for static websites but I'm not sure if it's a good idea for a dynamic web app where data needs to update on the screen in realtime. Some questions which come to mind: What if you had a 'chatbox' component which updated every time a user wrote a message; would Next.js have to resend the entire HTML for the 'chatbox' component (containing the full message log) every time a message is added to that chatbox? Am I right to assume that only the affected component will be rerendered? Or the entire page has to be re-rendered (and the entire HTML of the page resent over the wire) for every change in data? It sounds like a nightmare for caching: If data is updated dynamically and you constantly have to rerender components in realtime on the serverside; you can't really cache every permutation of every component's HTML for every data change and for every user... That's insane. Regarding CPU, it sounds like it's going to eat up server-side performance and increase hosting costs massively! What, like 10 times 100 times? Are there any benchmarks done on performance for a typical single page app built with Next.js? Then there is the latency issue... Finally; if we move back to full server rendering and get rid of the need for client-side code; why would we want to stick to JavaScript? I haven't used it yet so please correct me if I'm misunderstanding something. Next.js sounds great for building static websites... But so does PHP! |
The server only sends rendered components once, then the client handles the re-rendering afterwards.
It's still a javascript client-side SPA, except the initial rendering is done by the server. You don't see a loading screen, google can crawl your page, and users can see an initial page with JS turned off).
I hope that cleared things up a bit.