Hacker News Reader

Comment by leerob | Hacker News Reader

(I'm on the Next.js team)

Something we haven't done a great job of, so far, is talking about how you can use Next.js for SPAs or client-only React sites. You can start with basic HTML/CSS/JS, deploy and host anywhere, and then optionally opt-into features that require using a server (and host somewhere like a Node.js server or through a Docker container). Next.js can generate an HTML file per route, rather than having one large SPA bundle.

There's been a lot of feedback around CRA no longer being recommended and folks looking for a replacement[1]—and uncertainty if Next.js is the correct solution. We've been working on some better docs[2] that help explain how to use Next.js without a server.

[1]: https://twitter.com/dan_abramov/status/1636886736784457734

[2]: https://beta.nextjs.org/docs/configuring/static-export

View on HN

Vercel just does not get it, it tries to sell SSR-first(and that's what Vercel cares commercially, understood that) to CSR-works-too every time it gets a chance. It's not about document at all, if anything the document should never fake SSR-first to something like: set this flag then you get a CSR too, it does not work that way.

It's about the burden of mixing SSR and CSR, Vercel's next.js and sveltekit are both SSR-first by design no matter how you sugarcoat it. I may use them when I need SSR one day, but please stop overselling it as CSR-ready.

Talking about documentation, please do not forget Vuejs, it has the best document all in one place in the JS ecosystem, by the way, it is a true CSR SPA and its SSR(nuxt) is truly an opt-in.

The core of Next.js is static/CSR. There's a one line configuration option to set your application in this mode—if you don't want to use the server, you don't have to.

The obvious question is: what's the advantage of using Next (over, say Vite) if you're not doing SSR?

If you ever wanted to migrate to SSR, the path is open with Next, unlike Vite (without a lot of extra configuration).

Clean architecture, common patterns, lots of docs, fast compilation, horizontal scalability (one bundle per page), etc.

You should really step up your elevator pitch. I'm not in the JavaScript ecosystem and after skimming your docs and searching on Google "what does next.js actually do" I'm still none the wiser. Seems to have something to do with what web developers call "routing" (which btw seems like a pompous way of describing how pages map to urls but I digress).

So one more time, explain like I'm five, what does next.js actually Do?

ELI5: Helps you make websites.

Next level (no pun intended): Makes working with React easy.

And another: Next.js provides tools for web developers (rendering UI components, fetching data from APIs, optimizing and displaying images and fonts, etc.) to create fast web sites/apps.

It's not obvious from that what the difference between React and Next.js is. React handles rendering UI components, you don't need either to fetch data from APIs, and displaying images and fonts is not something you need any JavaScript for, and srcset and media queries deal with optimizing, still no JavaScript required.

I'm not dismissing Next.js or you, I just feel like these aren't great points in a vacuum.

Next adds all the "missing pieces" that you would otherwise need to cobble together yourself when using just plain React to create a production-grade and ready web app.

Obviously these things can be done without using Next, React or even Javascript, like you say, but it all comes in a really well-integrated solution that mostly just works.

I could believe it, I just think it's hard to sell that to some people, as it's not very specific. The pitch just isn't that compelling, as things like "fast", "just works", etc. aren't very useful. I'm not against things like Next, and I do think they're useful, but this branch of discussion was about the pitch. The homepage lists "Client and Server Rendering", "Nested Layouts", "Data Fetching", "API Routes", "Middleware", and "CSS Support" (and a few others) in a list of features that "make the web. Faster." Other than middleware, I would sure hope all of those things would be supported by a web tool since they've all been features of web browsers and servers for decades.

The point is that it's not clear what exactly Next does, let alone why it does those things. In my mind, Next (and friends) just helps smooth the edges of all aspects of modern web development. That's just not a very specific statement. Also, a lot of those edges aren't so sharp for a lot of use cases since modern browsers and servers offer the same functionality. I still think Next and friends are useful because the edges may not be as sharp, but there are quite a lot of them.

It's not the same as traditional SPA, especially with that 1 file per route setting. This is SSG and does impact how and where it can be deployed.

E.g. a traditional SPA (client only) can handle dynamic routes without extra intervention of a higher level router.

Otherwise yes SSG can be useful :)

I think you bring up a great point! But while true, nothing really prevents one from adding their own router that handles for them that's decoupled from Next.JS and it would largely function as a traditional SPA (in that the export/'SSG' only builds one page, a la a true SPA).

And that IMO is kind of where the problem is - what level of abstraction should be added? Lots of beginners had problems because they were bombarded with the many confusing things to install to make something, and more often than not routing was one of them. It's just that Next.JS' is opinionated, but I'd argue so is everything else.

You can still do client-only routing (it was mentioned in the tweet linked above). It can be deployed anywhere that takes HTML/CSS/JS files.

Dan's gist clearly states you need to do rewrites yourself to make it work compared to traditional client side routed apps.

If you have rewrites it is not anywhere that purely takes HTML/CSS/JS.

Dans gist is referring to needing a routing layer to map something like `/blog/my-latest-article` to `/blog/[article].html`. This is the same of any non-React SPA.

If I have `pages/blog/index.tsx` in my NextJS app this will get output to `blog.html` and can be deployed like a static site without further top-level routing.

My original comment was specifically in reference to dynamic routes.

You're referring to static routes.

This is not the same as any non-React or non-Next SPA either way. A lot of them have SPA support i.e. route anything to index if there is no match. They may not have random rewrite support though.

Strong agree, lack of confirmation that this is a planned and intended usage of next is one of the reasons I've been hesitant to recommend it. All of our backends are java, and no one on my projects want to change that. We don't want to risk adopting a framework that will deprecate client side only usage.

Folks have been using Next.js this way for many years, and it has been documented, but not as clearly as we could have been. So the answer is, yes! There are no plans to ever deprecate client-side usage. We believe it's important to use the best parts of both the client and the server, not just one.

> We believe it's important to use the best parts of both the client and the server, not just one.

And many believe they do not need server-side JavaScript at all. We just need an SPA to speak to our API. We do not need "best of both worlds". Next is just more complexity over plain old client-side React. That's why some people including me are looking for alternatives to React recently. Next is not what we want or need.

Does this include the ability to embed a NextJS CRA as a component from within a traditional server-returns-html page? I'd love to see an example of that sometime, where I could update my template to paste in some code that pulls in a NextJS component in one area of the page.

Yeah, of course. It's a set of HTML/CSS/JS files, so you can do really anything with it!

I recall reading Next docs and stumbling across features that are Vercel-only (like something about responsive images IIRC). Vercel being apparently their commercial thing, it put me off.

Shouldn't be (I'm on the team). All Next.js features work out of the box when using `next start`, either when deployed self-hosted (like a Node.js server or a Dockerfile), or when deploying to a platform like Vercel. We have documentation and examples for both types. This includes the image component, which automatically optimizes images for you.

Happy to see Client side stuff come back into NextJS. We exist and have legit use cases :-)

Reply on news.ycombinator.com