[myth_drannon]

Can you elaborate? My understanding is that SSR and NextJS are good for SEO and low powered devices with a slow connection. You load the content before the interactive js ...etc. Why would enterprise apps care about SEO, slow connection speeds. If it's data heavy, it means you still need to fetch data from db before you return html, so SSR is pointless.

[SamBam]

> If it's data heavy, it means you still need to fetch data from db before you return html, so SSR is pointless.

I'm very confused by this statement. Maybe I'm just being slow. If you want to fetch data from the db before returning html, then SSR is exactly what you want.

[chatmasta]

He's not wrong in some cases. If bandwidth cost from Next->Client exceeds cost from DataSource->Client, then you want to opt out of SSR, to avoid DataSource->Next->Client in favor of direct DataSource->Client during CSR.

Example: Next deployed to AWS (metered bandwidth), with DataSource deployed to colocation (unmetered bandwidth). Page fetches 1GB CSV from DataSource in order to render an HTML Table. In this case, you likely prefer the client to fetch directly from DataSource and render the HTML table during CSR. An exception might be if you care about the table for SEO purposes (e.g. structured data) – but in that case, you should find a way to fetch the first 10 rows instead of 1GB.

It's a fairly niche use-case, though, and it's easy to opt out of SSR for specific code/requests (check if window is defined) or pages (use Next getServerProps vs. getStaticProps).

As an aside... this convoluted scenario highlights one criticism I have with Next.js: It is NOT a friendly mental model for junior engineers. You cannot write a robust Next app without a thorough understanding of the HTTP request lifecycle, network architectures, closures, database/HTTP pools, caching, cookies, etc. If you stay within the lines, you can avoid worrying about most of this stuff, but it's impossible to fully grok Next without a strong background in web fundamentals. If I were advising a beginner on the best stack for practicing React, I would suggest starting with create-react-app, even though I think Next is ultimately the best production framework.

[koonsolo]

When you do a proper REST call, your data is always going to be smaller than your html+data.

If you don't show it, you don't need to query it.

[azangru]

> low powered devices with a slow connection

Some would argue that React in general isn't a good fit for low-powered devices with a slow connection, because of its bundle size, long first input delay and a rather high cost of heavy javascript usage during re-rendering.

[brailsafe]

In many cases SSR is automatically better, including the ones you're talking about, because page rendering errors get thrown in an environment you have more control over, as well as faster devices rendering your already fast pages even faster. In my experience, enterprise work stations are clunky abominations, and if you can save someone some ram and battery why not? It also gives you a platform for building other kinds of non-gated apps that inherit the same benefits.

You might think you have control over the environment someone accesses the app in, but you don't, at least not entirely, and why not just make it as easy as possible to get their work done however they want?

Of course, this doesn't make your thing automatically better all around. That's a design and implementation problem. But you do potentially help everyone by starting at the bottom

[koonsolo]

Round trip to the server to compose your HTML feels less responsive. Else you could just do it in PHP anyway.

[brailsafe]

Surely you wouldn't just be server side rendering though. Nobody needs a page load for every route change necessarily. These are implementation details.

[azangru]

> you could just do it in PHP

That's two languages: javascript and php. Many frontend developers would prefer to just work with one — javascript.