[LIVE] TANNER LINSLEY: TanStack Start, React, AI Agents, and More

Uh-huh. Yeah. I fight. Hey, hey, hey, hey, hey, hey, Hey, hey. What's up everyone? Welcome back to another live stream. Excited to see you all again for another beautiful live stream. Today will be all about tent stack. We are going to have the creator here and it will be absolutely awesome. First of all, I want to know how everyone is feeling today. I'm feeling fantastic. Just went to the gym again. My muscles are nice and how everyone is feeling. By the way, we are a little bit outside of the streaming schedule. I do know about that. But you know, just happy to be here today. Oscar for you. What's up, dude? Nice to see you. What's up? Thank you for saying hi. How you doing yourself? Oh my god. 1479. Hey, how you doing? Nice to see you, man. Nice to nice to see you. Excited to be here today, shed, for another conversation. Today we're going to have the creator of Tenstack. It will be awesome. I have done an amazing you know set of 10 20 questions and we are going to talk about all of them today. But you know I want to kind of say a few things to you before we go into that. Um the first thing is that um there is a new video on my YouTube channel. You guys should check that out. Absolutely. Okay. It was one of the very first videos I did literally outside touching the grass and speaking about PHP and Laravel and it was awesome. Check that out if you haven't done that already. All right. It will be awesome. uh you know and uh put the like button if you if you enjoyed it. All right, so that being said, let me introduce you to the guest of today. Chat, please type W Tenner Tener. How you doing today? Nice to see you, dude. Thanks so much for coming. Thanks, man. It's good to be here. Feeling pretty good. Thank you, man. It's so good to have you, man. And before we jump into the interview itself, let's say let's say thanks to the people who make this possible. Of course, Code Rabbit AI, they're absolutely awesome. If you want to have your code review through pull requests, they also do this nice diagrams in your pull request themselves. They're absolutely awesome. Check them out. Code Rabbit.AI, of course, Redberry. International, one of the best digital agencies out there for Laravel and View development. Check them out. Jet Brains, the company behind the best editor in the world, PHP Storm. Check them out. They're absolutely awesome. They have my favorite editor ever. And then obviously serapi.com if you want to have some nice Google search API and you have some JSON results out of Google search they're absolutely awesome check them out as well again new video on the channel check that out if you haven't already and moving to the interview itself chat today I'm here talking with tener linslay the creator of ten stack and someone who have a massive have done a massive impact on the modern javascript in react ecosystem he have also been built many of the tools a lot of people use today like 10 stack query, 10 stack table, t 10 stack router, 10 stack start and many others. Danner again, thank you so much for joining me. I super I'm super excited about this conversation. By the way, I have a lot of questions to you and uh you know I'm also a maintainer myself of open source. You are a maintainer as well. But I don't know if your team is smaller than Laravel. So we are going to talk about all of that as well. Chat everyone typing dub w tenor and moving moving to the very first question of today. Uh Tener, for those who don't know, what is Tanstack and who is the team behind it? What can you say about that? Man, Tanstack is uh open source organization. Uh it's a it's a business. It's also just a a group of cool people hanging out in Discord every day. uh you know we got a lot of open source projects that I' I've built over the years and also some that uh 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 yeah we make we make great stuff. Okay. How many people are behind Tenstock at the minute just out of curiosity? So there are about seven core maintainers, right? Um 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? Uh 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 um you know in varying degrees. Very interesting. Um, Shad, by the way, feel free to make any questions in the process. U, I'm going to listen to every single one of you. You mentioned Tenstack is open source, okay, which is, you know, when we think about open source, we think about free. Well, I don't think about that, but people think about that. So, I want to kind of uh make you a question about this. Do you have any business model behind Tanstack at least to pay a little bit of the bills that you have yourself? Oh, yeah. Absolutely. So, I mean, if you go to tansack.com, you're going to see uh a big fat list of partners. Um, okay. And so, on on the business side, we treat uh obviously there's there's a healthy throughput of GitHub sponsorships that come through to me personally. Um, I I don't need those anymore, which is great. So, all of my GitHub sponsorships are just basically proxied through to all the maintainers. Um, wow. On top of that, we also have uh brand and like marketing partnerships. So all these all these logos we have on our homepage, these are companies that either rely on and use Tanstack in-house 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, you know, 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 are not in trouble. Um, and it's nice because all of our maintainers uh have full-time jobs, full-time gigs, or they're contracting full-time. And if they don't, we're going to get them whatever they want because being a Tanstack maintainer, you know, gives you a leg up. So, Right. Right. That's that's a very interesting model. It's also the model that I believe that open source leaves a bet on because uh, you know, you go at your own pace. you don't have to worry about money and uh you know I have some projects myself open source wise and also leave out of that business model which is just sponsorships every month from people who are relying on it and it works um it really works GitHub sponsors have have helped a bunch on that even though they are down 90% of the time code rabbit in SER API yes you know and they are some of our partners they supported you as well oh nice that's pretty cool yeah I love code rabbit um they're absolutely awesome they just literally renewed the sponsorship with me again for another year and you know they believe in my work and I love them so cool they believe on tenstack as well talking about tenac dude I remember seeing tenstack years ago you know and um at the time and correct me if I'm wrong here but at the time it felt like it was a group of useful UI libraries you know and then literally three weeks ago I said okay I'm going to learn tenstack once again blah blah blah blah blah and I saw tenstack starter or start tenstack start and um you know and it it seems to that you went from you know 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 ten stack 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 um you know we we have all these libraries that we built and many of them are very brown field. You can drop them into any 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. Um, we got a little deeper into the weeds when I when I built the router. So, Tanstack router, I actually started building that five years ago. That came out in 2022, 2023, something like that. So, it's been out for a while, but it was only a client side router. And the the idea was just to build the best client side router that we could, Uh we 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. It was like oh I can't remember what year it was like 2014 2015 or something like that. I I built a framework that was still static site generation framework. It was a lot like Nex.js and and uh Tanac start is today. It was just not server enabled like like at runtime. It was a static site that would become an SPA. Um, and this was before serverless Lambda stuff just took off. So, it kind of made sense. But when I was doing that, I I 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. Um, and obviously I ate those words. So, uh, yeah, two and a half years ago, I decided like I I wanted to build a framework because I was doing more serverside 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, okay. Okay. Yeah, I started building Tanstack Start and that's what start is is it's like 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 and React Router, Remix, whatever you want to call it. Um, yeah. So, and it it's re it's a really viable solution there. Um 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 a lot of 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 um to tenstack you see companies literally migrating the entire products from nextgs 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 but before we go before we do that by the way we have about 60 people watching the live stream right now sh don't forget put go all the way down, click on the like button, also subscribe the channel, type W Tenner if you are enjoying the interview. Um, and you know, um, yeah, I want to I don't know if you can answer this or if you know the answer to this. I think you do, but uh, can you explain where 10 stack or 10 start 10stack start fits when compared with frameworks like Nex.js, Remix, Astro. Uh, what you were thinking in terms of okay, I want to build 10 stack start and it will be different from next.js. GS because of this. So, it's actually very different from Okay, let me let me put it this way. The 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 um and the consistency of how you can get there. So, Tanstack start is actually closer in uh in theory to how React Router Remix worked. Um mostly because it started at a client side router first. Uh which is what makes it very different than Nex.js. So, right, in fact, if you if anybody ever used Nex.js pages router, we're talking back like the old pages router. Um which is great, which is great. It was fantastic. uh 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 we assume that everything is going to end up on the client. 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, tanstack 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 and that 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. Um it it carries through to performance implications. Tanstack start and router are extremely fast. So right 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. So navigations for users going through your application or your site feel crazy fast. Uh they're they're all cached if you visit pages you've been to before. They're instant. So, it's a it's got a really heavy heavy focus on the client. And I would say the next biggest focus is that it's it's type safe through and through and it's it's the only like fully type safe um 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, we're one of the only front-end full stack frameworks that has type safety from top to bottom and it's all inferred. So, you can actually write uh a Tanstack route or use Tanstack and and if you do it right with inference uh you you don't even have TypeScript code in your editor, which is pretty crazy. That was 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 you always end up having to write these explicit types of TypeScript you know what I mean and uh you just have to literally tell okay this will be from this type you know 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 noticed that I actually noticed two things when I tried 10 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 loved that. So I let me let me 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, is I think this is better. Amen. D 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 is because so 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 that's the reality is if you're manually typing things, you're not really doing anything different than if you were just use JavaScript and with your brain, Uh if 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, right, I would argue that, you know, those are not the same thing. It's one is a superset of the other. So yeah, this is one of my biggest battles in the PHP ecosystem. Well, it used to be at least five years ago when first uh when type start to be like um something very common on the PHP code, 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. Like that is type inference. Uh you we have our our own version of Typescript. We just call it PHP stand. And um PHP stand will infer those types for you. You don't need to type them yourself. like you know and uh you know this is a huge battle type this probably a topic for another day but uh yeah 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 nextgs I felt that things were too magical for me you know what I mean and I am a magic person like I love which already has some magic on it in Rails and everything like kind of magic well yeah maybe exactly and nextgs 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 a that was the second thing I noticed yeah we we wanted to build something that was really traceable and transparent so that for every single request you are or a user was making to your page, you could follow that life cycle really easily. Um or or let me say simple, not easy. I mean there's nothing easy about full client hydration and streaming and I mean 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 and yeah, we we wanted it to be 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 t full stack RPCs are are they are magic. their 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 and get into the guts of it and customize it and do things with it that you know, we don't just assume. So, 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 I think it's just as big of a foot gun as use effect because it's it's such a 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 uh 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, Um 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 overabstraction that I'm allergic to. I hate it. So, 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. And that's what Tanstack start is is it's like we have prepared for the 90% use case, but all of the rest of it, the 10% is not just a possible because some of these other frameworks it's not even possible but it's not even possible it's just simple and easy to get to so right and you see it all the way through 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 it um which we need to we need to clear that up because I'm actually writing a blog post right now okay people people missed this in our announcement we support use client like Oh yeah yeah yeah but you have an 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. Yeah. 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 Nex.js has put into them. So, 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. Um, 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, you know, but 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, you know, we support it. We support it because this if 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. Uh but that's not always the case because and it's funny because 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 wants," people just like they don't they don't get it. So uh 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. I'm you know, I saw the explanation of composite components and I was like, well, this is clear for me. Like, you know, this is clear for me. This is literally a slot where you can just have your front end components and I'm going to render this one myself on the back end. So, that was at least it was cool. Stack slots. Yeah. Yeah. Yeah. So, I enjoyed it. stack slots and you and the server parts you can cache granularly. I don't I don't know if you know who Jack Harrington is. He's another YouTuber, but Jack Harrington did a video recently where he was like, "Hey, look, you can cache server components, composite components in a granular way on a like so subpage caching at the request level at the CDN level." So you just add CDN cache headers and you're done, which I've never seen that possible in any other system. So I have another question about React server components. Before we jump into that, let me say let me say hello to Nico, Danilo, Peak and Flow, Dorito, Joanito, a lot of people here on YouTube, but also on Twitch. Uh by the way, Shad, don't forget go all the way down, click on the like button, subscribe the channel if you haven't done that already. Today we're speaking with the creator of Tenstack, one of the most popular JavaScript frameworks. Today we have frameworks, meta frameworks is like such a confusion here, but let's just put it that is one of the is a creator of one of the most popular JavaScript frameworks um uh in the world. And the next question I have here is actually interesting. So when I was like when I saw Nex.js moving this uh react server component strategy as first as first citizen as as being something like components are you know rendered on the back end by default almost. I was like wait a second like you guys had a big advantages a big advantage over something like PHP or or Ruby right because 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 um because the explanation you gave to me of we default to render things on the client and only we only if we have to we are going to render things on on the back end so you can you see any reasoning on this yeah so there's a lot of different camps schools of thought here 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. And I mean that is true, right? That the the less kilobytes of JavaScript you need to parse and 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 right yeah that's important getting the bundle size down and getting to hydrated interactivity as fast as possible. That is that is one of the reasons that server components um can be helpful. 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. uh there's really no point in shipping a lot of bundle size to the client to rehydrate a div. You know what I mean? Like why 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. Um, 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 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 you know a 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. Um the other point I think that that gets a little lost in the weeds is that they they 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 um 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 a bunch of round trips and waterfalls or or even on the server, you you don't 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. So, 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 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. Mhm. And that's that's when you get really deep into stuff like like the next.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 Tanex 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 have we 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 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. Um, so 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 basically. Yeah, 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. It's basically only magic only when you need it basically and I think one good example of magic was actually one of the questions we just saw in the chat was like um if you just default for client side like what happens with SEO and things like that and something I've seen on 10 stack start and correct me if I'm if I'm wrong by the way correct me if I'm wrong but what I've seen is that it's just it defaults to serve SSR if you are going to the page for the first time but if you are moving out of that page within the brow still on the browser it will just serve it on the client Um, so it just works by default. You cannot opt in off this behavior by giving SSR false if I'm not mistaken. Uh, but why would you? I mean, by the way, that's how Nex.js works, too, right? Um, that's how a lot any anything that turns into an SPA. That's how it works. The first request is rendered on the server. The HTML gets sent down. And if you're a robot, then that's the only that's the only part you care about. I mean, yes, Google is running some of the client side stuff. Um, but for the most part, people talk about SEO and they I mean, a lot of people talking about SEO have no idea what they're talking about, by the way. So, I've been I I lived in the SEO industry for a decade from 2013 to 2023. We we built a tool called nozzle.io, which is uh like an enterprise competitor to ahrefs. Anybody who's done SEO out there? So, Nozzle is like an SEO analytical platform where we reverse engineered Google search rankings at scale. Why do you think I had to build all this Tanstack stuff? Because I was very deep into the weeds building dashboards, admins, crazy. Like, there were apps inside of our app just to manage the amount of data that we were managing. And all of it was based around SEO. In fact, I put a link into the chat if anybody wants to go find it. There there is a there's an SEO guide and even an AEO guide for for artificial intelligence. I think I think you might have to send me that that link uh on Twitter. I'll send it to you. Yeah. Yeah. Yeah. And then I will share it cuz u I think guests are not allowed to share links on my shed I think. But uh you know SEO is is uh 90% of SEO is just building the right content that people want to see. But what people are actually talking about when they do say frameworks is they think, "Oh, does this framework support SEO?" Support SEO isn't a thing. You got to be specific. What are you talking about? So, does it does it render HTML without JavaScript? Yes, absolutely. Okay. Then you've just covered a huge portion of what we would call technical SEO. Technical SEO. After that, there is a ton of stuff that you've got to take into account for technical SEO, and it's all in that link that I sent. But there's there's so much stuff there. You can do static pre-rendering. Do you have to do head management for all of your metadata? Performance goes into it. So it's like, does it support SEO? Well, part of SEO is how fast can your website actually run, Core web vitals, Lighthouse scores, all of that goes into SEO, too. And it and it gets deep into the weeds, like are you managing, you know, JSON LD appropriately? Are you exposing canonical links? A lot of this stuff front-end developers honestly don't care much about. Like application developers, we don't want to even have to think about. Um, so I just think it's funny when somebody says, "Does it support SEO?" Because it's a big tell that it's like you don't actually understand the question you're asking. So yeah, everybody should go read that guide. Um, and if you actually care about SEO, you should go and research what technical SEO actually means. Okay. Just by the way, just by the way, Ten Tener, one of the questions I haven't planned, but it just came to my mind, which is which is a which is a you know, it's kind of um just shows how good your thinking is is 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 you know and typically like genius of the genius people of the JavaScript world of the JavaScript frameworks literally they kind of go uh 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 uh tables you know uh which clearly tells me that you build a framework to solve people's problems and I guess your thinking was that as well right? I mean yeah I'm I think I'm like a an sometimes maybe an overly pragmatic person like everything that I built was because I was experiencing a really deep pain about that thing. Uhhuh. Uh, and I 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 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 uh 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 um and it it was inspired initially by NG Grid for Angular. Okay, which is 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 of the 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, Uh and that's how a lot of these projects were were born is is out of just we needed them. Even even the 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 tenstack form which is inertia forms basically. And um 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 SAS at Laravel called Laravel 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. Um you know I want to I want to change a little bit of topics here. Um, a lot of people think may I I honestly think that people here here on the chat also think that a little bit that tenstack is React only. However, from my investigation, Tenstack supports solid as well already and some of the components of the Tenstack ecosystem also support things like Vue. GS and more. We have a lot of Vue. GS people uh on my audience by the way, a lot of people that love Vue. Okay. 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 tenac start. So do you have a timeline on Vue already or not yet? Not yet because we have a lot of fans of Vue here. So we are working on a viewport. It's still early. Um, 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 uh 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. Uh, it'll be tanstack view router. But once we add that, the start pieces are actually pretty easy um 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. Um and then from that core we extend out into individual adapters. So to give you an idea, uh 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. So that's so interesting. Why would you support the whole pine? 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. You know 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. Um, and because of our highlevel, you know, 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, right? 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 like table and 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. uses the same logic to provide virtualization for you know all of the different frameworks. And what's neat is you we manage the state. 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. So I have actually two questions regarding this story of supporting multiple uh JavaScript frameworks. Meanwhile chat uh type on the chat which JavaScript framework is your favorite at the minute it's if it's Vue React or apparently also Alpine GS write on the chat. We want to know more about you. Um so I have two questions here on everything you just said. uh the first one meaning uh being um like what how important is for you to be framework agnostic like 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 I think okay I one I think that it promotes better code like if if you've got UI code specific to a very 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 uh isolation of concerns. So that's the first reason that we do it. The second reason is that no no software is immortal. It doesn't matter what it is. Even Tanstack, the Tanstack, all software, you know, is a means to an end to hopefully someday remove that software, right? We write something, it's it's all temporary. And so, you know, I I hate fashion. I'm not a a fashionable person. My wife dresses me nice. Um, but 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. And I don't think I think that UI libraries and component libraries and you know design styles and all this stuff that every year it's new. I don't want 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 for me I don't want to have a maintenance burden of every year I have to rethink the you know it's like this existential crisis for our software. So that's another reason. And you know what, luckily React has has been um a really good bet for a lot of people for many many years, but even React has it has a runway, you know, and 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. Yeah. Um, just by the way, how you are on time? Because I told you it was 30 minutes, but I'm literally in the middle. You good? Okay. Just on the story of React, I'm going to be honest. Like in 2022 23, I honestly thought, okay, React, I thought React was like forever, but now I think React is over because that 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. because 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. Um I' I've got actually I'm going to post a link. I'm going to find it really quick here. I've got Do you mind sending me that link on on Twitter because it might not be visible. I'm just posting it into the studio chat here. Oh, but uh that I've got a link in there where you can actually go and check out uh npm stats. So, I know there's a lot of npm stat uh little apps out there. The one that we have on tan stack's freaking awesome uh 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. So, that's one of the things that I sent. Um, but re React is wild. If you if you look at any of these charts that that have React over the last, you know, five years or whatever, To have something so big already be hockey sticking. Oh [ __ ] I closed the window. No way. Chat, wait, wait a minute. Wait a minute. Oh no. This is horrible news, chat. Audible news. Uh, horrible news chat. I know. I know. No good. I just hope it doesn't screw the the Oh no. Okay, this is good. Oh my god. I'm sorry. I just It crashed my Chrome. I don't know why. One second. You're good. I see two of you now. That's uh You see two of me? I think it will disappear at some point. Let me just confirm that we are still uploading and recording and we are. So, we should be technically good. We are crunching we're crunching a lot of data on this page. So, I should have warned people that I was sending them to a page that has a lot of data on it. Yeah. Shad, by the way, I will share the link of this page later on because the link is so big it doesn't fit the chat actually. But, uh, React is crazy. It's it's approaching like, you know, half a billion downloads a week. Uhhuh. Wait. Or no, sorry, sorry, sorry. Hold on. That's that's per month. Half a billion per month. If per week it's like 130, it's approaching like 130 million 150 million a week, which is wild. 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. I'm good friends with Ryan Carneato. Um, 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 two or three years out where it's like, oh yeah, you know what? I don't I don't know what's going to happen in two or three years, but a year from now, I got a good idea. Um, no, that's just gone. Like I if 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 two months. And so you know 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 there is one challenge there though um so you mentioned obviously supporting multiple frameworks um and you mentioned why you want to do that which is was super clear uh however as an open source maintainer myself um 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 um I don't really know how those people think. It might be a little bit weird to understand this but you know if I am just as as an example if I am a react developer I know 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 so I'm not 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 um maintain quality across the Alpine integration for example. I mean if you go and look at these integrations they're they're razor thin. Oh, okay. That's that's the reason I mean when I say we have a bulk of the core logic for running 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 trans translating that into the reactivity model of whatever the UI library it is it's using. Interesting. So basically use state on on react whatever it is on view and and that's it. Nothing. Okay. Interesting. Then some of them are a little more involved like with Tanac router you know it's not just a oneliner. We have to 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 um because they're just consuming what's coming out of the core. Um, and for the ones that do require a fatter uh adapter, I mean, 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. We just haven't found that. And so guess what? We don't have spelt adapters for a lot of these libraries. So I 100% agree with you. if we don't have anybody using them, Who cares? Usually that means that there's not enough demand for it anyway, right? It makes sense. Yeah. Yeah. Yeah. Okay. I feel you. Um and especially now, you know, uh especially as Tenstack is so open to open source and so open to contributions. I can see a world where, you know, an Alpine developer gets in charge of maintaining the driver uh for Tenstack. But also like if it's not a huge portion of code, I mean if it's like 30 lines of code like it's not it's not a big birthing basically for you. um talking a little bit about one component that surprised me dude was the tenstack AI because you look at you know 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 yeah you know the story behind that is interesting I was I was at react comp actually last here. Okay. Um 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 chat bot. Everybody's building something with um with AI and they everybody was using the uh Verscell AI SDK, And it's a it's a great piece of software. Um, obviously people love it, but we ran into a lot of people that didn't love it and we asked them why. And they I mean people had a lot of different reasons to why, but there were a couple of like really core there were a couple of core technical reasons too that 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 because 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 AI SD, the Versetta SDK and a couple of them just raised their hands and said, "We want to build 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." Um, and it was initially it was Jack Harrington and LM Tuslac. They I think they went from con like in they had the first conception of of the API that we wanted. They went from that to an alpha release in two weeks or no yes sorry two weeks. So wow 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. Um other other than tanstack DB. No, 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. So that helped us refine the API to a way that that not only humans think is cool like oh yeah full stack type safety on the tool calling and and there's all all this introspectability it's all unified but also we know that AI loves it too because we we developed it with it you know um so yeah it's uh it's nice it's just completely agnostic you know we we think it's got a lot of cool capabilities too also So there were a lot of features that people wanted that it seemed like they were waiting on forcell AI SDK to do but but they didn't know what if they were ever to come. We were specifically obsessed with code mode. Do you know much about code mode? You heard about this? Not familiar with that. Well, I think I know what it is but I'm going to let you explain. Yeah. So the the idea is that it's just a tool. It's a tool call that you can give your LLM, but what it is is you say, "Hey, here is a VM. go write code and and there's a lot of implications to that across a harness and across you know the environment that you're running it in. You have to have you have to have a driver uh different drivers for like a standard interface of how to use that thing. So like we have drivers for you know Cloudflare isolates. We've got a driver for just like normal node isolates if you want to do it like on your own machine. So there's there's a lot of a implications to the API design of that, but we code mode is amazing because in fact and I I hate to rep another YouTube video on your on your channel, but um Jack Harrington has a video on code mode that will probably just blow your mind. I'm going to paste it into this studio chat. Go again. Go. Yeah, go. Um okay. So to in a in a nutshell he takes he takes a process of hey I want you to go and query my database and tell me you know my my total metrics for this thing over the last seven days and then come back to me. So in normal mode, in normal LLM mode, it it orchestrates a bunch of tool calls to go and query the database, bring that data in, and then it uses inference to try and do the math behind it, and it's really slow because it's very serial. And then at the end of it, the math comes out, and it's wrong because LLM suck at math, right? And then he he turns tool he turns code mode on and he says, "Hey, I need you to do this." It goes into the isolate to run code. and it writes the code that's going to perform this task. It writes the code to actually hit the API endpoint and query the database. It it writes the code to calculate all of the calls in parallel. So, it parallelizes a bunch of stuff because it's just in node. It comes back and does real math that's in Typescript and gives him the result that he needed. So, and it did all that way faster and it did it with with 100% accuracy. And then here's the crazy part. He asks the normal mode to go do it again and it has to redo all of that work because it's just an inference loop. Uhuh. He asks code mode to do it again and code mode says, "Oh, I stored that procedure that I wrote for you in in a in a memory." In memory. Yeah. And it's like, if you want the same thing, I'm just going to run that thing again just with updated parameters. So, it grabbed it, ran it again, and came back in like a a couple seconds. It was amazing. it really will blow your mind. Um, so stuff like that, you know, we we have we had a lot of great ideas around what what we wanted to see out of like an open source AI harness. Um, and we didn't want to wait around so we built it ourselves. the however this AI component and also apparently your your passion for solving actual real world products real world problems on products um um seems to me that potentially um that is a bigger vision that you may have for ten stack that we are not seeing yet uh potent so I don't know I don't know if you're familiar with laval or rails probably you are but uh means um basically that's what we call like a full stack framework gives you things like authentification mailing to use database tools, caching, you know what I mean? Database migrations and all those stuff, various drivers for SQLite, uh, Postgress and everything. Do you see a world where potential potentially tenstack starts to adopting some of the um most common needs on the server? No. Uh, I'll tell you why. Okay. Uh I think that you know this starts to get into open source sustainability and a lot of people are like how you know how is Tanstack 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. I mean I can't tell you how many venture capital calls I've had over the last five years. They're like oh man let us 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. We could build 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. You know, we we are good at building agnostic platform level things that 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 well, 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? you know 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. Uh it it just rarely pans out 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've got a 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 that would limit the amount of companies that we can work with for partnerships and sponsorships, right? it 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 staying away from that is one of 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 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 Tansac. 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 or or greed or a passion or growth to actually inter intervene into the actual code. The minute that a line of code gets merged into the open source cores of any TANSAC library that favor something over the other you we are going to lose all trust right so I feel like well I have multiple thoughts on this one right um obviously things can go wrong you know what I mean but obviously also things can go good you know what I mean like I think for example the investment on on Laravel I don't know if you're familiar with that story by the way in case you don't want you are okay so I I think like uh one of the things I wanted to ensure well that I asked Taylor was like how do we ensure that this still feels like community still feels like u you know um that Laravel is Laravel as it is today and um he definitely managed to do it like it's been like already two years and that you don't see you don't see like weird code on Laravel which locks Laravel to a Laravel cloud for example you can literally host Laravel cloud whatever you whenever you want in whatever you want yeah you you you know so you don't get like uh ads on the CLI or whatever. It just really you really it's really cool. So I think you can do it right. I think like you can definitely go wrong as well. You know we have seen cases as well. Um you honestly I wouldn't be surprised that not that I don't trust you but I wouldn't be surprised if you would you know kind of also accept investment in like a couple years from now. Um so I wouldn't be surprised and I wouldn't I I don't necessarily mean think it's a bad thing you know but uh but I feel you. I can tell you this much that I I am I am open to and exploring all types of sustainability for Tanstack. Exactly. Including you know 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 sign contracts or whatever this is. We will not change the open- source software in any way and 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 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 for me to it would be naive for me to 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 could 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. Right. Right. 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, you know, and and it's like, okay, you know, this isn't going to work. So, um yeah, I've already passed up opportunities like that in the past, and it's really easy to pass those up because I I feel a sense of obligation and duty to the community and my maintainers. Um but no, I'm I will not pretend for one minute that like, you know, money doesn't matter and sustainability isn't important. You know, it if I if I hadn't made any money off of Tanstack up until this point, I would not be where I am today. You know, there's there's a reason that Tanstack is growing and that the main that our maintainers are happy and that we're all having a lot of fun is because there is money involved and we're doing fine. There's a lot of people on the chat. Anybody that says otherwise, anybody that says otherwise is just selling you something weird like it's a real problem. Uh by the way a lot of people in the chat mentioning that it would be really nice to have a lot of val 10 stack integration. So at Lavl we have this thing we call starter kits and those starter kits work very well with inertia in react inertia in view and inertia and spelt now as well. Um it could be potentially starting to explore and I'm going to I'm going to I'm going to make sure this that happens. We have a p and then I'm going to show you the p to let you know what you think about uh potentially a lot of val. There's already a lot of people there's already a lot of people in our discord who are who are running inertia as their API as their as their back end and who are using so as the yeah they're using Tanac start as the backend for front-end layer and you know what that that's an interesting angle because I came from a world where like it would be ridiculous to think that you're going to build and scale a a huge backend system in JavaScript. Like I'm I'm pretty firmly of the belief that you should just not use JavaScript or TypeScript on the back end. Now I say that for like real backend workloads backend for front end or like this middle ground area where it's like you know you're you're writing JavaScript to communicate with your backend APIs and some of that might happen on the server during SSR. They call this kind of a BFF like backend for front end. This this is the way that is the way to go forward because I I mean I spent 10 years at a company where all of our stuff on the back end was written in Go, you know, and that's the reality at a lot of these at a lot of these really sophisticated products and businesses is that you're not writing stuff in JavaScript on the back end. And if you are and it works, then that's cool. I respect you. you should probably you be using tan sex start for type safety or something like that. But I I just I think that um anytime that I hear somebody say, "Hey, I I want to use, you know, Laravel or Inertia with Tanste Start. Can I do that?" And I'm like, "You should do that. You should build your backend in whatever language you think is is best for the back end." And then when it comes to front end, Tanstack's going to be there for you, but not try to control everything that you do. Oh my god, this will be such a good short. It will be so good because ju just because you know we we we we we obviously believe a lot in a lot of ecosystem and we believe Laval backend is actually super good and uh you know uh but moving forward a little bit here. Um I have a by the way one of the questions in the chat is that and if you can answer quickly is have you ever used PHP and Laravel before? Not Laravel. So so I actually started in PHP way back in the day. Okay. Um, and then and I got really into WordPress and building WordPress plugins and and building custom PHP stuff in school and college and whatnot. Um, but eventually I I got out of that and and you know the last framework interaction I had in PHP was with Cake PHP uh through some of my co-founders back in the day. So, um, I didn't quite make it to to Laravel, but I have I've kept my tabs and my eyes open on it, and I'm I'm aware enough to know that I I think it's a great piece of software. So, it is it is it is uh moving a little bit here to a question that I have personally I had actually that question during my live stream. So, at Laravel, we have something called the Laravel boost, which literally gives AI skills to let AI know how to work with Laravel with good conventions. How should he write the code? How should you write modern code and etc. In Tenstack, do you offer anything close to this? Yeah. So, the the the node world is weird and but and it's different. So, everybody's but but there are some similarities there. So, we're everybody's talking about skills, right? You've got to you want to distribute skills for for your agent to know to know how to use it. So, let me go through the different layers of AI with you. I'll I'll be really quick here. So the first layer that everyone should be thinking about is type safety. So if you if you're using an agent harness that is worth its that is worth anything, it's going to have LSP integration. It's going to hook right into the language service provider and it's going to know exactly what's happening every tick of the way. Which is why having actual type safety, not just TypeScript, but actual type safety is not just going to make it easier for you to write, but it makes your agent better. It helps like and and not even just safety, but we actually encode the best practices for using all of our libraries into the types so that the types actually steer you into the pit of success. So type safety is the first layer of defense. We can make sure that your agent is doing things correctly before they even compile uh before they even build for production. So the next step after that I think there's a lot that goes into training data that's becoming less of a deal of a thing but having good documentation is obviously the next thing and and TANSAC docs are nowhere near perfect. We're always trying to improve that. Um but something some some of these new things are really interesting to me. So skills are really interesting right now. I don't know if you're part of the npm ecosystem you're probably aware of something called skills.sh. Yep. I'm familiar. Yep. Skills.sh really cool idea. I resp I respect them for coming up with this idea and shipping early. But man, I do I think that there is something very wrong with this implementation. And I'll tell you why. Because if if you go to skills.sh and just type in tanstack, tell me what you see. You're going to see steel enough ones. No, you're going to see a page of of skills repos. And none of them are from us, None of them are from Tanstack. And even if we did publish our own skills on Skillssh, we would now have to compete with the 5K installs of Decar Dearger/Tanstack agent skills, Tanstack best practices, whoever this guy is, he's not the authority, you know, And so this is a provenence question. This is a question of trust, distribution, and registry. So what skills.sh has done here is they've created a new registry. And that registry is going to suffer from the same problems that every other registry has, but it's not found. It's not founded on the same principles as something like npm. So where's the versioning? You know, where where's the the security providence? How can you trace that something was published that when it was updated? How do you even update? Right? you've got to use npx skills or whatever. And this isn't this isn't uh specific to skill set.sh either. It's any skills registry is going to end up reimplementing the same problems that every other registry has ever implemented themselves. So we at TANSAC we asked ourselves why would we do that? Why don't we just use npm? We already have npm so let's just distribute skills through npm. And then the problem was well how do you get your agent to find the skills in npm? that doesn't really exist yet. And so that's what that's what we built. If you go to tanstack.comintent, tanstack intent is a CLI uh package for both for library authors to make the skills in their npm modules accessible to intent and for normal users to install into their agent harness that will let it look up skills from npm. And you know what's cool is someday agent harnesses might just make this uh might just make this not needed anymore, right? Maybe they'll just say, "Hey, you know what? We automatically scan your npm modules and look for skills." But today they don't do that. So we built a little CLI to do that for us. And what this does is it means that if you install a Tanstack library and you're using intent, you've got the skills. And if we upload new skills to Tanstack and to to if we upload new skills through npm, as soon as you upgrade your npm dependencies, you get the new version. And that's the thing is they're versioned and they're they're as secure as you can get for a package manager. You know, you know that the skills you're getting from npm are just as secure as the code you're running from those modules. So, and you can invalidate versions. Yeah. Yeah. Right. So, there are a lot of new ways to get AI to to write code really well. Um, and and I'm surprised at how well AI does with Tanstack. I know that a majority of it is because of the type safety, right? But even on top of that, all of the stuff around training data being a thing and and skill distribution is kind of getting solved. Um, I have tons of people now that are oneshotting Tanstack sites. They're oneshotting apps. They're oneshotting migrations from Nex.js. Um, you know, they're they're building really complex stuff. For the last four or five months, I have not been writing manual code in on on my projects that use Tanstack. Um, does it mean it's the prettiest? No. But it's type- safe. I know it's going to compile and I know that it's following best practices because they're all encoded into the system. So, my confidence levels are pretty high. Right. As long as the output is like a good one, you know, um, and if it's type safe, if it compiles like, you know what I mean? That's one of the discussions I had like with people regarding like AI in general is like, for example, if you look at PHP is obviously written on C, right? It compiles down to C or whatever and uh or assembly or whatever. Like do we really care about the aesthetics of the compiled code or even the performance? Like as long as it's like super fast, do we really care? We just care about the output really, you with tenstack is probably a little bit different. You want to follow like the good principles so it's fast on the browser and blah blah blah. But I feel like probably for developing this real quick website that you need for providing something to your family or whatever it's like more than enough to ask AI to just do it with Tanstack if it's if it compiles good if the outcome is good enough basically. Yeah. And then we want to cover all the bases right. So like if somebody wants to use Tanstack to build something personal software Yeah. right it's good enough. Uh but we also need to make sure now that for the crazy huge companies that are going to be deploying Tanstack at scale over the next six months or whatever, right? That it's going to be able to handle the brunt of scale. that it's going to be able to handle all of the requests per second during SSR and that when you know when you get into applications that are hundreds or thousands of routes or that you've got you know millions of lines of code that the type safety doesn't buckle and that the performance on the server stays really snappy and that page navigations on the client stay really really fast. Right? Right. So, I mean there there's a full broad spectrum of of performance implications that you need to be aware of and making sure that AI can fall into the pit of performance is is really um something I think we should be paying attention. So interesting because we at Laravel and then I want to move forward to the to the end of the conversation but just just to finish on this topic at Laravel we actually solve the same problem as you like the intent thing it's literally Laravel boost that we have it's called Laravel boost does the same stuff versioning skills and blah blah blah blah um we also ship conventions to make your code not only doatic but like fast secure blah blah blah blah blah and um you know it's it's interesting moving a little bit to the end of the conversation because I want to be respectful about your time I have two questions and then a Quick game at the end. Uh, this I'm good on time. You're good on time. Cool. I want I'm curious about we just talked about AI. I'm curious about your personal agentic workflow at the minute. What is your mo What is your favorite model? Are you using more than one model? Um, what do you…

Transcript truncated. Watch the full video for the complete content.