Next.js vs TanStack

See this post for inspiration.

Over the past few months, I’ve moved as much code as possible away from Next.js. While I see why people are attracted to it and its growing ecosystem, I am no longer sipping the KoolAid. TanStack, while not perfect either, provides better abstractions that are more than adequate for the vast majority of projects.

In this post, I am going to share my personal opinions about the two projects as they relate to making web applications.

What is Next.js good at?

Before I discuss its shortcomings, I want to share where I think Next.js excels by sharing my recent experience with it.

At Particl, we took a bet on where the ecosystem was moving for our web properties. Vercel had hired up many of the React core team (around 25% of it), and was hiring open source maintainers aggressively. It looked like Next.js would see continuing support and would feature the most integrations with the latest packages.

For that reason, we chose Next.js to build our web app, as well as our website (when we moved off of Webflow).

Everything OOTB

Getting set up was not difficult, adding support for most package was a breeze, and there were integration guides for everything from MUI, to Markdoc, as well as more enterprise stuff like DataDog real-user monitoring.

The speed with which you can get setup out of the box is great, and other ancillary tools often just work™️ with it. If you want Jest, someone from the Next.js team has already merged a native plugin that gets things configured semi-magically.

The marketing lingo labels Next.js “The React Framework for the Web”, and it’s definitely one of the easiest ways to get a React app up and running out there.

High-scale optimization

Next.js is also great at the really high scale use cases, with the ability to surgically tweak the rendering pattern of individual pages across your app. You don’t have to inflate your build times to render millions of pages, you can render them on demand with server-side rendering (SSR). Authenticated routes can stay client-side (CSR) if you want.

You can shave off milliseconds with advanced APIs like partial pre-rendering (PPR), edge functions, and caching. Other packages like streaming and selective hydration can make your app feel snappier and precisely isolate performance bottlenecks. For an ecommerce site, every micro-optimization like this can sell more products.

There are Next.js specific APIs like incremental static regeneration (ISR) that make it easier to build high-traffic content that doesn’t need to be refreshed super frequently (and without extra builds).

Also included is nice out of the box behavior for things like code splitting, which does feel like it should be done for you.

The list of extra APIs is pretty long.

3 letter acronyms are overkill for most apps

The problem with the 3 letter acronyms and the extra APIs, is that most of them are optimizations I don’t really need?… In addition to feeling unnecessary for smaller scale, they are also financially hard to justify, and difficult to grasp.

Scale

For some use cases, I can see the justification for micro-performance improvements. For small to mid-sized startups I really don’t need much more than a server and a client. I’m okay with a couple hundred extra milliseconds while we find product-market fit.

But the users! How dare you!

Our customers buy our software because it solves their problem.

Our customers want their problem solved in seconds, instead of days or weeks. At our size, saving an extra 100ms is a premature optimization.

Financial incentives

Because incentives rule everything around me, I understand the marketing dollars get poured into selling cloud software. That leads to a lot of these things feeling like you need them, but are they really?

Each is almost inevitably tied to a service sold:

• Edge compute (middleware.ts)
• Image transformation (next/image)
• ISR reads/writes (export const revalidate = 60)
• Serverless function execution (app/api/route.ts)

Financially, Vercel feels incentivized to push their own services (of course), they are a business after all. However, by buying into the APIs, it becomes increasingly difficult to justify the cost of switching. Perhaps the build output API makes things easier to run across providers, though I haven’t ever been one to try it or self-hosting myself.

My financial incentives push me to spend as few dollars as possible on my code, which is why I consider this is my current optimal architecture for B2B SaaS: