[bryik]

I don't think that's a fair characterization of the "Start a New React Project" page [0]. Next.js is the first option listed and is described as a way to "create React apps of any size—from a mostly static blog to a complex dynamic application."

This reads to me like "Next.js can do SPAs (like CRA) plus static sites and SSR". Next.js' site even says "The core of Next.js has been designed to enable starting as a static site (or Single-Page Application)" [1].

0 - https://react.dev/learn/start-a-new-react-project

1 - https://nextjs.org/docs/advanced-features/static-html-export

[synergy20]

Vercel's next.js and sveltekit are both SSR first because that's its business needs, which has nothing to do with mine(CSR only case), and Vercel is actively pushing the SSR-can-do-it-all in the open source space, I feel it is very much short-sighted.

Just use vuejs which is the only one truly never forces SSR on you if you do not want to have anything to do with it.

[chambers]

Speaking as an engineering manager, vercel’s approach seems to cater to the last market where overengineering and complexity were status symbols that middle management was happy to pay for. When the headcount was free, there weren’t many questions from upper management why basic UIs required so much heavy lifting by (overly) experienced engineers.

In the new market, there will be much more scrutiny on costs and the complexity that creates it. The prospect of hiring a “React Engineer” with 7+ years of experience to build a cookie cutter UI, will be just as questionable as forcing the front end and backend to use the same technology and framework governed by one single vendor.

I predict vercel will have a rough time.

[Rauchg]

Interestingly, I have the exact opposite bet: “SPAs were a zero interest rate phenomenon”. Putting the burden of compute on clients, and shipping slower apps for the sake of DX and convenience. Customer-first wins.

Looking forward to see how this plays out.

[zarzavat]

SPAs are faster than SSR because you can choose whether to incur network latency or not.

For example, let’s consider a site with two pages. In the SSR case, if I click the link to page 2, then I have to wait a whole network roundtrip for the page to appear.

In the SPA case you can decide when you want to load the content for page 2: with page 1 (if it’s a small amount of content), if the user scrolls to a certain point, … it’s completely up to you. You can cleverly hide the latency so that when the user does navigate to page 2, it’s instant.

[Jnr]

You can do what you described with Next.js and latest React easily. In addition, it will also help with SSR where it makes sense for speed and performance.

Building site with Next.js makes it simple to get a good perceived performance, the framework handles it out of the box.

[tqkxzugoaupvwqr]

MPAs can do the same trick. Use JavaScript to add a <link rel=prefetch> element to prefetch a URL. Or just serve your server-side rendered page with this element included to prefetch the next page. When the user navigates to the next page, it’s instantly shown.

https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes...

[pjmlp]

Nope, you do a bit of DHTML to update the only section that matters.

[zarzavat]

Isn’t DHTML just 00s speak for SPA? Not much difference between an accordion and react router, except the history API.

[myrryr]

Vercel is I think going to have a great time of it. Setting up code pipelines, and the devops time needed for it, compared to just having it deploy from github, and having sane logging?

Only people who haven't had to set all this up themselves think Vercel isn't amazing.

It is handling a LOT of devops heavy lifting for you.

[Rauchg]

I actually strongly advocate for: SSR and server is the absolute best default[1], and Next.js gives you tremendous flexibility on where to place your compute[2], including skipping SSR altogether[3], with the best-in-class static export that can actually at least put some content in your HTML instead of a blank page[4]

[1] https://rauchg.com/2014/7-principles-of-rich-web-application...

[2] https://twitter.com/rauchg/status/1637136013083684864

[3] https://twitter.com/timneutkens/status/1636693508223270912

[4] https://twitter.com/dan_abramov/status/1636827365677383700

[leerob]

Your understanding is correct – Next.js can do static sites, SPAs, SSR – all of them.

We (just today) updated the Next.js docs linked based on feedback around this to make it more clear. Hopefully this helps, let me know if you have other feedback.

[jameshart]

"The core of Next.js has been designed to enable starting as a static site" is a little contradicted by the fact static export is considered an 'advanced feature' though.

That said, I'm not sure why running `next export` is considered 'advanced'.

[leerob]

I'd say this is documentation organization "debt" – there's a bunch of "advanced" features that aren't that advanced. We're aware and fixing with the new docs -> https://beta.nextjs.org/

[klysm]

The part about this that bothers me is it not being documented well is in vercels financial interest

[freedomben]

This is what has made me hesitant to really invest deeply in Next.js. It's just too familiar where some open source project starts. Later it attempts to monetize. Some feature in open source makes it so new monetization thing (usually cloud functionality) isn't needed, so those feature(s) get downplayed, neglected, and eventually deprecated, often with self-fulfilled prophecy/declaration of "nobody is using those" (because they were engineered that way, but that inconvenient part is never mentioned and rarely acknowledged). It's one thing not to invest in unprofitable features (that's understandable for a for-profit company), but making them difficult or more obscure to use is often a part of this pattern.

I'm not saying Next.js is doing that with static export, but I'm not sure they aren't either. It fits the pattern too well. I'm still suspicious about how the Image implementation (which nearly every website needs) breaks `export` and the only solution is "roll your own image handler." I'm not sure if that fits into the understandable lack off investment or the intentional difficult/obscure.

[leerob]

We've made quite a few improvements to the static export with the new App Router, including support Server Components, Route Handlers, i18n routes, and more. Definitely still being invested in. My comment about documentation debt is that the entire information architecture of the Next.js docs needed some work. It's being fixed and will be stable soon.

You can read more about how to use Image Optimization with a static export in the new docs: https://beta.nextjs.org/docs/configuring/static-export. There's a full example there with Cloudinary, but you could use any service you want.

[freedomben]

Nice, thanks for the link. Those new docs do look great!

I wanted to note that I'm not asking you to build this, I'm more sharing my use-case in case it's helpful feedback.

What would really be amazing for me is a build-time image processing pipeline. Any images I use for the static site are already present in the repo (none are user-supplied or come from object storage, etc). Since all the image info is present at build/export time, it would be amazing if the image processing were done locally during the build and then the next/Image tags would instead of invoking server-side code, generate the static <img> code necessary to reference the different versions (such as srcset, sizes, etc)[1]. There is at least one open source project to do that, but at least when I last tried it, it was essentially dead on the vine. I searched around but couldn't find any solutions, which was pretty disappointing. I did end up shipping the app and just manually pipelined those images and hacked out the <img> tags instead of using the component, but if I had more than a handful in the site that wouldn't scale too well.

Anyway, thanks for what you've done with next.js! it's really an incredible project and you've been an important part of moving the web forward.

[1]: https://developer.mozilla.org/en-US/docs/Learn/HTML/Multimed...

[tmpz22]

And they've raised at least $313 MILLION! Where have we seen this story before?

[1]: https://www.crunchbase.com/organization/vercel

[darepublic]

I only use next.js in the static context.

[eric-burel]

next export, the feature that produces a "true" SPA out of a Next.js app, has been under-developed for along time. However the very newest developments in Next 13 seems to fix that, making Next.js truly versatile

[leerob]

New docs are a work-in-progress here: https://beta.nextjs.org/docs/configuring/static-export