Ask HN: Vite or NextJS?

I almost never used Next.js before because I had contributed to another project before that uses Next.js, but never really touched the parts that are Next.js-specific.

The main thing about Next.js (or I guess any modern React meta-framework in this day) that was a new concept to me would be React Server Components.

My experience with Vite consists of SvelteKit (which is built on Vite) and I would just say that the DX of Vite is a bit nicer than Next.js as Next.js tries to get in everything: it’s fairly opinionated on how to do things while Vite typically doesn’t get in your way.

Next.js builds on React, so if you're comfortable there, picking it up might take a few days to a week. The documentation is extensive, making the initial learning process quite manageable. I suggest starting with the official Next.js documentation (https://nextjs.org/docs) as it provides a comprehensive guide.

One thing to keep in mind is the concept of data fetching, which can be a bit tricky initially. The documentation provides useful patterns for data fetching (https://nextjs.org/docs/app/building-your-application/data-f...), helping you navigate this aspect of Next.js development.

Next.js is more opinionated than React, which can be an advantage for newcomers. However, coming from a React background, it might take some time to adjust to the project structure and conventions. Once you get accustomed, these opinions can actually make development more streamlined.

If you decide to go with Next.js and run into any challenges, feel free to reach out to me at sudheer@nextcrafter.com. I'd be happy to lend a hand or share insights from my experience.

Overall, my experience with Next.js was pleasant. In this age of AI assistants like Bard and ChatGPT, you're likely to find valuable support regardless of the technology you choose. Happy coding!

NextJS was (and maybe still is) a popular choice for server-side rendering. If you don't need that, not sure if its worthwhile.

If you're just looking to stand up a SPA frontend for your BE, I'd recommend going with Vite, or using NextJS but going full SPA-mode.

Doing things in a properly "NextJS"y way requires buy-in to the SSR/React Server Components paradigm, which takes some time to learn, if you're used to doing things in the SPA way. You have to architect differently -- specifically the way you handle data fetching/caching. I think it's worth digging into if you have the time, just depends on your goals.

Also worth mentioning, since NextJS is full-stack, deployment will be more involved. You might not notice any pains if you use Vercel, but definitely doesn't match the simplicity of sending along a single JS bundle with Vite.

Next.JS 14, which introduced server actions, is really worth it though.

But, IMHO, the main advantage of Next.JS is Vercel. You get a free platform to deploy your app just by "pointing it to your git repository". I've used it with Prisma and MongoDB (with a MongoDB Atlas free instance), so I have deployed my app completely, free of charge. Which for proof of concepts is a great thing.

NextJS always break for some weird reason and the upgrades are painful sort of

Earlier this year, I was helping someone create an MVC for a startup idea and I stumble upon NextJS (v13 at the time).

Within 2 or 3 weeks I was able get it up and running, hosted it in Vercel for demos and hand it to the team that was going to build it.

I found it very approachable and well documented. Everything I needed was on their website

TLDR: Vite is good for client-side only single-page apps. Next can do that too (with more complexity), but its real strength lies in being able to handle some of the stuff a more dedicated backend traditionally would, offloading some of the frontend rendering and fetching to the backend server (or serverless funcs).

Next also has the additional benefit (big, IMO) of being the most popular way to do React (and arguably web frontends in general)... it has a thriving ecosystem of third-party packages, examples, and users. IMO that is a bigger benefit than any strict feature parity comparison. I don't think it's an exaggeration to say that Next is now the "standard" way to do React -- and when React last overhauled their docs, Next replaced the default CRA for a while, until they added some other frameworks in a subsequent update. It makes a big difference in day to day work, especially with other teams/companies, when you can share the same framework and mental model.

Longer version:

CRA, Vite, and Next.js all do what's typically expected of a framework these days: improve on the barebones React DX. They all handle bundling (via webpack or esbuild or Rollup or similar), tests (usually jest), hot module refresh (live previews as you edit), built-in support for SASS and TypeScript, etc. And they also give you a single framework to upgrade together, integrated and tested by a company, instead of a dozen individual packages across the React ecosystem -- drastically reducing the chance of incompatibilities. Now, these are all nice for the developer, but they don't really help the end-user UX.

Next goes a step beyond those basics: If your data lives in a backend and visitors see a frontend, Next also takes up the space in between the two, in a place where reverse proxies, Varnish caches, and other optimizations of that sort used to live. It lets you optimize the heck out of your pages (and components now, with the App Router 13+) so the server can do a lot of the work and send the client pre-built HTML blobs, reducing the fetching and rendering done on the client.

In a traditional clientside SPA (like create-react-app or default Vite), the user's browser downloads a bunch of JS, runs it, fetches any data it needs, and then combines that data and your code into a bunch of HTML. That all happens in real-time on the client, and it can sometimes be a bottleneck for users with slower devices or networks.

The power of Next.js is in letting you, the developer, more carefully manage that lifecycle. The downside is that it often forces you to manage that lifecycle when you don't want to -- like in a traditional SPA.

For example, let's say you run a website with a blog and an ecommerce section.

The blog is the easier example: The content lives somewhere (doesn't really matter where, say a headless CMS or a bunch of Markdown files). Next can do a serverside fetch/readfile, combine the content with your React components, and then render HTML + hydratable JS all on the server, efficiently packing it down and code-splitting it for delivery via CDN. When a user sees that page, what they first download is the HTML, so the blog content is immediately readable. Half a second later the JS is downloaded in chunks and rehydrated in the background. When the user clicks the "Next post" link, Next fetches ONLY THE JSON CONTENT from its middleware -- as distinct from your original backend -- and uses that small blob (probably just a few kB) and uses that to re-render the next post's blog body, while keeping the rest of the page (headers, menus, scripts, etc.) unchanged. This makes inter-page navigation lightning fast, because it's not refetching/reloading EITHER all the JS or the HTML, just the JSON of the content that changed. And for clients without JS, or who didn't get to load it in time be...