TanStack: A Deep Dive into Server Functions and Routing with Tanner Linsley - JsJ 667 - JavaScript Jabber

Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Speaker 1 (00:05):
Hello, everybody, Welcome to another exciting episode of JavaScript Shabber.
I am Steve Edwards, the host with the face for
radio and the voice for being in mine. But you're
stuck with me as your host today. With me on
our panel, we have mister Dan Shapiro.

Speaker 2 (00:19):
How are you doing, Dan, I'm fine, Hello from Tel Aviv.

Speaker 3 (00:23):
Where it's probably really warm, right, well.

Speaker 2 (00:25):
Not super warm, but nice. You know, you can wear
a T shirt outside if you like.

Speaker 1 (00:31):
Right, Yeah, I was just I'll diverge a little bit here.
I was just in Thailand, been gone for a couple
of weeks. Was visiting my daughter there. And in Thailand
it's really really warm. It barely gets below seventy fahrenheit
during the year, even at the lowest point in the year.
And on the way there we got so I dressed

(00:51):
for Thailand, right too close for Thailand. Well, on the
way there, we got delayed in twenty four hours in Soul, Korea,
And to say it was cold is the understatement of
the year. We went from I told when we left
Seoul and went to Chang Mai, we went from twenty
two fahrenheit to twenty two celsius because it was.

Speaker 3 (01:13):
Like below zero cold.

Speaker 1 (01:14):
It was so cold we tried to go for a
walk one day and lasted about three minutes and said, okay,
we're going back inside. So but yeah, chang Mi was
awesome because we had it was like in the eighties fahrenheit,
you know, no humidity. This is the coolest time of
the year, coolest in terms of temperature. Not because I
was there, but but yeah, it was perfect, perfect weather.

(01:36):
And then I came back from wearing shorts and no
code all week to bundling up and having multiple lets
on the bed.

Speaker 2 (01:44):
So tel Aviv is not in the eighties, but it's
in the high sixties, low seventies.

Speaker 3 (01:50):
That's still pretty nice.

Speaker 2 (01:51):
During the day.

Speaker 3 (01:52):
Yeah, that's nice.

Speaker 2 (01:53):
Night night it gets a bit colder.

Speaker 1 (01:55):
And then also on our panel, we have mister aj
how are you doing, aj Yo yo?

Speaker 4 (02:01):
Coming at you live from the show room, So.

Speaker 2 (02:05):
It's better than the alternative, Yes.

Speaker 3 (02:08):
Coming out you dead? Yes, I agree.

Speaker 1 (02:11):
So, and our very special guest today is mister Tanner's
Wensley of tan Stack fame.

Speaker 3 (02:17):
How you doing Tanner?

Speaker 5 (02:19):
I do you agree?

Speaker 2 (02:21):
Yeah, I'm very excited.

Speaker 5 (02:22):
To be here.

Speaker 3 (02:23):
All right, it's good to have you back.

Speaker 1 (02:24):
We had have had Tanner here in the past on
JavaScript Drabber on episode what was it Dan?

Speaker 3 (02:30):
I forgot the number.

Speaker 2 (02:31):
Oh I think it was episode five seventy eight.

Speaker 1 (02:34):
Five seventy eight talking about the tan Stack. And for
those of you who might be wondering, this is a
question I asked on the previous episode. It is not
called Tanner tan Stack because he is tan, because if
you look at him, he is obviously not very tan
like me.

Speaker 3 (02:50):
It is tan because of Tanner.

Speaker 1 (02:52):
So for those of you unlike me who made that
logical jump, good for you.

Speaker 3 (02:57):
But some of us aren't that smart anyway.

Speaker 1 (03:00):
So we are here ten day to talk about Actually,
before we get into start, let's uh just give a
brief description of what the tan stack is overview for
those who might not have heard of it before.

Speaker 5 (03:14):
You guys are gonna give that, right, not me.

Speaker 3 (03:18):
Yeah, yeah sure. Let me pull up the about us.

Speaker 2 (03:21):
Page and you'll do it. Thank you, So do it
if you want to.

Speaker 5 (03:26):
But I appreciate it. I got it. I'm just playing
with you. No. I started tan stack as like an
open source GitHub organization a couple of years ago to
start collecting all of my libraries that I was building.
It started with uh React table and then React query

(03:47):
that we took both of those agnostics, so they became
something that I didn't want to have to like brand
you know, every framework times every library that I had.
So I decided to call it TAN stack, and so
I pulled all those libraries together and then we kept building.
So now there's a there's a virtualization library called tan

(04:08):
SAG Virtual. We have some libraries that are for like
helping you build open source packages. We have our own
store now or reactive store. Tan sac form is an
agnostic headless form library, which is pretty sweet. It's almost
one dot zero, which is pretty pretty cool. What is that?

Speaker 1 (04:29):
Is that like a form rendering library where you provide
the underlying structure and it renders the form or what exactly.

Speaker 5 (04:35):
Yeah, so it's more around just like the state management,
the validation and the form life cycles for forms, like
for doing client side and full sack forms, but it's headless,
so when it comes time to render those forms, you
attached the form logic to whatever you want, whether it's

(04:55):
like a component library or just a raw input something
like that. Yeah, So it gives you full control over
you over your UI, but gives you all of the
nice logic and validation and management of the form state
that you would expect.

Speaker 2 (05:11):
That's cool.

Speaker 5 (05:12):
Yeah, Corbyn correctly is the one who's kind of heading
that up. We combined our libraries together. He was building
I can't remember when he was it's been a while,
it's been about two years, but he was building a
form library that was supposed to kind of be the
next version of Formic, but it was React only. And

(05:35):
then I was building one that was really really type
safe and agnostic. So we put them together and that
became pan sac form.

Speaker 1 (05:42):
The according to the description, it helps you, quote stop
crying over your forms. So obviously obviously you have experience
in working with forms.

Speaker 5 (05:50):
I don't cry too much, but if there's something that
would make me cry, it would be building forms.

Speaker 3 (05:56):
Yeah.

Speaker 2 (05:57):
By the way, are you familiar with the VEST form validator?

Speaker 5 (06:02):
So what validator? Sorry?

Speaker 2 (06:03):
Vest?

Speaker 5 (06:04):
No, I'm not.

Speaker 2 (06:07):
It's greaty. We actually had the creator own of hotel.
He's uh, he works at Meta, but it's it's his
own project. It's it's interesting in that it does form
validation in a way that looks very much like unit testing.

Speaker 5 (06:23):
Interesting. Yeah, I would love to look at it. That
sounds cool.

Speaker 2 (06:26):
So it's called best Okay.

Speaker 1 (06:28):
Needless to say, he's you hear this coming, very invested
in it. Sorry, that was just hanging out there. I
had to grab that one.

Speaker 5 (06:37):
Oh yeah, months of all so that so form is
kind of another one we're working on. And then obviously
the last so a year ago we did one dot
zero for Tan sac Router, which I'd been working on
for several years before that as well. And now we're
here to talk about start, which is.

Speaker 2 (06:59):
So before before we go there, I noticed that you
have a few more things on the ten stack site.
You've got ten stack ranger.

Speaker 5 (07:07):
What is that ranger is? It's not used as much
in my opinion. It's a fun little library from my past.
But you can use it to create multi range sliders.
So if you ever use the range element, you've got
that single slider. Yeah, we needed some that had both

(07:29):
handles that you'll kind of see for range slider selectors,
and then we even had some that would create steps,
so we'd have like three or four different handles on
an individual range input and you'd be able to kind
of create different steps using different handles. So it's a
headless library to create those we wanted it to have

(07:50):
a very custom UI. I don't use it as much
anymore admittedly, but it's still a pretty cool library.

Speaker 2 (07:58):
And also ten stack configure.

Speaker 5 (08:01):
Yeah, the the config is what we use for publishing
all of our libraries. So it it helps us both
build all of the different versions like ESM and common JS,
like legacy and modern versions, and it helps us publish

(08:22):
those to tan SAC using or to NPM using kind
of our It's it's based on Angular semantic version ing,
but basically lets us do all of our pr automation
for releasing new versions and whatnot.

Speaker 2 (08:39):
Cool. Okay, So now back to ten stack start.

Speaker 5 (08:46):
So start is I'm going to be honest, it's like
ninety percent of start is just tan stack router. Because
routers are frameworks, there's not really any way around that.
But we decided, I decided to build the router first.
That's just like a client side router that would have

(09:07):
some SSR utilities on top of it. But then trying
to put together your own SSR environment really sucks, which
is why like meta frameworks as we call them exist.
So tansec start is like the official implementation of getting

(09:28):
server features into a tanseac router application that mostly includes
so you get SSR, which is the very first thing
which most people want. It gives you streaming on top
of that as well, so all the new streaming you
know APIs that React has for suspense and just being

(09:48):
able to stream data down in responses in general. And
then it gives you bundling for both, like for all
the environment, so it bundles the client side the server
SID and it also bundles for server functions, which is
it's our version of being able to access you know,

(10:10):
all of the server features that you would expect. But
so that's where it gets a little interesting. I think
we could discuss that a little bit more. But server
functions are really.

Speaker 2 (10:18):
Cool before we get to server functions, which I would
definitely want to discuss. RPCS is a favorite topic of
mind and I actually had an episode on jobscript Jabber
when I spoke about our PCs. I don't even I
don't remember the number off the top of my head.

Speaker 3 (10:37):
What about it? I would check both places.

Speaker 2 (10:40):
Yeah, that's true. I think it's worth mentioning though, because
I think we kind of skipped it that all of
your libraries, utilities, frameworks, whatever, they're all built on top
of React. Right, there's nothing like that. You don't you
haven't implemented your own view framework or whatever it's supposed

(11:03):
to be called.

Speaker 5 (11:04):
No, they're not built on top of React. We have
React adapters for all of them. So every single one
of these libraries is in fact called tanstak something because
it's no longer just React. So, for instance, tan sac
query has adapters for React and view and spelt and

(11:27):
solid tan sac Virtual has adapters for all of those,
and SODA's tan sac form and table. Tan sac router
is the only one that is currently React only, and
that's mostly just for our own sanity's sake right now,

(11:48):
basically because we just wanted to get all the way
finished from you know, zero to one dot zero on
one framework. We're still preparing the code base and writing
it to the agnostic but we're just not trying to,
you know, do too much at once.

Speaker 2 (12:06):
You think it's really doable. I think I spoke with
Ryan Carneiato while back where he told me that I
think it might have been him. Maybe I'm confusing him
with somebody else, but I think was probably him, and
he probably said something along the lines that he came
to the conclusion that writing a true multi framework router

(12:28):
is bordering on impossible or something.

Speaker 5 (12:32):
I've recently changed his mind. So he had some concerns
and so did I honestly, and we got together and
we we've been talking for I mean years, we go
back a long time, and we've been chatting a lot
about this, and recently he he's like, oh, you know what,
with our new Solid two point zero stuff they're working

(12:54):
on in the new async data primitives, there's really no
concerns anymore. It's just opinions on top of routing and
life cycles for navigation. So really what we're going to
do is actually I'll let you in on some fun news.
So it's nothing. It's something official and it might might

(13:15):
never become something official, but behind the scenes, So the
Tanstack Start and the Solid start team we're working very
very closely now on a lot of things. So mainly
one is that tansec Start and Solid have both been
based on Vinci up to this point, which is awesome.
It helped us get to where we are today.

Speaker 2 (13:37):
But to.

Speaker 5 (13:39):
Better consume Nitro and to even further align our architectures,
we are we are moving away from Vincy to just
a unified layer for start essentially, and it's just going
to have some server function plugins on Nitro coordinator and
that's going to set this stage four tan stack router

(14:04):
for solid, so solid router, and that's that's not nice
that that is a semi active development. We have some
people who are you know, we're separating some of the utilities.
We're making sure that you know, we're not mixing up
framework types and getting ready to build these adapters. But
essentially there's nothing blocking us now if we want. If

(14:25):
I wanted to divert all my attention to solid router
and solid you know, getting that working and solid, I
could do that today, but I'm not going to do
that till we get the REACT when done.

Speaker 2 (14:35):
So question about that. You threw out a whole bunch
of project names, some of which are familiar with, some
of which less. So Vincy Nitro also as I recalled,
Vinci is built on VAT. Yeah, so can you tell
us a little bit about all these projects?

Speaker 5 (14:53):
I would love to. So let's start at the let's
start the bottom level. So all of this is based
on beat where one hundred percent bought into the VAT ecosystem.
I believe it's I believe it's the future. So we
wouldn't be able to do any of this without Beat.
And at the end of the day, a lot of
this boils down to just VEAT and Beat plugins, and

(15:15):
some of it is going to use the new VAT
six environment APIs, and some of it we can just
do today already just by building multiple environments ourselves. So
then on top of VEAT there's Nitro. So Nitro is
this toolkit that it uses Beat, but it helps you

(15:36):
build your back end code to work basically anywhere you
want to deploy it. So you can use Nitro as
this unified layer. Nitro is by the UNJS team and
it has this unified layer for pretty much everything you'd
want to do on the back end. You can write
your code mostly one way and deploy it to basically

(15:59):
anywhere that they may maintain an adapter for and it
will just work.

Speaker 2 (16:03):
So they handle the deployment part of building a framework
Slash Metal framework for you, because that's obviously a big
challenge having to deploy to all the different platforms.

Speaker 5 (16:15):
Well, like to put it into perspective if you so, so,
like next JS and Remix, they have to maintain their
own adapters to build their projects into the right formats
for all these different deployment destinations. Nitro does that. That's

(16:37):
Nitro's job, and so if you just use Nitro, you
don't have to worry about that and duplicate all that effort.
You just get to use what Nitro has built. So literally,
for me, I recently migrated a site from Versell over
to Netlify, and it was literally the difference of me
going into my config and saying deployment you know, I

(17:03):
think deployment preset, I think is what it's called. I
just changed it. It's a string, and just changed it
from Vercell to Netlafi. And when I rebuilt it, it
just rebuilt everything for Netlify instead. I didn't have to
change anything.

Speaker 2 (17:18):
And it also assumes supports as cloud Flare whatever and
so on and so forth.

Speaker 5 (17:24):
Yeah, and so Nitro is built on top of VEAT
and they're upgrading to the new VAT APIs as well.
So it's the clearest path for no duplicated effort. Really
whatsoever is they're going to maintain these adapters and we're
going to use Nitro directly, and you get to use
the Nitro APIs in your apps as well, so they

(17:48):
have wonderful products like un storage where you just kind
of have this unified storage API and you supply the
drivers and that driver may map to, you know, one
type of memory on this host, or you could map
it to another one. If you're using cloud flair, you
could map it to D one or something like that.
So they have a really great like abstraction for all

(18:13):
of these different implementations of features that we like to
use on servers.

Speaker 2 (18:19):
I'm curious aside from you guys, you and Ryan and
who else is using them for what.

Speaker 5 (18:28):
It actually came out of the view and the Next ecosystem.
So Next is built on top of UJS essentially like
all of it, and that's what they use. So UNJS
and Nitro is kind of like the lower level server
toolkit and the primitives that came out of the Next project.

Speaker 1 (18:51):
I was wondering if there was a relationship because I
remember talking with Daniel Rowe about Nitro when that first
came in, when they first started using that, and the
speed increase was supposedly real phenomenal.

Speaker 5 (19:01):
And you know who else uses it is Brandon who
built analog JS. So that's it's the it's kind of
the same approach, like, hey, let's build a framework that
uses Nitro, but for Angular. So he built his own
Angular meta framework and it uses Nitro under the hood.
Very very cool. That's that's how powerful and portable it is.

Speaker 2 (19:25):
So it's certainly interesting that vit came out of you
and now Nitro came out of you. So if he
was contributing a lot to the framework space way beyond
View itself.

Speaker 5 (19:37):
Yeah, absolutely, There's there's a lot of things about Next
that have been pushing forward what we've been able to
do outside of like Next itself. It's pretty sweet. So
Vinchi Vinci is built by Nikhil Serov, and Nikiel was

(19:59):
working on a Solid team for a little while. I
think he still is technically started the part of the
Solid team. But before VT six came out, there wasn't
really a way for you to do kind of a
unified Hey I'm building a full stack application, like a
unified config you would have to have had like one

(20:22):
VAT configuration and build setup for your client, and then
you'd have to have another setup with Nitro or something
else for your back end, and you kind of merge
those together or you end up building something that something
like that on your own, like Remix has done. But
Nikkio wanted kind of this unified layer, and we also

(20:43):
needed to do some multi environment things before VAT six
came out, so he built Vinchi vin XI and Vinci
is essentially a wrapper around that experience. So it uses
Nitro directly and Beat directly to coordinate this full stack

(21:05):
dev and broad build experience. And it was phenomenal, Like
it helped me get off the ground really quickly and
just start focusing on building like the run time and
my framework APIs. Now that we're getting closer to one
dot zero for Tanstak Start, we want I want more

(21:26):
control over what we're doing with Nitro and what we're
doing with VAT, and Nikkiel is also just very busy
with other things, in my opinion, more important things for him,
and that's totally fine. So Ryan and I have decided
that we're going to kind of slowly start to supplant

(21:47):
this Vinci logic with just a shared layer that we
that we use between all the start projects implemented in
what by the way, Well, sorry, what do you mean?

Speaker 2 (22:00):
What are you Well, of course, I of course I
assume it's job Well typescript, but like, what libraries are
you using there? Is it like based on signals because
it's Ryan or no.

Speaker 5 (22:14):
So so this layer is mostly going to be a
collection of veat plugins that are very configurable and they'll
use Babel under the hood, and really it will all
come together in hopefully what's going to be a very
thin layer on top of Nitro. So essentially just feeding

(22:36):
Nitro a unified config to say, here's here's what I
want you to build for my server environment, for my
SSR environment, and for my client environment, those the bundles particularly,
and just to kind of make all that cohesive.

Speaker 2 (22:55):
Mm.

Speaker 5 (22:56):
Yeah, it'll just be typescript at the end of the day.
What I would like to have it be is just
a veat plug in itself, which kind of sounds weird.
It's a beat plug in that would call into Nitro
to produce many different environments and build even more veat
the bundles. So but that's I think that's the beautiful

(23:19):
part about it is that if we can boil it
down to just Beat plugins, I think it's going to
be really powerful.

Speaker 2 (23:25):
And that's basically going to be like under some sort
of a start moniker.

Speaker 5 (23:30):
Yeah, most likely we'll probably just share internal packages privately
for now, and each one of us will just export
our own builders for it, so you'll still you know,
you'll probably build something like create tan stacks start. VAT
will be like one of our packages, and you'll call
that function and it will produce all the VAT plugins

(23:52):
that you need to add to your build essentially.

Speaker 2 (23:56):
And the way, by the way, one thing that you
said before, or that the ten stack router was ninety
percent of the way towards tenstack start in terms of
being a framework, I think Ryan Florence more or less
said the same thing about remix and React router. I

(24:18):
think they even kind of merged the two projects together
for that reason.

Speaker 5 (24:23):
Yeah, I yeah, I don't. I wish that maybe that
had been recognized sooner so that they didn't have to
go through kind of a snip snap, snip snap kind
of a pattern, because it's always been apparent that the
router is what drives much of what you do. That's

(24:47):
where all the opinions are and where you're feeding you know,
it's calling into your code and scheduling its own things
and doing something, so it very much is the framework.
I yeah, I don't have a whole lot to say there,
other than I just wish that they had maybe it

(25:07):
would have been better for their branding. I think if
they hadn't have done like, oh, it's remix and then
they took react router and put it into remix, and
now it's React router and putting Remix back in there,
it's very confusing. It should have just been incremental from
the beginning. They should have built remix as an add
on to react router. But I do everybody has their reasons.

Speaker 2 (25:28):
Well the reasons, and also, like you said, people realize
things as they built them.

Speaker 5 (25:34):
Yeah, and you know, that was merely an idea that
I had. I just wanted to build my own router,
and I knew that I wanted it to be client
side only and that server side features were going to
come later. I'm very very grateful that they were willing
to go guinea pig that process and probably find out

(25:56):
the hard way that it should have just been React
router all along. So I'm not complaining they they have.
They've done me a great favor in research.

Speaker 6 (26:06):
And yeah, by the way, I'm curious, do you think
that maybe routing client side routing, I mean, should have
been part of the platform in some.

Speaker 5 (26:18):
Way, which platform, like the web platform.

Speaker 2 (26:23):
Yeah, like dome APIs for client side routing beyond the
basic history APIs or.

Speaker 5 (26:33):
I don't know. I mean it's easy to say, yeah,
that would be great, but uh, where would those opinions
come from that would serve everyone? I don't I don't know,
because even for projects that look that look a lot alike,
even for like like react router and tan sac router,

(26:53):
like I took good ideas from react router, I took
the loader pattern and you know a couple of other
patterns that I just thought, you know what, these guys
really nailed these APIs, and then for other things I
just did things completely different.

Speaker 2 (27:09):
So can you maybe talk a little bit about that.
Can you elaborate a little bit about what is the
loader pattern and also about some of the things that
you've done differently?

Speaker 5 (27:18):
For sure? So the loader pattern is just a really
fancy way of saying like life cycle management for navigation, Basically,
you click a link and we know, hey, you're about
to go to this next page, and before you even navigate,
before we try and render, before do anything about showing

(27:41):
the next content, you have life cycle methods that will fire.
This goes way way back even to like knockout and older,
older frameworks that were just like, oh yeah, they're about
to navigate to this new page. Here's a function that
you can run before that happened and potentially do some

(28:02):
asynchronous work. So that concept, that's the core concept, and
then the loader pattern is just applying that life cycle
method to data loading, specifically to say, before we navigate
to this route, we need to make sure that we
have this data. So when you hear people talk about loaders,

(28:24):
that's generally what they're talking about. It's just a life
cycle method to ensure that data is present.

Speaker 2 (28:30):
By a synchronous By the way, in this context, you
mean it's a synchronous to the operation of the browser,
but it's not a synchronous to the actual navigation. I mean,
you do need the data in order to display the
quote unquote new page.

Speaker 5 (28:43):
Right, yeah you might. And again here's another reason why
it doesn't really work to just have some universal web standards.
Some frameworks will even wait to change the URL before,
like until the data is loaded. And for me, for instance,
I like as soon as they navigate, the URL changes

(29:04):
synchronously and then the side effect of rendering what the
user wants to see is asynchronous. So yeah, there's lots
of opinions there.

Speaker 2 (29:17):
Interesting. So that's what is similar about about what you've
done and react route. Can you talk a little bit
about what is different because I also think that informs
some of the differences between tintac and other frameworks.

Speaker 5 (29:31):
Yeah, so yeah, they both have loaders, they both support
I mean, it's not even limited to remix. But let's
just say, like modern routers, kind of the expectations for
all modern routers is that they have nested routing, the
ability to like nest route matching segments inside of each other,

(29:52):
to do shared layouts.

Speaker 2 (29:54):
So I apologize for interrupting you. Just to clarify, nested
routing means that you click a link and you go
into uh, let's say call it a sub page or
sub resource in a sense, or like and part of
the page stays the same, and then part of the
page changes or is that something else and I'm explaining

(30:15):
it wrong.

Speaker 5 (30:16):
No, that's that's exactly right, And it's the difference of
it's just encapsulation and reuse is what it is. You
could write your entire router as a flat map to
say this exact URL matches this exact component. And if
you have components that share the same layout, like a

(30:38):
nav bar or a sidebar, and this is back like
with older versions of next JS, you would have to
render that nav bar and sidebar on every single page
that you wanted it to be on, right, and that
has implications depending on the framework you're using that sometimes
those components would unmount and remount even though they look
like they're still there, you know they haven't changed. So yeah,

(31:02):
that's that's one of the things too. Yeah, there's lots
of these shared things. Nested routing is one of those things,
but instead of having this flat list of URLs to components,
you get to share those r l roots. So say
you have you have an admin slash admin right, you
might have a lot of sub pages on that slash
admin slash admin, slash users or whatever. And instead of

(31:26):
having to render like the admin sidebar for every single
one of those sub pages, you just render at once
in the admin layout component, and then every single sub
admin page below that will get inserted into that layout
wherever you render an outlet or rendered children essentially.

Speaker 2 (31:44):
So you got you have this sort of a slot
where the sub page is like, well slotted.

Speaker 5 (31:51):
In yep, and that slot works for index pages, which means, hey,
we didn't match anything, so we're just on the index
and you can slot something in there or you can
slot in subpages. Yeah, so nested routing is a big one.
That's that was kind of that's that's one where react
router really nailed it. You know, next js didn't have

(32:14):
that for a while and it was really enraging and
React router has had that for a long time. When
next gs finally added that, it was like, oh, well,
this is wonderful, and it's like, yeah, why didn't you
do that sooner? And and that was a no brainer
for us. It's like, yeah, we're going to support that.
We're going to do nested routes, things like file based
routing where you can you know, create that tree using

(32:38):
a file structure, just to kind of have maintenance be
nice and have some opinions and convention around just moving
quickly loaders. We talked about kind of just your basic
navigation APIs being able to have links and you know,
imperative navigate calls to kind of move around your app.

(32:59):
That all that stuff is pretty much the same where
it starts to get different from both next JS and
remix is so tanstack router basically was. I rewrote it
from the ground up with type safety at the forefront.
So every single decision that I made when I rewrote

(33:22):
this router was so that we could have one hundred
percent inferred type safety. Essentially, the goal was I don't
want to have to write typescript zintax in my routing,
but I want it all to be extremely type safe.

Speaker 2 (33:38):
Type safe means that if I put in an invalid route,
I get read squigglyes. Is that what type safe means
in this context?

Speaker 5 (33:46):
Yeah, I mean it means a lot of things. That's
one of them, and that's what I like to call that.
The That is the basic level one type safety that
I would expect out of a router is that, yeah,
you don't let me navigate static warn me that, hey,
you're trying to navigate somewhere that doesn't exist. That's that's
just the basic bear bones. There's a lot more to it,

(34:09):
though I don't know how much you want to go
into that, but.

Speaker 2 (34:12):
I think we talked about it actually in the last
time you were here. So I don't want to go
too deep because I want to talk about the ten
stack framework and some of the RPC work is really
interesting for me. I'd love to talk about that too,
so just in a few words, just to mention it.
As I recall, it's also type safety about r L parameters,
so you can specify the type of a r L

(34:34):
parameter and the value has to match that.

Speaker 5 (34:39):
Type, right, and that that applies to a lot of
different areas of the API. So search perands is a big,
a big piece of tan Stack router. All of our
search parameters are validated and type safe and have first
class APIs built in to manage search parameters like you

(35:01):
would like use state essentially, like you're just managing state.
That's that's a really big difference and something that really
not many other routers, if any that I know have.
That's a that's a big reason of why I wrote
it as well. On top of that, there's there's type
safety throughout all the other APIs that we have in there,

(35:22):
So there's things like route context and middleware, all of
that stuff is type safe as well. There's the configuration itself,
like being able to use loader data inside of your
components or use data from other routes, from different files.
It's all type safe, it all works, it's all very magical.

(35:44):
I don't know what else to say there other than
you should try it because you're you're probably missing out
if you haven't tried it yet.

Speaker 2 (35:50):
Let me put it this way, we are starting a
new project. I basically made it part of our standard
starter kit at Sisense, so you know, we might it's
if it's a project that needs a full framework, like
we might debate between that's a next JS or something else.

(36:15):
But if it's a project that's mostly going to be
client side rendered, then I've made ten stack like part
of our standard config.

Speaker 5 (36:24):
I would agree, all right. So before we move on
to start, there's another one more thing I want to mention.
So tan stack router has caching built into it, which
is like a really really lightweight version of React Query
or tan stack Query built right into the router. So

(36:44):
for very so for simple use cases, you may not
even need tan sack Query. You just load the data
you need in your routes and it's managed for you there,
and you have things like stale time, s w R
background refetching. It's all just built into the router. So
that's very important, a very important distinction. And yeah, just

(37:06):
generally managing state in the URL. If you're going to
use search parameters like at all. If you're going to
use search parameters, you should use dandsack router.

Speaker 6 (37:15):
Well.

Speaker 2 (37:15):
I love it when as many as possible configuration values
are in the URL, So, for example, I use gfana.
I've even spoken about it here on JavaScript Jabber, and
one of the things I love about grafana is that
most of their configurations are your parameters, which makes it
very easy to share grafts.

Speaker 5 (37:37):
Yep. More state should be in the URL, not all state,
but more of our state should be in the r L.
And as soon as you want to start doing that,
you'll realize that the tools you have at your disposal
are not that great. So come use dan sack router
and you'll be much happier.

Speaker 2 (37:57):
Okay, then can stack the framework ten sax start.

Speaker 5 (38:01):
Tan stacks start yep. So I wasn't planning on building
it initially, you know.

Speaker 2 (38:11):
What I'm I'm not surprised. I mean, one person kind
of taking on the whole next JS ecosystem. In a sense,
it's a lot.

Speaker 5 (38:23):
It is a lot. I was I wasn't planning on
building it initially because one I didn't need it personally,
just building a lot of spas. But I'll be honest,
I nerd sniped myself on this one really really bad.
So I had this idea about a year basically a

(38:45):
year ago, and I was like, you know what, I
wonder if I could rewrite tan stack dot com and
migrate it from Remix to just use tan stack router
with a custom SSR setup. And I did that. It
was really hard, and I was like, man, that was.

Speaker 7 (39:03):
Really by the way.

Speaker 2 (39:04):
As an aside, when I worked at WIS, I used
to work at WIS up to about five years ago
time flies four or five, yeah, four, four years ago,
five years ago, something like that. Wicks. Actually, when I
was there, we built our own SSR framework platform, and
we did it for first of all, because none existed

(39:25):
at the time. We predated next JS. I think also
the use case was very different. I mean, you know,
hosting millions of websites on on one platform is a different,
you know, use case. So I know for a fact
how difficult that can be, very challenging to do it efficiently.

Speaker 5 (39:49):
It's enraging a lot of the time to be honest,
because I mean, the first thing you're going to realize
is now you have hydration problems. Anytime you're trying to
do SSR with ACT, you just have to get really
strict about hydration. But yeah, it was it was difficult,
and that's kind of what started tanstac Start because I
was like, Okay, I just did this manually and it

(40:11):
really really sucked. How can I make that better? And
I started talking to Ryan Carniato and I was like, hey,
what are you using for solid Start? And he said, well,
I'm using Vinci to kind of put all this together
to make my life a little easier. And I tried
Vinci out and I just kind of again just built
it manually, but using Vinci, and it made my life easier.
And so you could see it's sort of snowball at

(40:32):
that point. Then I decided, you know what this is.
This is going to be pretty cool. And I showed
it to some people that I trusted and they said,
this is amazing. But I really wish it had server
like like server loaders. How do I only do something
on the server, And because in remix you have you know,

(40:54):
server side loaders, and even in next days pages router
you have get service props and stuff like that, and
so I was like, okay, so it's not really complete yet.
How can I how can I make this better? And
that's when I started diving into server functions. Then initially
those were implemented with Vinci, but designing a proper API

(41:19):
around server function rpcs has been like my last six
months of work.

Speaker 2 (41:27):
So let's talk a little bit about r PC because
apparently it's a subject that's close to your heart, and
I know for a fact that it's goes to mine.
As I mentioned, we even had an episode about it.
Can you talk a little bit about first of all,
about what is RPC?

Speaker 5 (41:44):
Yeah? Pretty sure? It stands for Remote Procedure call, right,
Am I wrong?

Speaker 2 (41:50):
No, you're you're absolutely correct. And by the way, I
used rpc's by the way, as an aside back in
the early nineties. Yeah, nothing nothing to do with weblogies. Yeah,
things like COREBA or d coom mm hmm.

Speaker 5 (42:04):
Yeah, they have a they have a really like rich
history in in computer programming, and uh, I've read a
little bit about that. Ryan has sent me Ryan Carneat
has sent me some stuff about them as well, and
I just I love when we can like find old
tech and make it feel new and great. But this
is one of those things where it's like, yeah, we've
been doing this for a really long time. But the

(42:27):
idea behind the RPC is that you know, you get
to uh, you get to create this function. Uh. In
a very generic sense talking about rpcs, this this function
that can be called remotely, and when it's called remotely,
it has you know, an underlying protocol implementation and messaging

(42:48):
implementation that sends those messages back and forth. But it
creates a very like a very opaque interaction where you
can just say, I need to call this function. It
may happen on your machine, or it may happen on
another machine, right, but it's a remote procedure call. It's

(43:08):
going to happen remotely, and it feels very different than
calling into say arrest API or graph QL or something
like that. Well, just to know because similarities, Yeah.

Speaker 2 (43:24):
Yeah, because putting a side yeah, putting a side graph
QL for a second. Yeah, if we're talking about RESTful
APIs rest for API is to some extent, you know
their requests response, which is the basic prerequisite for something
that looks like function that you send the message and
you wait until you get the response.

Speaker 5 (43:44):
Yeah, basically yeah, And you know, graph Ql even has
a little bit of RPC vibes in it as well,
where you kind of you can you can and do
kind of create these functions that you that you call
through the graph Ql like zintax and proto call. Right.
So RPC is kind of in a lot of different things,
and we even kind of implicitly create rpcs in rest

(44:09):
environments all the time as well. You know, you have
a rest API and you just kind of need this
one off, like hey, you know, slash generate whatever, and
you call it and it's going to do something and
it's going to come back. I think in the modern
in our modern definition of our PCs, though, I think
a lot of it comes down to how you compose

(44:32):
that logic, right, because generally when we're talking about graph
Ql procedures and functions and and HTTP like rest APIs,
these are APIs that you you kind of have to
design in separate places. You say, Okay, I'm building an API,

(44:52):
I'm building a graph Ql endpoint, and I'm going to
build this function in this place and then in a
completely separate location, either whether it's in your mono repo
or a completely separate application. You're then constructing a way
to call into that function through you know, URL schema

(45:13):
or graph QL client that's been generated or something like that.
So you creating that function and authoring that function and
calling it are seemingly very separate places with an RPC,
at least in our mod.

Speaker 2 (45:29):
Often, by the way, implemented by separate people. It might
be the back end team that's creating the RESTful end
points and then the front end teams that are putting
some sort of facade on top of.

Speaker 5 (45:41):
Them, and possibly in separate languages too, right, often separate, yeah, often,
And so our PCs, at least the modern way we're
thinking about our PCs is more it's more of like
an integrated approach to creating that messaging layer. So for
anybody listening, who who could imagine you, I'm just going

(46:04):
to tell you how we do it in ten six start.
But basically, in any file you want in your application,
you can call a function called create server function, and
you pass that call a function, and everything inside of
that function is going to only run on the.

Speaker 2 (46:24):
Server, even only exist on the server.

Speaker 5 (46:27):
It's only yeah, it's only going to exist on the server.
So it like when we bundle your application, we literally
take that function that's inside of there and we strip
it away from the client, and what we do is
we replace it with a fetch call. It's a fetch
to to you know, an HTTP endpoint.

Speaker 2 (46:50):
Which is the sub.

Speaker 5 (46:53):
Yeah stub, right, you stub it, and we implement that
stub we have with fet and with an httpn point,
and then we extract that function into the server bundle,
and on the server, we're listening to that same endpoint
for that stub for that fetch call. And when we
receive that call, we take their request and we pipe

(47:16):
it through to the function that we extracted, And so
they execute in completely different environments, but you author them
in a full stack way. So I mean, these functions
can live right next to a React component that renders
on the client, and they could even live next to
things that are client only in the same file.

Speaker 2 (47:39):
I think that's kind of the key. I think that
three things I think enabled RPC for the modern Web
because RPC has existed on the back end like forever,
so you know, you obviously I mentioned the old technologies
at Corbo and dcom. Now you have gRPC, so all
this stuff on the back end is always been there

(48:01):
on the web. I think three things that happened in
recent years that's called it this way kind of enabled it.
So one was the full stack frameworks. Yeah, because you
needed to be able to write code that builds or
compiles to both sides for this mechanism to be truly seamless.

(48:21):
And you kind of said it it's intended for the
full stack scenario. So that's number one. Another one is typescript.
Without typing, this whole thing would have been moot because
you need to be able to specify the types of
parameters that you're sending over the wire. Now you could
have done it explicitly using something that kind of looks

(48:42):
like ZOD or something, but it would have been really
uncomfortable or you know, the old component props that we
used to have and react. It would have been really
uncomfortable to do it that way. And the third thing
that in my opinion, and I wonder if you have
that kind of enabled it are is a weight a

(49:03):
sink a weight The fact that you can call a
function and have it execute a synchronously, but with the
function called semantics.

Speaker 5 (49:15):
Yeah, I don't know about the third. I feel like
it definitely helps. It definitely helps. We could have done
it with callback functions. It wouldn't have been fun.

Speaker 2 (49:26):
Yeah, it would have been fun, and it would have
broken the function called semantics. I mean, yeah, one of
the big things about RPC is that it feels like
a function call, and when it doesn't, then then you're
missing out on most of the fun.

Speaker 5 (49:42):
Yeah, I would agree. It definitely a sinklewaight elevates the
experience to more of the traditional RPC feel that definitely,
But how.

Speaker 2 (49:52):
Do you do that in React client side? I mean
you can't really do a sincle weight in in client
side React. No.

Speaker 5 (50:00):
I mean they would like to make you think that
you can with then you use API, but I mean
it's not. It's not really intended for like end user usage.
So again that kind of falls back to like that's
why I built tanstat query is because React lacked and

(50:20):
honestly to this day still lacks a really well vetted,
good client side asynchronous primitive And maybe they don't add
it because React query is there and it's good enough,
or they don't or they just decided to skip it.
But really, if you ask somebody today from from React

(50:43):
purist Land or core Land, I'll say, oh, well, you know,
you're just supposed to use server components for data fetching
and and just pass promises and then you call the
use or whatever to that, I say, that's making big
assumptions about the way your author in your application.

Speaker 2 (51:01):
So yeah, well, to be fair, it's part of their
their vision of the how do they call it the
Uni directional data flow That RPC kind of kind of
somewhat breaks that in a sense because with the Uni

(51:22):
directional data flow model, you've got the data flowing down
as props and you've got interactions flowing up as you know,
let's say, server actions. I don't know do they still
call it server actions or do they also call it
server functions?

Speaker 5 (51:37):
Now, yeah, they call it server functions, which is kind
of annoying, but that's fine.

Speaker 2 (51:43):
Yeah, it's it's functions that are not supposed to return
a value though.

Speaker 5 (51:48):
Yeah, And see that's where that's where things differ. For me.
I don't really think it breaks the React methodology, and
most of that just comes down to how you're handling
the responses in my opinion. But you know, for rpcs
that just aren't doing anything. I mean, look at the
way next JS handles server functions. Right now, you call

(52:10):
a server function and they basically just indolidate everything they
call back into the route on the server and they
can re render your whole app. Now, there's a ways you.

Speaker 2 (52:22):
Need directional data flow. The events flow bubble up, the
data flows down.

Speaker 5 (52:28):
It's just really not great for performance though, especially the
way the React is even designed. It's it's kind of
sucks to render your entire application from the top down.

Speaker 2 (52:40):
Let's put it this way. It's not surprising that you
created React query rather than they.

Speaker 5 (52:46):
Yeah, no, I agree, Like I really like React, and
I like this intact. I like the framework. It's it's
really wonderful. If I had if I had a magic
wand that I could wave, it would be that that
we just use solid. But that's not going to happen.
So for now, you know, I have to ride on

(53:09):
the on the shoulders of this giant that has React.
And that's fine because it's it's really good, and it's
good enough and and and it's decent to work in.

Speaker 2 (53:20):
And No, but I'm not fired for using React.

Speaker 5 (53:23):
No exactly. But you know, It kind of goes back
to the way that we're trying to build things with
Tan SAC libraries is that it shouldn't matter really where
you go. We just want to We just want to
build great core functionality and bring it to all the frameworks.
And yeah, I worry a little bit about reacts future

(53:44):
with pushing server components so much because it's a wonderful
technology that is kind of derailing a lot of people.
And from where I'm standing this, it's very confusing for
a lot of people. Well, it's very difficult to implement
as a framework, and it comes with a lot of

(54:05):
new rules and overhead that just don't really apply to
I'm going to call it the more traditional way of
building an SSR application that's just isomorphic and fully hydrated.

Speaker 2 (54:16):
So I'll derail us a little bit because I do
want to talk a little bit about that. From what so,
I've been looking at some statistics about the React usage
and Metal framework usage. For those who don't know, more
people are using reacts and all the other view frameworks
put together. So React is number one, View is number two,

(54:39):
but views less and half of React and everything else
is less than the remaining part.

Speaker 3 (54:44):
Those stats are wrong. I know it. I can feel it.

Speaker 2 (54:48):
And in react Land, approximately almost twenty percent are using
NEXTGS and the rest are not. They're not using any
meta framework. But if you look at new websites, it
seems that almost all of them are being built using NEXTGS.

(55:09):
So any project, there's a good chance at any project
older than two or three years that started two or
three years ago is probably not using NEXTGS and may
never use NEXTJS. But any project that's being started right now,
there's a good chance that they're using NEXTJS.

Speaker 5 (55:24):
It's a fair assumption.

Speaker 2 (55:26):
The interesting question though, when they're using nextgs, are they
also using server components and that I have no way
to know, And I'm kind of curious about that, Like
what is the buy in for server components.

Speaker 5 (55:40):
I don't know if it's easy to know the buy in.
I mean, I we could we go back and look.
I've done tons of polls. I mean, it's obviously biased
off of my audience, but I've done a lot of
polls on Twitter about people, how people feel about server
components and NEXTJS and and if they want to use
them or not, which framework they would use, and for

(56:03):
the most part, what I've the conclusion that I've come
to is that there are a lot of people coming
into next JS who are who are using server components
just because that is the happy path that they have
designed for next JS.

Speaker 2 (56:17):
It's also the default unless you put client it's a
server component.

Speaker 5 (56:23):
Yeah, and for me it's it's not interesting for me personally. Many,
if not almost all the apps that I've ever built,
I don't know if they would really directly benefit from
from the capabilities of server components at this time. I mean, yes,

(56:45):
they could benefit in terms of some bundle size, but
the trade offs for me just are not worth it. One,
I don't want to have to reason about this new
mental model of you know, interweaving client and server components
almost at every level of the component tree just to

(57:08):
get you know, trade offs that don't matter for me
or really won't matter much for my users at this point.

Speaker 2 (57:13):
But by the way, I'm going to interrupt because I
need to. I think I always like to give a
bit more context to our listeners. So first of all,
we had two episodes with Dan Abramov and Jose Savona
talking about server components. So if anybody is really interesting
in the nitty gritty of what they are, I highly

(57:33):
recommend listening to those episodes that were excellent. The key
aspect about server components is that they are components that
only run on the server, versus client components which run
which can run both on the client and on the server,
which is interesting.

Speaker 5 (57:55):
I'm even going to extend that to say that server
components have the worst name ever. They should not be
called server components. They should be called like static components
are serializables, I mean, because you can technically generate server
components at build time too, at bundle time. Really, really,

(58:16):
all it is is you're just pre rendering a component
and producing uh this output that is like stringified JSX,
and then you're shipping that to the client from either
the static build or dynamically during from the server during runtime,

(58:37):
and then you're you're rendering that JSX stringified version. You're
turning that into something you can I.

Speaker 2 (58:44):
Prefer to think about it as serialized virtual dome.

Speaker 5 (58:49):
Exactly what it is, it's serialized virtual dome. And when
you talk about it like that, it becomes much easier
to reason about what you would actually get from using them,
which for me, out of the box, the things that
I think, what are that are interesting about server components
is that you could you could import and render and

(59:15):
do a lot of complex work with using really large
bundles and libraries on the back end that produce a
really small uh jsx output and you would only have
to ship that to the client. And that's something that's
that actually is very useful, uh thinking about it from
that way, and that's something where like it would be
useful for like Meta. You know that that's the whole

(59:37):
reason they built relay and the ability for relay to
send components down in chunks with certain grapht QL responses
was so that they could only send down the code
that they needed to render the thing at that exact moment.
So it's very much like the next generation of that idea,
even though Meta is not using it, which is another topic,

(01:00:02):
but that's this is the next generation of that idea
is only sending the code that's needed to run on
the client to produce that things. It doesn't really have
a whole lot to do with data loading other than
you can load the data on the server and then
produce the HTML and the server and send the htmail

(01:00:23):
down to the client. So it's very much like using
a traditional rendering framework from like old back end days.
You produce the HTML I'm air quoting here, but it's
JSX and you ship that down to the user instead
of having to ship all of your data fetching logic
and you're rendering logic down to the client.

Speaker 2 (01:00:43):
So does ten stack actually support server components or do
you solely rely on server functions.

Speaker 5 (01:00:52):
I will support them, so I've actually written all the
code to proof of concept this out. It works. We're
going to support them in a very safe way. I
can go into depth and that actually I think it's
worth talking about that. So server components. People look at
server components through the lens of next JS right now,

(01:01:15):
because that's.

Speaker 7 (01:01:15):
The only thing that we know and the implementation I think, yeah,
next JS, their entire router, like the entire experience from
the root of the of the application down, is a large.

Speaker 5 (01:01:31):
Server component. Essentially, it starts at the route and it
starts on the server, and it interweaves between client and
server going all the way down. That has kind of
skewed the way that people look at server components. I
think they think that that's the only way that it
can happen, and that all of their routing files and
their layout files and all these other things are going

(01:01:53):
to be written in this like us server used client
kind of handoff thinking about these rules well, similar to
so if you caught next JS comp this last year
Ryan Florence, they demoed how it could be different, and
it aligns, it almost aligns exactly with how I was

(01:02:15):
thinking about them as well, is that server components are
really just another form of asynchronous state or data that
you're getting from an API endpoint or some embedded static
data that you have in your application, and so really
it can happen at network io boundaries. Next JS has

(01:02:39):
those built into the entire system, so it's just kind
of that's just what's happening all the time. But for
tansecs start, the way that we're going to do it
is if you want to use a server component, you
simply return jsx or react in a server function in
an RPC.

Speaker 2 (01:02:58):
That's I felt that that was where you were going.

Speaker 5 (01:03:01):
That's it, And you know that fits right in with
Remix too, because so they don't really have rpcs, but
they do have loaders, which is kind of like they're
hard coded rest their kind of rest flavor of an RPC,
right and they're doing the same things. You just return
jobs or you just return react on JSX inside of

(01:03:22):
a loader. So server functions are really going to be
the place.

Speaker 2 (01:03:29):
Where you can use server So a question about that. So,
first of all, it seems kind of almost like you
might be returning a string and then injecting it to
be using what's it called unsafe in dangerously unsafe insert
HTML or whatever a little bit. But the question that

(01:03:49):
I have about that, what prevents that server function from
returning JSX or virtual dome that the client doesn't know
what to do with, like using components that don't exist
or whatever.

Speaker 5 (01:04:05):
A lot of that just comes down to how it
gets bundled. So the real feature, if you ever listen
to Andrew from the React court is Andrew Clark. I can't.
I think it's his name, right, Andrew, Yeah, I think so. Yeah.
I like the way Andrew talks about it. He says,
the real feature of server components is not a framework feature.

Speaker 2 (01:04:26):
It's a bundler.

Speaker 5 (01:04:27):
It's a bundler feature, and it allows you to basically
render a component and only bundle up the things that
it needs to render with with it. And so when
you serialize that component, everything that ran on the server
is going to turn into JSX markup. That's right there

(01:04:48):
in that representation, and everything that can't run on the
server that needs to run on a client is referenced
through a manifest, and it gets a little tricky with
how that that works, but that manifest is just a
mapping of client component references that can come down through

(01:05:09):
server components to the actual modules and bundler modules that
it can go out and grab if it needs to
grab them. So when you render something on the server,
it comes down with this responses is here's all this
server function or the server component markup, and there might
be some client components in there, and if they're already

(01:05:31):
loaded into your app on the client, then they'll just render,
and if they're not, then they will suspend while they
go and pull that client side bundle chunk that they
need to render, and then they will finally render.

Speaker 2 (01:05:44):
So a key difference, it seems to me, and again
correct me if I'm wrong, between the next GS way
and your approach, is that with NEXTGS the root is,
like you said, a server compon, whereas in your case,
the route is a quote unquote client component, even though

(01:06:07):
it actually might run on the server.

Speaker 5 (01:06:10):
Yeah, I think that's a good distinction, is that with
next JS, everything's going to be server first all the time,
no matter what well ver so, right of course. And
then with tan SAX start even down to the way
that the APIs are designed, everything's written to be isomorphic first.
So if you don't do anything inside of a server function,

(01:06:33):
what you write is just going to happen during SSR,
and it's going to happen on the client.

Speaker 2 (01:06:39):
You know what I really like about your approach now
that I'm thinking about it. So I have this presentation,
this talk that I gave about different ways to overcome
the cost of hydration, the performance cost of hydration, and
I show the different ways, and I for each such
method like this, something like six or seven approach and

(01:07:00):
for each one of them, I give both the upsides
and the downsides of each approach. And one of the
approaches that I mentioned towards the end are server components.
And one of the downside of server components that I
presented in my talk is that they require you to
basically re architecture application. You can take an existing application

(01:07:21):
and just throw in server components into it. You need
to rethink your entire architecture. You need to learn this,
not even new technology, but new approach and then architecture
application accordingly. And what I really like, Sorry go on.

Speaker 5 (01:07:37):
I was going to say, I agree, but I think
there's some nuance there where with server But with server components,
you can migrate incrementally, but you have to do it
from the top down. You have to slowly move the
server bound So at the top if you just say
I want to render my whole app as a client component,
you can do that in next JS. You can even

(01:07:59):
do that, I think help you can render your entire
app as a client component.

Speaker 2 (01:08:03):
Well, you can have a really thin server component that basically.

Speaker 5 (01:08:07):
Just right, and and then migration path is to slowly
push that server boundary down through your component structure as
far down as you can. That's the incremental migration strategy.
And I don't like doing refactors from the root down.

Speaker 2 (01:08:23):
Uh.

Speaker 5 (01:08:24):
In fact, I like to my my leaf node up.

Speaker 2 (01:08:28):
Yeah, but you're absolutely correct. But if you if you
basically do that, then you've not Again, my presentation was
in the context of improving the reducing the cost of vibration,
and if you just do that, you basically not elimit
not reduce the cost of vibration at all. And yeah, slowly,

(01:08:50):
but all it means is that you've slowly re architected
your application exactly. But and what I like about Europe,
it seems to me, is that you can get these
this value without re architecting your application you want to,
you can you think you have some components somewhere in

(01:09:11):
the tree that could benefit from being a server rendered
component because I don't know, it uses some d date
and time functionality that would require you to download moment jas.
Well you just turned that into a server function that
returns gsx.

Speaker 5 (01:09:28):
Yeah, and you know you bring up you and you
brought a cool thought into my head? Is that talking
about refactoring?

Speaker 4 (01:09:36):
Right?

Speaker 5 (01:09:36):
Let's imagine a lot a lot of people are on
create react app. At the very least, it's it's not
too difficult to get into VAT at the very least,
just saying hey, I want to use veat. But to
be able to use what would it take for somebody
at that point then to use server components?

Speaker 2 (01:09:53):
Right?

Speaker 5 (01:09:54):
Telling them that they would need to adopt an entirely
new framework is a big pill to sw swallow if
they just want to consume this new server component pattern,
this new technology. It's a hard pill for them to swallow,
and I would wager that a lot of people wouldn't
do that. But what if you could say, Hey, all

(01:10:15):
you need to do is just get off of create
React app, which you should do anyway, get into beat right.
All you need to do is get into VAT, and
if you can do that, we can give you a
VAT plug in that will let you call server functions
and then let you return server components, and then you
can just render those server components even without refactoring really

(01:10:38):
any other part of your application. Even if you're still
using React router version four or five, you could still
make an API call using whatever you want using React
query even and call into a server function, get back
a server component, and render it. You would just need
to migrate to VAT and be using real act nineteen.

(01:11:01):
So that that's probably the path of least resistance if
like you're, if you just want to get your hands
on server components, that's the path of least resistance that
I'm trying to make possible. So I know I said
that start is ninety percent router. That's if you're consuming
the whole the whole framework. But really at the end
of the day, what Start is is just the ability

(01:11:25):
to do SSR if you want and server functions. That's right.

Speaker 2 (01:11:32):
I love that. And and by the way, I told
Dan Abramov when he was on the show that the
because you know, they were they were getting huge pushback
against React server components, and you know, and I know
that it. The React team got a lot of pushback

(01:11:55):
that they weren't used to get. That's put it this way.
They were always The last time they got such pushback
from the community was I think more or less when
they introduced x and they had hoped that the reaction
would have been similar to the reaction that they got
when they introduced hooks, which were really quickly adopted by

(01:12:19):
the creatity. And the key difference was that hooks you
could basically take it or leave it. You could use
it on a per component basis. So when you could
take an existing React application and decide that I'm not
going to touch any of the existing code, but new
components that I'm adding would use hooks and everything would

(01:12:41):
just work.

Speaker 5 (01:12:43):
Andiquire an architectural overhaul.

Speaker 2 (01:12:46):
Exactly. It was at the component level, and if you
can do that for React server components. That would be amazing.

Speaker 5 (01:12:57):
In my opinion, it's fine that it requires an architectural overhaul.
It's going to require something. If it involves a server,
you're going to have to do something architecturally. I just
think that rolling up that architecture change into hey, you
have to adopt this entirely new framework, that's a hard
pill to swallow. And you know that's both next JS

(01:13:18):
is in and I think React routers hope is that hey,
just buy into our router and will take care of
the rest, right And unfortunately for me, that's that's the heart.
That's an even harder pill for me to swallows because
I don't really like the routers that I see out there.
I don't like next JSS router, and I moderately enjoy

(01:13:42):
React router, but it lacks a lot of things. For me,
I'm definitely not happy using it anymore. And so knowing
that other people are going to have to make that
same sacrifice to say, oh, yes, I have to buy
into next JS all of it, or I have to
buy into React router at least if I want to
get on a path to use these latest React features

(01:14:04):
That's not something that I want to have to do
even myself, and I don't want to have to make
other people do that as well. So I'm trying my
hardest to build start in a way that can be
consumed without having to just turn your entire application upside down.
There's always going to be a little bit of buy in,
you know, you have to buy in a beat. You're
going to have to buy into servers in general, Like

(01:14:27):
I hope your company lets you run server code, because
a lot of a lot of front end devs are
not allowed to provision servers.

Speaker 2 (01:14:35):
So I'll put it this way. When a while not
so long ago, I was interviewing at a couple of companies,
and I was interviewing at senior technical rank. So one
of the things that I was looking at during the
interview process was actually the technologies and architectures that they

(01:14:58):
were using for the front end. And what I saw
is that all of them were using React, and almost
none of them was using SSR or any other any
consequently any meta framework. And if you could provide the
ability for such companies to start leveraging the benefits of

(01:15:24):
React on the server side in a way that does
not disrupt their existing architecture and their existing code base.
That that's a huge benefit.

Speaker 5 (01:15:35):
Yeah, I agree, And you know, I came from that
world where like I wasn't going to start even on
my small team, I didn't want to have to provision servers.
My team. We had our APIs written in a different language,
you know, distributed through a very different means, Like I
wasn't going to touch server code anytime soon. I mean,
a lot a lot of very successful applications and enterprise

(01:15:58):
companies like to even think about, oh yeah, our front
end developers are going to start running server side code.
Is a big leap because just the way that you know,
APIs need to scale, they get their own teams, they
turn into different languages. I just think that there's so

(01:16:19):
many more benefits that we should be looking to give
front end developers right now who work on these kinds
of applications and large enterprise applications, who you know, so
many of them won't even be able to touch server
components until their company finally decides years from now to
let them run server side code. So yes, I'm excited

(01:16:42):
about you know, the server and I'm trying to go
down that path as much as I can, but I'm
still so heavily invested in the client side tooling space.
I think Query has been phenomenal for the industry. I
think Table is great. I think tan SAK router is
still the most underrated part of what I'm building, because

(01:17:06):
if you're if you're a client, if you're a client
side application, and you're going to stay a client side application,
I really don't understand why you would even consider using
next JS or React router at this point. There there's
just if you if you're questioning that, then you should
DM me and I'll talk to you about it. Because

(01:17:27):
I built Tansac router for enterprise routing use cases and
it truly shines. So yeah, those that in that part
of our industry is very underrepresented and soft spoken, especially
on places like social media and Twitter. There's very very big,
successful applications being maintained by very smart people that we

(01:17:50):
never hear from on Twitter or x or anywhere like that.
So I know they exist though, and I talk to
them offline, I talk to them in DMS, and I'm
trying to represent them as well.

Speaker 1 (01:18:02):
Oh, Dan, we need to get wrapped up here because
it's been a long time here, so let's do some
last words from both of you guys, and we'll move
on to picks.

Speaker 2 (01:18:10):
Now. One thing that I wanted to talk about, but
I don't think we have time, so we can do
it in the future time is but like some of
the downsides of our PCs that existed again way back
in the nineties, rpc's, for example, tended to be chatty protocols.

(01:18:30):
They also tended to introduce a lot of endpoints and
generally introduce various maintenance issues. But I don't think we
really have time to delve into this this time, so
maybe we should bring you on to talk about RPC
in depth.

Speaker 5 (01:18:46):
Sometimes I can give you a thirty second teaser on
that if you want. I think that there's some chattiness
that can happen. But I think if you're using them
for your actual source of truth on full stack stuff,
some interesting things there, like actually building full stack APIs.
But if you're just using them to then you know,

(01:19:07):
do secure things on the server that communicate externally with
your other API or back in, I mean, I think
that some of that chattiness can be justified. And then
also there's there's fun things about server functions that we
didn't even get to talk about, but we've added validation
to our server functions strategies. We've added type safe middleware

(01:19:29):
to our server functions, which is very very powerful where
you can wrap up client side and server side transactions
through server functions and do really really cool things. And
then also being able to do public rpcs in the
future is something that we're considering. So once you've written

(01:19:51):
an RPC in Tanstak, the only thing keeping it from
becoming a fully blown rest like httpn point that's public
just supplying a path, a static path. So we're we're
considering allowing people to even build public rests and points
like static paths that they'll be able to use not

(01:20:13):
just in their application side by side as an RPC,
but even call into with say an RPC client that's
generated for their React native app or for a bunch
of different projects and kind of create some tooling around that.

Speaker 2 (01:20:27):
You know what would be awesome if we brought both
you and Ryan on the show to talk about our PCs.
I think that would be amazing.

Speaker 5 (01:20:34):
Anytime you get me and Ryan together, it's going to
be a party. So I would love to I would
love to come on with Ryan.

Speaker 2 (01:20:40):
Okay, right right, friends, I'll try to organize it.

Speaker 1 (01:20:44):
Okay, all right, well, thanks thanks Tanner. If you wanted
to learn more about canstackcanstack dot com is the place
to go docs and demos and all kinds of goodies.
So with that, we'll move on to Picks Picks, to
the part of the show we get to talk about
things that we want to talk about that maybe aren't
tech related.

Speaker 3 (01:21:05):
Oh could be.

Speaker 1 (01:21:06):
Let's see, Aja, you've been quiet, what do you got
for us for picks?

Speaker 8 (01:21:11):
So I was looking for something to play just I
was in a video game mood, and I was very,
very kind of disheartened that a lot of the games
I really loved as a kid, they have not been
recreated in a similar form like GoldenEye. I figured, there's
got to be something like GoldenEye, but there aren't really
any other games other than GoldenEye in Perfect Dark where

(01:21:33):
you sneak around and assassinate people through a maze to
accomplish some goal. And I ended up trying out something new.
I've never even heard of the genre of four x
but it's explore, extend, exploit, extinguish, something like that.

Speaker 4 (01:21:53):
It's like the Microsoft strategy.

Speaker 3 (01:21:55):
It sounds like Microsoft.

Speaker 8 (01:21:58):
Yeah, so Civilization six is kind of like Age of
Empires or Command and Conquer mixed with SimCity. And it
is heavily, heavily heavily discounted right now because SIM or
Civilization seven is about to come out, And so for
all the different platforms for Nintendo Switch, you can check

(01:22:21):
on GG dot Deals GG as in Good Game GG
dot Deals, or decu deals dot Com deku as in Decotry,
and you can get either the premium package or just
the base game for two three, four five dollars. And
it's my warning is that it's addictive if you have

(01:22:44):
an addictive personality, if you like things where you have
to mind max and strategize to figure out the best route.
It's every every time you play the game. The map
is randomized, and but you have a civilization that has
certain been fits like what it can build earlier or whatever.
And you you get a couple hours into the game

(01:23:06):
and then you're past or I guess past. You get
into your next age and new things unlock and you
have other civilizations on the board. It's like it's also
kind of like Risk and that there's different civilizations on
the board. And you're trying to basically gather more land
before they do and and mass more points to some
of the AJM.

Speaker 2 (01:23:28):
I'm looking at the GG deals page right now and
they're selling them for under three bucks.

Speaker 8 (01:23:35):
Yeah, sont for the next one. My one caution would
be don't buy it for Mac, because after I got
it for Switch, I also got it for Mac. Basically,
my it doesn't work. It doesn't work. The game opens,
it crashes if you can keep it open long enough,

(01:23:59):
you can't.

Speaker 4 (01:24:00):
You can't move it from one monitor to another. All
of the key bindings or Windows key bindings like with
numb pad and f F six and all that sort
of stuff. You can change those key bindings, of course.
But my assumption is that they never tested it on
Mac whatsoever, that they use some sort of framework that
allows it to compile on different operating systems, and they

(01:24:23):
just hit the compile button and they said, oh, the
Mac build finished, okay, uh, put up the digital code.
But I don't think that anyone. I don't think any
of the developers of the game have ever tested it
on a Mac. And if you look at any of
the reviews that are one star reviews, they're all mentioning Mac.
It doesn't run on Mac. It doesn't actually like it

(01:24:43):
will install, it will open, you can click two or
three buttons and then it crashes, so don't do that.

Speaker 2 (01:24:50):
So you're basically saying, if you've got the computer at home,
get it for ecne on Farmac.

Speaker 6 (01:24:57):
Yeah.

Speaker 8 (01:24:57):
I might even run on Linux. I don't remember if
that was on there, but yeah, Windows or Xbox or PlayStation.
You the consoles are good because Microsoft and Nintendo and
Sony will rip you a new one if your game
just crashes when you start it, whereas Steam doesn't care.
Steam's like, oh, game just crashes when you start it? Uh,

(01:25:18):
contact the publisher.

Speaker 4 (01:25:19):
We don't care. We just take the money, all right.
That's my one thing.

Speaker 3 (01:25:24):
Thank you, Dan. You got any picks for us?

Speaker 2 (01:25:27):
Yeah, not a lot.

Speaker 5 (01:25:29):
I have a I have a hard stop right now,
and I don't don't how many picks, So I'd be
happy to do my sign off, but I gotta run.

Speaker 3 (01:25:38):
Okay, Thanks for coming, Tanner.

Speaker 5 (01:25:39):
Thanks guys for having me. I do want to come
back on and talk about server stuff with Ryan Carneado,
so let me know.

Speaker 2 (01:25:45):
Make sure to organize that. Now. You've given me extra
incentive that would be so awesome.

Speaker 5 (01:25:52):
Thank you so much. Good to see you guys.

Speaker 2 (01:25:56):
Awesome, thank you. So my pick is I've been an
Anthony justiniic fan for a long time. You guys know
who he is. He's like this edgy stand up comic
and I really have enjoyed his material over the years.

(01:26:18):
We even had this one really pleasant surprise where when
we went to this stand up club in LA and
he made a surprise appearance there to try out new stuff,
new material, So that was really awesome. And I really
loved his shows that he did in the past, Thoughts
and Prayers and Fire in the Maternity Ward. And now

(01:26:43):
he's recently come out with a new show called Bones
and All and it's okay. I watched it and I
enjoyed it, but it wasn't as good as his old shows.
So if you're an Anthony Justinic and you haven't watched
it yet, you know you should. But don't expect it

(01:27:06):
to be as great as his previous his past stuff.
I don't know why that's that's just my take on it.
But anyway, that would be my pick for today.

Speaker 1 (01:27:17):
Alrighty, I will go last year. Since I'm the my
picks are always the high point. First pick is a
reference to something that Tanner said during the when he
was talking earlier and he talked about how we got
Nerd Sniped reminds me of one of my favorite XKCD
cartoons called Nerd Sniping. It's number three, five six, So

(01:27:41):
considering where things are right now, it's a very early,
early one and it's called nerd Sniping, and it's it
describes it perfectly. Makes me laugh every time I read
this cartoon. But yeah, I go check it out Nerds
x k CD number three, five six. And for the

(01:28:04):
dad jokes of the week, it's been a while so
so I have a.

Speaker 3 (01:28:09):
Plethora to choose from.

Speaker 1 (01:28:11):
The other day, I was talking to a friend of
mine and I told him, hey, I took my wife
to the Caribbean last month, and he said Jamaica.

Speaker 3 (01:28:17):
I said, no, she wanted to go.

Speaker 1 (01:28:22):
Also, did you know that you're actually born with four
kidneys when you grow up, two of.

Speaker 3 (01:28:28):
Them become adult nies.

Speaker 1 (01:28:32):
And finally, it really annoys me when people get well
known phrases wrong. I mean, seriously, it's not like his
rocket surgery. Anyway, those are the dad jokes of the week,
We'll say thanks to Tanner for coming on and talking
about tan Stack. Sounds like we're going to get another
episode scheduled with him and Ryan Carneatto.

Speaker 2 (01:28:55):
I really hope, so I'll do my I can only
promise to do my best.

Speaker 1 (01:28:59):
Dan has connect everywhere. Man, if we want to get
somebody on, just talk to Dan.

Speaker 3 (01:29:03):
He knows more. Thanks guys for

Speaker 1 (01:29:06):
Coming on, Thanks to Tanner for coming on, and we'll
talk with you all next time on Jobs Hit Gebor

All Episodes

TanStack: A Deep Dive into Server Functions and Routing with Tanner Linsley - JsJ 667

Episode Transcript

Popular Podcasts

Dateline NBC

Stuff You Should Know

Law & Order: Criminal Justice System - Season 1 & Season 2

.css-15opob5{left:0;position:absolute;top:0.8rem;} All Episodes

.css-14f5ked{margin:0;word-break:break-word;display:-webkit-box;-webkit-box-orient:vertical;box-orient:vertical;-webkit-line-clamp:2;overflow:hidden;}TanStack: A Deep Dive into Server Functions and Routing with Tanner Linsley - JsJ 667