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.
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.
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.
(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, 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.
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.
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.
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.
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.
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.
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).
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
With a lot of SSGs, you can pre-generate all your "entry points" and then after the initial entry, it can be a SPA experience where a client-side router takes over navigation.
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.
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
Comments
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.
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.
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.
I also like how it adds a light API layer, you can proxy 3rd-party APIs to your front-end.
This is a huge advantage when you’re building client-side apps that need a light backend.
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
(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, 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.
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.
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.
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.
You'd think that, but I like JSX as a templating language.
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.
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.
SPAs can be indexed, so the entire premise of your post is invalid.
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).
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
Has it gotten easier to do deep links correctly with SPAs?
Back when I explored this it felt like working against the grain.
With a lot of SSGs, you can pre-generate all your "entry points" and then after the initial entry, it can be a SPA experience where a client-side router takes over navigation.
You can deeplink with SPAs just fine.
Not sure you understand what indexing is.
That’s literally what the article is explaining. Better routing system, and bundling, and a simpler optimized config for output.
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.
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
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.