Why React Developers Are Leaving Next.js for TanStack

Why are you doing this? It is a direct competitor with Nex.js. No software is immortal. You're going to hear that React server components are this silver bullet, but they're not. Current Nex.js app router is an overprescription of RSC's. Everybody thinks that they're like required because of the marketing Nex.js has put into them. By the way, you don't need React server components to do literally anything, but the use server directive is like I think it's just as big of a foot gun as use effect. So, it's this kind of like blackboxing and overabstraction that I'm allergic to. I hate it if they had just kept investing into the pages router and making it the best that they possibly could. That's where you might end up with something like Tanstack start. What's up everyone? Was a lot of work editing this video. So, if you guys enjoyed the video in the conversation, go all the way down and subscribe to the channel. What is Tanstack and who is the team behind it? What can you say about that? Man, Tanstack is open source organization. It's a business. It's also just a group of cool people hanging out in Discord every day. We got a lot of open source projects that I' I've built over the years and also some that I haven't built personally, but my maintainers and contributors have have built themselves as well. So, it's a growing open- source organization and we make great stuff. How many people are behind Tenstack at the minute? There are about seven core maintainers and then if you go to the extended maintainer group, there's probably about 20 more. Okay. How many people full-time if you don't mind sharing? I'm the only person full-time. I have one business development employee full-time now. Uh, everyone else is either GitHub sponsored or contracted in varying degrees. Do you have any business model behind Tanstack at least to pay a little bit of the bills that you have yourself? Absolutely. So, I mean, if you go to tanstack.com, you're going to see a big fat list of partners. Obviously, there's there's a healthy throughput of GitHub sponsorships that come through to me personally. I don't need those anymore, which is great. So all of my GitHub sponsorships are just basically proxied through to all of the maintainers. On top of that, we also have brand and like marketing partnerships. So all these logos we have on our homepage, these are companies that either rely on and use Tanstack inhouse uh or they care very deeply about the success of Tanste and on top of all that they obviously want to have their brand associated with our users and our software. So there's a bit of a marketing play there as well. Uh the business side of Tanstack does make money off of those partnership uh agreements and a good portion of that goes to pay my salary, the salary of my one employee that I have just barely got a new employee, my first one. And then a lot of that still spills over into funding all of our um open source sponsorships. So we we yeah we do pretty well. We're not in trouble. I remember seeing Tenstack years ago. At the time, it felt like it was a group of useful UI libraries. And then literally 3 weeks ago, I said, "Okay, I'm going to learn Tenstack once again." And I saw Tenstack start. It seems to me that it went from being a a small group of libraries to something like I wouldn't call it a framework. You call it application stack, which is interesting. So I wanted to ask you like when did you realize that Tenstack was becoming something bigger that deserves a tenstack start? It is. I mean it's definitely a framework. We call it a framework internally. You can call it that. We have all these libraries that we built and many of them are very brownfield. You can drop them into any React project, any JavaScript project and they'll they'll do a good job and they don't want to take over your whole application. We got a little deeper into the weeds when I when I built the router. So Tanstack router, I actually started building that 5 years ago. That came out in 2022, 2023, something like that. So, it's been out for a while, but it was only a clientside router and the the idea was just to build the best client side router that we could. We released that. People loved it. Lots of companies that started adopting it and then people started asking me if they could use it for the server as well. So, using it to build full stack applications, not just like a client side spa. And I said no initially because I didn't want to build a framework. I had already built a framework a long time ago. I built a framework that was still static site generation framework. But when I was doing that, it could have become my full-time job. Like I had investors lined up that wanted to give me money to build it full-time, but I already had a startup. I was already I was already working on a startup with some friends. And so I I said, "No, I'm not going to do that. I already have a thing." So I tabled that and got rid of it and vowed that I would never build a framework again. And obviously I ate those words. Two and a half years ago, I decided like I I wanted to build a framework because I was doing more server side stuff, full stack stuff, and I was take I wanted to take my router with me. Um I do think it's a really great piece of software and and so I didn't want to have to go back to using Nex.js or or Remix or React router. So I started building Start and that's what Start is. It is the full stack embodiment of what it means to use Tanstack and it is like a it is a direct competitor with Nex.js JS and React Router, Remix, whatever you want to call it. It's a really viable solution. There are a lot of people starting to use it and there's a lot of there's a lot of businesses that are starting to use it as well. It's all over the place. Tanstack if I'm honest. You know, you see high people influencers saying that they have switched from NextGS to tenstack. You see companies literally migrating the entire products from NexJS and other frameworks to tenstack you know and I all it caught my attention that's why I literally you know start also testing it out and I was surprised by multiple things that I have to question you about by the way can you explain where 10stack start fits when compared with frameworks like nextgs remix astro what you were thinking in terms of okay I want to build 10 stack start and it will be different from nextgs because of this let me put it this way the possible outcomes of many of these frameworks are all the same. You're going to be able to have a full stack application. You'll be able to run code on the server and on the client. You can use React. It can be interactive. It can be really fast. It you can, you know, static pre-render, you can cache, you can do all the same things are going to be very possible with all of these frameworks. So, it's it's less about the ultimate outcome. And there are some small, you know, differences there and things might be easier to get than others, but it's a lot about how you get there and the consistency of how you can get there. So, Tanstack start is actually closer in theory to how React Router Remix worked mostly because it started at a client side router first. Uh, which is what makes it very different than Nex.js. So, in fact, if you if anybody ever used Nex.js JS pages router. We're talking back like the old pages router. This is probably more similar to that. So just imagine that instead of Nex.js going down this whole app router React server component obsession uh you know timeline if they had just kept investing into the pages router and making it the best that they possibly could. That's where you might end up with something like tanstack start. So what makes it different is that we assume that everything is going to end up on the client. It it will you're building a full stack application. So instead of pretending that we're building a a server side thing and opting into the client side interactivity, TANSC start is built to assume that you're on the client and assume that you're hydrating everything and assume that you you want to build as if you're on the client in the browser and then you opt into the server side pieces that you need. That carries through everything. It carries through uh the way that we approach the build system with VIT. It carries through to all of the API design. So everything you do is technically isomorphic, which means it's going to run during SSR and on the client. It carries through to performance implications. Tanstack start and router are extremely fast. So when you when you get to the page, everybody's obsessed about, oh, Lighthouse metrics or whatever, but once you load the page, tanstack start is one of, if not one of the fastest SPA router and library out there. Navigations for users going through your application or your site feel crazy fast. They're all cached. If you visit pages you've been to before, they're instant. I would say the next biggest focus is that it's type safe. It's the only like fully types safe system for front-end apps. I think uh you got you've got good type safety in other frameworks. In fact, a lot of the type safety that they have added over the last two or three years is because they have seen our obsession with type safety and they want to try and match it. So you can actually write tanstack route or use tanstack and and if you do it right with inference, you you don't even have Typescript code in your editor, which is pretty crazy. That was actually one of the things I noticed the most when I started working with tenstack is that you know with other frameworks you always end up having to write these explicit types of typescript you just have to literally tell okay this will be from this type even though like you almost feel like the the framework should infer this for me like you know what I mean like it's always this type like why do I have to give it so I actually noticed two things when I tried for ten stack for the first time so the first one was that like the type inference was super good and I'm a big fan of typescript by the way And I love to do that. Let me correct this to you. I'm a big fan of type safety. I'm not a big fan of type of writing types. Okay. Amen. Same. Uh I I am writing type averse. I mean that is that is exactly why we've built all of our tools the way we have. I actually don't think they're the same. I I think you can you can write apps and code with TypeScript and have it not be type safe. That's the reality is if if you're manually typing things, you're not really doing anything different than if you were just use JavaScript and with your brain. If you break the inference chain, then nothing is automatic and you still have to go back and remember all the places where you you broke things. So I would argue that, you know, those are not the same thing. It's one is a superset of the other. This is one of my biggest battles in the PHP ecosystem. M people were like convinced okay to be like a modern PHP developer I need to type every single thing I have on my code and I was like no you don't use type inference uh you we have our our own version of TypeScript we just call it PHP stand PHP stand will infer those types for you don't need to type them yourself topic for another day so I noticed the type safety which I was super in love to and I also noticed something interesting which is when I first learned NexGS I felt that things were too magical for me you know what I mean and I am a magic person like I love lot which already has some magic on it in rails and everything and next.js GS it felt like oh I'm seeing this error I don't know where it's coming from like this is probably some convention that I don't understand it's I don't know I felt it's too magical in the other hand with tenstack I felt that things were explicit but not like in like super explicit like the enough you know so that's that was the second thing I noticed we wanted to build something that was really traceable and transparent so that for every single request you were making or a user was making to your page you could follow that life cycle really easily. I mean, there's nothing easy about full client hydration and streaming. Everything about it is complex. That's why there's a framework built around it. But we wanted to make it simple so that you could debug it and you could understand, oh, if this error is happening, this is where it's happening. If I want to get into the life cycle here, I know exactly the API to use. I know exactly the convention point to plug into. I mean, you have to have magic somewhere. Otherwise, it wouldn't be a framework. And so we think that we have found the right tradeoffs for where that magic needs to go. One of those is server functions. RPCs. RPCs are magical. Full stack RPCs are are they are magic. They're compiler magic. And everybody's doing compiler magic, right? But we we decided if we're going to do compiler magic, we're going to make it really safe. We're going to make it so that it works out of the box for 90% of the use cases, but you can actually open it up. You'll hear me talk about this some in some other videos, but like the whole use server directive, this is something even comes from React, but the use server directive is like I think it's just as big of a foot gun as use effect because it it is a magical directive that carries so much power and there's zero way to control it other than just adding the use effect directive. Now, if you compare that to something like our create server function factory that we have, create server function is freaking awesome. It's got full stack type safety. It it doesn't provide you type safety unless you provide validation. So, we actually push people into providing validation so that it's secure. You can customize things like all of the HTTP language about it. You can change the method, add headers, you can return streams. So, it's this kind of like blackboxing and hate it. Everything that we did with magic, we're like, "Hey, if this is going to be magical, we need to be able to to break it down and have tra, you know, escape patches everywhere." You see it all the way through, right? Like the use not using use client in favor of composite components is another example that I really liked it. We need to clear that up because I'm actually writing a blog post right now. People missed this in our announcement. We support use client. Oh, no. Yeah. Yeah. Yeah. But but you have an ex like a more explicit alternative basically. Yeah. Like if if if the we're talking about React server components, by the way, for anybody listening who's not familiar with this topic, React server components, Nex.js was the first one to have them and and everybody thinks that they're like required to do to do anything now because of the marketing that Nex.js has put into them. By the way, you don't need React server components to do literally anything. They're they're really good at a couple of specific things. For instance, we've been running tanstack.com on start for the last two and a half years. We've never had server components and never had a problem. We finally added support for them and I moved a couple of things over in tanstack start or intens.com and saved a couple of kilobytes on the client bundle. For the most part, you're going to hear that React server components are this silver bullet, but they're not. They're very important. Anyways, the use client thing, we support it because this is the server has to be able to tell the client sometimes, hey, these are components that I need you to hydrate and I'm the server and I'm deciding your fate. But that's not always the case because and it's funny cuz most other most other uh frameworks, they're not client first. So the idea of the client being in control of what gets finally displayed is it's not even a thing. So when I say, "Oh yeah, with the composite components you can invert control back to the client to compose what you give it however it wants," people are just like they don't they don't get it. So we're going to explain it a little bit more. Again, even even with all the cool things that we're providing around server components, they still have a very limited like use case. When I saw Nex.js moving this uh React server component strategy, I was like, "Wait a second." And like you guys had a big advantage over something like PHP or or Ruby, right? Cuz we are forced on rendering things on the back end. You can actually render things on the client side. Like why do you default to actually not doing it? So I'm wondering if you know any of the reasoning behind this. Couple of different motivations. I'm just going to name them in no particular order. So the first one that comes to mind is there there's this obsession around bundle size, right? So you've got to get the bundle size down. Ship less JavaScript to the client. the the fewer bytes you ship to the client, the faster it's going to be. I mean, that is true, right? That the the less kilobytes of JavaScript you need to parse and make sense of on the client before you can render or hydrate into interactivity, it is very important and those affect Lighthouse scores and core web vital metrics. So, for instance, if you have a bunch of markup on your page that is a lot of markup, but maybe it doesn't have a lot of interactivity in it, there's really no point in shipping a lot of bundle size to the client to rehydrate a div. Why do you need to rehydrate a div with the the component code that built that div? But that's different than saying, "Hey, I've got this really interactive widget on the screen. It needs client side code, so you want to ship that." So server components were a way to instead of saying, "Hey, we we're just going to ship all of the code to the to the browser so that we can run all that same code we ran on the server again to rehydrate and and bring the app back to life." You're kind of doing it twice. You do it once on the server to produce the HTML. You ship the HTML down. Then you have to ship the application with it so that when the HTML comes back to life, it has all the code it needs to run again. That's the default for SSR. And actually, that works great. But in some scenarios, say where most of the page is static or there's a lot of it's really just around static content in my opinion. So if you've got blogs, documentation, content, e-commerce, right? Big portions of a content or site that are just HTML or just static markup and they rarely change or they don't need to change. Why are you shipping the whole bundle down to recreate that? So that is kind of where React server components come in where you can generate those static portions on the server, send them down to the client and they they still get made interactive but they don't need the portions of the application that you needed on the server because static content markdown it doesn't need to be interactive. There are pieces of it that are there might be a button in there or a little you know nested inside of static content. That's the whole point behind React server components. The other point I think that that gets a little lost in the weeds is that they invented this protocol, right? The ability to say, "Okay, we're going to do a bunch of work on the server and we're going to send only the little pieces down to the client that we need." And what they found is that server components are really affordable to data fetching and to eliminating some of the pains that you have with with client side waterfalls. So you don't want to fetch here and then go to the client and fetch again and then go back to the server and fetch again. You have a bunch of round trips and waterfalls or or even on the server on even on the client you don't want to render a page and then have it show a new widget and then it has to fetch data and then it shows a new something and then it has to fetch data. So they call this the waterfall cycle. you start waterfalling through requests. And parts of React server components can really help get rid of waterfalls because when you're on the server, you're close to your database. You can fetch the data that you need to render whatever it is you're going to render and send it to the client and be done. One of the overreaches in my opinion of server components is that the people who invented them and the people who have been propagating them for the last few years see them as more than just a protocol to help with static content. They think that they are this amazing magic hammer to solve routing and waterfalls and data collocation. And so what you what I see in like the current Nex.js JS app router is an overprescription of RSC's. It's like, hey, we invented this new protocol. Let's just move everything we've ever done into this new protocol because it's this silver bullet solution. That's when you get really deep into stuff like like the Nex.js APIs where something like reading a header from the request is asynchronous for whatever reason. And if you use that API, it it starts to conventionally change the rest of your page to be asynchronous and streaming. And so I think it's just a little bit of an overprescription of of a primitive that can be very useful. In my opinion, React server components are just serialized markup. It's just an ability to take some markup on the server, serialize it, bring it back to life on the client with with some interactive pieces inside of there. Anything beyond that uh I feel is a a bit of an overreach and that's the way that we embrace them at TANSC start. We have a router that that gets rid of waterfalls. We have tanstack query that allows for really good data collocation. Um, we have all of these pieces and and also we built it so that you can use the stuff that already exists like CDN CDNs exist already and they have request level caching on them and you can use that and but but you don't see that in a lot of the traditional RSC prescriptive approaches. They have their own caching language of use cache and component cache and it's kind of this this new blackbox that they've created around components and I just think it's all kind of a waste of time. I think that it's I would rather have primitives that I can compose that I don't have to learn something new to do something that I've known how to do for the last 15 years. I if I want to cache something on the server, I want to be able to throw it into Reddus, throw it into a database. I want to be able to put it into a key value in memory store. Who knows, you know, crank up the TTL and be done. I don't want to have to, you know, mess around with some new custom API layer that is specific to my framework. That's how we take the approach with Tanex start. all of the different primitives you've been working with for caching over the last whatever how many years. That's still how you cache a React Server component. You're on the server, throw it into Reddus or whatever. If if you want to use the CDN, set a cache header. When you get to the client, it React server components aren't this special thing. They're just it's just a stream of data and you have that in a variable. And if you want to chuck that stream into local storage or index DB or tanstack query or tanstack router or Apollo, I don't even care. It's just bytes. And that's it's that transparency kind of going full circle back to like what makes Tanstack start special. It's that transparency of data and the transparency of the life cycle of that data through the whole stack. And you just don't get that in a lot of other frameworks. you have components for tables and forms. Just let that sink in because the world lives on tables and forms you know like 99% of the websites are forms and tables period. And typically like genius people of the JavaScript world of the JavaScript frameworks literally they kind of run from it because having a component that is a table which is atlas and blah blah blah blah all of this stuff takes a lot of time to build. So uh in one of the first components you had was like 10 stack forms 10 stack tables which clearly tells me that you build a framework to solve people's problems and I guess your thinking was that as well right everything that I built was because I was experiencing a really deep pain about that thing and I I selfishly built it for myself first like the very first one that I built was React Table and I needed that because I was doing dashboards and like you said everything is tables. Yeah, you can make charts, you can make but any s any any application or SAS product that becomes sophisticated enough to have customers, you're going to have tables. In fact, every page is probably going to have a table or it's going to be a detailed view of something from that table. So, when I when I actually migrated from Angular to React, there wasn't a decent table library out there. There was like ag grid, but they were working on a React renderer and it wasn't ready at the time. And I knew Nile, the CEO of AG Grid. Um, and it wasn't quite ready and I needed it now. So, I just went and built it. React Table. It was inspired initially by NG Grid for Angular, a relic of the past. And when I built that, it was because I just needed a way to just take a schema and the data and drop it into my React app and just have it render the the perfect table that I needed with all the filtering and the pageionation and all of like the row model manipulation stuff that you need out of a table. It just needed to work and and I built that and used it internally for a a long time before I even open sourced it. And that's how a lot of these projects were born is is out of just we needed them. Even the form one right is so bread and butter is so something that people just do all the time like the form component like I remember when they came to inertia. So we have something kind of similar to ten stack form which is inertia forms basically when it came to inertia I was like oh my god I spent so many time using use state from react like preserving this loading state all doing all this stuff and this uh form component was so useful from that point like we have a sass at laval call laval cloud and it's the form component all over the place like I don't know it's just crazy the amount of usage we have about that form a lot of people think that ten stack is react only however ever from my investigation tenstack supports solid as well already and some of the components of the tenstack ecosystem also support things like Vue.js and more. So uh after watching a talk of you from literally a month ago if I'm not mistaken you mentioned that you have plans to add Vue and Angular to ten stack start. So do you have a timeline on Vue already or not yet? Not yet cuz we have a lot of fans of Vue here. We are working on a viewport. It's still early. The nice thing about this is that Vue isn't super different from React and Solid. It has more in common with what we're doing than say like Angular or spelt or something like that. So I'm very hopeful for Vue. And what's cool is once we add Vue support to router, that's really the most difficult one. So it's like we will first add it to Tanstack router. It'll be tanstack view router. But once we add that, the start pieces are actually pretty easy to to make work. But yes, we build all of our libraries agnostic. So every single one of our libraries has just a TypeScript core where a bulk of the logic lives and then from that core we extend out into individual adapters. So to give you an idea, 13 of our libraries support React, five of them support Pact, seven support Vue, Angular has seven, Solid has 12, spelt has seven. We even support Quick and Lit and Alpine apparently for a couple of them. And there's even vanilla adapters for four of them that you just you can just use as normal. Why would you support Alpine? I hope you can see a theme here that like we like a the UI library that you use might feel like it dominates a lot of what you do and it is a very crosscutting concern for everything that you do. All of your components and HTML are probably written in it. But it's easy to forget that it is still in just an implementation detail. And because of our highle approach to all these libraries, we see React and Solid and and Vue and and whatever they're just implementations of hopefully something that we have created that should be timeless. like if a new UI library comes out, we should not have to rewrite the core logic of a data grid just because of a new UI library. And that that's the whole concept. So same with the router and with start. Um some of these are pretty close to the UI library like table and the router and tan stack virtual, but you'd be surprised what you can do with headless design. So all of our libraries are headless where they can be there. There's a few, you know, that that would never make sense, but for instance, Tanstack virtual is is a headless list virtualizer, which is cool. It uses the same logic to provide virtualization for all of the different frameworks. And what's neat is we manage the state and the side effects and the life cycle and the logic and the math and all the stuff that developers really don't want to worry about. And then we just hand it back to you and say, "Okay, you can now implement your UI however you want. We don't care. Just make sure that you put, you know, our calculations into the right places and and it should just work. How important is for you to be framework agnostic? I understand that you can do it. I understand that you are doing in the way that um ten stack doesn't become coupled to the internals of react for example. But why are you doing this? There's a couple of reasons. One, I I think that it promotes better code. Like if if you've got UI code specific to a library dirtied throughout your core logic, I think that's smelly. If you can't extract some really valuable piece of logic out into something out of a UI UI library and it's tightly coupled, I just don't think it promotes good isolation of concerns. So that's the first reason that we do it. The second reason is that no software is immortal. It doesn't matter what it is. Even Tanstack, all software is a means to an end to hopefully someday remove that software, right? We write something, it's it's all temporary. And so I hate fashion. I'm not a a fashionable person. My wife dresses me nice, but I I really hate fashion. I hate the just the way that things are always changing. So I'm always trying to combat against that. I think that UI libraries and component libraries and design styles and all this stuff that every year it's new. It's it's a maintenance burden just to base your to base anything around that life cycle unless that's what you make money off of is something new every year. But even React has its has a runway and that may not mean that React dies, but it just means that there's going to be other libraries and other solutions that don't involve React and we want to be prepared for those. Just on the story of React. I'm going to be honest like in 2022 23 I thought React was like forever but now I think React is over because there is literally better alternatives you know spelt and everything but now with AI like literally smashing so much React code I don't even know anymore man cuz React is so big at the minute like on market wise agents wise you know and agents are literally smashing React code like nobody you know what I mean? Uh yeah I know exactly what you mean. So, I know there's a lot of npm stat little apps out there. The one that we have on Tanstack's freaking awesome because you can do normalization. So, if I want to peek into the React ecosystem, I can flatline React and and look at market share inside of it. So, it's kind of cool. React is crazy. You know, we talk about AI and React. Is there going to be another framework? I think there is. And there already are. Like, I love Solid. I think Solid is just really fast and really elegant. and I'm I'm good friends with Ryan Carneato and you know it's it's hard to say. I just think that if there's anything that the last year has taught us, it's that our uncertainty timelines may have been 2 or 3 years out where it's like, oh yeah, you know what? I don't I don't know what's going to happen in 2 or 3 years, but a year from now, I got a good idea. That's just gone. I don't know what's what things are going to be like in a month. I don't know what they're going to be like in 2 months. Luck favors the prepared. and I am trying to build tan stack to be prepared for anything including the the unknown of AI you know so you mentioned obviously supporting multiple frameworks and you mentioned why you want to do that which is was super clear however as an open source maintainer myself what I have done in the past at least is that I typically don't like to maintain the things that I don't use and the reason is because I don't really know how those people think it might be a little bit weird to understand this but just as an example if I am a React developer. I know exactly what React developers want, you know? I know exactly what how they want things, you know what I mean? However, I'm not an Angular developer. I'm not familiar with the conventions and everything, you know. So, how do you maintain quality across all these framework integrations if I bet that you're probably not a Alpine user, are you? No. Exactly. So, how do you um maintain quality across the Alpine integration for example? When I say we have a bulk of the core logic for providing the core value of these libraries in a Typescript core, like I'm not overstating that. A lot of these libraries, the like some of them, the framework adapters are like 30 lines long. It's literally just wiring up our reactivity model inside of our core to translating that into the reactivity model of whatever the UI library it is it's using. Interesting. So basically use state on react whatever it is on view and and that's it nothing. Okay, then some of them are a little more involved like with Tanac router you know it's not just a oneliner we have to write hooks we have to write providers you know there's a there's many files but a lot of those files are still very shallow because they're just consuming what's coming out of the core and for the ones that do require a fatter adapter that's why it's not just me right we have people inside of the Tanstack ecosystem who are solid people who who do use Angular and who do enjoy Vue And so it's a community effort in keeping those up to date. And you know what? There there are some that we don't use like spelt. There's not a lot of spelt people inside of Tanstack. There's just not a lot of spelt people actually. So we we have a hard time finding champions who would want to come in and say, "I know spelt and I love spelt and I want to use tan stack and so I'm going to help you out." One component that surprised me, dude, was the tenstack AI because you look at tenstack forms, you see like UI forms, you see 10 stack table, you see UI tables and then suddenly you see an API client and it was like wait a second like why they are doing this and um maybe you have a reasoning behind this. The story behind that is interesting. I was I was at react comp actually last year. I was there with uh Jack Harrington and we were we were going around and I I talked to a lot of people who at that time it it was just like everybody's building a chatbot, everybody's building something with AI and they everybody was using the Verscell AI SDK and it's a it's a great piece of software obviously people love it but we ran into a lot of people that didn't love it and we asked them why. There were a couple of core technical reasons that came up between all of our conversations and and a lot of that landed into what Tanstack is really good at. Type safety, full stack type safety, um being very headless, being very unopinionated, uh not hedging bets against, you know, specific platforms or specific implementations. And just overall, I think the quality of our of our design um and our experience and the people we have involved allows us to build great open source solutions. So I wasn't particularly interested cuz I wasn't doing a lot with it. But when we started talking internally to the rest of the Tanstack team, there were a lot of maintainers who were using SDK and a couple of them just raised their hands and said, "We want to build our own tool because we think that would be awesome." And I said, "You know what? Go for it." I I support you. Let's do this. Initially, it was Jack Harrington and Alm Tuslac. They I think they went from like in they had the first conception of of the API that we wanted. They went from that to an alpha release in 2 weeks. It was really fast. And what's cool is we built it with the help of AI. This was the first library that we actually built with the help of AI other than Tanstack DB. You know, but you you'd be surprised like what we did is we first designed everything by hand and then we went back and when we we actually asked all of the LLMs at scale like what do you think of this API? What do you think of this design? What do you think of this? Would you use this? And you this the feedback was surprising. That helped us refine the API to a way that that not only humans think is cool but also we know that AI loves it too. Also, there were a lot of features that people wanted that it seemed like they were waiting on for cell AI SDK to do, but but they didn't know what if they were ever going to come. Seems to me that potentially that is a bigger vision that you may have for 10 stack that we are not seeing yet. I don't know if you're familiar with Laravel or Rails. Probably you are. But, uh, basically that's what we call like a full stack framework. Gives you things like authentification, mailing, cues, database tools, caching, you know what I mean? database migrations and all those stuff, various drivers for SQLite, uh, Postgres and everything. Do you see a world where potentially Tenstack starts to adopting some of the most common needs on the server? No. Uh, I'll tell you why. Uh, I think that this starts to get into open source sustainability and a lot of people are like, how is TANSAC going to survive? Everybody immediately jumps. So, not just people who think they know what we should do better than we do, but venture capital. can't tell you how many venture capital calls I've had over the last 5 years. Oh man, let us dump a couple million dollars onto the Tanstack fire and just see what happens. And I'm like, what do you expect to come out of that, you know? And they're like, well, you know, we could build a a hosting platform, you could build uh an email service and or you could build authentication. You could build all these things. And I said, yeah, you know, we could, but that would just end up distracting from what we are actually good at. We are good at building agnostic platform level things that help a lot of people in very flexible ways. The second you get into platform specific things, you introduce a bunch of weird motivators into the business. So now when we wake up in the morning, there's this question in everybody's mind of do we work on the open- source thing and improve that or do we work on the thing that's going to make us money? And that question can be balanced and it has been by companies in the past, but historically and statistically that is not a good bet, especially for front-end or full stack software. If you've got a database that you're building and part of it open source or you are specializing in like an authentication library or something, balancing open source is possible there. But think about like a router. Like how do we how do we make money off of a router? Like the only way you could do that is to just try and lock people into services. That would limit the amount of companies that we can work with for partnerships and sponsorships. It it it automatically paints a weird agenda on Tanstack. It's like, oh, you should use Tanstack. And somebody shows up on the homepage of the website and they're like, they just want me to get they just want me to use their hosting platform or they just want me to use their email, you know? So staying away from that is one of the reasons why Tanstack is succeeding and growing like it is because for better or worse we're kind of seen as a Switzerland. We don't have an agenda other than we just want to build the best open- source. We we will keep it free forever. Yes, there are a couple of signs on the front yard of Tanstack. If you go to tansack.com, we got some logos. you know, we we got to be sustainable somehow, but I will never allow sustainability or greed or a passion or growth to actually intervene into the actual code. I am open to and exploring all types of sustainability for Tanstack. If somebody comes to me tomorrow and says, "Hey, Tanner, uh, I will offer you this huge bag of cash and you get to keep Tanstack 100% open source. We will sign contracts or whatever this is. We will not change the open source software in any way and we have a way to navigate that socially with good optics that people will continue to trust the brand. Oh yeah. I mean, why not? I I would love to to take a check and get a bunch of money to all my maintainers. Like I would love to like lock in the sustainability of Tanstack for the next decade. That would be super cool because it would be naive for me to think that open source sustainability is something I've solved. I'm not like we're making it work. We are surviving and we're doing just fine. But to say that it's solved and that I'm not worried about the next year or two years. Yeah. Yeah. That that's ridiculous. So if I had the opportunity and it made sense right now, I want I want to add context here that I've already had offers for Tanstack. I've already had people approach me and offer me lots of money for it, but it was very easy to see from day one that you know what, you're not going to be a good steward. They're not going to respect the open source. They're going to want to get into the source code and say, hey, you know what? What if we made it work really good on our platform? And it's like, okay, you know, this isn't going to work. Thank you so much for joining me today. If you enjoyed this conversation, hit the like, the subscribe button, drop a comment below on your thoughts about Tenstack. And also, if you want to see an interview I did to Dax Red from Open Code, please go to this video right here. I have discussed a bunch of stuff, including his favorite model, editor, and much more. So, click on this video to watch that right now. That was it for this interview. I love you all and see you guys next time. Boo.