SPA to SSR and Everything in Between

This ad is not shown to multipass and full ticket holders
React Summit US
React Summit US 2025
November 18 - 21, 2025
New York, US & Online
The biggest React conference in the US
Learn More
In partnership with Focus Reactive
Upcoming event
React Summit US 2025
React Summit US 2025
November 18 - 21, 2025. New York, US & Online
Learn more
Bookmark
Rate this content

FAQ

React has transformed the industry by providing a robust framework that has evolved to include server capabilities, improving performance, code reuse, and SEO, which were not as accessible in other frameworks.

Key developments included the introduction of Hooks and Suspense, which improved ergonomics and paved the way for streaming and progressive hydration. Additionally, server-rendered Next.js and the Remix framework made server-side rendering more accessible.

React server components are a new feature that allows server-side rendering to be more efficient, solving challenges like bundling and component data fetching waterfalls. They represent a new architecture that can enhance performance and scalability.

Using React server components can increase complexity by multiplying server challenges throughout an application. They also demand both micro and macro changes to the codebase, including file organization and compliance with new rules.

TanStack has contributed by developing tools like TanStack Router and TanStack Start, which improve routing, state management, and server-side capabilities in React applications, aiming to meet developers' needs both in client-side and server-side environments.

TanStack plans to support React server components broadly, waiting for upstream stability, especially in tools like Vite, to make server components widely accessible across different projects and frameworks.

TanStack Router provides advanced features like 100% type safety, state management for URLs, fine-grained subscriptions, and efficient route handling, making it a powerful tool for both single-page and server-rendered applications.

The speaker believes SPAs are critical and here to stay, highlighting their importance in various applications and the efforts to build tools that enhance the SPA development experience.

The speaker focused on the transformative impact of React, the evolution of server-side rendering, the introduction of React server components, and the development of tools like TanStack Router and TanStack Start to enhance both client-side and server-side React applications.

The current state of bundler support, particularly with Vite not yet supporting server components, presents a challenge in making React server components broadly accessible and usable across different environments.

Tanner Linsley
Tanner Linsley
29 min
13 Jun, 2025

Comments

Sign in or register to post your comment.
Video Summary and Transcription
React's transformative impact, community support, and server-side evolution highlighted. Exciting developments from static site generators like Next.js and Gatsby to server-side rendering evolution, including React Fiber, Hooks, and server components. The pressure on servers in 2020 led to the announcement of server components, a complex but transformative idea. New challenges arise with weaving server and client, requiring adaptation and file organization. Evaluation of React server components' worth based on server-side needs and bundle issues. SPAs are prevalent and valued, despite the focus on client-side apps. TanStack Router offers unparalleled URL state management and type safety, enhancing SPA development. Exciting developments ahead with the DaVinci release, supported by sponsors for TAN stack's full-time commitment and core contributors.

1. React's Evolution and Impact

Short description:

React's transformative impact, community support, and server-side evolution highlighted. SEO benefits, code reuse, and ease of server-side React emphasized.

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.

2. React's Server-Side Evolution

Short description:

Exciting developments from static site generators like Next.js and Gatsby to server-side rendering evolution, including React Fiber, Hooks, and server components. 2020 brought challenges and innovations like Remix, enhancing SSR accessibility for React developers.

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.

3. React's Server Component Revolution

Short description:

The pressure on servers in 2020 led to the announcement of server components, a complex but transformative idea. Next.js introduced support for React server components, initiating a shift towards a new framework and architecture, posing various questions and uncertainties among developers.

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.

4. Exploring React Server Component Functionality

Short description:

Next.js introduced React server components, leading to questions about their role as a tool, bundler feature, or new architecture. The exploration of these components' potential and challenges highlights their varied applications and benefits, including solving issues like pre-compiling JSX and optimizing client bundles.

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.

5. Challenges of Implementing React Server Components

Short description:

With every feature, there are trade-offs. React server components introduce challenges such as multiplicity and the need for micro and macro changes in code, requiring vigilance and adaptation to new rules and concepts.

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.

6. New Frontiers in React Server Components

Short description:

New challenges arise with weaving server and client, requiring adaptation and file organization. Aiming for optimal use of React server components, addressing data co-location and limitations without a server-first router. Trade-offs exist in achieving full server component potential, including complexities with bundler support.

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.

7. React Server Components: Worth and Reality

Short description:

Vite lacks React support currently, but progress is ongoing. Evaluation of React server components' worth based on server-side needs and bundle issues. Personal perspective on social media's portrayal of reality and the prevalence of client-side React applications.

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.

8. SPA Importance and Development Commitment

Short description:

85% of developers work on client-side React apps, yet SSR isn't obsolete. SPAs are prevalent and valued, despite the focus on client-side apps. The speaker expresses love for SPAs and highlights their commitment to enhancing SPA experiences through tool development at TanStack.

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.

9. Advanced Tool for SPA Development

Short description:

Developers are valued equally. Tools aim to meet current and future needs. The TanStack Router offers unparalleled URL state management and type safety, enhancing SPA development.

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.

10. Enhanced Type Safety and URL Management

Short description:

Type safety with TypeScript in TanStack Router. Enhanced URL state management. Support for thousands of routes and shareable, bookmarkable URLs.

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.

11. Enhanced State Management and Server Integration

Short description:

Enhanced state management, performant client-side tools. Seamless integration for SPA development with server capabilities through TanSec Start and VEET plugin.

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.

12. Exciting Developments and Acknowledgments

Short description:

Purely additive and optional, enhancing the already great experience with amazing server functions and upcoming features. Exciting developments ahead with the DaVinci release. Supported by sponsors for TAN stack's full-time commitment and core contributors.

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.

QnA

Exploring TAN Stack Router Capabilities

Short description:

Tanner Stan's question about additional bundler support for TAN stack router, common use cases for RSCs, ongoing projects aligning with React server components, challenges with monorepo setups, and the superiority of TAN stack router compared to React router.

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.

Comparing TAN Stack Router Features

Short description:

React server components support comparison with TAN stack router, plans for module federation, TAN stack router client loaders support, and upcoming full Angular support discussions.

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.

TAN Stack Development Insights

Short description:

Discussion on team size, funding, and aspirations for TAN stack development. Interaction with the audience for potential financial support and a detailed explanation of composing server and client components within React server components.

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.

Managing Breaking Changes in 10 Stack Router

Short description:

Handling upgrades in the 10 stack router with a focus on stability and minimizing core changes. Embracing breaking changes for library relevance while ensuring they are easy and beneficial. Aim to make breaking changes at 10 stack where users can delete more code, signifying improvements.

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?

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Building Better Websites with Remix
React Summit Remote Edition 2021React Summit Remote Edition 2021
33 min
Building Better Websites with Remix
Top Content
Remix is a web framework built on React Router that focuses on web fundamentals, accessibility, performance, and flexibility. It delivers real HTML and SEO benefits, and allows for automatic updating of meta tags and styles. It provides features like login functionality, session management, and error handling. Remix is a server-rendered framework that can enhance sites with JavaScript but doesn't require it for basic functionality. It aims to create quality HTML-driven documents and is flexible for use with different web technologies and stacks.
Speeding Up Your React App With Less JavaScript
React Summit 2023React Summit 2023
32 min
Speeding Up Your React App With Less JavaScript
Top Content
Watch video: Speeding Up Your React App With Less JavaScript
Mishko, the creator of Angular and AngularJS, discusses the challenges of website performance and JavaScript hydration. He explains the differences between client-side and server-side rendering and introduces Quik as a solution for efficient component hydration. Mishko demonstrates examples of state management and intercommunication using Quik. He highlights the performance benefits of using Quik with React and emphasizes the importance of reducing JavaScript size for better performance. Finally, he mentions the use of QUIC in both MPA and SPA applications for improved startup performance.
Full Stack Documentation
JSNation 2022JSNation 2022
28 min
Full Stack Documentation
Top Content
The Talk discusses the shift to full-stack frameworks and the challenges of full-stack documentation. It highlights the power of interactive tutorials and the importance of user testing in software development. The Talk also introduces learn.svelte.dev, a platform for learning full-stack tools, and discusses the roadmap for SvelteKit and its documentation.
SolidJS: Why All the Suspense?
JSNation 2023JSNation 2023
28 min
SolidJS: Why All the Suspense?
Top Content
Suspense is a mechanism for orchestrating asynchronous state changes in JavaScript frameworks. It ensures async consistency in UIs and helps avoid trust erosion and inconsistencies. Suspense boundaries are used to hoist data fetching and create consistency zones based on the user interface. They can handle loading states of multiple resources and control state loading in applications. Suspense can be used for transitions, providing a smoother user experience and allowing prioritization of important content.
From GraphQL Zero to GraphQL Hero with RedwoodJS
GraphQL Galaxy 2021GraphQL Galaxy 2021
32 min
From GraphQL Zero to GraphQL Hero with RedwoodJS
Top Content
Tom Pressenwurter introduces Redwood.js, a full stack app framework for building GraphQL APIs easily and maintainably. He demonstrates a Redwood.js application with a React-based front end and a Node.js API. Redwood.js offers a simplified folder structure and schema for organizing the application. It provides easy data manipulation and CRUD operations through GraphQL functions. Redwood.js allows for easy implementation of new queries and directives, including authentication and limiting access to data. It is a stable and production-ready framework that integrates well with other front-end technologies.
Tanstack Start - A Client-Side First Full-Stack React Framework
React Summit US 2024React Summit US 2024
30 min
Tanstack Start - A Client-Side First Full-Stack React Framework
Top Content
We surveyed thousands of developers to show that a louder audience leads to a better presentation. There has been a shift in web app development towards server-first architectures, which has improved full-stack capabilities but at the cost of complexity and divergence from the client-centric approach. Tanstec Start is a meta-framework that aims to provide the best client-side authoring experience with powerful server-side primitives. The Tansec Router supports advanced routing features, URL state management, and JSON storage. Combined with the server-side rendering capabilities of TanStack Start, it becomes even more powerful. The TanStack Router has isomorphic loaders and integrates seamlessly with TanStack Query for additional features like polling and offline support. UseSuspenseQuery allows for dynamic streaming of data during SSR. TanStack Start also offers server-side features, API routes, server functions, and middleware. The future plans include RSCs, websockets, real-time primitives, and static pre-rendering. TanStack Start is now in beta and is suitable for building React apps. It is open source.

Workshops on related topic

Building WebApps That Light Up the Internet with QwikCity
JSNation 2023JSNation 2023
170 min
Building WebApps That Light Up the Internet with QwikCity
WorkshopFree
Miško Hevery
Miško Hevery
Building instant-on web applications at scale have been elusive. Real-world sites need tracking, analytics, and complex user interfaces and interactions. We always start with the best intentions but end up with a less-than-ideal site.
QwikCity is a new meta-framework that allows you to build large-scale applications with constant startup-up performance. We will look at how to build a QwikCity application and what makes it unique. The workshop will show you how to set up a QwikCitp project. How routing works with layout. The demo application will fetch data and present it to the user in an editable form. And finally, how one can use authentication. All of the basic parts for any large-scale applications.
Along the way, we will also look at what makes Qwik unique, and how resumability enables constant startup performance no matter the application complexity.
Back to the Roots With Remix
React Summit 2023React Summit 2023
106 min
Back to the Roots With Remix
Workshop
Alex Korzhikov
Pavlik Kiselev
2 authors
The modern web would be different without rich client-side applications supported by powerful frameworks: React, Angular, Vue, Lit, and many others. These frameworks rely on client-side JavaScript, which is their core. However, there are other approaches to rendering. One of them (quite old, by the way) is server-side rendering entirely without JavaScript. Let's find out if this is a good idea and how Remix can help us with it?
Prerequisites- Good understanding of JavaScript or TypeScript- It would help to have experience with React, Redux, Node.js and writing FrontEnd and BackEnd applications- Preinstall Node.js, npm- We prefer to use VSCode, but also cloud IDEs such as codesandbox (other IDEs are also ok)
Let AI Be Your Docs
JSNation 2024JSNation 2024
69 min
Let AI Be Your Docs
Workshop
Jesse Hall
Jesse Hall
Join our dynamic workshop to craft an AI-powered documentation portal. Learn to integrate OpenAI's ChatGPT with Next.js 14, Tailwind CSS, and cutting-edge tech to deliver instant code solutions and summaries. This hands-on session will equip you with the knowledge to revolutionize how users interact with documentation, turning tedious searches into efficient, intelligent discovery.
Key Takeaways:
- Practical experience in creating an AI-driven documentation site.- Understanding the integration of AI into user experiences.- Hands-on skills with the latest web development technologies.- Strategies for deploying and maintaining intelligent documentation resources.
Table of contents:- Introduction to AI in Documentation- Setting Up the Environment- Building the Documentation Structure- Integrating ChatGPT for Interactive Docs
Learn Fastify One Plugin at a Time
Node Congress 2021Node Congress 2021
128 min
Learn Fastify One Plugin at a Time
Workshop
Matteo Collina
Matteo Collina
Fastify is an HTTP framework for Node.js that focuses on providing a good developer experience without compromising on performance metrics. What makes Fastify special are not its technical details, but its community which is wide open for contributions of any kind. Part of the secret sauce is Fastify plugin architecture that enabled developers to write more than a hundred plugins.This hands-on workshop is structured around a series of exercises that covers from basics "hello world", to how to structure a project, perform database access and authentication.

https://github.com/nearform/the-fastify-workshop
Build a Product Page with Shopify’s Hydrogen Framework
React Advanced 2022React Advanced 2022
81 min
Build a Product Page with Shopify’s Hydrogen Framework
Workshop
David Witt
David Witt
Get hands on with Hydrogen, a React-based framework for building headless storefronts. Hydrogen is built for Shopify commerce with all the features you need for a production-ready storefront. It provides a quick start, build-fast environment so you can focus on the fun stuff - building unique commerce experiences. In this workshop we’ll scaffold a new storefront and rapidly build a product page. We’ll cover how to get started, file-based routing, fetching data from the Storefront API, Hydrogen’s built-in components and how to apply styling with Tailwind.You will know:- Get started with the hello-world template on StackBlitz- File-based routing to create a /products/example route- Dynamic routing /products/:handle- Hit the Storefront API with GraphQL- Move the query into the Hydrogen app- Update the query to fetch a product by handle- Display title, price, image & description.- Tailwind styling- Variant picker and buy now button- Bonus if there’s time: Collections page
Prerequisites: - A Chromium-based browser (StackBlitz)- Ideally experience with React. A general web development background would be fine.
Build a Universal Reactive Data Library with Starbeam
JSNation 2023JSNation 2023
66 min
Build a Universal Reactive Data Library with Starbeam
WorkshopFree
Yehuda Katz
Yehuda Katz
This session will focus on Starbeam's universal building blocks. We'll use Starbeam to build a data library that works in multiple frameworks.We'll write a library that caches and updates data, and supports relationships, sorting and filtering.Rather than fetching data directly, it will work with asynchronously fetched data, including data fetched after initial render. Data fetched and updated through web sockets will also work well.All of these features will be reactive, of course.Imagine you filter your data by its title, and then you update the title of a record to match the filter: any output relying on the filtered data will update to reflect the updated filter.In 90 minutes, you'll build an awesome reactive data library and learn a powerful new tool for building reactive systems. The best part: the library works in any framework, even though you don't think about (or depend on) any framework when you built it.
Table of contents- Storing a Fetched Record in a Cell- Storing multiple records in a reactive Map- Reactive iteration is normal iteration- Reactive filtering is normal filtering- Fetching more records and updating the Map- Reactive sorting is normal sorting (is this getting a bit repetitive?)- Modelling cache invalidation as data- Bonus: reactive relationships