0:16

and play over 100 online casino

0:18

style games, all for free. Go

0:20

to chumbacasino.com to collect your free

0:22

welcome bonus. Sponsored by Chumba Casino.

0:25

No purchase necessary. VGW Group. Void

0:27

where prohibited by law. 18

0:29

plus terms and conditions apply. Now taxes, Now

0:31

taxes is 100% free when

0:33

you file in the TurboTax app if

0:36

you didn't file with us last year.

0:38

Oh yeah? Yeah, just do your own

0:40

taxes in the app by 218. What

0:43

if I have lots of forms? All

0:45

good. All 100% free. What if I

0:47

had three jobs? Still 100% free.

0:49

Still 100% free. Now that's what

0:51

I'm talking about. Now this is

0:54

taxes. See if you qualify

0:56

in the TurboTax app. Excludes Terb attacks

0:58

live must start and file an app

1:00

by 218. Hello

1:06

everybody welcome to another exciting episode

1:08

of JavaScript Jabber. I am Steve

1:10

Edwards the host with the face

1:12

for radio and the voice for

1:15

being in mind But you're stuck

1:17

with me as your host Today

1:19

with me on our panel we

1:21

have mr. Dan Shapiro. How are you

1:23

doing Dan? I'm fine. Hello from Tel

1:25

Aviv Where it's probably really warm

1:27

right? Not super warm, but nice.

1:29

You know you can wear a t-shirt

1:32

outside if you like right? Yeah,

1:34

I was just oh I'll diverge

1:36

a little bit here. I was

1:38

just in Thailand. I've been gone

1:40

for a couple weeks, was visiting

1:43

my daughter there, and in Thailand

1:45

it's really, really warm. It barely

1:47

gets below 70 Fahrenheit during the

1:49

year, even at the lowest point

1:51

in the year. And on the

1:53

way there, we got delayed 24

1:56

hours in Seoul. Korea. And to

1:58

say it was cold is the

2:00

understatement of the year. We went

2:02

from, I told when we left

2:04

Seoul and went to Chang Mai,

2:07

we went from 22 Fahrenheit to

2:09

22 Celsius. Because it was like

2:11

below zero cold, it was so

2:13

cold. We tried to go for

2:15

a walk one day and lasted

2:17

about three minutes and said, okay,

2:20

we're going back inside. So, but

2:22

yeah, Chang Mai was awesome because

2:24

we had, it was like in

2:26

the 80s Fahrenheit. You know, no humidity,

2:28

this is the coolest time of

2:31

the year, coolest in terms of

2:33

temperature, not because I was there.

2:35

But, um, but yeah, it was

2:37

perfect, perfect weather and then I

2:39

came back from wearing shorts and

2:42

no coat, I'll wait two, bundling

2:44

up and, and, uh, having multiple

2:46

blankets on the bed. So, Tel

2:48

Aviv is not in the 80s,

2:50

but it's in the high 60s,

2:52

low 70s. That's still pretty nice.

2:54

During the day. Yeah, that's nice.

2:56

And then also on our panel

2:58

we have Mr. A.J. How are

3:00

you doing A.J? You know, coming

3:02

at you live from the show.

3:05

Purple room. So it's better than

3:07

the alternative. Yes, coming

3:09

at you dead. Yes, I

3:11

agree. So and our very

3:13

special guest today is Mr.

3:15

Tanner Winsley of Tan Stack

3:18

Fame. How you doing Tanner?

3:20

I'm doing great. I'm very

3:22

excited. Good to be here. All

3:24

right, it's good to have you back.

3:26

We had, have had Tanner here in

3:29

the past on JavaScript, Java on episode.

3:31

What was it, Dan? I forgot the

3:33

number. Oh, I think it was episode

3:35

578. 578, talking about the tan stack.

3:38

And for those of you who might

3:40

be wondering, this is a question I

3:42

asked on the previous episode. It is

3:44

not called Tanner, because he is tan

3:47

because he is tan because he is

3:49

tan because he is tan because he

3:51

is tan because he is tan because

3:53

of tan. for those of you, unlike

3:55

me who made that logical jump, good

3:57

for you, but some of us aren't

3:59

that smart. Anyway, so we

4:01

are here today to

4:03

talk about actually before we get

4:05

into start Let's just give a brief

4:07

description of what the tan stack is

4:09

overview for those who might not have

4:11

heard of it before You

4:15

guys are gonna give that right not me Yeah,

4:19

yeah, sure, let me pull up the

4:21

about us page You'll

4:23

do it. Thank you. So I could do

4:26

it if you want to but I Know

4:31

so I I started tan

4:33

stack as like an open

4:35

source GitHub organization a

4:37

couple of years ago to

4:39

start collecting all of my libraries that I was

4:41

building it started

4:43

with React table

4:46

and then react

4:48

query and we took both of those

4:50

agnostics. So they became something that I Didn't

4:52

want to have to like brand,

4:54

you know, every framework times every

4:56

library that I had So

4:59

I decided to call it tan stack

5:01

And so I pulled all those libraries

5:03

together and then we kept building. So

5:05

now there's a There's a

5:07

virtualization library called tan stack

5:09

virtual. We have some

5:12

Libraries that are for like helping

5:14

you build open source packages. We have

5:16

our own store now our reactive

5:18

store Tan

5:20

stack form is an

5:22

agnostic headless form Library

5:25

which is pretty sweet. It's almost

5:27

1 .0, which is pretty pretty

5:29

cool What is that? Is that like a form

5:31

rendering library where you provide the underlying structure

5:33

and it renders the form or what exactly? Yeah,

5:36

it's it's more around just

5:38

like the state management the validation

5:40

and the form life cycles

5:42

Four forms like for doing client

5:44

side and full stack forms

5:46

But it's headless. So when it

5:48

comes time to render those

5:51

forms you attach the form logic

5:53

to Whatever

5:55

you want, whether it's like

5:57

a component library or just a raw input

5:59

something like that Yeah, so it

6:01

gives you full control over

6:03

you over your UI, but

6:05

gives you all of the nice

6:07

logic and validation of the

6:10

form state that you would expect.

6:13

That's cool. Yeah, Corbin correctly

6:15

is the one who's kind

6:17

of heading that up. We

6:20

combined our libraries together.

6:22

He was building. I can't remember

6:24

when he was built. It's been a while.

6:27

It's been about two years. But he was

6:29

building a form library that was supposed to

6:31

kind of be the next version of Formic.

6:33

But it was react only. And then I

6:36

was building one that was really, really

6:38

type safe and agnostic. So we put

6:40

him together and that became 10 stack

6:42

form. According to

6:44

the description, it helps you

6:46

quote, stop crying over your

6:49

forms. So obviously you have

6:51

experience in working with forms.

6:53

I don't cry too much.

6:56

But if there's something that

6:58

would make me cry, it

7:01

would be building forms. Yeah.

7:03

By the way, are you familiar

7:05

with the vest form validator?

7:07

The what validator? Sorry? Vest.

7:10

No, I'm not. It works

7:12

at Meta, but it's his

7:14

own project. It's interesting in

7:16

that it does form validation

7:19

in a way that looks

7:21

very much like unit testing.

7:23

Interesting. Yeah, I would love

7:25

to look at it. That sounds cool.

7:27

So it's called Best. Okay. Needless

7:30

to say, he's, you hear

7:32

this coming, very invested in

7:34

it. Sorry, that was just hanging

7:36

out there. I had to grab

7:38

that one. Oh yeah, like a

7:40

multiple. So that so form is

7:43

kind of another one we're working

7:45

on and then obviously the last

7:47

so a year ago we did

7:49

1.0 for 10 stack router which

7:52

I'd been working on for several

7:54

years before that as well

7:56

and now we're here to talk

7:59

about start. which is so before

8:01

we go there I notice that you

8:03

have a few more things on the

8:05

10 stack site you've got 10 stack

8:08

Ranger what is that Ranger is

8:10

it's not it's not used as

8:13

much in my opinion it's a

8:15

fun little library from my past

8:17

but you can use it to

8:20

create multi range sliders so if

8:22

you ever use the range

8:24

element you've got that single

8:27

slider Yeah, we needed some that

8:29

had both handles that you'll kind

8:31

of see for range slider selectors. And

8:33

then we even had some that

8:36

would create steps. So we'd have

8:38

like three or four different handles

8:40

on an individual range input and

8:43

you'd be able to kind of

8:45

create different steps using different handles.

8:47

So it's a headless library to

8:50

create those. We wanted it to

8:52

have a very custom UI. I

8:54

don't use it as much

8:57

anymore admittedly, but it's

8:59

still a pretty cool

9:01

library. And also tends

9:03

to that config. Yeah, the

9:05

config is what we use

9:08

for publishing all of our

9:10

libraries. So it helps us

9:13

both build all of the

9:15

different versions like ESM

9:17

and CommonJS, like legacy

9:20

and modern versions. and

9:22

it helps us publish

9:24

those to TanTech

9:27

using, or to NPM using

9:29

kind of our, it's

9:32

based on angular semantic

9:34

versioning, but

9:37

basically lets us

9:39

do all of our PR

9:41

automation for releasing

9:43

new versions and

9:45

whatnot. Cool. Okay, so

9:47

now back to Ten Stack

9:50

Start. I'm going to be

9:52

honest, it's like 90% of start

9:54

is just tan stack router because

9:56

routers are frameworks. There's

9:58

not really. any way around

10:01

that. But we decided to, I

10:03

decided to build the router

10:05

first, it's just like a

10:07

client side router that would

10:09

have some SSR utilities on

10:11

top of it. But then trying

10:14

to put together your own

10:16

SSR environment really sucks, which

10:19

is why like meta frameworks,

10:21

as we call them, exist.

10:24

So Tansek's start is like

10:26

the official implementation of. getting

10:28

server features into a 10

10:31

stack router application. That mostly

10:33

includes, so you get SSR, which

10:35

is the very first thing

10:37

which most people want. It

10:39

gives you streaming on top

10:42

of that as well, so

10:44

all the new streaming, you know,

10:46

APIs that React has for

10:48

suspense and just being able to

10:50

stream data down in responses in

10:53

general. And then it gives

10:55

you bundling. for both, like for

10:57

all the environment. So it bundles

10:59

the client side, the server side,

11:02

and it also bundles for server

11:04

functions, which is, it's our version

11:07

of being able to access, you

11:09

know, all of the server features

11:11

that you would expect. But that's

11:13

where it gets a little interesting.

11:15

I think we could discuss that

11:18

a little bit more, but server

11:20

functions are really cool. Before we

11:22

get to server functions, which

11:24

I will definitely want to

11:26

discuss, our PCs is a favorite topic

11:28

of mine and actually had an

11:31

episode on JavaScript Java when I

11:33

spoke about our PCs. I don't

11:35

even, I don't remember the number

11:37

off the top of my head.

11:39

What about the end? I would

11:41

check both places. Yeah, that's true.

11:44

I think it's worth mentioning though,

11:46

because I think we kind of

11:49

skipped it that all of your...

11:51

libraries, utilities, frameworks, whatever, they're

11:53

all built on top of react,

11:55

right? There's nothing like, you

11:57

don't, you haven't implemented your own.

12:00

Step And

12:05

luck. I'm going to make him an

12:07

offer he can't refuse. With family, canoles,

12:09

and spins mean everything. Now, you want

12:11

to get mixed up in the family

12:13

business. Introducing the Godfather at Chompa casino.com.

12:16

Test your luck in the shadowy world

12:18

of the Godfather slot. Someday, I will

12:20

call upon you to do a service

12:22

for me. Play the Godfather. Now at

12:24

Chompa casino.com. Welcome to the family. No

12:26

purchase necessary. VGL Group. VGW were prohibited

12:28

by law. 18-per terms and conditions and

12:30

conditions and conditions apply. Terms and

12:33

conditions apply. Terms and conditions apply.

12:50

View framework or whatever it's supposed

12:52

to be called. No,

12:55

they're not built on top

12:57

of React. We have

12:59

React adapters for all of them. So

13:02

every single one of these

13:04

libraries is in fact called

13:06

Tan Stack something because it's

13:08

no longer just React. So

13:11

for instance, Tan Stack Query

13:13

has adapters for React and

13:16

View and Svelte and Solid.

13:19

Tan Stack Virtual has adapters for all

13:22

of those and so does Tan Stack

13:24

Form and Table. Tan

13:26

Stack Router is the only one

13:28

that is currently React only. And

13:31

that's mostly just for

13:33

our own sanity's sake right

13:35

now. Basically

13:38

because we just wanted to get

13:41

all the way finished from

13:43

zero to 1 .0 on one

13:45

framework. We're still preparing

13:47

the code base and writing

13:49

it to be agnostic, but

13:51

we're just not trying

13:54

to do too much at

13:56

once. You think it's really

13:58

doable? I think I spoke with...

14:00

Ryan Carniato a while back where he

14:02

told me that, I think it

14:04

might have been him, maybe

14:06

I'm confusing it with somebody

14:08

else, but I think it

14:10

was probably him and he

14:13

probably said something along the

14:15

lines that he came to

14:17

the conclusion that writing a

14:19

true multi-frame work router is

14:21

bordering on impossible or

14:23

something. I've recently changed

14:25

his mind. He had some concerns

14:27

and so did I honestly. And

14:30

we got together and we've been

14:32

talking for, I mean, years. We

14:34

go back a long time and

14:36

we've been chatting a lot about

14:38

this and recently he's like, oh,

14:41

you know what, with our

14:43

new solid 2.0 stuff they're

14:45

working on and the new

14:47

assink data primitives, there's really

14:49

no concerns anymore. It's just

14:51

opinions on top of routing and

14:54

life cycles for navigation. So

14:56

really what we're going to do is

14:58

actually I'll let you in on some

15:00

fun news. So it's nothing, it's something

15:02

official and it might never,

15:05

might never become something official,

15:07

but behind the scenes, so

15:09

the tan stack start and the

15:11

solid start team, we're working

15:13

very very closely now on a

15:15

lot of things. So mainly one

15:17

is that tan sex start and

15:19

solid have both been based on

15:21

Vinci up to this point. which

15:23

is awesome. It helped us get

15:25

to where we are today. But

15:28

to better consume nitro

15:30

and to even further

15:32

align our architectures, we

15:34

are moving away from

15:36

Vinci to just a

15:38

unified layer for start,

15:40

essentially, and it's just going

15:43

to have some server function

15:45

plug-ins, a nitro coordinator,

15:48

and that's going to set

15:50

the stage for Tanstack. router

15:53

for solid so

15:55

solid router and that's

15:57

that's not that's

16:00

is a semi-active development. We have some

16:02

people who are, you know, we're

16:04

separating some of the utilities, we're

16:06

making sure that, you know, we're

16:08

not mixing up framework types and getting

16:10

ready to build these adapters. But

16:13

essentially, there's nothing blocking

16:15

us now. If I wanted to divert

16:17

all my tension to solid router and

16:19

solid, you know, getting that working in

16:21

solid. I could do that today, but

16:23

I'm not going to do that

16:26

till we get the react one

16:28

done. So a question about that.

16:30

project names, some of which I'm

16:32

familiar with, some of which less

16:34

so. Vinci, Nitro, also as I

16:36

recall, Vinci is built on VIT.

16:39

So can you tell us a

16:41

little bit about all these projects?

16:43

I would love to. So let's

16:46

start at the bottom level.

16:48

So all of this is based

16:50

on VIT. We're 100% bought into

16:52

the VIT ecosystem. I believe it's

16:54

a future. So we wouldn't be

16:56

able to do any of this

16:59

without beat. And at the end

17:01

of the day, a lot of

17:03

this boils down to just VET

17:05

and VET plugins. And some of

17:07

it is going to use the

17:09

new VET6 environment APIs. And some

17:12

of it we can just do

17:14

today already, just by building

17:16

multiple environments ourselves.

17:19

So then on top of VET,

17:21

there's nitro. So nitro is this

17:23

toolkit that it uses VET.

17:25

but it helps you build your

17:27

back end code to work basically

17:30

anywhere you want to deploy it.

17:32

So you can use nitro as

17:34

this unified layer, nitros by the

17:36

unjust team, and it has this

17:38

unified layer for pretty much

17:40

everything you'd want to do on

17:42

the back end. You can write your

17:45

code mostly one way and deploy it

17:47

to basically anywhere that they

17:49

maintain an adapter for, and

17:52

it will just work. So

17:54

they handle the deployment part

17:56

of building a framework slash

17:59

meta frame. work for you

18:01

because that's obviously a big

18:03

challenge having to deploy to

18:05

all the different platform. But

18:07

like to put it into

18:10

perspective if you so so like

18:12

next JS and remix they have

18:14

to maintain their own adapters

18:16

to build their projects

18:18

into the right formats

18:20

for all these different

18:23

deployment destinations. Nitro does

18:25

that's nitro does that's

18:27

nitro does job. And so

18:29

if you just use nitro, you

18:31

don't have to worry about that

18:34

and duplicate all that effort. You

18:36

just get to use what nitro

18:38

has built. So literally for

18:40

me, I recently migrated a

18:42

site from Versailles over to

18:44

Netlify. And it was literally

18:47

the difference of me going

18:49

into my config and saying

18:51

deployment, you know, I think

18:53

deployment preset, I think is what

18:56

it's called. I just changed it. It's

18:58

a string. I just changed it

19:00

from Versailles to Netlify. And

19:02

when I rebuilt it, it

19:05

just rebuilt everything for Netlify

19:07

instead. I didn't have to

19:09

change anything. Also, it seems supports

19:11

AWS, cloud flare, whatever, and so

19:14

on and so forth. Yeah. And

19:16

so Nitro is built on top

19:18

of VET and they're upgrading to

19:20

the new VET APIs as well.

19:23

It's the clearest path for

19:25

no duplicated effort really whatsoever

19:27

is they're going to maintain

19:30

these adapters And we're going

19:32

to use nitro directly and you

19:34

get to use the nitro APIs

19:37

in your apps as well So they

19:39

have wonderful products like

19:41

uns storage where you just

19:43

kind of have this unified

19:45

storage API and you supply the

19:48

drivers And that driver may map

19:50

to you know one type of memory on

19:52

this house or you can map it to

19:54

another one if you're using cloud flare you

19:56

can map it to D1 or something like

19:58

that. So they have a real... great like

20:00

abstraction for all

20:03

of these different implementations

20:06

of features that we like

20:08

to use on servers. I'm

20:10

curious aside from you guys

20:12

you and Ryan and who

20:14

else is using them for

20:17

what project? It actually

20:19

came out of the view

20:21

in the next ecosystem. So

20:24

next is built on top of

20:26

unjust essentially like all of it.

20:28

And that's what they use. So

20:30

UnjS and Nitro is kind of

20:33

like the lower level server toolkit

20:35

and the primitives that came out of

20:37

the next project. I was wondering

20:39

if there was a relationship because

20:41

I remember talking with Daniel Rowe

20:44

about Nitro when that first came

20:46

in when they first started using

20:48

that and the speed increase was

20:50

supposedly really phenomenal. And you

20:52

know who else uses it is

20:54

Brandon who built? So it's really interesting

20:56

that VEED came out of view

20:59

and now NITO came out of

21:01

view that uses nitro but

21:03

for angular. So he built

21:05

his own angular meta framework and

21:07

it uses nitro under the

21:09

hood. Very very cool. That's

21:12

how powerful and portable it

21:14

is. So it's really interesting that

21:16

VEED came out of view and

21:18

now nitro came out of view.

21:21

So views contributing a lot to

21:23

the framework. space way beyond

21:26

view itself. Yeah, absolutely.

21:28

There's a lot of

21:30

things about Nux that

21:32

have been pushing forward

21:35

what we've been able

21:37

to do outside of

21:39

like Nux itself. It's

21:41

pretty sweet. So Vinci,

21:44

Vinci is built by

21:46

Nikil Saroff and... Nikil

21:48

was working on the solid team

21:50

for a little while. I think

21:53

he still is technically started the

21:55

part of the solid team. But

21:57

before v. Six came out, there

21:59

wasn't. really and

24:01

play over 100 online casino

24:03

-style games, all for free.

24:05

Go to chumba.com to collect your

24:07

free welcome bonus. Sponsored by

24:10

by chumba no purchase necessary. VGW

24:12

void where prohibited by law. 18

24:14

plus and conditions apply. apply. hearing

24:18

is hardy, fibrous immense siding

24:20

living up to its reputation

24:22

as the siding that handles

24:24

hail impact with ease. James

24:26

Hardy knows how important a

24:29

reputation is, especially when you're

24:31

a contractor. That's why Hardy's

24:33

siding withstands severe weather better

24:35

than vinyl siding, with styles

24:37

to match its strength. So

24:39

you can be sure you're

24:41

providing your clients with the

24:43

best. Protect your reputation with

24:45

exterior products by James Hardy.

24:48

Implemented in what, by the way? Well, sorry,

24:50

what do you mean? What are

24:52

you, well, of course, I,

24:54

it's, of course, I assume it's

24:57

Java, well, typescript, but like,

24:59

what libraries are you using

25:01

there? Is it, like, based on

25:03

signals, because it's Ryan or?

25:05

No, so, so this layer is

25:07

mostly going to be a

25:09

collection of veat plugins

25:11

that are very configurable

25:14

and they'll use Babel

25:16

under the hood. And really, it

25:18

will all come together in hopefully

25:21

what is going to be a

25:23

very thin layer on top of nitro.

25:25

So essentially just feeding

25:28

nitro a unified config

25:30

to say, here's what I want

25:32

you to build for my

25:34

server environment, for my SSR

25:36

environment, and for

25:39

my client environment, the

25:41

bundles particularly. And just

25:43

to kind of make

25:45

all that cohesive. Yeah, it'll

25:48

just be typescript. At the end of

25:50

the day, what I would like to

25:52

have it be is just a beat

25:54

plug-in itself, which kind of sounds weird.

25:57

It's a beat plug-in that would call

25:59

into night. road to produce

26:01

many different environments and

26:03

build even more beat the bundles.

26:06

So, but that's, I think that's

26:08

the beautiful part about it is

26:10

that if we can boil it down

26:12

to just beat plugins, I think it's

26:14

going to be really powerful. And

26:16

that's basically going to be like

26:18

under some sort of a start

26:20

moniker. Yeah, most likely. We'll

26:23

probably just share internal packages

26:25

privately for now. and each

26:27

one of us will just

26:29

export our own builders for

26:31

it so you'll still you

26:33

know you'll probably build something

26:35

like create 10 stack start

26:38

beat will be like one of

26:40

our packages and you'll call that

26:42

function and it will produce all

26:45

the beat plugins that you need

26:47

to add to your build essentially

26:49

and by the way one

26:51

thing that you said before

26:53

that the 10 stack router

26:55

was 90% of the way

26:57

towards 10 stack start in

26:59

terms of being a framework.

27:01

I think Ryan Florence more

27:03

less said the same thing

27:06

about remix and react

27:08

router. I think they're

27:10

even kind of merged

27:12

the two projects together

27:14

for that reason. Yeah, I

27:17

don't, I wish that maybe that

27:19

maybe that had been recognized

27:21

sooner so that they didn't

27:23

have to go through kind

27:25

of the snip snap snip

27:27

snap kind of a pattern

27:29

because it's always been apparent

27:31

that the router is what

27:33

drives much of what you

27:35

do. That's where all the

27:37

opinions are and where you're

27:39

feeding, you know, it's calling

27:41

into your code and scheduling

27:43

its own things and doing

27:46

something. So it very much

27:48

is the framework. I yeah

27:50

I don't have a whole lot

27:52

to say there other than I

27:54

just wish that they had

27:56

maybe it would have been better

27:59

for their branding I

28:01

think if they hadn't have

28:03

done like, oh, it's remix

28:05

and then they took React

28:07

router and put it into

28:09

remix and now it's React

28:11

router and they're putting remix

28:13

back in there. It's very

28:16

confusing. It should have just

28:18

been incremental from the beginning.

28:20

They should have built remix

28:22

as an add-on to React

28:24

router. But I don't know.

28:26

It was. That was merely

28:28

an idea that I had.

28:30

I just wanted to build

28:32

my own router and I

28:34

knew that I wanted it

28:37

to be client-side only and

28:39

that server-side features were going

28:41

to come later. I'm very,

28:43

very grateful that they were

28:45

willing to go guinea pig

28:47

that process and probably find

28:49

out the hard way that

28:51

it should have just been

28:53

react router all along. So

28:56

I'm not complaining. They have

28:58

done me a great favor

29:00

in research and Yeah. By

29:02

the way, I'm curious, do

29:04

you think that maybe routing,

29:06

client-side routing, I mean, should

29:08

have been part of the

29:10

platform in some way? Which

29:12

platform? Like the web platform?

29:14

Yeah, like, Dom APIs for

29:17

client-side routing beyond the basic

29:19

history APIs. Or... I don't

29:21

know. I mean, it's easy

29:23

to say, yeah, that would

29:25

be great. But where would

29:27

those opinions come from that

29:29

would serve everyone? I don't,

29:31

I don't know. Because even

29:33

for projects that look, that

29:36

look a lot alike, even

29:38

for like, like, React router

29:40

and Tansack router, like, I

29:42

took good ideas from React

29:44

router, I took the loader

29:46

pattern. And, you know, a

29:48

couple other patterns that I

29:50

just thought, you know what,

29:52

these guys really nailed these

29:54

APIs. And then for other

29:57

things, I just did things

29:59

completely different. So can you maybe

30:01

talk a little bit about that?

30:03

Can you elaborate a little bit

30:05

about what is the loader pattern

30:08

and also about some of the things

30:10

that you've done differently? For

30:12

sure. So the loader pattern

30:14

is just a really fancy

30:16

way of saying like life

30:18

cycle management for navigation. Basically,

30:21

you click a link and

30:23

we know, hey, you're about to go

30:25

to this next page. And before

30:27

you even navigate, before we

30:30

try and render, before we

30:32

do anything about showing the

30:34

next content, you have life

30:36

cycle methods that will fire.

30:38

This goes way, way back

30:40

even to like knock out and

30:42

older, older frameworks that were

30:44

just like, oh yeah, they're

30:47

about to navigate to this new

30:49

page. Here's a function that you

30:51

can run before that happens

30:53

and potentially do some asynchronous

30:56

work. That concept that's a core

30:59

concept and then the loader pattern

31:01

is just applying That life cycle

31:03

method to data loading specifically

31:06

to say Before we navigate to

31:08

this route we need to make sure that

31:10

we have this data So when you hear

31:12

people talk about loaders That's

31:14

generally what they're talking about.

31:16

It's just a life cycle method

31:19

to ensure that data is present

31:21

By a synchronous, by the way, in

31:23

this context, you mean it's a

31:25

synchronous to the operation of the

31:27

browser, but it's not a synchronous

31:29

to the actual navigation. I mean,

31:31

you do need the data in

31:33

order to display the quote-unquote

31:36

new page. Right. Yeah, you might, and

31:38

again, here's another reason why it

31:40

doesn't really work to just

31:42

have some universal web standards.

31:44

Some frameworks will even wait

31:46

to change the URL before, like

31:49

until the data is loaded. And

31:51

for me, for instance, as soon

31:53

as they navigate, the URL changes

31:55

synchronously. And then the

31:57

side effect of rendering what the...

32:00

user wants to see is asynchronous.

32:02

So yeah, there's lots of opinions

32:04

there. Interesting. So that's what is

32:07

similar about what you've done in

32:09

react router. Can you talk a

32:11

little bit about what is different?

32:14

Because I also think that informs

32:16

some of the differences between 10

32:18

stack and other frameworks. Yeah, so

32:21

yeah, they both have loaders, they

32:23

both support. I mean, it's not

32:25

even limited to remix, but let's

32:28

just say like modern routers, kind

32:30

of the expectations for all modern

32:32

routers is that they have nested

32:35

routing the ability to like nest

32:37

route matching segments inside of each

32:39

other to do shared layouts. So

32:42

I apologize for interrupting you just

32:44

to clarify. Nested routing means that

32:46

you click a link. and you

32:49

go into let's say call it

32:51

a sub page or sub resource

32:53

in a sense or like in

32:56

part of the page stays the

32:58

same and then part of the

33:00

page changes or is that something

33:03

else and I'm explaining it wrong?

33:05

No that's that's exactly right and

33:07

it's the difference of it's just

33:10

encapsulation and reuse is what it

33:12

is. You could write your entire

33:14

router as a flat map. to

33:17

say this exact URL matches this

33:19

exact component. And if you have

33:21

components that share the same layout

33:24

like a navbar or a sidebar,

33:26

and this is back like with

33:28

older versions of NextHS, you would

33:31

have to render that navbar and

33:33

sidebar on every single page that

33:35

you wanted it to be on,

33:38

right? And that has implications, depending

33:40

on the framework you're using, that

33:42

sometimes those components would unmount and

33:45

remount, even though they look like

33:47

there. still there, you know, they

33:49

haven't changed. Yeah, that's that's one

33:52

of the things too. Yeah, there's

33:54

lots of these shared things, nested

33:56

routing is one of those things,

33:59

but it's Instead of having this

34:01

flat list of URLs to

34:03

components, you get to share those

34:05

URL routes. So say you have an

34:07

admin slash admin, right? You might have

34:09

a lot of sub pages on that

34:12

slash admin slash admin slash

34:14

users or whatever. And instead

34:16

of having to render like

34:18

the admin sidebar for every

34:20

single one of those sub pages, you

34:22

just render it once in

34:24

the admin layout component. And then

34:27

every single sub admin page

34:29

below that will get inserted into

34:31

that layout wherever you render

34:33

an outlet or render children

34:35

essentially. So you have this

34:38

sort of a slot where the sub

34:40

pages like, well, slotted in. Yep. And

34:42

that slot works for index

34:44

pages, which means, hey, we Hello,

34:54

it is Ryan, and we could

34:56

all use an extra bright spot

34:59

in our day, couldn't we? Just

35:01

to make up for things like

35:03

sitting in traffic, doing the dishes,

35:05

counting your steps, you know, all

35:07

the mundane stuff. That is why

35:09

I'm such a big fan of

35:11

Chumba Casino. Chumba Casino has all

35:13

your favorite social casino style games,

35:16

that you can play for free,

35:18

anytime, anywhere, with daily bonuses. So

35:20

sign up now at Chumba casino.com.

35:22

That's Chumba Cumba Casino. by

35:39

joining the James Hardy Alliance today. Yeah,

35:41

so nested routing is a big one. That

35:43

was kind of... That's that's one where

35:46

React router really nailed it. You

35:48

know, NextJS didn't have that for a

35:50

while and it was really enraging and

35:52

React router has had that for a

35:55

long time. When NextGS finally added

35:57

that, it was like, oh, well,

35:59

this is what. wonderful and it's

36:01

like yeah why didn't you do that

36:03

sooner? And that was a no-brainer for

36:06

us. It's like yeah we're gonna support

36:08

that. We're gonna do nested routes.

36:11

Things like file-based routing where you

36:13

can you know create that tree

36:15

using a file structure just

36:18

to kind of have maintenance

36:20

be nice and has some

36:22

opinions and convention around just

36:24

moving quickly. Loaders we

36:27

talked about. kind of just

36:29

your basic navigation APIs being

36:31

able to have links and you

36:33

know imperative navigate calls to kind

36:36

of move around your app that

36:38

all that stuff is pretty much

36:40

the same where it starts to

36:42

get different for from both next

36:45

j.s and remix is so tan

36:47

stack router basically was re- I

36:49

rewrote it from the ground up

36:51

with type safety at the

36:53

forefront. So every single decision

36:55

that I made. when I rewrote

36:58

this router was so that we could

37:00

have 100% inferred type safety. Essentially,

37:02

the goal was, I don't want

37:04

to have to write TypeScript

37:07

syntax in my routing, but

37:09

I want it all to be

37:11

extremely type safe. Type safe means

37:13

that if I put in an

37:15

invalid route, I get red squigglies.

37:17

Is that what type safe means

37:19

in this context? Yeah, I mean,

37:21

it means a lot of things.

37:23

That's one of them. And that's...

37:25

I like to call that. That is

37:28

the basic level one type safety

37:30

that I would expect out of

37:32

a router is that yeah, you

37:34

don't let me navigate statically warn

37:36

me that, hey, you're trying

37:38

to navigate somewhere that doesn't

37:40

exist. That's just the basic

37:42

bare bones. There's a lot more to

37:44

it though. I don't know how much you

37:46

want to go into that, but. I think

37:49

we talked about it actually in the

37:51

last time you were here. So I

37:53

don't want to go too deep because

37:55

I want to talk about the 10

37:57

stack framework and some of the

37:59

RPC work is really. interesting for

38:01

me. I would like to talk

38:03

about that too. So just in

38:05

a few words, just to mention

38:07

it, as I recall, it's also

38:10

type safety about your parameters, so

38:12

you can specify the type of

38:14

a URL parameter, and the

38:16

value has to match that type. Right.

38:18

And that applies to a lot of

38:21

different areas of the API.

38:23

So search parens is a big.

38:25

a big piece of tan stack

38:27

router. All of our search parameters

38:30

are validated and type safe and

38:32

have first class APIs built in

38:34

to manage search parameters

38:36

like you would, like use

38:39

state, essentially, like you're just

38:41

managing state. That's a really

38:43

big difference and something that

38:46

really not many other routers, if

38:48

any, that I know of have.

38:50

That's a big reason of why

38:52

I wrote it as well. On

38:54

top of that, there's there's type

38:56

safety throughout all the other APIs

38:58

that we have in there. So

39:00

there's things like route context

39:02

and middleware. All of that stuff

39:05

is type safe as well.

39:07

There's the configuration itself, like

39:09

being able to use loader data

39:11

inside of your components or

39:13

use data from other routes

39:16

from different files. It's all

39:18

type safe, it all works, it's

39:20

all very magical. I don't know

39:22

what else to say there other

39:24

than you should try it because

39:26

you're probably missing out if you

39:29

haven't tried it yet. Let me

39:31

put it this way. We are

39:33

starting a new project. I basically

39:35

made it part of our standard

39:38

starter kit at Sison. So,

39:40

you know, we might, if

39:42

it's a project that needs...

39:44

a full framework like we

39:46

might debate between that's a

39:48

next jazz or something else.

39:50

But if it's a project

39:52

that's mostly going to be

39:54

client side rendered, then I've

39:56

made 10 stack like part of

39:59

our standard. I would agree. All

40:01

right, so before we move on

40:03

to start, there's another one

40:05

more thing I want to

40:07

mention. So Tanstack router has

40:09

cashing built into it, which

40:11

is like a really, really lightweight

40:13

version of React query or

40:16

Tanstack query built right into

40:18

the router. So for very,

40:20

so for simple use cases, you

40:22

may not even need Tanstack

40:24

query. You just. load the data

40:27

you need in your routes and it's

40:29

managed for you there and you have

40:31

things like stale time, SWR, background

40:33

refetching, it's all just built

40:35

into the router. So that's

40:37

very important, a very

40:40

important distinction. And yeah,

40:42

just generally managing state in the

40:44

URL. If you're going to use

40:46

search parameters. Like at all, if

40:49

you're going to use search parameters,

40:51

you should use Stan sacral. Oh,

40:53

I love it when as many

40:56

as possible configuration values are in

40:58

the URL. So for example, I

41:00

use Gafana. It's even spoken about

41:03

it here on JavaScript Jabber. And

41:05

one of the things I love

41:07

about Gafana is that most of

41:09

their configurations are your parameters, which

41:12

makes it very easy to share

41:14

graphs. Yep. More state should be in

41:16

the URL. Not all state, but

41:18

more of our state should be

41:20

in the URL. And as

41:23

soon as you want to start

41:25

doing that, you'll realize

41:27

that the tools you have

41:29

at your disposal are not

41:32

that great. So come use 10

41:34

stack router and you'll

41:36

be much happier. Okay then,

41:38

10 stack the framework. 10

41:40

stack start. Yep. So I wasn't

41:43

planning on building it

41:45

initially. You know what,

41:48

I'm not surprised. I

41:50

mean, one person kind

41:52

of taking on the

41:54

whole next JS ecosystem

41:56

in a sense. It's a lot.

41:58

It's a lot. It is a

42:01

lot. I wasn't planning on

42:03

building it initially because one,

42:05

I didn't need it personally,

42:08

so it's building a lot

42:10

of SPAs. But I'll be honest,

42:12

I nerd sniped myself on this

42:14

one really, really bad. So

42:17

I had this idea about a

42:19

year, basically a year ago, and

42:21

I was like, you know what? I

42:23

wonder if I could

42:25

rewrite tanstack.com and migrate

42:28

it from remix. to just

42:30

use 10 stack router

42:33

with a custom

42:35

SSR setup. And

42:37

I did that. It

42:39

was really hard. And

42:41

I was like, man,

42:43

that was really tough.

42:46

By the way, as

42:48

an aside, when I

42:50

worked at Wix, I

42:52

used to work at

42:54

Wix up to about five

42:56

years ago, and we did

42:59

it for big first of

43:01

all because none existed at

43:03

the time we predated next j

43:06

i think also the use

43:08

case was very different i

43:10

mean you know hosting millions

43:12

of websites on yeah one

43:14

platform is is a different you know

43:16

use case so so i i know

43:18

for a fact how difficult that can

43:20

be yeah very challenging to

43:23

do it efficiently it's in raging

43:25

a lot of the time to be

43:27

honest because I mean, the first thing

43:29

you're going to realize is now you

43:31

have hydration problems. Anytime

43:33

you're trying to do SSR with

43:36

react, you just have to get really

43:38

strict about hydration. But yeah, it

43:40

was difficult. And that's kind of

43:42

what started Tanstack Start. And I was

43:44

like, okay, I just did this manually,

43:46

and it really, really sucked. How can

43:48

I make that better? And I started

43:51

talking to Ryan Carniado. And I was

43:53

like, hey, what are you using for

43:55

solid start? to kind of put all this

43:57

together to make my life a little easier.

44:00

tried Vinci out and I just

44:02

kind of again just built it

44:04

manually but using Vinci and it

44:06

made my life easier. And so you

44:08

could see it's just snowball at that

44:11

point. Then I decided you know what

44:13

this is this is going to be

44:15

pretty cool and I showed it to

44:17

some people that I trusted and

44:19

they said this is amazing but I

44:22

really wish it had server like server

44:24

loaders. How do I only do something

44:26

on the server? And because in

44:29

remix you have, you know,

44:31

server-side loaders and even in

44:33

next JS pages, router, you have

44:35

get server-side props and stuff like

44:38

that. And so I was like,

44:40

okay, so it's not really complete

44:42

yet. How can I make this

44:45

better? And that's when I started

44:47

diving into server functions,

44:49

then initially those were implemented

44:52

with Vinci, but designing

44:54

a proper API around. server function

44:57

RPC's has been like my last

44:59

six months of work. So let's

45:02

talk a little bit about

45:04

RPC because apparently it's a subject

45:06

that's close to your heart and

45:08

I know for a fact that

45:10

it's close to mine as I

45:13

mentioned we even had an episode

45:15

about it. Can you talk a

45:17

little bit about first of all

45:19

about what is RPC? Yeah, pretty

45:22

sure it stands for remote procedure

45:24

call, right? Am I wrong? No,

45:26

you're absolutely correct. By the way,

45:29

I used our PCs, by

45:31

the way, as an aside, back in the

45:33

early 90s. Yeah, nothing to do

45:35

with web technologies. Yeah, things

45:37

like Corba or DCOM. Yeah, they

45:39

have a really, like, rich

45:42

history in computer programming

45:44

and... Hey, it's Ryan Seacrest.

45:46

Life comes at you fast, which

45:48

is why it's important to find

45:50

some time to relax, a little

45:53

you time. Enter Chumba Casino with

45:55

no download required you can jump

45:57

on anytime anywhere for the chance

45:59

to and

46:04

play over 100 online casino style

46:07

games, all for free. Go to

46:09

chumbacasino.com to collect your free welcome

46:11

bonus. Sponsored by Chumba Casino. No

46:13

purchase necessary. VGW Group. Void where

46:15

prohibited by law. 18 plus

46:18

terms and conditions apply. bit about that.

46:20

Ryan has sent me, Ryan Carniato sent

46:22

me some stuff about them as well.

46:24

And I just. I love when we

46:26

can find old tech and make it

46:29

feel new and great. This is one

46:31

of those things where it's like, yeah,

46:33

we've been doing this for a really

46:35

long time. But the idea behind the

46:37

RPC is that, you know, you get to,

46:39

you get to create this function

46:42

in a very generic sense, talking

46:44

about RPC, this function that

46:46

can be called remotely. And

46:48

when it's called remotely, it has,

46:51

you know, an underlying. protocol

46:53

implementation and messaging

46:56

implementation that sends

46:58

those messages back and

47:00

forth. But it creates a very,

47:02

like, a very opaque interaction

47:05

where you can just say, I

47:07

need to call this function. It

47:09

may happen on your machine or

47:11

it may happen on another machine,

47:13

right? But it's a remote procedure

47:16

call, it's going to happen remotely.

47:18

And it feels very different.

47:21

Calling into say a

47:23

rest API or graph QL

47:25

or something like that Well,

47:27

just a no because Similarities.

47:29

Yeah, because I'm putting aside

47:31

yeah, putting aside graph QL

47:33

for a second. Yeah, if

47:35

we're talking about restful APIs,

47:37

restful APIs to some extent,

47:39

you know, their request response,

47:41

which is the basic prerequisite

47:43

for something that looks like

47:45

a function. Yeah, that you

47:48

send a message and you

47:50

wait until you get a

47:52

response. Yeah, basically. Yeah, and you

47:54

know, graph QL even has a little bit

47:56

of our PC vibes in it as well.

47:58

where you can, you can. you can and

48:00

do kind of create these functions that

48:03

you that you call through the graph

48:05

QL like syntax and protocol right so

48:07

our PC is kind of in a

48:10

lot of different things and and

48:12

we even kind of implicitly create

48:14

our PCs in rest environments all

48:17

the time as well you know you have

48:19

a rest API and you just kind of

48:21

need this one-off like hey you know slash

48:23

generate whatever and you call it and

48:26

it's going to do something and it's

48:28

going to come back. I think in

48:30

the modern, in our modern definition

48:33

of our PCs though,

48:35

I think a lot of it

48:37

comes down to how you compose

48:39

that logic, right? Because generally

48:42

when we're talking about

48:44

GraphQL procedures and

48:46

functions and and

48:49

HTTP like rest APIs,

48:51

these are APIs that you, you

48:53

kind of have to design

48:55

in separate places. you say,

48:57

okay, I'm building an API,

48:59

I'm building a GraphQL endpoint,

49:01

and I'm going to build

49:03

this function in this place. And

49:06

then in a completely separate

49:08

location, either whether it's in your

49:10

mono repo or a completely separate

49:13

application, you're then constructing

49:15

a way to call in to

49:17

that function through, you know, URL

49:19

schema or GraphQL client that's

49:22

been generated or something like

49:24

that. So you creating that

49:26

function. and authoring that function

49:28

and calling it are seemingly

49:31

very separate places. With an RPC,

49:33

at least in our modern... Often, by

49:35

the way, implemented by separate

49:38

people, it might be the

49:40

back-end team that's creating the

49:42

restful endpoints and then the front-end

49:44

teams that are putting some

49:46

sort of facade on top

49:48

of them. And possibly in

49:50

separate languages too, right? Usually

49:52

often in separate. Yeah, often. And

49:55

so... Our PCs, at least the modern

49:57

way we think about our PCs, is

49:59

more. It's more of like

50:02

an integrated approach to

50:04

creating that messaging layer.

50:06

So for anybody listening

50:08

who could imagine you,

50:10

I'm just going to tell

50:12

you how we do it

50:14

in 10 six start. But

50:16

basically in any file you

50:18

want in your application, you

50:20

can call a function called

50:22

create server function. And

50:24

you pass that call a

50:27

function. And everything inside

50:29

of that function is going

50:31

to only run on the server.

50:33

Even only exist on the

50:35

server. It's only, yeah, it's

50:37

only going to exist on

50:39

the server. So it, like

50:41

when we bundle your application,

50:43

we literally take that function

50:45

that's inside of there and

50:47

we strip it away from the

50:50

client. And what we do is we

50:52

replace it with a fetch call. It's

50:54

a fetch to, you know, an HDTP

50:56

endpoint. used to be called the stub

50:58

in the old RPC day. Yeah, the

51:00

stub, right? We, you stub it and

51:02

we implement that stub,

51:04

we, we have, with fetch and

51:07

with an HDTP endpoint, and then

51:09

we extract that function into the

51:12

server bundle, and on the server,

51:14

we're listening to that same endpoint

51:16

for that stub, for that fetch

51:18

call, and when we receive that

51:20

call, we take the request, and

51:22

we pipe it through to the

51:24

function that we extracted.

51:26

And so they execute

51:29

in completely different

51:31

environments. But you author them in

51:33

a full stack way. So

51:35

these functions can live right

51:38

next to a react component

51:40

that renders on the client.

51:42

And they could even live next

51:44

to things that are client only

51:46

in the same file. I think

51:49

that's kind of the key. I

51:51

think that three things, I think,

51:53

enabled RPC for the modern web.

51:55

because our PCs existed on the

51:57

back end like forever so you know

52:00

yeah Obviously, I mentioned the old

52:02

technologies like CORBA and DCOM. Now

52:04

you have GRPC. So all this

52:06

stuff on the back end has

52:08

always been there. On the web,

52:10

I think three things that happened

52:12

in recent years, that's called it

52:15

this way, kind of enabled it.

52:17

So one was the full stack

52:19

frameworks. Yeah. Because you needed to

52:22

be able to write code that.

52:24

builds or compiles to both sides

52:26

for this mechanism to be truly

52:28

seamless. And you kind of said

52:30

it. It's intended for the full

52:33

stack scenario. So that's number one.

52:35

Another one is typescript. Without typing,

52:37

this whole thing would have been moot

52:39

because you need to be able

52:41

to specify the types of parameters

52:43

that you're sending over the wire.

52:45

Now you could have done it

52:47

explicitly using something that kind of

52:49

looks like Zod or something, but

52:51

it would have been really uncomfortable.

52:53

or the old component props that

52:56

we used to have in

52:58

react. It would have been

53:00

really uncomfortable to do it

53:02

that way. And the third thing that,

53:04

in my opinion, and I wonder

53:06

if you agree, that kind of

53:08

enabled it is a weight, a

53:10

single weight. The fact that you

53:12

can call a function and have

53:15

it execute a synchronously,

53:17

but with the function

53:19

called semantics. Yeah,

53:22

I don't know about the third. I feel

53:24

like it definitely helps. It

53:26

definitely helps. We could have done

53:28

it with callback functions. It

53:31

wouldn't have been fun. Yeah, it

53:33

would have been fun and it

53:35

would have broken the function call

53:37

semantics. I mean, yeah. One of

53:39

the big things about RPC is

53:41

that it feels like a function

53:43

call. And when it doesn't, then

53:46

you're missing out on most of

53:48

the fun. Yeah, I would agree.

53:50

It definitely a single way

53:52

elevates the experience to more

53:54

of the traditional RPC feel

53:57

that definitely But how do

53:59

you do that? in react client side?

54:01

I mean, you can't really

54:03

do a single weight in client

54:06

side react. No, I mean,

54:08

they would like to make you

54:10

think that you can with the

54:12

new use API. But I

54:14

mean, it's not really intended

54:16

for like end user usage.

54:18

So again, that kind of

54:20

falls back to like, that's why

54:23

I built Tanstack query is

54:25

because react lacked and. Honestly,

54:27

to this day still lacks

54:30

a really well vetted good

54:32

client side, asynchronous

54:34

primitive. And maybe they don't

54:36

add it because React query

54:38

is there and it's good enough.

54:40

Or they don't or they just

54:43

decided to skip it. But really

54:45

if you ask somebody today

54:47

from from React purest land

54:49

or Coreland, they'll say, oh, well,

54:52

you know, you're just supposed

54:54

to use. server components

54:56

for data fetching

54:58

and just pass promises and

55:00

then you call the use

55:03

or whatever. To that I

55:05

say that's making big assumptions

55:07

about the way you're

55:09

offering your application.

55:12

So yeah. Well to be fair

55:14

it's part of their their

55:16

vision of the how do

55:18

they call it the unidirectional

55:20

data flow. that RPC kind of

55:23

somewhat breaks that in a

55:25

sense because with the unidirectional

55:27

data flow model you've got

55:29

the data flowing down as

55:31

props and you've got interactions

55:33

flowing up as you know

55:35

let's say server actions I

55:37

don't know do they still

55:39

call it server actions or did

55:41

they also call it server functions

55:44

now? Yeah they call it server functions

55:46

which is kind of annoying

55:48

but that's fine. Yeah, it's

55:50

functions that are not supposed

55:53

to return a value though. Yeah.

55:55

And see, that's where that's

55:57

where things differ for me. I

55:59

don't really. think it breaks the

56:01

react methodology. Most of that just

56:03

comes down to how you're handling

56:06

the responses, in my opinion.

56:08

But, you know, for RPCs that just

56:11

aren't doing anything, I mean, look

56:13

at the way next JS handles

56:15

server functions right now. You call a

56:18

server function, and they basically

56:20

just invalidate everything. They call

56:22

back into the root on the server,

56:24

and they kind of re-render your

56:27

whole app. Now there's ways. You

56:29

need directional data flow. The

56:31

events bubble up, the data flows

56:33

down. It's just really not great

56:35

for performance though. Especially the

56:38

way the react is even

56:40

designed. It's kind of sucks

56:42

to re-render your entire application

56:44

from the top down. Let's

56:46

put it this way. It's not

56:48

surprising that you created React

56:51

query rather than they. Yeah,

56:53

no, I agree like I I

56:55

really like react and I like

56:57

the syntax I like the framework

57:00

It's it's really wonderful If I

57:02

had if I had a magic

57:04

wand that I could wave it

57:06

would be that That we just used

57:09

solid But that's not going

57:11

to happen so For now, you

57:13

know, I I have to ride

57:15

on the on the shoulders of

57:18

this giant that is react and

57:20

that's fine Because it's really good

57:22

and it's good enough and it's

57:24

decent to work in. And nobody

57:26

got fired for using React. No,

57:29

exactly. But you know, it kind

57:31

of goes back to the way

57:33

that we're trying to build

57:35

things with Tansack libraries is

57:37

that it shouldn't matter

57:40

really where you go. We just want

57:42

to build great core functionality

57:44

and bring it to all

57:46

the frameworks. And yeah, I

57:48

worry a little bit about. reacts

57:51

future with pushing

57:53

server components so much

57:56

because it's a wonderful

57:58

technology that is kind

58:00

of derailing a lot of people

58:02

from where I'm standing. It's

58:05

very confusing for a lot

58:07

of people. It's very difficult

58:09

to implement as a framework and

58:12

it comes with a lot of new

58:14

rules and overhead that just

58:16

don't really apply to. I'm going

58:18

to call it the more traditional

58:20

way of building an SSR application

58:22

that's just isomorphic and fully hydrated.

58:25

So I'll derail us a little

58:27

bit because I do want to

58:29

talk a little bit about that.

58:31

From what, so I've been looking

58:33

at some statistics about react usage

58:35

and meta framework usage. For those

58:37

who don't know, more people are

58:39

using react and all the other

58:41

view frameworks put together. So React

58:44

is number one, views number

58:46

two, but views less and

58:48

half of React and everything

58:50

else is less than the

58:53

remaining part. Those stats are

58:55

wrong. I know it. I

58:57

can feel it. And in

59:00

Reactland, approximately almost 20% are

59:02

using NextGS. And the rest

59:04

are not. They're not using any

59:06

meta framework. But if you look

59:09

at new websites, it seems that

59:11

almost all of them are being

59:13

built using NextGS. So any project,

59:15

there's a good chance at any

59:18

project older than two or three

59:20

years that started two or three

59:22

years ago is probably not using

59:24

NextGS and may never use NextGS,

59:26

but any project that's being started

59:28

right now, there's a good chance

59:30

that they're using NextGS. And it's

59:32

a fair assumption. The interesting

59:34

question though, when they're using

59:36

NextGS, are they also using

59:39

server components? And that I have no

59:41

way to know. And I'm kind of curious

59:43

about that. Like what is the

59:46

buy-in for server components? I don't

59:48

know if it's easy to know the buy-in.

59:50

I mean, we could go back and

59:52

look, I've done tons of polls. I

59:54

mean, it's obviously biased off of my

59:56

audience. But I've done a lot of

59:59

polls on Twitter. Twitter about people,

1:00:01

how people feel about server components

1:00:03

and NextJS and if they want

1:00:05

to use them or not, which

1:00:08

framework they would use. And for

1:00:10

the most part, what I've, the conclusion

1:00:12

that I've come to is that

1:00:14

there are a lot of people

1:00:16

coming into NextJS who are

1:00:18

using server components just because

1:00:20

that is the happy path that

1:00:22

they have designed for NextJS.

1:00:25

It's also the default. Unless

1:00:27

you put in your client,

1:00:29

it's a server component.

1:00:31

Yeah. And for me, it's

1:00:34

not interesting for me

1:00:36

personally. Many, if not almost

1:00:38

all of the apps that I've

1:00:40

ever built, I don't know

1:00:42

if they would really

1:00:44

directly benefit from the

1:00:47

capabilities of server components

1:00:49

at this time. I mean...

1:00:51

Yes, they could benefit in

1:00:54

terms of some bundle size.

1:00:56

But the tradeoffs for me

1:00:58

just are not worth it. One,

1:01:00

I don't want to have to

1:01:02

reason about this new

1:01:05

mental model of interweaving

1:01:07

client and server components

1:01:09

almost at every level

1:01:12

of the component tree

1:01:14

just to get tradeoffs that

1:01:17

don't matter. for me or really

1:01:19

won't matter much for my users

1:01:21

at this point. By the way,

1:01:23

I'm going to interrupt because I

1:01:25

need to, I think, I always

1:01:27

like to give a bit more

1:01:29

context to our listeners. So first

1:01:31

of all, we had two episodes

1:01:33

with Dan Abramov and Josephona talking

1:01:35

about server components. So if anybody

1:01:37

is really interesting in the nitty

1:01:39

gritty of what they are, I

1:01:41

highly recommend listening to those episodes.

1:01:43

They were excellent. The key aspect

1:01:45

about server components is

1:01:48

that they are components

1:01:50

that only run on

1:01:52

the server versus... Step

1:01:54

into the world of power,

1:01:57

loyalty, and luck. I'm gonna

1:01:59

meet... Can't offer you, you can't

1:02:01

refuse. With family, canoles, and spins

1:02:04

mean everything. Now, you want to

1:02:06

get mixed up in the family

1:02:08

business. Introducing the Godfather at Chompa

1:02:11

casino.com. Test your luck in the

1:02:13

shadowy world of the Godfather slot.

1:02:15

Someday, I will call upon you

1:02:17

to do a service for me.

1:02:20

Play the Godfather. Now at Chompa

1:02:22

casino.com. Welcome to the family. No

1:02:24

purchase necessary. V.GW Group. Way

1:02:26

where prohibited by law. client

1:02:29

components which run which can run both

1:02:31

on the client and on the server

1:02:33

which is yeah an interesting I'm even

1:02:35

going to extend that to

1:02:38

say that server components have the

1:02:40

worst name ever they should not

1:02:42

be called server components they should be

1:02:44

called like static components

1:02:46

or serializable JSS only

1:02:48

components maybe I mean

1:02:50

because you can technically generate server

1:02:53

components at build time too at

1:02:55

bundle time Really, really all it

1:02:57

is is you're just pre-rendering

1:03:00

a component and

1:03:02

producing this output that

1:03:05

is like stringified JSS and

1:03:07

then you're shipping that

1:03:10

to the client from either

1:03:12

the static build or

1:03:14

dynamically from the server

1:03:16

during runtime and then

1:03:19

you're, you're rendering that.

1:03:21

JSX, stringified version, you're turning

1:03:23

that into something you can

1:03:26

use. I prefer to think

1:03:28

about it as serialized virtual

1:03:30

DOM. Exactly what it is.

1:03:32

It's serialized virtual DOM. And

1:03:34

when you talk about it like

1:03:37

that, it becomes much easier to

1:03:39

reason about what you would actually

1:03:41

gain from using them. Which for

1:03:44

me, out of the box, the things that

1:03:46

I think are that are

1:03:48

interesting about server components is

1:03:50

that You could import and

1:03:53

render and do a lot

1:03:55

of complex work with

1:03:57

using really large buttons.

1:03:59

and libraries on the back

1:04:01

end that produce a really small JX

1:04:04

output and you would only have to ship

1:04:06

that to the client. And that's something

1:04:08

that's that actually is very

1:04:10

useful thinking about it from that

1:04:13

way. And that's something where like

1:04:15

it would be useful for like

1:04:17

meta, you know, that's the whole

1:04:19

reason they built relay. And the

1:04:21

ability for relay to send components

1:04:24

down in chunks with certain graph

1:04:26

QL responses was so that they

1:04:28

could only send down the code

1:04:30

that they needed to render the

1:04:32

thing at that exact moment. So

1:04:34

it's very much like the

1:04:36

next generation of that idea,

1:04:39

even though meta's not using

1:04:41

it, which is another topic. But

1:04:43

this is the next generation of

1:04:45

that idea is only sending. the

1:04:47

code that's needed to run on

1:04:50

the client to produce that

1:04:52

thing. It doesn't really have

1:04:54

a whole lot to do with

1:04:56

data loading other than you can

1:04:58

load the data on the server

1:05:00

and then produce the HDML and

1:05:02

the server and send that HDML

1:05:04

down to the client. So it's

1:05:06

very much like using a

1:05:09

traditional rendering framework from

1:05:11

like old back-end days. You

1:05:13

produce the HDML. I'm air quoting

1:05:15

here. But it's JSX and we

1:05:18

ship that down to the user.

1:05:20

Instead of having to ship all of

1:05:22

your data fetching logic and

1:05:24

your rendering logic down to

1:05:27

the client. So does 10

1:05:29

stack actually support server components

1:05:31

or do you solely rely

1:05:33

on server functions? I will support

1:05:36

them. So I've actually written all

1:05:38

the code to proof of concept

1:05:40

this out. It works. We're going

1:05:43

to support them. in a very

1:05:45

safe way. I can go into depth

1:05:47

and actually I think it's worth talking

1:05:49

about that. So server components, people look

1:05:52

at server components through the lens

1:05:54

of NextGS right now because that's the only

1:05:56

thing that we know. And it's not

1:05:58

implementation, I think. Yeah, next

1:06:00

JS, their entire router, like the

1:06:03

entire experience from the root of

1:06:05

the application down, is a large

1:06:07

server component, essentially. It starts at

1:06:10

the root and it starts on

1:06:12

the server and it interweaves between

1:06:15

client and server going all the

1:06:17

way down. That has kind of

1:06:19

skewed the way that people look

1:06:22

at server components. I think they

1:06:24

think that that's the only way

1:06:26

that it can happen and that

1:06:29

all of their routing files and

1:06:31

their layout files and all these

1:06:34

other things are going to be

1:06:36

written in this like use server

1:06:38

use client kind of hand off

1:06:41

thinking about these rules. Well, similar

1:06:43

to so if you caught next

1:06:46

JS comp this last year, Ryan

1:06:48

Florence. they demoed how it could

1:06:50

be different. And it aligns, it

1:06:53

almost aligns exactly with how I

1:06:55

was thinking about them as well,

1:06:57

is that server components are really

1:07:00

just another form of asynchronous state

1:07:02

or data that you're getting from

1:07:05

an API endpoint or some embedded

1:07:07

static data that you have in

1:07:09

your application. And so really it

1:07:12

can happen at network IO boundaries.

1:07:14

Next JS has those built into

1:07:16

the entire system. So it's just

1:07:19

kind of that's just what's happening

1:07:21

all the time. But for 10

1:07:24

seconds start, the way that we're

1:07:26

going to do it is if

1:07:28

you want to use a server

1:07:31

component, you simply return JSS or

1:07:33

react in a server function in

1:07:35

an RPC. That's I felt that

1:07:38

that was where you were going.

1:07:40

That's it. And you know, that

1:07:43

fits right in with remix too,

1:07:45

because so they don't really have

1:07:47

our PCs, but they do have

1:07:50

loaders, which is kind of like

1:07:52

their hard coated rest, their kind

1:07:54

of rest flavor of an our

1:07:57

PC, right? And they're doing the

1:07:59

same. thing is you just return

1:08:02

jobs or you just return React

1:08:04

and JSS inside of a loader.

1:08:06

So server functions are

1:08:08

really going to be the place

1:08:10

where you can use servers. So

1:08:13

a question about that. So first

1:08:15

of all it seems kind of

1:08:17

almost like you might be returning

1:08:20

a string and then injecting it

1:08:22

to be using what's it

1:08:24

called unsafe, dangerously unsafe

1:08:26

insert HDML or whatever?

1:08:29

But the question that I have

1:08:31

about that, what prevents that

1:08:33

server function from returning JSS

1:08:36

or virtual dome that the

1:08:38

client doesn't know what to

1:08:40

do with, like using components

1:08:42

that don't exist or whatever?

1:08:44

A lot of that just comes

1:08:46

down to how it gets bundled.

1:08:48

So the real feature, if you

1:08:50

ever listen to Andrew from the

1:08:52

React Cortese, Andrew Clark, I

1:08:54

can't, I think this is name, right?

1:08:57

Andrew? Yeah, I think so. Yeah, I

1:08:59

like the way Andrew talks about

1:09:01

it. He says the real, the

1:09:03

real feature of server components

1:09:05

is not a framework feature.

1:09:08

It's a funler. It's a

1:09:10

funler feature. And it allows

1:09:12

you to basically render a

1:09:15

component and only bundle up

1:09:17

the things that it needs to

1:09:19

render with it. And so. When

1:09:21

you serialize that component, everything

1:09:23

that ran on the server

1:09:26

is going to turn into

1:09:28

JSX markup that's right there

1:09:30

in that representation. And everything

1:09:32

that can't run on the server

1:09:34

that needs to run on the

1:09:36

client is referenced through a manifest.

1:09:39

And it gets a little tricky with

1:09:41

how that works, but that manifest

1:09:43

is just a mapping of... client

1:09:45

component references that can

1:09:48

come down through server

1:09:50

components to the actual

1:09:52

modules and bundleer modules that

1:09:55

it can go out and

1:09:57

grab if it needs to

1:09:59

grab them. So when you render something

1:10:01

on the server it comes down with

1:10:03

this responses is here's all this server

1:10:06

function Or the server component markup

1:10:08

and there might be some

1:10:10

client components in there And if

1:10:12

they're already loaded into your app

1:10:14

on the client then they'll just

1:10:16

render and if they're not Then

1:10:18

they will suspend while they go and

1:10:20

pull that client side bundle chunk

1:10:23

that they need to render and

1:10:25

then they will finally render. So

1:10:27

a key difference it seems to

1:10:29

me And again, correct me if

1:10:31

I'm wrong, between the NextGS way

1:10:33

and your approach is that with

1:10:36

NextGS, the root is, like you

1:10:38

said, a server component,

1:10:40

whereas in your case, the

1:10:42

root is a quote-unquote

1:10:44

client component, even though

1:10:46

it actually might run

1:10:48

on the server. Yeah. I

1:10:51

think that's a good distinction.

1:10:53

Is that with NextGS everything's going

1:10:56

to be server first all the

1:10:58

time no matter what? Right, of

1:11:00

course. And then with Tansac's start,

1:11:03

even down to the way that the

1:11:05

APIs are designed, everything's written to

1:11:07

be isomorphic first. So if

1:11:09

you don't do anything inside

1:11:11

of a server function, what

1:11:13

you write is just going to

1:11:15

happen during SSR and it's going

1:11:17

to happen on the client. You

1:11:20

know what I really like about

1:11:22

your approach now that I'm thinking

1:11:24

about it so I have this

1:11:26

presentation this talk that I gave

1:11:28

about different ways to overcome the

1:11:30

cost of hydration the performance cost

1:11:32

of hydration and I show the

1:11:34

different ways and I for each

1:11:36

such method like this something like

1:11:38

six or seven approaches and for

1:11:41

each one of them I give

1:11:43

both the upsides and the downsides

1:11:45

of each approach and one of

1:11:47

the approaches that I mention towards

1:11:49

the end are server components. And

1:11:51

one of the downside of server

1:11:53

components that I presented in my

1:11:56

talk is that they require you

1:11:58

to basically re-architect your application. Yes.

1:12:00

Can't take an existing application and

1:12:02

just throw in server components into

1:12:04

it. You need to rethink your

1:12:07

entire architecture. You need to learn

1:12:09

this new, not even new technology,

1:12:11

but new approach and then architect

1:12:14

your application accordingly. And what I

1:12:16

really like, sorry, go on. I

1:12:18

was going to say, I agree,

1:12:21

but I think there's some nuance

1:12:23

there, where with server. But with

1:12:25

server components, you can migrate incrementally,

1:12:28

but you have to do it

1:12:30

from the top down. You have

1:12:32

to slowly move the server bound.

1:12:35

So at the top, if you

1:12:37

just say, I want to render

1:12:39

my whole app as a client

1:12:42

component, you can do that. In

1:12:44

NextHS, you can even do that,

1:12:47

I think. I hope. How to

1:12:49

have fun. Anytime, anywhere. Step one.

1:12:51

Go to chumbacassino.com. Got it. Step

1:12:54

two. Collect your welcome bonus. Come

1:12:56

to Papa, welcome bonus. Step three.

1:12:58

Play hundreds of casino-style games for

1:13:01

free. That's a lot of games,

1:13:03

all for free. Step four, unleash

1:13:05

your excitement. Whoo-hoo! Ch, ch, ch,

1:13:08

ch, ch, ch, ch, ch, ch,

1:13:10

ch, ch, ch, ch, ch, chum-ch.

1:13:12

Chum. Chum-chum. Chum-chum-chum-chum-chum. But you can

1:13:15

render your entire app as a

1:13:17

client component. Well, you can have

1:13:19

a really thin server component that

1:13:22

basically just renders your... Right. And

1:13:24

then migration path is to slowly

1:13:26

push that server boundary down through

1:13:29

your component structure as far down

1:13:31

as you can. That's the incremental

1:13:33

migration strategy. And I don't like

1:13:36

doing refactors from the root down.

1:13:38

In fact, I like to make

1:13:40

my leaf node up. Yeah, but

1:13:43

you're absolutely correct. But if you

1:13:45

if you basically do that, then

1:13:47

you've not again, my presentation was

1:13:50

in the context of improving the

1:13:52

reducing the cost of hydration. And

1:13:54

if you just do that, you

1:13:57

basically, if not eliminate, not reduce

1:13:59

the cost of hydration at all.

1:14:01

Yeah, slowly, but all it means

1:14:04

is that you've slowly re-architected your

1:14:06

application. Exactly. But, and what I

1:14:08

like about your approach, it seems

1:14:11

to me, is that you can

1:14:13

get these, this value without re-architecting

1:14:15

your application. You want to, you

1:14:18

can, you think, you have some

1:14:20

components somewhere in the tree

1:14:23

that could benefit from being

1:14:25

a server rendered component, because

1:14:27

I don't know, it uses

1:14:29

some date and time functionality

1:14:31

that would require you

1:14:33

to download MomentJS. Well,

1:14:35

you just turned that into a

1:14:38

server function that returns GSX.

1:14:40

Yeah. And you know, you bring up,

1:14:42

you brought a cool thought in my

1:14:44

head is that talking about refactoring,

1:14:46

right? Let's imagine a lot of

1:14:49

people are on Create React app.

1:14:51

At the very least, it's not

1:14:53

too difficult to get into VET

1:14:55

for the very least, just saying,

1:14:57

hey, I want to use VET.

1:14:59

But to be able to use

1:15:01

what would it take for somebody

1:15:03

at that point then to use

1:15:05

server components right? Telling them that

1:15:07

they would need to adopt an

1:15:09

entirely new framework is a big

1:15:12

pill to swallow if they just

1:15:14

want to consume this new server

1:15:16

component You know pattern this new technology.

1:15:18

It's a hard pill for them to

1:15:20

swallow and I would wager that a

1:15:22

lot of people wouldn't do that

1:15:25

but What if you could say, hey,

1:15:27

all you need to do is just

1:15:29

get off of Create React app, which

1:15:31

you should do anyway, get into

1:15:33

VIT, right? All you need to do

1:15:35

is get into VIT, and if you

1:15:37

can do that, we can give you

1:15:39

a VIT plug-in that will let

1:15:42

you call server functions and then

1:15:44

let you return server components.

1:15:46

even without refactoring really any

1:15:48

other part of your application,

1:15:50

even if you're still using

1:15:52

react router version four or

1:15:54

five, you could still make

1:15:56

an API call using whatever

1:15:58

you want using react query

1:16:01

even and call into a

1:16:03

server function, get back a server

1:16:05

component and render it. You

1:16:07

would just need to migrate to

1:16:09

beat and be using React 19.

1:16:12

So that's probably the path

1:16:14

of least resistance. If you

1:16:16

just want to get your

1:16:18

hands on server components, that's

1:16:20

the path of least resistance

1:16:23

that I'm trying to make

1:16:25

possible. I know I said that

1:16:27

start is 90% router. That's

1:16:29

if you're consuming the

1:16:31

whole the whole framework. But really

1:16:34

at the end of the

1:16:36

day what start is is just

1:16:38

the ability to do SSR

1:16:40

if you want and server

1:16:43

functions. That's right. I

1:16:45

love that. And by the

1:16:47

way I told Dan Abramov

1:16:49

when he was on the

1:16:51

show that the because you

1:16:54

know They were getting huge

1:16:56

pushback against React server components

1:16:58

and you know, and I

1:17:00

know that it, the React

1:17:02

team got a lot of pushback

1:17:04

that they weren't used to

1:17:07

get, that's for it this

1:17:09

way. They were always, the

1:17:11

last time they got such

1:17:13

pushback from the community was

1:17:15

I think more or less

1:17:17

when they introduced GSX. And

1:17:20

they had hoped that the

1:17:22

reaction would have been similar

1:17:24

to the reaction that they

1:17:26

got when they introduced hooks,

1:17:28

which were really quickly adopted

1:17:30

by the community. And

1:17:32

the key difference was that hooks,

1:17:35

you could basically take it or

1:17:37

leave it. You could use it

1:17:39

on a per component basis. So

1:17:42

when you could take an existing

1:17:44

react application and decide that I'm

1:17:46

not going to touch any of

1:17:49

the existing code. But new components

1:17:51

that I'm adding would use hooks

1:17:53

and everything would just work. And

1:17:56

it didn't require an architectural overhaul.

1:17:58

Exactly. It was... at the component

1:18:00

level. And if you can do

1:18:03

that for react server components, that

1:18:05

would be amazing in my opinion.

1:18:07

Yeah. It's fine that it requires

1:18:09

an architectural overhaul. It's going

1:18:12

to require something, if it

1:18:14

involves a server, you're going

1:18:16

to have to do something

1:18:18

architecturally. I just think that

1:18:20

rolling up that architecture change

1:18:22

into, hey, you have to adopt

1:18:24

this entirely new framework. That's a

1:18:26

hard pill to swallow. And you

1:18:28

know, that's both next JS is

1:18:30

in, and I think React router's

1:18:33

hope is that, hey, just buy

1:18:35

into our router and we'll take

1:18:37

care of the rest, right? And

1:18:39

unfortunately for me, that's

1:18:41

not, that's an even harder

1:18:43

pill for me to swallow because

1:18:46

I don't really like the routers

1:18:48

that I see out there. I

1:18:50

don't like next JS's router and

1:18:52

and I moderately enjoy. react router,

1:18:55

but it lacks a lot of things

1:18:57

for me. I'm definitely not happy using

1:18:59

it anymore. And so knowing that other

1:19:01

people are going to have to make that

1:19:03

same sacrifice to say, oh yes, I have

1:19:05

to buy into NextHS all of it, or

1:19:07

I have to buy into React router at

1:19:10

least, if I want to get on

1:19:12

a path to use these latest react

1:19:14

features, that's not something that I want to

1:19:16

have to do even myself, and I don't

1:19:18

want to have to make other people do

1:19:21

that as well. I'm trying my hardest

1:19:23

to build start in a way that

1:19:25

can be consumed without having

1:19:28

to just turn your entire

1:19:30

application upside down. There's always

1:19:33

going to be a little bit of

1:19:35

buy-in. You know, you have to buy

1:19:37

in a beat. You're going to have

1:19:39

to buy into servers in general. Like,

1:19:41

I hope your company lets you

1:19:44

run server code because a lot

1:19:46

of front-end devs are not allowed

1:19:48

to provision servers. So... I'll

1:19:50

put it this way. A while

1:19:52

not so long ago I was

1:19:55

interviewing at a couple of companies

1:19:57

and and I was interviewing at.

1:19:59

at a senior technical rank.

1:20:01

So one of the things

1:20:04

that I was looking at

1:20:06

during the interview process was

1:20:08

actually the technologies and architectures

1:20:10

that they were using for

1:20:12

the front end. And what

1:20:14

I saw is that all

1:20:16

of them were using react

1:20:18

and almost none of them

1:20:21

were was using SSR or

1:20:23

any other and consequently any

1:20:25

met a framework. And if

1:20:27

you could provide. the

1:20:29

ability for such companies

1:20:31

to start leveraging the benefits

1:20:34

of React on the server

1:20:36

side in a way that does

1:20:38

not disrupt Their existing architecture

1:20:40

and their existing code base

1:20:43

that that's a huge benefit

1:20:45

Yeah, I agree and you know I

1:20:47

came from that world where like

1:20:49

I wasn't gonna start even on

1:20:51

my small team I didn't want

1:20:54

to have to provision servers My

1:20:56

team, we had our APIs written

1:20:58

in a different language, you know,

1:21:00

distributed through a very different means,

1:21:02

like I wasn't going to touch

1:21:05

server code any time soon. I

1:21:07

mean, a lot, a lot of

1:21:10

very successful applications and enterprise

1:21:12

companies, like to even think

1:21:14

about, oh yeah, our front end

1:21:17

developers are going to start running

1:21:19

server side code, is a big leap.

1:21:21

Because just the way that, you know,

1:21:23

APIs need to scale, they get

1:21:25

their own teams, they turn into

1:21:27

different languages. I just think that

1:21:29

there's so many more benefits that

1:21:32

we should be looking to give

1:21:34

front-end developers right now who

1:21:36

work on these kinds of

1:21:39

applications and large enterprise applications

1:21:41

who, you know, so many of them won't

1:21:43

even be able to touch server components

1:21:46

until their company finally decides years

1:21:48

from now to let them run

1:21:51

server side code. Yes, I'm excited

1:21:53

about, you know, the server and

1:21:55

I'm trying to go down that

1:21:57

path as much as I can.

1:22:00

I'm still so heavily invested

1:22:02

in the client side tooling space.

1:22:04

I think query has been

1:22:07

phenomenal for the industry. I

1:22:09

think table is great. I think

1:22:11

Tansack router is still

1:22:13

the most underrated part of

1:22:15

what I'm building because

1:22:17

if you're a client side

1:22:20

application and you're gonna

1:22:22

stay a client side application.

1:22:24

I really don't understand why

1:22:26

you would even consider

1:22:29

using NextGS or React router

1:22:31

at this point. There's just,

1:22:33

if you're, if you're questioning

1:22:35

that, then you should DM

1:22:38

me and I'll talk to

1:22:40

you about it. Because I

1:22:42

built Tansack router for enterprise

1:22:44

routing use cases and it

1:22:46

truly shines. So yeah, those.

1:22:49

In that part of our

1:22:51

industry is very underrepresented and

1:22:53

soft-spoken, especially on places like

1:22:55

social media and Twitter, there's

1:22:58

very, very big successful applications

1:23:00

being maintained by very smart

1:23:02

people that we never hear from on

1:23:05

Twitter or X or anywhere like that.

1:23:07

So I know they exist though. I

1:23:09

talked to him offline. I talked to

1:23:11

him in DMs and I'm trying to

1:23:13

represent them as well. Oh, sure. Again,

1:23:15

we need to get wrapped up

1:23:17

here, because it's been a long

1:23:19

time here. So let's do some

1:23:21

last words from both you guys,

1:23:23

and then we'll move on to

1:23:25

PICS. One thing that I wanted

1:23:27

to talk about, but I don't

1:23:29

think we have time. So we

1:23:31

can do it since a future

1:23:34

time, is like some of the

1:23:36

downsides of our PCs that existed,

1:23:38

again, way back in the 90s.

1:23:40

RPCs, for example, tended to be

1:23:42

chatty. protocols. They also attended to

1:23:44

introduce a lot of

1:23:46

endpoints and generally introduce

1:23:49

various maintenance issues. But

1:23:51

I... Step into the world of

1:23:53

power. Loyalty and luck. I'm

1:23:55

going to make him an

1:23:57

offer he can refuse. With

1:23:59

family. and spins mean everything. Now,

1:24:01

you want to get mixed up

1:24:03

in the family business? Introducing the

1:24:05

godfather at chompa casino.com. Test your

1:24:07

luck in the shadowy world of

1:24:10

the godfather slot. Someday, I will

1:24:12

call upon you to do a

1:24:14

service for me. Play the godfather.

1:24:16

Now at chompa casino.com. Welcome to

1:24:18

the family. No purchase necessary. V.G.W.

1:24:20

group. Way where prohibited by law. Eighteen

1:24:23

plus, terms and conditions apply. I

1:24:25

don't think we really have time to

1:24:27

delve into this this time. So maybe

1:24:29

we should bring you on to talk

1:24:31

about our PC in depth sometime. I

1:24:33

can give you a 30-second teaser on

1:24:36

that if you want. I think that

1:24:38

there is some chatiness that can happen,

1:24:40

but I think if you are using

1:24:42

them for your actual source of truth

1:24:45

on full stack stuff, there are some

1:24:47

interesting things there, like actually building

1:24:49

full stack APIs. But if you're

1:24:51

just using them to then, you

1:24:53

know, do secure things on the

1:24:55

server that communicate externally with

1:24:57

your other API or back in, I mean, I

1:24:59

think that some of that chatiness

1:25:02

can be justified. And then also,

1:25:04

there's fun things about server functions

1:25:06

that we didn't even get to

1:25:08

talk about, but we've added validation

1:25:10

to our server function strategies.

1:25:12

We've added type safe middleware

1:25:14

to our server functions, which

1:25:16

is very, very powerful where you can.

1:25:19

wrap up client side and

1:25:21

server side transactions through server

1:25:23

functions and do really really

1:25:25

cool things. And then also

1:25:27

being able to do public

1:25:30

RPCs in the future is

1:25:32

something that we're considering. So

1:25:34

once you've written an RPC in

1:25:36

Tanstack, the only thing keeping

1:25:39

it from becoming a fully

1:25:41

blown rest like HTTP endpoint

1:25:43

that's public is just

1:25:45

supplying a path, a static

1:25:47

path. So we're considering allowing

1:25:50

people to even build public

1:25:52

rests and points like static

1:25:55

paths that they'll be able to

1:25:57

use, not just in their application.

1:25:59

side by side as an RPC,

1:26:02

but even call into with say

1:26:04

an RPC client that's generated for

1:26:06

their React Native app or for

1:26:08

a bunch of different projects and

1:26:10

kind of create some tooling around that.

1:26:12

You know what would be awesome if we

1:26:14

brought both you and Ryan on the show

1:26:16

to talk about RPCs? I think that would

1:26:19

be amazing. Any time you get me and

1:26:21

Ryan together, it's going to be a party.

1:26:23

So I would love to come on with

1:26:25

Ryan. Okay, Ryan's a friend. I'll

1:26:27

try to organize it. All right.

1:26:29

Well, thanks. Thanks. Thanks, Tanner. If

1:26:31

you want to learn more about

1:26:33

Tanstack, tanstack.com is the place to

1:26:36

go. Docs and demos and all

1:26:38

kinds of goodies. So with that, we'll

1:26:40

move on to PICS. PICS to the part

1:26:42

of the show where we get to talk

1:26:44

about things that we want to talk about

1:26:46

that maybe aren't tech related. Could

1:26:48

be. Let's see, AJ, you've been quiet.

1:26:51

What do you got for us for

1:26:53

us for PICS for PICS for PICS.

1:26:56

So I was looking for something

1:26:58

to play just I was in a

1:27:00

video game mood and I was very

1:27:02

Very kind of disheartened that

1:27:04

a lot of the games I really loved

1:27:06

as a kid They have not

1:27:09

been recreated in a similar form

1:27:11

like Golden I figured there's got

1:27:13

to be something like Golden I

1:27:15

but there aren't really any other

1:27:17

games other than Golden I and

1:27:20

perfect dark where you sneak around

1:27:22

and assassinate people through a maze

1:27:24

to accomplish some goal. And I

1:27:26

ended up trying out something

1:27:29

new. I've never even

1:27:31

heard of the genre

1:27:33

of Forex, but it's

1:27:35

explore, extend, exploit, extinguish,

1:27:37

something like that. It's

1:27:40

like the Microsoft strategy.

1:27:42

It sounds like Microsoft.

1:27:44

Yeah. So, civilization six

1:27:46

is kind of like Age

1:27:49

of Empires or Command and

1:27:51

Conquer mixed with SimCity. and

1:27:53

it is heavily heavily heavily

1:27:56

discounted right now because some

1:27:58

or civilization is about to

1:28:01

come out. And so for all

1:28:03

the different platforms for Nintendo

1:28:05

Switch, you can check on

1:28:07

GG dot deals, GG as

1:28:10

in good game, GG dot

1:28:12

deals, or deco deals.com, deco

1:28:14

as in deco tree. And

1:28:16

you can get either the

1:28:18

premium package or just the

1:28:21

base game for two, three,

1:28:23

four, five dollars. And it's,

1:28:25

my warning is that it's

1:28:28

addictive. If you have an

1:28:30

addictive personality, if you like things

1:28:32

where you have to min

1:28:34

max and strategize to figure

1:28:36

out the best route, it's every

1:28:38

every time you play the game,

1:28:41

the map is randomized and but

1:28:43

you have a civilization that has

1:28:45

certain benefits like what it

1:28:47

can build earlier or whatever

1:28:50

and you you get a couple hours

1:28:52

into the game and then you're past

1:28:54

or I guess past it. you get

1:28:56

into your next age and new things

1:28:59

on lock and you have other civilizations

1:29:01

on the board it's like

1:29:03

it's also kind of like risk

1:29:05

and that there's different civilizations on

1:29:07

the board and you're trying to

1:29:09

basically gather more land before they

1:29:12

do and and amass more points

1:29:14

to some good age i'm i'm

1:29:16

looking at the g g deals

1:29:18

page right now and they're

1:29:20

selling them for under three bucks

1:29:22

yeah so it's 95 percent discount

1:29:24

For the next four days. My

1:29:26

one. My one caution would be

1:29:28

don't buy it for Mac. Why? After

1:29:31

I got it for switch. I also

1:29:33

got it for Mac. Basically my

1:29:35

it doesn't work. It doesn't work.

1:29:37

The game opens. It crashes. If

1:29:39

you can keep it open long

1:29:42

enough. You can't you can't move

1:29:44

it from one monitor to another.

1:29:46

All of the key bindings or

1:29:48

Windows key bindingsings like with numb

1:29:51

pad and. F6 and all that

1:29:53

sort of stuff. You can change

1:29:55

those key bindings of course, but

1:29:58

my assumption is that they never

1:30:00

tested it on Mac whatsoever that they

1:30:02

use some sort of framework that allows

1:30:04

it to compile on different operating systems

1:30:06

and they just hit the compile button

1:30:08

and they said oh the Mac build

1:30:11

finished okay put up the digital code

1:30:13

but I don't think that anyone I

1:30:15

don't think any of the developers of

1:30:17

the game have ever tested it on

1:30:19

a Mac and if you look at

1:30:21

any of the reviews that are one-star

1:30:23

reviews they're all mentioning Mac it

1:30:26

doesn't run on Mac. It doesn't

1:30:28

actually, like, it will install, it

1:30:30

will open, you can click two

1:30:32

or three buttons and then it

1:30:34

crashes. So, don't do that. So you're

1:30:36

basically saying if you've got a computer

1:30:39

at home, get it for EC, not

1:30:41

for Mac? Yeah, I might even run on

1:30:43

Linux, I don't remember if that

1:30:45

was on there, but yeah, Windows

1:30:47

or Xbox or PlayStation, you know,

1:30:49

consoles are good because... Microsoft

1:30:53

and Nintendo and Sony will rip

1:30:55

you a new one if your

1:30:58

game just crashes when you

1:31:00

start it. Whereas Steam doesn't

1:31:02

care. Steam's like, oh, game just

1:31:04

crashes when you start it.

1:31:06

Contact the publisher. We don't

1:31:09

care. We just take the money. Alrighty.

1:31:11

That's my one thing. Thank you. Dan,

1:31:13

you got any picks for us? Yeah,

1:31:15

not a lot. I have a hard

1:31:18

stop right now. And I don't know

1:31:20

how many picks, so I'd be happy to

1:31:22

do my sign off, but I gotta

1:31:24

run. Okay, thanks for coming Tanner.

1:31:26

Thanks guys for having me. I

1:31:28

do want to come back on

1:31:31

and talk about server stuff with

1:31:33

Ryan Carniato, so let me know.

1:31:35

I'll make sure to organize that.

1:31:37

Now you've been giving me

1:31:39

extra incentive. That would be

1:31:42

so awesome. That would be

1:31:44

so awesome. So my pick

1:31:46

is I've been an Anthony

1:31:48

Jessonic fan for a long

1:31:51

time. You guys know who

1:31:53

he is? He's like this

1:31:55

edgy stand-up comic.

1:31:57

And I really have...

1:31:59

this material over the

1:32:01

years. We even had this

1:32:04

one really pleasant surprise where

1:32:06

we went to this stand-up

1:32:08

club in LA and he

1:32:11

made a surprise appearance there

1:32:13

to try out new stuff,

1:32:15

new material. So that

1:32:17

was really awesome. And I

1:32:20

really loved his shows that

1:32:22

he did in the past,

1:32:24

thoughts and prayers and fire

1:32:26

in the maternity ward. And

1:32:28

now he's recently come out

1:32:30

with a new show called

1:32:32

Bones and All. And it's

1:32:34

okay. I watched it and I

1:32:37

enjoyed it, but it wasn't as

1:32:39

good as his old shows. So

1:32:41

if you're an Anthony

1:32:43

Justinic fan and you

1:32:46

haven't watched it yet, you

1:32:48

know, you should, but don't expect

1:32:51

it to be as great as

1:32:53

his past stuff. I don't know

1:32:56

why. That's... just my take on

1:32:58

it. But anyway, that would be

1:33:00

my pick for today. All righty,

1:33:02

I will go last year since

1:33:05

I am the my picks are

1:33:07

always the high point. First pick

1:33:09

is a reference to something that

1:33:11

Tanner said during the when

1:33:13

he was talking earlier and he

1:33:15

talked about how we got nerd

1:33:18

sniped. Reminds me of one

1:33:20

of my favorite XKCD cartoons

1:33:22

called nerd sniping. It's

1:33:25

number three five six so

1:33:27

considering where things are

1:33:29

right now, it's a very

1:33:31

early, early one. And it's

1:33:34

called nurse typing and

1:33:36

it's, it describes it

1:33:39

perfectly, makes me laugh

1:33:41

every time I read this

1:33:43

cartoon, but I go check

1:33:45

it out. Nurse XKCD number

1:33:47

356. And for the dad

1:33:49

jokes of the week, it's

1:33:51

been a while, so, so I

1:33:53

have a plethora to choose from. The other day

1:33:56

I was talking to a friend of mine and

1:33:58

I told him, hey I took my wife... to

1:34:00

the Caribbean last month and he

1:34:02

said Jamaica I said no she

1:34:05

wanted to go. Also did you

1:34:07

know that you're actually born with

1:34:09

four kidneys when you grew up

1:34:12

two of them become adult knees?

1:34:14

And finally it really annoys me

1:34:16

when people get well-known phrases wrong.

1:34:19

I mean seriously it's not like

1:34:21

it's rocket surgery. Those are the

1:34:24

dad jokes of the week. We'll

1:34:26

say thanks to Tanner for coming

1:34:28

on and talking about Tan Stack

1:34:31

sounds like we're gonna get another

1:34:33

episode scheduled with him and Ryan

1:34:35

Carniato. I really hope so I'll

1:34:38

do my I can only promise

1:34:40

to do my best. Dan has

1:34:43

connections everywhere man. If we want

1:34:45

to get somebody on just talk

1:34:47

to Dan he knows well. Thanks

1:34:50

guys for coming on. Thanks to

1:34:52

Tanner for coming on and we'll

1:34:54

talk with you all next time

1:34:57

on Jobbitz together. Hello,

1:35:01

it is Ryan and I was

1:35:03

on a flight the other day

1:35:06

playing one of my favorite social

1:35:08

spin-slock games on Chumba casino.com. I

1:35:10

looked over the person sitting next

1:35:13

to me, and you know what

1:35:15

they were doing? They were also

1:35:17

playing Chumba Casino. Everybody's loving, having

1:35:20

fun with it. Chumba Casino. Everybody's

1:35:22

loving, having fun with it. Chumba

1:35:24

Casino. Chumba Casino is home to

1:35:27

hundreds of casino style games, and

1:35:29

live the Chumba Casino. supply.