954: Fullstack TanStack! The Scoop with Tanner Linsley

Welcome to Syntax Today. We are live at GitHub Universe and we have Tanner Lindsley in the box. Look who we found. Yes, look who we have here. Wandering the floor. Hello, hello. Taking all the merch, drinking all the drinks. I don't have that low. You know that low range you've got? Yeah. I do. I don't have that either. I'm jealous. What's up? Now I got the... Hey, guys. You like JavaScript?

Hey, I've got some cool JavaScript tips for you. Wow, that's great, guys. So Tanner is the creator of TanStack. Everything. You've probably used Tansac Query. Almost everything. Tansac, almost everything. This is the first year that libraries are out that I didn't create. You haven't even touched before. Yeah. Wow.

It's more of a TanStack team now, right? Yeah, absolutely. You guys got like lots of fun. We had Corbin on the podcast maybe a year, year and a half ago, and he was telling us about how you write libraries to work with multiple. Things. Yeah. Yeah. It's so funny. Yeah. When I talked to Corbin at the thing, I was like, I think it was about like four years ago we had you on the pod. I looked it up. It was 2024. I'm like, oh, okay. Four years ago. Yeah. Time flies. Yeah. Right.

Since we've last talked, I know that you're cooking on stuff right now and we're going to have you on for a proper podcast. Well, we thought we would just grab you into chit chat. But like you've been you've been cooking, right? What have you been working on? Yeah, we've been cooking some fun stuff. I have been heads down on Tansac Start.

And router lately. Me and Manuel Schiller have mostly been working on that. Sam Willis and Kyle Matthews from Electric have been putting a ton of work into TanStackDB. Oh, so that's your like sync engine.

local yeah local first Scott absolutely loves this stuff oh yeah we were talking about it last night yeah like if I wasn't doing router and start yeah I would be working on that because I'm just so excited about it tell us about about like what that is so it it is like a sync engine but it's only it's only the client part of it so you you set up what we call collections yeah and they're basically tables

And you can then query those collections using queries and text that you're used to from like Drizzle. It's a first class query engine. You can do joins. You can do where clauses. You can do really fun, tricky things. And that's all powered by this differential data flow system behind the scenes in the browser. So it's really, really fast to run these queries on these collections. Okay. But those collections can be powered agnostically.

So you could shove data into those from React Query, from WebSocket, from IndexDB. So you can push data into these collections from anywhere. Okay. So it's like you get to start building your own sync engine. which is what makes it incrementally adoptable, which is very important. That's what we were talking about with Xero, which is what I'm using for everything.

You have to have either your Postgres set up already and be committed to that, or you have to build from scratch. So that incremental adoption.

pieces much more difficult. Oh, man. With the syntax side, it wouldn't be possible because we're not on Postgres unless, yeah, we move to Postgres. One of the benefits, if we peel back, one of the benefits to TanStack query is that you just needed... on a sync function you know and you didn't it's not like it had to be a fetch call not like it had to be this like weird signature or whatever it just needs to be a synchronous function and pass that you don't give a shit

how what happens is that the same thing with the sync engine same spiritual idea yeah you do need a little bit more so yes you need async functions to you know you need to be able to push your data into the collection And that can happen through a REST call setup you've got. You can use React Query to push data in there. Or you can set up a socket or a live stream of events coming in.

So that's the first thing you need is to be able to push data in. The second thing you need is it is schema based. Because you need to be able to have strict type safety, but not just that. You need to be able to query this stuff like a table and do joins on IDs and joins on things. So it takes a schema. So it's not relational, but you can treat it like that.

So let's see, data, schema, that's really it. That's all you need. And I think one thing that people really don't realize is just how transformative that speed is. can be when you're working in these local cash systems it is so fast and i i feel like i'm always constantly talking about this yeah and like a year from now people are going to be like

I feel like you've been so early to this stuff and not everyone realizes how good it is. Because it's so shockingly fast. That's why I'm excited for the Tanstack DB. I'm excited for this incremental adoption. I would love to use it on Syntax.

And just know that that speed in which you're able to load things from your local data cache with syncing happening behind the scenes or whatever that process is, is... transformational what does the actual syncing look like you know like i understand like querying you're pulling data down but like what happens when you need

To have a mutation or whatever? So the transaction, there's a transaction framework built into it. Okay. And a lot of that is automatic. So when you work with individual collections, you're doing an insert or a deletion or an update. a lot of those transactions are managed for you around these common actions you can take. And all you have to do is supply the implementation details of those common actions. And you can also create your own.

But like insert, update, and delete, you just supply the implementation details for those. So you may have a collection that's powered by a really old crappy REST API. Yeah. When you call those three functions, you got to go in and actually make a fetch call with the data and do the thing, right? But once you set that up one time...

You can then go back to your business logic, your application layer, and you can interact with that collection as if it's synchronous. You can just mutate properties. You can delete and add things. And behind the scenes, it's batching and doing all those.

fetch calls for you. And that gives you easy control over permissions and stuff like that because you're not changing your API, right? Yeah, that's a problem that I know Xero has been trying to solve in different ways of permissions, of which if you're not having to... adopt a whole new thing, right? You're just using your API. And I got to rep Electric, which is where Kyle and Sam are from. Yeah, Kyle's been on that for a while now. But by using long polling.

You get to reutilize all your normal authentication flows because it's just REST. It's just HTTP, right? So you don't have to invent something new for sockets and go through that charade. I'm excited to try that out. Let's switch.

gears a little bit. Next.js last week launched. Next.js 16 launched a workflow with the use workflow directive, which is a little bit magic, right? I haven't really caught up with what everybody's saying about it, but I know you've had some thoughts on it. Can you?

Give us the scoop as to what you think about that. The workflow stuff itself is actually really exciting. Yeah. Like we've got to be honest with ourselves that like durable execution is really exciting. Yeah. No matter what you're using. So like. Maybe pause just for a second. Like the idea with the for the audience listening, the idea with a workflow is that you can like you can have an async function and you can just like pause that function for.

42 days yeah or you can have like multiple steps or you can say like come back and sleep for 30 minutes and come back and check if this thing and it's really cool like i'm i've used cloudflare durable objects and their workflow big fan of that and like all of your memory all of your

variables all of that sort of just like is reinstated there's like ingest there's a couple of like other startups in that space so it's It's great, especially for agents where you're like, come back in half an hour, but you don't have to like save your variables to database or anything like that.

seals it up but it's a hot space yeah and it's useful it's really cool to do that yeah and if you want to see all of the errors in your application you'll want to check out sentry at sentry.io forward slash syntax you don't want a production

application out there that, well, you have no visibility into in case something is blowing up and you might not even know it. So head on over to century.io forward slash syntax. Again, we've been using this tool for a long time and it totally rules. All right. I think the interesting part that kind of was trending a lot on Twitter and social media these last few days has been around their usage of directives for kind of setting that up. And on one hand, you look at it and it's like...

It does look really innovative. and cool to be like, oh, look what you had to do with these other APIs and nesting things and functions and setting them up to be resilient. We've replaced all that with just these kind of magic directives. So on one hand, it does look really great. And man, it sells well. Even when I saw it, I was like, oh, wow, that looks really cool. But for me personally, I think that we kind of have a directive problem.

We're getting a little obsessive about using them for everything. So I decided to collect some of my thoughts on directives in general, not just about use workflow, but just about all the directives that we've kind of chosen to adopt over the last couple of years and put them into. a little blog post that I did. So, yeah. And like,

Give us the cliff notes of that. Like, what should we be using instead of these magic directives? So from my perspective, people are saying that magic directives are the way to indicate that some kind of transformation is happening under the hood by a compiler. And I would say that we've actually been doing that for a long time without directives, with just functions and other things. JSX. Yeah, JSX. And for me, I'd say, you know what, let's use...

Sure, let's invent ways to do compiler tricks because it's all tricks. None of it's real JavaScript. So if we're going to invent tricks, my opinion is that they should at least be future-proof. for type safety and especially room to grow because I actually messaged this to David Kershied today and I said, hey, I actually thought of you because directives are kind of like...

the use state Boolean of compilers, right? And I know that he would be like, oh my gosh, use state Boolean. Yeah, that's David K. Piano. You say anything about state machines, he arrives. But in the same spirit, a directive is kind of just like, this boolean you only have the one choice it's either there or it's not yeah and and if if anybody wants to try and expand that into okay well now we have this special

colon syntax. Now there's directives, but there's also magic functions that change how those directives work. Directive arguments. Right. And like, okay, we're starting to invent... javascript again right and in that case i would just say well why don't we just use wrappers maybe they're not pretty and maybe they maybe they don't scream hey a compiler is doing something here yeah but at least they're type safe they're traceable

they have an import, you can follow them back to a spec. Hopefully, you know, even JSX looks. Pretty magical, you know, but you can go and say, oh, well, what's the pragma being used here? You can trace that pragma back to, oh, here's the actual transforms that are happening under the hood. So, you know, there's been a lot of talk about creating standards.

and wanting to share work across the ecosystem. And I love that. And there's, there's some leeway in personally, like for things like use server and use client, you know, I like the spirit of that, like trying to share. and make it as useful as possible for everybody. At the same time, I'm building a meta framework and I'm not using use server. We support it. We support it, but I don't want to use it because I want.

type safety and I want all this nice stuff. So, you know, I'm kind of on the, on the team of like, If you want to try and create standards, that's great. Let's make them open and make them easy to customize and safe. But I just feel like going down this directive route is going to create a lot of standard proliferation. Yeah.

And I don't like that. Yeah, that tracks for sure. Cool. We'll link up the blog post below and people can check it out. Yeah, sure. Love hearing that. What other spicy takes you got? You know, we're working on...

react server component support okay for tansec start and we're going to support the normal flavors of server components how everybody wants to use them But we have kind of a special take on server components that I think is going to be a little bit unique. I'm not going to share too much because we're still in the prototype stage. We know that it works, but we just don't have it ready to show off.

The teaser is that we've been talking about server components for a long time now. But in reality, what they really are, or what we've seen, is server elements. When you think about returning a server component from Next or wherever these days, you're not returning a component to the client or, you know, to render. You're returning an element that's been rendered. Yeah. And I've always had this dream of being able to actually send a component back to the client and render it with.

slots and inversion of control. That inversion of control is so important to me because I don't like to assume that the server knows how to do everything. I want to be able to send it a task. to do this thing on the server that only it can do on the server, but then come back to me and let me continue to do things on the client that I want to do. Okay. Fill in the little, fill in the, fill in the gaps. Yeah.

Just from what I said there, you can probably put the pieces together, what we're working on. But it's going to be a different implementation of server components than I think a lot of people are used to. And it opens up a path to using server components that doesn't require the use client directive for a majority of use cases. There's still use cases for that.

Man, yeah. And it does feel like there's so much momentum behind you and your projects right now. Does that feel, is it reaching you in that same way that there is a lot of... heat on what you're doing, positive heat? Yeah, and it's exhausting because a lot of it... I mean, I know that we've written some blog posts and we've put some new projects out there, you know, but a lot of it feels like it's being thrown at us from social media and the community.

Like, I'd say 95% of the stuff that I've been reading on Twitter is just coming from random people that we've never met or anything. They've just decided to... use Tanstack as this podium to speak their thoughts, which is really cool. In some regards, they're doing our marketing work for us. On the other hand, it makes me nervous. I want to make sure that...

it's a positive spin that people are being nice and kind and upholding what I would call like the tan stack tenants of, you know, always making sure we're, we're being nice and, and being positive. That's great. Yeah.

What else, Tanstack? Is Tanstack CMS one day? What are the areas that you would love to touch and something that you will never want to touch? I do not want to make a CMS or an ORM. No, 10 stack ORM, okay. We do have one more library that we're prototyping right now. It's in the very early alpha, like pre-alpha stages. Okay. But I cannot say anything about it. What area is it in? Me and Scott are going to guess. I can't even hint to it. Somebody in the comments will know.

Please go in the comments below, drop what you think it is, and then find the ones and upvote the most ones. But I will say that we are working with a lot of people. in the community. So usually we'll just build something internally first. And then we'll just like, here, we built something new. This project has...

big scope. A lot of people are behind it from outside of the TanSec community. So we've got a huge working group channel in our Discord with a bunch of people who have been invited to this work interesting yeah fan stack format fan stack v plus plus but but we think it's we think it's going to be very foundational um something that i think People have asked us even saying, we would like you to have this. We would like you to build this. And I ask them why. And some of it comes down to ownership.

They just trust us to do the right thing with software. And some of it is technical. A lot of it is technical where it's just like, hey, we're using this tool and it gets the job done. But it's kind of the only choice we have. It could be better. And we think that the TanStack... It's a bundler. It's a text editor.

We're just going to, yeah. 10 stack code. I'm just going to say sure to all of that so that there's a bunch of... 10 stack agent. So that there's a red herring in there for basically everything. It's got to be a... A bundler with AI built into it. A bundler. Tansac Sparkle. Yeah, it's Sparkle. Tansac Sparkle is coming. Cool. Well, I'm really looking forward to that. All right. Well, thank you so much for coming in. Appreciate it.

have you back on the show once you've got some more to say. You bet. Thanks so much, Tanner.