SPA to SSR and Everything in Between

I'm sorry, I don't have any t-shirts this time, so I brought something much better with me to Amsterdam this year. My wife and three children are on the front row right here. So the more fun we have, the more fun they're gonna have. So let's keep it fun.

All right. It is no secret React is on fire. And is React on fire? When I started using React in 2014, I did not know that this is what it was gonna look like. And I thought for sure after a decade we'd start to see some changes in this line. But it is just going up. It is crazy. It's definitely transformative. It's transformed our industry and it's transformed other industries too, believe it or not.

But something I think is really important is that I don't think it would be anywhere where it is today without this community and this ecosystem that has rallied around it. I want to say that we're here because we choose React as our framework every day. I think we need to celebrate that. So React is great. So ten years ago I started using it. And ever since I started using it, it's been moving to the server ever since.

I've been building websites for over 15 years. Not always with React. So when I started learning React and saw that I could start using server capabilities, I was really excited about that because it really brings some good benefits to the table, especially SEO. I spent 10 years in the SEO industry this last decade and so I really appreciate that. We get performance. We get a ton of code reuse, a unified stack. And today it's pretty easy to use React on the server. But that was not always the case.

Back in 2013, we didn't even have server APIs. It was a brief honeymoon of about three months after they released it, we got the very first API for the server, render to string. And compared to other existing frameworks at the time, believe it or not, render to string was revolutionary. I don't know if anybody tried to do SSR and Angular 1x, but wow.

It was crazy. So the idea that you can take your app and just turn it into HTML is really amazing. And that opened up this exciting path for the next 10 years. From 2016-17, we saw some really big growth. We got Next.js and Gatsby. But we didn't get the Next.js that you're thinking of today. These were static site generator frameworks, because we hadn't even quite made it to the server yet, at least not all of us.

We also got improvements like React Fiber, core upgrades that started to pave the way for a push to the server even harder. In 2018 and 2019, we got Hooks and Suspense. These massively upgraded all of our ergonomics, and they paved the way for things like streaming and progressive hydration. And then finally, we started to get server rendered Next.js, which was amazing. This was the beginning of the commoditization of server-side rendering for React developers. It was a massive win.

In 2020, we got COVID. No, I'm just joking. We got Remix. We got another key framework in making SSR more accessible to more React developers. And we all know that 2020, we suppressed a lot of 2020, let's admit. But I do remember it as being one of the most exciting times to be a React developer, because it seemed like things were just getting so easy to take part in. Whatever you wanted to build with React, you could do it, and the server was definitely a part of that. It was awesome.

But everybody was on the internet in 2020, a lot of people. And that put a lot of pressure on the server, the server-side aspect of everything that we did, including React. In December 2020, something even bigger and more exciting happened - server components were announced. This new, powerful idea generated a lot of excitement for what they could unlock, although their workings were still a mystery to many. Server components were perceived as groundbreaking but challenging to comprehend, leaving many perplexed.

Next.js extended its support to include React server components, marking a significant development. However, the implementation of React server components within Next.js unveiled unexpected changes. The shift to a React server component-first approach introduced an entirely new router and framework, fundamentally altering the development landscape. The introduction of this innovative concept raised numerous inquiries and uncertainties among developers, questioning its categorization as a mere tool, a bundler feature, or an entirely new framework.

After five years, the realization dawned that React server components encompassed multiple facets, blurring the lines between being solely a new tool, a bundler feature, or an entirely new architecture. The complexity and transformative potential of React server components prompted further exploration to unravel their true essence. Despite the varying interpretations and speculations surrounding React server components, their adoption remained limited, predominantly within the realm of Next.js app router users.

Next.js added support for React server components, and I thought, great. Next.js added them. The future is here. Now they're gonna get added everywhere I can start using them. That future was not what I expected, because it was an entirely new router. It was an entirely new framework. And it was rewritten to be React server component first. And while extremely cool, it felt very different from anything else that I had ever used. And honestly, it raised a lot of questions for me, and I think it did for a lot of other people.

Questions like, is this just a new tool? Or is this a bundler feature? I'm being told that it's a bundler feature. Does it have to be a new framework? I'm also being told by really smart people that this is an entirely new architecture that is going to change everything. And I think after five years, I've realized that it is all of these things. And that doesn't necessarily make it better. But we should explore all these things. And that's what I want to do for a moment.

So it could be all of these things, or it could be some of them. Or it could be none of them. Because the reality for a lot of us today is that we're probably not using them unless you're using Next.js app router. But they're very widely applicable. They can be used in tons of different ways. They solve very real challenges. They solve challenges like pre-compiling JSX on the server. They can make our client bundle smaller. And if used to a certain degree, they can eliminate waterfall issues with component fetching, which we've been looking... I mean, even I've been looking to do that with React query for the last five years. All this sounds really great. And honestly, I've got use cases right now on tansoc.com that I would love to use React server components for. I still have to ship a markdown parser to the client to hydrate our documentation. It should just be static HTML. And it's the most ridiculous thing ever.

I can't wait to use them just for that use case. And so I'm thinking, what's not to love, right? But with every technology, with every feature that we build, everything that we add, there's always trade-offs. And I've been trying to explore these trade-offs for the last five years. And you know what? Even before server components came to be, the server was complex. We were already dealing with a lot of difficult challenges and problems with the server. You know, these are nothing new. This isn't just even five years ago. We've been dealing with these things for a long time.

But even in React, I don't know, we have some frameworks that have made it really easy on us. They have managed to take these challenges and contain the blast radius to places that make us productive. So what does that have to do with React server components? I believe that one of the very first trade-offs that we're making with server components is multiplicity. We're taking those challenges that we have learned to deal with for many years, and we're multiplying them all over our application, potentially anywhere we want to put them. We need to be able to weave in and out of the server. It's really multiplying these problems everywhere that we use it.

I think when people say that it just increases complexity, this is a little bit of what they're talking about. It definitely doesn't help my brain. I've used server components in Next.js, and it takes a lot of getting used to. You have to be constantly vigilant about where you're weaving in and out of the server. And if it's difficult for humans, it's difficult for people to do, I can't imagine it's difficult for AI to do either. Trade-off number two that I realized is that RSCs demand micro and macro changes to our code. I think there's obvious ones like putting used client, used server in a ton of places. There's lots of new rules about what you can use and what you can't. And we also have to make sure that a lot of the tools that we use are compliant.

There's also new concepts like weaving together the server and client. How do we do that properly? How do we pass down promises? What happens when you pass props and callbacks to the client? How does that serialization layer work? There's a lot of new things to learn, a lot of new ground to cover. And it even goes as macro as file organization. Splitting our files up into server and client versions. These changes were intense, but if we made it through React hooks, I think that we could make it through this.

This is a little shout out to my last talk that I gave in Amsterdam. I wish I could have had more Jurassic Park gifts, but they didn't make the cut. So if we can do, if we can manage a transition through hooks, which was pretty big, we should be able to manage something like this. But that brings me to the next interesting question I've had about RSCs, is there's this concept that I'm calling canonical React server components. It's kind of like the vision, the holy grail of what's the best way that we could possibly use React server components to get the most out of it. And that's what a lot of really smart people and what a lot of frameworks and a lot of tools are aiming for today.

They're aiming to get rid of component data fetching waterfalls, right? It's kind of the holy grail. You want to be able to co-locate your data with your components and just move on. And server components can do this. And it's actually really impressive how they do it. But the goal is to use to do it only with React. Sort of. Because without a server-first router or metaframework, you can only go so deep with server components. You cannot get to this next level canonical usage of being able to use them to their fullest ability. And I'm not saying that we need to get there even, or that you need to get there. But things like needing to fetch new data requires going to the server again. You have to go back to the server every time that you need to to invalidate your server data. Server-first. Yes, it gives you this amazing component fetching, you know, pattern where you can weave in and out and just kind of fetch the data you need. And it all happens on the server. And it's really beautiful and pure. But you also give up some things, and things get a little harder that you may not have expected. There's trade-offs everywhere. And one of the last trade-offs, which I hope is temporary, is the bundler support. The state of bundler support for server components has been on my mind a lot.

Vite is a key part of the React ecosystem, and it does not have support yet. Progress is being made, but it's just not ready. And I hope this gets fixed soon. I am very hopeful that it will.

Which leads me to the final question. Are they worth it? I get asked this question all the time, every day, everywhere I go. Are React server components worth it? And I would say that if you need server-side rendering, and you're really suffering from server waterfall issues, or some really big client bundle blow, server components are for you. Now, I think it's obvious that I'm not here to sell you on server components. And if I did, I love that for you. Okay?

The truth is, that from where I'm standing, from my reality, I'm doing just fine. Reality for me is different. And everything that I see on social media, I always tell my wife, don't believe what you see on social media. That's not reality. The reality that I see is very different, even though that's all we seem to be talking about. AI and server components. And that's not what I feel. The reality is that you're probably fine too. Because even though for the last 10 years or more, we have had many advancements for server-side infra, full stack frameworks, we've had great APIs even before React server components.

But even with all of that, 85% of us still work on client-side only React applications. And that's from the latest state of React survey. And that means that four out of five of us are working on applications that don't even use the server, unless it's like a fetch call to an API or something. And that's crazy to me. And that does not mean that SSR is bad. And it also means that you could be working on both kinds of apps. A client-side app and an SSR app. I am. I've got TanStack.com and I've got all my apps. Right?

But the thing is, these apps are everywhere. They are internal tools and B2B products. They're in games, SaaS apps. They're everywhere. And many of us work on these projects every day. But we just don't talk about it very much. Because what's cool and hip to talk about, it's a client-side React app. I think they're cool. And I want to talk about them. SPAs are critical. And they're here to stay. I don't think they're going anywhere. If you agree with that, I want to hear a shout.

So why am I saying all this? Well, for one, I love SPAs. I always have. I always will. Also, I've built some very intense SPAs. Very intense SPAs over the last 10 years that have consumed so much of my time and energy in trying to make that experience amazing. Which is why I built a lot of these tools, or helped build some of these newer tools, to make that process easier. And all those tools are what eventually turned into TanStack. And at TanStack, you ask anybody on the core maintainer team, we love the client and the server.

We don't discriminate. We love them both. And we really want to build tools that are going to meet developers where they stand today. At the very least. And look forward to the future. Which is also important.

And I believe that we're building tools today, especially two tools that I want to talk about, that are meeting developers where they stand, where maybe they're not being met by other tools. That first one is TanStack Router. Routing is the heart of any application. And whether it's client or server first, the bulk of URL state management should happen in a router.

And I believe that TanStack Router would be the most amazing router you've ever used. It's something you've got to feel. And I'm very confident that it would be a game changer for you. Especially if you're building an SPA. It's 100% type safe. It's state management for the URL. And it's got a lot of other great stuff built into it.

That type safety is a big one. I can't understate how cool this is. And I don't mean just it was written with TypeScript. It is written for TypeScript. It is bulletproof. Inferred types everywhere. In fact, a lot of the code that you write with TanStack Router doesn't even have TypeScript syntax in it. Because it's so fully inferred that it just looks like it's plain JavaScript. But it's all type safe. It's amazing.

And you can stop shooting yourself in the foot with bad links and bad state that's probably going to break your users and break your URLs. And we go the extra mile. Not just beyond type safety, but there's type safe middleware. There's nested search parameter validation. I don't have enough time to talk about all of it. But we can handle a lot. Thousands of routes. No slow down.

The URL state management in it is amazing. They're all shareable, bookmarkable URLs, which is like built-in undo and redo in your history, which is pretty sweet. Search parameter validation. Throw Zod in there. Throw whatever you want in there. We validate search parameters so that you don't have to think about them ever again. You just think about them like state. So you can do stuff like this, or this. And you can even do crazy stuff like this. All in single transactions to the URL. You can even replace. So it's like use state for the URL.

Who doesn't want that? That's amazing. Thanks. It's got all the problems that come with state management. We've solved them all. It has fine-grained subscriptions, which you can't even get with a lot of other tools in the React ecosystem. We've gone to great lengths to make sure that it's very performant. And this is all just client-side. That's what I'm trying to get at.

You can use this today. If you're building an SPA, you can start using this today. And we'll meet you where you stand. I've got one minute to talk about the server. Server is very important to us, too. We have contributors here from React Query. Frederick, TK Dodo. These guys care deeply about the server and about React Query and how we can use React Query with server-side stuff. The question is always, what about framework? What's NANDstack going to do about this framework? Well, it turns out that most of the framework is just routing. And then you add on some SSR capability and some server routes. And then you just need to be able to bundle it up and send it away.

Well, TanSec Start is exactly that. We paired it up with VEET, which is now just a VEET plugin. So if you've used TanSec Start, it's just a VEET plugin now. So cool. I love that animation. VEET's amazing. You get server capability and SSR. But it's incremental. It's optional. I really want to say that you just add it to the router. You're not replacing the router.

It's purely additive and optional. And it's an enhancement to an already great experience. You get a lot of other things that now I'm not going to have time to talk about. Server functions are amazing. And we've got a lot of great features that we're releasing. Even in just V1, it's going to be amazing. And there's a lot more coming. We haven't even really opened up the floodgates for what we want to do. I'm out of time, but I got to answer the question, what about React server components? Soon. Just like React Router, just like many others, we're waiting for some upstream stability. We need to be able to use VEET and we need to be able to give it to everyone, not just people who use something like Next.js. We want it to be broadly accessible. RSEs are amazing. We just think they're streams of text and we're going to make it so that you can use them everywhere, across everything. Even new projects that we're building that you can come ask me about later. And one more thing, we merged in some really cool stuff, so now it's called the DaVinci release, but it's still beta, so don't ask me about that. And last but not least, I've got a lot of great sponsors and partners that have made this possible. I was able to go full-time on TAN stack a year ago because of these companies who are also supporting a lot of our core contributors and maintainers now too, and they deserve a round of applause.

Tanner Stan is asking the first question, that's amazing. Will TAN stack router get additional bundler support like RS pack and RS build? The router probably will. I can't say for start yet but we're hopeful that start will as well, but router probably will. One day, one day. All right, actually it might even already have it. Router, start, you got to be specific.

What are some common use cases for RSCs? I just talked about them, so if you want to rewind, watch my talk again. All right, well, probably Sergei asked before. Sorry, I'm just trying to be respectful to all the questions. Are you currently working on any library or project that relies on React server component capabilities? We're certainly trying to integrate with the patterns that they have. If you want to learn about some tricky things that we're doing with React server components around React query, TAN stack query, you can find Dominic, TK Dodo or Frederick and they can tell you all about the tricky, crazy things that we're doing. But yes, we're trying our best to support them with all of our tools.

How is TAN stack router support with monorepo setups? Great. I think there's some challenges with sharing types across really large monorepos that may have multiple front-end pieces. We're still figuring part of that out, but the future is bright. In fact, you could probably come talk to Dominic yet again, who has somehow managed to set up a great monorepo experience with TAN stack router and start. Should we just get Dominic up a stage? Yeah, yeah. Come join us. What about React router v6 or 7 then? What can TAN stack router offer more and should we switch to TAN stack? You know, core capabilities, they're very similar. They use the same approach to hydration and SSR. They'll probably ship React server components support sooner than us, which is totally fine. But apples to apples, I stand by what I said. I believe TAN stack router, just as a router, is way more advanced and just better, nicer, easier to use. And that's what I would recommend. Would be weird if you thought something else was better than what you're working on.

They'll probably ship React server components support sooner than us, which is totally fine. But apples to apples, I stand by what I said. I believe TAN stack router, just as a router, is way more advanced and just better, nicer, easier to use. And that's what I would recommend. Would be weird if you thought something else was better than what you're working on.

Question from Marcus. Are there any plans for supporting module federation in TAN stack start? Oh yes. Zach Jackson talks to me every week about it. We would love to support it. We are just kind of waiting for the right time to put an effort into that, but it's on our radar. One day. And maybe Marcus can just build it.

Next question from our dear visitor Anonymous. Does TAN stack router support client loaders? Yep. Easy. Oh, yeah. Then there's no more questions coming in. Sweet. Sweet. Then I guess your talk was pretty clear. So if there's no more questions from anyone here, I'm going to give you 10, 9, 8, 7, 6, 5, 4. Oh, Anonymous. Is it planned to give full Angular support for TAN stack query? Love to see it soon. Oh, I would love that. As with framework adapters, we like to have strong support for framework adapters. And we have some really smart Angular adapter people right now working with TAN stack query. Is it Arnoud? He's here. Arnoud is here. So if you want that, go talk to Arnoud and be like, come on.

So if you want that, go talk to Arnoud and be like, come on. Let's get that. So yeah, we're going to add it. Let's give him a round of applause. There he is. It's already experimental. So you can try it out today. But yeah, we want to have bulletproof support. I guess it's pretty hard to build for so many frameworks. But good to hear.

How big is the team? Oh, the team is huge. We have probably 7 or 8 core maintainers, another 15 ancillary maintainers, and then a ton of contributors. And most of them, you mentioned, like you had the sponsors for last year working full time. And these people are now working for free? Or there's still some sponsorship money left? There's sponsorship money that we distribute out to core maintainers. And hopefully that's just going to get bigger and better soon. Maybe someday we'll be able to hire more than just me full time on TAN stack.

It would be nice if there's people maybe in the audience that work at a million dollar company that use TAN stack that maybe can, maybe give some money. Wouldn't that be something? I'm not begging, but it would be nice. Next question from our dear visitor Anonymous again. He's asking a lot of questions. There was a screenshot where you wrapped server and client and server, client, server. Can you talk a bit more about this approach? Yeah, when you use server components, you can compose client components inside of server components that compose other server components inside of those. And there's a pattern to be able to do that, to compose React children together in a way that lets you weave them together. Yeah, it's just kind of part of using React server components. Does it work the same way with the same rules as the Next.js app router? Yeah, that has nothing to do with Next. That's just how React server components... I mean the same rules. Oh, yeah, same rules. Yeah.

Yeah. Nice. All right. One more question from Anonymous. Upgrades between major React versions have been painful. How will you handle this in the 10 stack router? We're just going to try to not change things as much. Be stable. Yeah. I mean, nobody's perfect. We'll have some breaking changes. But I think the... I think what we try to do is not change core philosophies and change core architectures and ask users to take on big lifts. So, yeah, I think every library has breaking changes and it's just part of a library staying relevant. So, I won't promise that we won't ever have breaking changes, but I can promise that if we do, they're going to be easy, graceful and worth it. It's just... Yeah. Breaking changes usually in my eyes also mean that you've just gained new insights and things are becoming so much better that it was worth it. It's a decision you consciously made. And, yeah, you don't take such decisions lightly. The breaking changes we try to make at 10 stack are where you get to delete more of your code. Worth it. We have ten seconds left.

So, that's going to be it for our live Q&A. I'm going to say thank you one more time, Tanner. It was great having you again. If you have any more questions for Tanner, he's going to be upstairs on the balcony. Tanner?