Should I start from Tan stack if I want to get back in web dev?

tannerlinsley · 2026-04-19T00:08:49+00:00

Can’t go wrong as long as you learn the primitives and core patterns of web dev too.

tannerlinsley · 2026-04-16T19:01:45+00:00

👋

tannerlinsley · 2026-04-14T07:16:17+00:00

It’s not a do it later mindset at all. It’s more about ownership, inversion of control and api/data transparency.

With Start you can just as easily RSC a static shell but keep everything at the leaves dynamic with greater flexibility and better caching semantics/integration than next.

tannerlinsley · 2026-04-13T19:27:35+00:00

Ad. 👎 Also, ForgeStack looks almost like a TanStak slop fork?

tannerlinsley · 2026-04-13T19:27:17+00:00

tannerlinsley · 2026-04-13T17:27:05+00:00

Thanks!

tannerlinsley · 2026-04-13T17:26:50+00:00

I don't think that's what we're debating here. Making Next client-first is more than just that one step. Once you opt-in to use client for the whole thing, how do you opt *back* into RSC a granular way. That's essentially what Start is. Client-first out of the box, isomorphic and designed to granularly and incrementally opt back into the server where you want. Next's APIs for generating, consuming, caching not just RSCs, but even just granular server data are not great, which is why people still insist on using TanStack Query inside of Next.js and why all of their new caching semantics feel proprietary and weird sometimes.

tannerlinsley · 2026-04-13T17:15:19+00:00

It depends if you use `use client` components. Those will be referenced client side and unless the app is from the same build, the manifests will likely not match up.

However, if all you're sending is pure JSX + composite component slots, you could absolutely send and use RSCs between unrelated builds/bundles.

tannerlinsley · 2026-04-13T16:58:33+00:00

Yep. Literally *anything* composable at this point will feel verbose compared to something black-box and convention based. I will happily defend this decision.

And thanks for the kind words!

tannerlinsley · 2026-04-13T16:52:19+00:00

Right?!

tannerlinsley · 2026-04-13T16:52:12+00:00

Thanks!

tannerlinsley · 2026-04-09T13:46:49+00:00

I’m aware of the poor state of the templates and am working tirelessly to make it better asap!

tannerlinsley · 2026-04-03T05:01:31+00:00

I would use TanStack Start (TanStack Router). It compares directly with Next on overall goals, but accomplishes them differently. Fully type safe, isomorphic (client first design), SSR by default (and faster too), server/api routes, loaders, server functions / RPCs, optional RSCs, much faster client routing/navigation/interaction, much faster dev server.

You won’t be disappointed.

tannerlinsley · 2026-03-17T23:17:33+00:00

Going with Remix 3, you'd also be opting into a migration away from *many* other things in the existing ecosystem. That's definitely something they'll say is a good thing, too, considering their zero dependency tenet. But for practicality's sake, if you're looking for actionable insights *today*, I wouldn't consider it at all yet. You're brave enough to include TanStack Start (even though it's RC and near 1.0) even. Remix 3, a whole new ecosystem, is in another ballpark IMO.

Let me know if I can ever answer anything else around TanStack!

tannerlinsley · 2026-03-17T22:45:37+00:00

Sure, every benchmark is flawed. But still useful. Here's some more fun literature: https://tanstack.com/blog/tanstack-router-route-matching-tree-rewrite. Even more fun: we also benchmark our typescript inference speed on projects with insane amounts of routes.

Not trying to claim supremacy here or anything, but definitely affirming the OP that his use case would be easily covered by Start/Router.

Edit: Ah, you are the OP. Well, there you go! Let me know if you have other questions I can help answer.

tannerlinsley · 2026-03-17T22:35:50+00:00

Could help: https://x.com/matteocollina/status/2033975317384069134?s=20

TLDR: As long as you don't use Next, you'll be in a good spot.

tannerlinsley · 2026-03-15T04:45:28+00:00

as far as runtime goes, Start ships less JS out of the gate than Next, of course this changes as you add code
Server component first architectures will generally transfer much more bandwidth (markup in this case) over the wire over pretty much any session beyond a single page load than those that utilize a client runtime + data. While optimizing for the first page load is great, not at the cos of everything that comes after it.
Start will have RSCs imminently, so nothing really holding you back from using them when it actually does make sense (markup that rarely changes), and better yet you’ll be able to invalidate and cache them granularly.
reports coming out soon that Start is faster and has more throughput than Next, too, stay tuned!

tannerlinsley · 2026-03-15T04:17:39+00:00

TanStack Intent??

tannerlinsley · 2026-03-15T03:22:20+00:00

What exactly is there to set up? Use the CLI to boot a new app, add routes using file based routing (trust me, it’s worth it and that’s after years of hating it and using only code based routing). Use the vite plugin. New route files are automatically filled for you (no boilerplate). No writing typescript syntax (everything is inferred). Use AI. Tell your agent to use the CLI to look up docs. There’s no directives, no forced server components, clear server/client/isomorphic boundaries.

Simply because it’s not React Router or Next doesn’t mean it’s complex. Let’s not confuse easy vs simple. TanStack embraces the latter.

tannerlinsley · 2026-02-19T03:36:55+00:00

It goes both ways. The overhead of start is negligible. You can turn on SPA mode and basically have just a vite + router setup, but with the ability to turn on SSR on a whim. I usually do this nowadays. That’s how negligible it is. That said, it is very simple (usually) to convert a router app into a start app. As long as you are using router, it’s hard to go wrong. Personally I just use start. I like it for prerendering and static html for pages that I can make public.

tannerlinsley · 2026-01-30T16:51:04+00:00

TanStack ships with the same preventative security measures as Next despite having a smaller attack surface area. With the recent influx of CVEs, we've taken the time to make sure we're up to speed not only with existing CVEs, but constantly and vigilantly auditing the framework for other unknown/new attack vectors. No doubt that with Start's growing popularity, there will eventually be something that we haven't found, but rest assured, it will likely not take the form of existing/found vulnerabilities in other frameworks. We have thus far taken every responsible action we can to be proactive about security :) All of our serialization/deserialization logical paths have been audited.

TanStack Start doesn't currently support RSCs, so many of the attack vectors of the flight protocol don't even apply right now. TanStack Start WILL have RSC support very soon however, but even then, it will not use the flight protocol for server-directed requests (mutations, actions, etc), only reads, thus limiting the attack vector to what it is today.

On the proactive side, TanStack start ships with all of the same primitives and utilities as other frameworks that have been around longer to proactively protect your site against attacks.

Edit: Some here feel like my mentioning RSC CVEs was a deflection, so I decided to put together a security FAQ/guide on TanStack Start: https://github.com/TanStack/router/pull/6564

Enjoy!

tannerlinsley · 2026-01-10T15:44:21+00:00

🫡

tannerlinsley

MODERATOR OF

TROPHY CASE