5 ms·

What does next.js offer if server side rendering is of no relevance? It seems to me that ssr adds a lot of complexity and a great number of projects have no nee

What does next.js offer if server side rendering is of no relevance? It seems to me that ssr adds a lot of complexity and a great number of projects have no need for it at all.

manigandham 4y ago
That’s literally what the article is explaining. Better routing system, and bundling, and a simpler optimized config for output.
- throwaway4good 4y ago
  But that is a lot of complexity and dead functionality to drag into a project for just that? Surely next.js's router is not that different from React router.
  - adchurch 4y ago
    In our experience, using Next.js reduced our complexity, because it has out-of-the-box implementations (and simple configuration) for lots of stuff we had to manually hack around with CRA as our project grew
Scarbutt 4y ago
nextjs is crap but IMO doing react ssr on most requests with hydration is faster, more robust and less complex than going full csr/spa.
selfmodruntime 4y ago
Well true SSR allows you to send zero javascript to your client, so this is ultimately a net positive. My site is written entirely in React because I like working with it, but thanks to Next.js you as a client will never know the difference between that and me serving static HTML in the first place. All pages, subpages and blog posts ship in a relatively tiny 200KB bundle.
- sgdesign 4y ago
  Unless you’re talking about SSG and not SSR, I think one potential issue would be that React’s SSR process is pretty slow and costly, at least from what I understand. I have to confess I haven’t heard of a pure-SSR React app before, as you wouldn’t get many of React’s benefits if it’s just being used as a templating language.
  - selfmodruntime 4y ago
    > as you wouldn’t get many of React’s benefits if it’s just being used as a templating language You'd think that, but I like JSX as a templating language.
  - tomnipotent 4y ago
    It's really no more costly than Django/PHP/Ruby mustache-style template rendering. I consistently see 100-150ms last byte timings from a Next.js app I host on Vercel.
lewisl9029 4y ago
Curious to hear from people out there using Next.js, but without _any_ SSR, i.e. using the `next export` command mentioned in the article: https://nextjs.org/docs/advanced-features/static-html-export https://nextjs.org/docs/advanced-features/static-html-export (Seems like the folks in the article are beginning to use SSR, and have some great use cases with publicly available, SEO-friendly content, but a lot of apps don't, and can benefit from avoiding the operational complexity.) Create React App is a bit long in the tooth these days, so I can imagine `next export` being a lot nicer to work with in a whole bunch of ways, but the only advantage of `next export` I can think of over something more modern like Vite is file-system routing. For those using `next export` but have also evaluated Vite, is FS routing what made you choose `next export`? Or is it something else? Disclaimer: Asking with ulterior motives. I'm building https://reflame.app https://reflame.app, a Vercel competitor focused on client-rendered React apps, with millisecond deploy times to previews and production. We currently have decent compatibility with Vite and CRA, but considering if we should try to add support for apps using `next export` as well.
- hultner 4y ago
  I’ve used the next export based approach on quite a few projects and agree with previous commenters, next takes care of a lot of the boring stuff when setting up a new project and the routing feels refreshingly out of the way compared to many pre-next alternatives.
pen2l 4y ago
The obvious argument, tried and cliché as it may sound, would be that SPA are anti-web. A healthy web must be indexable and searchable. It almost seems like the rulebook now for some newcomers is to start out with SSR, make use of the auspices of the open web that allow for easy and organic discovery, - and after a significant marketshare has been captured, erecting all types of of lock-in walls, including turning SPA.
- endisneigh 4y ago
  SPAs can be indexed, so the entire premise of your post is invalid.
  - pen2l 4y ago
    Maybe Google can by traversing the virtual DOM and other trickery but it's not as simple for other small players. Moreover, in a healthy web I should be able to easily deeplink to something I'm thinking about without jumping through hoops. The SPA web is not as easily discoverable and connected as it is very much meant to be. I think there are valid arguments to be made for SPA, like that SPA need to SPA because they are not just a series of pages and documents but complex applications which need to be that way (though I would still tread with caution: I remember java applets and javascript bits doing complex things, submerged within pages, and that was all fine).
    - endisneigh 4y ago
      You are conflating things. With urls you can link fine, spa or not. It’s possible to design a single page server side rendered page without properly implemented links. The things you are describing are not attributable to spa inherently, just a poorly designed site
      - paulryanrogers 4y ago
        Has it gotten easier to do deep links correctly with SPAs? Back when I explored this it felt like working against the grain.
gherkinnn 4y ago
It takes care of all the boring stuff like reliable reloads, .env files, routing, config (without me writing any), bundling, etc. It leaves me the fuck alone. SSR doesn’t add too much complexity and at the very least is a reliable way to serve a server-rendered shell of the application so the content doesn’t fly about as it loads.
- jonny_eh 4y ago
  I also like how it adds a light API layer, you can proxy 3rd-party APIs to your front-end.
  - yunohn 4y ago
    This is a huge advantage when you’re building client-side apps that need a light backend.
- hklgny 4y ago
  100% this. Spinning up a new Next project "just works" for getting started, and makes me confident in a scaling path as times goes on. Adding things like lightweight API routes (weirdly useful in a ton of situations) or pulling in interactivity are trivial. I still write static HTML if I'm positive it'll be a forever fit - but anything client facing or with an ambiguous feature I reach for Next.

What does next.js offer if server side rendering is of no relevance? It seems to me that ssr adds a lot of complexity and a great number of projects have no need for it at all.

manigandham 4y ago

That’s literally what the article is explaining. Better routing system, and bundling, and a simpler optimized config for output.

throwaway4good 4y ago
But that is a lot of complexity and dead functionality to drag into a project for just that? Surely next.js's router is not that different from React router.
- adchurch 4y ago
  In our experience, using Next.js reduced our complexity, because it has out-of-the-box implementations (and simple configuration) for lots of stuff we had to manually hack around with CRA as our project grew

Scarbutt 4y ago

nextjs is crap but IMO doing react ssr on most requests with hydration is faster, more robust and less complex than going full csr/spa.

selfmodruntime 4y ago

Well true SSR allows you to send zero javascript to your client, so this is ultimately a net positive. My site is written entirely in React because I like working with it, but thanks to Next.js you as a client will never know the difference between that and me serving static HTML in the first place. All pages, subpages and blog posts ship in a relatively tiny 200KB bundle.

sgdesign 4y ago
Unless you’re talking about SSG and not SSR, I think one potential issue would be that React’s SSR process is pretty slow and costly, at least from what I understand. I have to confess I haven’t heard of a pure-SSR React app before, as you wouldn’t get many of React’s benefits if it’s just being used as a templating language.
- selfmodruntime 4y ago
  > as you wouldn’t get many of React’s benefits if it’s just being used as a templating language You'd think that, but I like JSX as a templating language.
- tomnipotent 4y ago
  It's really no more costly than Django/PHP/Ruby mustache-style template rendering. I consistently see 100-150ms last byte timings from a Next.js app I host on Vercel.

lewisl9029 4y ago

Curious to hear from people out there using Next.js, but without _any_ SSR, i.e. using the `next export` command mentioned in the article: https://nextjs.org/docs/advanced-features/static-html-export https://nextjs.org/docs/advanced-features/static-html-export (Seems like the folks in the article are beginning to use SSR, and have some great use cases with publicly available, SEO-friendly content, but a lot of apps don't, and can benefit from avoiding the operational complexity.) Create React App is a bit long in the tooth these days, so I can imagine `next export` being a lot nicer to work with in a whole bunch of ways, but the only advantage of `next export` I can think of over something more modern like Vite is file-system routing. For those using `next export` but have also evaluated Vite, is FS routing what made you choose `next export`? Or is it something else? Disclaimer: Asking with ulterior motives. I'm building https://reflame.app https://reflame.app, a Vercel competitor focused on client-rendered React apps, with millisecond deploy times to previews and production. We currently have decent compatibility with Vite and CRA, but considering if we should try to add support for apps using `next export` as well.

hultner 4y ago
I’ve used the next export based approach on quite a few projects and agree with previous commenters, next takes care of a lot of the boring stuff when setting up a new project and the routing feels refreshingly out of the way compared to many pre-next alternatives.

pen2l 4y ago

The obvious argument, tried and cliché as it may sound, would be that SPA are anti-web. A healthy web must be indexable and searchable. It almost seems like the rulebook now for some newcomers is to start out with SSR, make use of the auspices of the open web that allow for easy and organic discovery, - and after a significant marketshare has been captured, erecting all types of of lock-in walls, including turning SPA.

endisneigh 4y ago
SPAs can be indexed, so the entire premise of your post is invalid.
- pen2l 4y ago
  Maybe Google can by traversing the virtual DOM and other trickery but it's not as simple for other small players. Moreover, in a healthy web I should be able to easily deeplink to something I'm thinking about without jumping through hoops. The SPA web is not as easily discoverable and connected as it is very much meant to be. I think there are valid arguments to be made for SPA, like that SPA need to SPA because they are not just a series of pages and documents but complex applications which need to be that way (though I would still tread with caution: I remember java applets and javascript bits doing complex things, submerged within pages, and that was all fine).
  - endisneigh 4y ago
    You are conflating things. With urls you can link fine, spa or not. It’s possible to design a single page server side rendered page without properly implemented links. The things you are describing are not attributable to spa inherently, just a poorly designed site
    - paulryanrogers 4y ago
      Has it gotten easier to do deep links correctly with SPAs? Back when I explored this it felt like working against the grain.

gherkinnn 4y ago

It takes care of all the boring stuff like reliable reloads, .env files, routing, config (without me writing any), bundling, etc. It leaves me the fuck alone. SSR doesn’t add too much complexity and at the very least is a reliable way to serve a server-rendered shell of the application so the content doesn’t fly about as it loads.

jonny_eh 4y ago
I also like how it adds a light API layer, you can proxy 3rd-party APIs to your front-end.
- yunohn 4y ago
  This is a huge advantage when you’re building client-side apps that need a light backend.
hklgny 4y ago
100% this. Spinning up a new Next project "just works" for getting started, and makes me confident in a scaling path as times goes on. Adding things like lightweight API routes (weirdly useful in a ton of situations) or pulling in interactivity are trivial. I still write static HTML if I'm positive it'll be a forever fit - but anything client facing or with an ambiguous feature I reach for Next.