0:00

builds a compiler that produces the smallest

0:02

bundle would most likely win the

0:04

bundle or war. Regardless of how developers

0:06

feel about it, or if they

0:08

say, oh, well, they love this ecosystem

0:10

so much, that doesn't matter if

0:12

you can produce 50 % less payload. Hello,

0:20

welcome to DevTools FM. This is a podcast about

0:22

developer tools and the people who make them. I'm

0:24

Andrew, and this is my co -host, Justin. Hey

0:26

everyone, we're really excited to have

0:28

Zach Jackson back on the podcast with

0:30

us. Zach, you were on, it

0:32

was like episode 30, we're like in

0:35

the hundreds now, so it's been

0:37

a while. So

0:39

excited to have you on. And

0:41

we know there's a lot that's changed with you. So

0:45

previously, when we last

0:47

talked to you, you were working at Lululemon,

0:49

and now you're at ByteDance. And

0:52

so if anybody wants to

0:54

go back and check out episode

0:56

30, we talked a lot

0:58

about some really interesting work you're doing at

1:00

the time, and I hope to get

1:02

some updates on that. But before we dive

1:04

in, would you like to update our

1:06

listeners and kind of tell the new listeners

1:08

about yourself and what are you up to

1:10

these days? Uh, yeah, sure. So, um,

1:13

I'm a info architect

1:15

at bite dance. And

1:17

what that basically means is that I

1:19

work on like a lot of our

1:21

infrastructure tools. So, uh,

1:23

obviously the company is really large.

1:25

So there's a, a big

1:27

set of problems that, uh, is

1:29

never ending to sell. And,

1:32

uh, And yeah, and so essentially

1:34

we think our team with

1:36

about 60 members on the infrastructure

1:38

team. And so it's about

1:40

60 of us. And on Infra,

1:42

we pretty much deal with everything

1:45

from like building

1:48

out custom runtime. So like custom

1:50

JS run times that comes out

1:52

of our kernel team. native

1:55

frameworks and renderers for

1:57

various things, compilers, obviously, JS

2:00

frameworks, and then other things

2:02

in between, like just the tooling

2:04

to get stuff from A

2:06

to B. So

2:08

yes, that's a lot of what I do day to

2:10

day, which is essentially what I've just always been

2:12

doing, but now at a much bigger scale, which is

2:15

quite nice. Then

2:18

obviously, module Federation is

2:20

still very close to my

2:22

heart. Luckily,

2:24

I happened to land at the company

2:27

who happens to be the largest user

2:29

of it out there. So it all

2:31

worked out well. Yeah. It seems like

2:33

ByteDance has created a lot of different

2:35

things just from the outside looking in.

2:37

There's like a lot of

2:39

innovation going on and like

2:41

next generation type tooling. So like what

2:43

for when you first started, like

2:45

what attracted you to the company

2:47

and what projects that the company

2:49

of you gravitated towards. Let's

2:52

see. Okay,

2:54

so I guess like a thing that

2:57

I usually look for at a company

2:59

is like, you know, I'm always about

3:01

like impact. And I know that's like

3:03

an overused word these days. But

3:05

like generally, if I have to go

3:07

somewhere and I'm just pigeonholed into cool,

3:09

well, like you'll do this is kind

3:11

of why I got out of product

3:13

engineering is it was just not high

3:15

impact enough. And I think after

3:18

a while, it's also very dependent

3:20

on the health of the organization, how

3:22

enjoyable it is to work on the

3:24

product actually becomes. In

3:29

some places,

3:31

you're very beholden

3:34

to changes of non -technical users,

3:36

which can be difficult to

3:38

really get and get things

3:40

done. I

3:42

would say the the main reason what kind

3:44

of attracted me was just really the size of

3:46

the issues that they had and the fact

3:48

that a lot of the problems that they were

3:50

looking at were really similar to things that I

3:53

had been interested in solving. And, you

3:55

know, I think ultimately it was kind of like,

3:57

OK, well, you know, like when I was looking around

3:59

at the opportunities and then the kind of

4:01

just the numbers come out of like, hey,

4:03

well, here's the size of the people that

4:06

use this stuff and here's like the runway

4:08

of problems that you can have to solve

4:10

here. And that really kind

4:12

of hooked me in the end but

4:14

how it kind of started was

4:16

it turned out bite dance had been

4:18

after me a couple times and

4:20

I Just didn't remember Speed apparently I

4:22

had like a call with the previous

4:24

in protein manager before and I don't

4:26

know like why I didn't end up

4:28

going there or what the deal was

4:31

but So what ended up happening on like about

4:33

a year and a half later or so? how

4:36

we actually started like getting

4:38

involved was I was trying

4:40

to replace Webpack's ES TreeParser

4:42

with SWC in like a desperate

4:44

search for, you know, to

4:46

make it faster. And obviously

4:48

I knew nothing about Rust at the time. So I'm

4:50

like, hey, how do I get like the Rust

4:52

back to the JavaScript? Like, you know,

4:55

the most basic thing, like just how do you

4:57

like get it back out? And

4:59

so I'm fumbling through asking

5:01

around online and somebody, Someone's

5:04

like, hey, yeah, I can help you. And

5:06

jumps on a call with me. And so

5:08

we chat for a little bit. And he

5:10

unblocks me. And then we're going back and

5:12

forth over just like as I uncover the problems

5:14

of why this ultimately is not going to

5:16

work. And

5:20

who I ended up speaking to was actually

5:22

the lead of RS5. And I just

5:24

didn't know it at the time. So we're

5:26

kind of going back and forth. He's

5:28

watching me like fumble through, like failing, trying

5:30

to make Webpack faster with some rust. and

5:33

then you know things kind of die down and then maybe

5:35

like a week or two later he just messes with me like

5:37

hey I want to show you something and so

5:39

I get on a call and they're

5:41

like surprised there's this thing we've been working

5:43

on where we actually have ported Webpack

5:46

into Rust which obviously I was very skeptical

5:48

about because I've heard this song and

5:50

dance many a time before and you know

5:52

my general assumption was you can't like you

5:55

can't really do it. Like for the surface

5:58

of the API that it gives you, that's

6:00

just not something that you can create

6:02

in native. Cause I haven't seen anything done

6:04

in like, you know, in any of

6:06

the other native build tools that have

6:08

like an API on par

6:10

to something that's just stays in

6:13

JavaScript. So, you know, he

6:15

kind of sent me through it, showed me actually

6:17

these are the real loaders and are the

6:19

real plugins that we didn't just fork visit

6:21

and just look like web packets actually running

6:23

their ecosystem without a problem. And

6:25

I think if that was probably the main thing

6:27

that hooked me into coming in was like,

6:29

okay, this is real inch like for all my

6:31

involvement in a web pack and like how

6:34

much I've been like, you know, a fan of

6:36

it and how it's helped my career. Obviously,

6:38

when like the rust web pack pops up and

6:40

it's like, okay, well, you know, I feel

6:42

like this would be real good. And then

6:44

on top of that, I found out, you

6:46

know, they use a lot of Federation here. So,

6:48

you know, there was just like, cool, I

6:50

get to work on the thing I like to

6:52

work on already. just in Rust and faster

6:54

and less constraints because we would actually own the

6:56

product. So, you know, it was

6:58

just, that's really

7:00

kind of what attracted me. Cool. There's really

7:02

big problems to solve here that usually

7:04

you can't really get solved unless you just

7:07

have like unlimited resources to throw at

7:09

the problem. And that's really, really

7:11

difficult to come by. And luckily,

7:13

just because of like how the company is,

7:15

it like because it has so

7:17

many products and so many different

7:19

like, you know, offshoots of various

7:21

things, a lot

7:23

of the architecture attempts to be unified. So

7:26

that means it's like, okay, well, you need a

7:28

tool that's going to be able to do

7:30

like 200 different, you know, business cases that

7:32

are, you know, vastly different. So just,

7:34

you know, it was kind of

7:36

cool because it wasn't as fragmented and

7:38

disjointed as like you would usually

7:41

see where things kind of pop up.

7:43

around an organization for, hey, what works

7:45

there? Which I mean, you know, that's

7:47

totally fine. But I guess, like, it's one of

7:49

those things where I think economies of scale really kind

7:51

of help. And I like working in the areas

7:53

where economy of scale is useful. So there were a

7:55

lot of things here that just made it a,

7:57

yeah, I'd love to come and work here. Big

8:00

thanks to WorkOS for sponsoring this

8:03

episode of DevTools .fm. If

8:05

you're building a SaaS and thinking about moving up

8:07

market, WorkOS gives you everything you need to make

8:09

your app enterprise ready. without turning your

8:11

roadmap completely upside down. From

8:14

single sign -on and directory sync to audit

8:16

logs and fine -grained authorization, WorkWest is packed

8:18

with the features that companies expect and developers

8:20

can actually work with. What sets it

8:22

apart is how modular and well -designed everything

8:24

is. You don't have to use everything at

8:26

once, just pick what you need and

8:28

drop it in. The APIs are

8:30

consistent, the SDKs cover all major languages,

8:33

the developer docs are genuinely some of

8:35

the best out there. And

8:37

if you're dealing with onboarding flow

8:39

issues or user management headaches, WorkOS

8:41

has solutions for that too. A prebuilt

8:43

admin portal, secure credential storage

8:45

with ball domain verification and a whole

8:47

lot more. It's built to scale with

8:49

you, whether you're closing out your first

8:51

enterprise deal or rolling out compliance features

8:54

before the questions start coming in. So

8:56

if that sounds like something you

8:58

need, check out workOS at workOS .com. Let's

9:03

talk a little bit about. Webpack.

9:06

So it seems like for

9:08

a little while, at least

9:10

in the realm of Twitter and Blue

9:12

Sky or whatever that I'm on, a

9:14

lot of companies and a lot of

9:16

people have been talking a lot about

9:18

Veet and its shape in the ecosystem.

9:21

And I know that there are still

9:23

a ton of companies using Webpack

9:25

and I know some folks. places

9:28

that I used to work there still using

9:30

webpack but like you definitely don't hear

9:32

as much about it these days and I'm

9:34

curious like How do you think like our

9:36

spec is like changing that? What are

9:38

you sort of doing fresh and new and

9:40

like how does it sort of how

9:42

do you see it fitting in the the

9:45

current ecosystem? So

9:48

I guess

9:50

I Don't

9:54

know I personally view them

9:56

as like two different categories

9:58

of tool, to be honest.

10:00

And nothing against Veet, just in

10:03

its current form, I

10:05

know that it can do the

10:07

job for many developers, but

10:10

I

10:12

guess, well, why

10:14

doesn't Next .js just use

10:16

Veet then? Why does TurboPack

10:19

exist? I'm not

10:21

trying to throw shade here, and maybe I

10:23

just got off a very long flight, so. But,

10:26

you know, if it's the BL and Mdoll,

10:28

then we should, then nobody would be building

10:30

TurboPak. Next would be using it and blah,

10:32

blah, blah. But it's not. And that's nothing

10:34

like, I mean, nobody uses the RA to

10:36

build out these crazy type of things. And

10:38

there's various use cases for them. I

10:41

think, really, why Veet

10:43

got so momentously popular, you

10:45

know, just speculating here

10:47

is configuring build stocks. And

10:50

nobody cobbled a solution to that

10:52

together. You had WebPak, which was

10:54

okay. It's all in one. But

10:57

then you also have like, you know, a

11:00

PhD degree in configuring Webpack to

11:02

go along with it. So

11:04

over time, and then, you know, it's

11:07

something like ES Build pops up. And

11:09

it's like, oh, cool. Here's like, you

11:11

know, an API with four hooks. And

11:13

that sounds fantastic. Because if what

11:15

you want, you know, when I think of ES

11:17

Build, I always kind of in my

11:19

head kind of put it as, oh, I need

11:21

fancy Babel. Like I need something

11:23

that mostly just transforms things and kind

11:25

of puts it in certain places and that's

11:27

about it like a little bit

11:29

more than SWC but You know

11:32

fancy Babel transpile

11:34

things pack it into simple files

11:36

and off you go So so

11:38

I don't know I kind of

11:40

see like What Veet had done and we've learned

11:42

from this as well when we saw what they had

11:44

done, but they got super successful because if

11:46

you weren't using webpack then it was like either

11:48

roll up or es build or some kind

11:50

of frankenstein between the two or whatever and so

11:53

what v did was say okay well and they

11:55

introduced this thing of like a build

11:57

tool i don't think we had that really

11:59

like i don't know i really only use webpack

12:01

so i can go hunting around but

12:03

we didn't really have something like a

12:05

v type experience that was just off

12:07

the shelf to use where hey here's

12:09

a react plugin and it's not you

12:11

like configuring the loaders but there's like

12:13

middleware on top of the that's instrumenting

12:15

the tool. I think that

12:17

really helped a lot in its popularity

12:19

because Can Shake Hell was real and

12:21

also it was just faster because unbundled,

12:24

you know, Skip's doing a lot of

12:26

the build -up front and back in

12:28

the JavaScript -based tooling world, that was a

12:30

big issue. Now, I

12:32

would say on the flip side,

12:34

though, it hasn't been all like

12:36

Sunshine and Rainbows from like... And

12:39

again, I just know from like the research

12:41

that I do on these bundlers and from

12:43

like what users tell me. So I'm mostly

12:45

just kind of parroting like the things

12:47

that I've heard or think they might

12:49

not be totally accurate or whatever, but

12:52

you know, like, I think

12:54

a big one that we can probably all

12:56

understand is like, okay, well, the development versus production

12:58

discrepancy. And so, I

13:01

mean, that's not a super bad

13:03

problem. It's something you can work

13:05

around. Like either way, like it

13:07

seems to have not impacted the community

13:09

to a detrimental point. The problem

13:11

is though, is I don't see a

13:13

lot of people putting like half

13:15

a trillion dollar company embedding it on

13:17

that consistency being good. And

13:20

this is something that I would say

13:22

like Webpack has historically done well.

13:24

It's had good artifact integrity. It bundles

13:26

really small. It supports lots of

13:28

things. It kind of meets you where

13:30

you're at. and I think like

13:32

when you're looking at the tools that

13:34

you want when you're on the

13:36

lower end of like the problem surface

13:38

when you're in the let's say like you're

13:40

when you're in the 80 -20 rule in the

13:42

80 you have a lot of options but in

13:44

the 20 you don't have so many like

13:46

example okay if you take next .js well next .js

13:48

can't just use the s build or you

13:50

just use v like I mean, maybe if you

13:52

rewrote it from scratch, you could get all

13:54

the things in there, but they could do that

13:56

easier with just like TurboPak or WebPak to

13:59

kind of do the roll. But these

14:01

are also some of the more sophisticated like

14:03

build needs out there where they're doing a

14:05

lot more crazy stuff. So,

14:07

you know, I think there's just kind of

14:09

a difference between the target markets of

14:11

what we're looking at. There's, you

14:14

know, like. I would usually

14:16

say that probably these are an acquired

14:18

taste, but our target market is

14:20

obviously everybody we'd love for you to

14:22

use the tools, but our

14:24

focus primarily is like the focus

14:27

we have here at home, which is,

14:29

okay, you've got a $400

14:31

billion business and everybody uses these

14:33

things and it needs to

14:36

scale and like your compute costs

14:38

are like, you know, it's at the

14:40

point where you're, you know, you're looking at

14:42

engineering is cheaper than compute. So,

14:44

CI taking long and

14:46

chewing up boxes, the amount

14:49

of manpower to just write a new

14:51

compiler is cheaper than living with the

14:53

boxes taking 40 minutes. And if you

14:55

can do that, plus artifact integrity, all

14:57

the other things that you want, we

15:00

were just in a position of why not go

15:02

and do it. So ultimately, I think

15:04

the two will live side by side. What

15:06

I think really needs to happen, though, is

15:08

with roll down. So that's kind of what

15:10

I'm excited to see what's going to happen

15:12

there. Because I think

15:14

a lot of the problems in Veet, it's also

15:17

kind of unfair to say, oh, well, I

15:19

see some users use an escape code. Oh, well,

15:21

it doesn't do this set or the other

15:23

thing. And yeah, sure. But they have a

15:25

thing that they're working on to bring out. It's

15:27

just not out yet, which you

15:31

know, again, we'll see what happens when it

15:33

comes out. But I

15:35

think when we're in that space, what

15:37

we've also noticed that was interesting is

15:39

that Z seems to be like looking

15:41

at the bundle mode for apps. So

15:44

instead of doing the bundle list and dev like

15:46

it's always done, they're looking at adopting some kind of

15:48

like proprietary webpack -esque

15:50

chunking format

15:53

and some kind of

15:55

runtime for it. And I think

15:57

that that's a really good move because at

15:59

the end of the day, think like, The whole idea

16:01

of unbundled ESM, I think everybody

16:03

has tried it for a while

16:05

and it, you

16:07

know, it kind of works, but

16:10

there's like problems with it that

16:12

aren't necessarily on paper problems. Like

16:14

doing everything unbundled, it's technically

16:16

going to work really well on

16:18

your machine in incognito mode. but

16:21

go get the user machine with like the

16:23

six Chrome extensions and the Bing search

16:25

bar. Like you remember the old IE where

16:27

you'd have like that many toolbars? Like,

16:30

you know, imagine a browser that's

16:32

got like that, like your average Chrome

16:34

like laden

16:36

extension laden browser. And then if you

16:38

have to download like, you know, 4 ,000

16:40

little modules, it's not your

16:42

network isn't the problem. It's all the junk

16:44

that's sitting on the client device that

16:46

you can't benchmark against that like brings it

16:48

down in the real world. So

16:53

I think a lot of these things seem to

16:55

be going in the right direction of, hey,

16:57

we tried various things. We think a bundled mode

16:59

would be good. And the reason that we

17:01

can do a lot of this stuff is we

17:03

have faster tools, so they can do more

17:05

work. Cool, we can bundle

17:07

it all really quickly and make

17:10

it more or less as fast

17:12

as unbundled just because Rust

17:14

would enable. speed

17:16

where, oh, if it takes like, you know, 300

17:18

milliseconds to start up, we don't really care at

17:20

that point. Like it's beyond the point of caring. So

17:23

I'm also excited for us to get that because it

17:25

seems like everybody in the bundling space is kind

17:27

of getting to the point where speed isn't going to

17:29

be like this thing that, you know, the bundle

17:31

of wars are fought over, which I feel for like

17:33

the past two years, that's a lot of what

17:35

it's been. Oh, well, you know, which one's faster or

17:38

so on and so forth. But now it seems

17:40

we're talking about like, oh, well, this one did it

17:42

in one second and this one did it in

17:44

600 milliseconds. And it's like,

17:46

okay, sure, that's still maybe, you

17:48

know, two times faster or whatnot.

17:50

But then when you look at the demo app and

17:52

it's building like, you know, 15

17:55

,000 modules or something, you're like,

17:57

okay, well, realistically, yes, there could

17:59

be scaling issue. But if you can build,

18:01

I don't know, like we have one

18:03

here that's like, I think 50 ,000 modules. It's

18:06

like, okay, I can build a product of 50 ,000

18:08

modules and I can build it in 20 seconds. then

18:11

you know, that's probably the slowest

18:13

build RSPAC has on the market. And

18:16

that seems more than

18:18

acceptable to us coming from,

18:21

you know, that taking like over an hour

18:23

or more to build. So I think as

18:25

well, just like the focus is going to

18:27

start to shift as we all get the

18:29

tools where it's fast and where it's like,

18:31

okay, well, a little fit. Like when you're

18:33

doing HMR, if it takes 100 milliseconds versus

18:36

like 85 milliseconds, Nobody cares at that

18:38

point. It doesn't take 15 seconds to see

18:40

the update. So I'm hoping that

18:42

the speed war kind of changes. But then

18:44

again, I don't know what the next thing

18:46

will be that the bundler is kind of,

18:48

you know, vying for. Anyway,

18:51

long winded response. But that's just kind of

18:53

how I see things. I think there's a

18:55

place in the market for two and or more.

18:57

And at the same time, like now it's more

18:59

become like, well, what ecosystem do you want to

19:01

buy into? Like which one

19:03

has the parts you want? Veet

19:05

has a big community and big type

19:07

of ecosystem and lots of people

19:09

like using that. But there's also people

19:12

who, you know, enjoy the Webpack

19:14

type ecosystem. But

19:16

usually because of like, oh, well, they're very familiar

19:18

with loaders or there's certain APIs that let

19:20

them do certain things that are just easier to

19:22

get done in there or, you know, whatever

19:24

other reason, just that's their flavor of the month.

19:27

Then it's kind of nice to say, OK,

19:29

well, this becomes more of a preference choice than

19:31

not like a, oh, Well,

19:33

what's the real big difference here? But I think what

19:35

we'll just see is there's going to be, just like

19:37

you have React and you have Angular and you have

19:39

View, you're probably going to have like,

19:41

cool, they're all going to more or less

19:43

do the same jobs that 80 % of the

19:45

users need. And then it's really

19:47

just what do you like using to do that

19:49

job? Or what does it integrate with that you

19:51

might also want? A lot to

19:53

dig into there. One

19:57

of the original goals of RS

19:59

pack was kind of just to be

20:01

this drop in replacement for web

20:03

pack into like completely support the API.

20:06

Uh, that, that works in the beginning,

20:08

but as you said, new things

20:10

are going to be unlocked. So like

20:12

what, what has RS pack like

20:14

worked towards that's kind of like innovations

20:16

on top of web pack rather

20:18

than just like matching the old API.

20:20

Okay, so I guess to go back a little bit

20:22

as well for some context on why we went

20:24

this route. So we didn't just like

20:27

go let's port webpack and that was the

20:29

plan. That was the last thing that we did.

20:31

So we have like pages and pages of

20:33

documents. I think there

20:35

was something crazy. I think

20:37

like people who, people

20:40

from ByteDance have worked on every

20:42

Rust bundler except TurboPack as far as

20:44

I'm aware. So most of them

20:46

that are on the market, like in

20:48

some way shape or form, some

20:50

origin story can be traced back to

20:52

that person's time working here. So

20:54

there's just a ton of knowledge in

20:56

building these rust bundlers. And like,

20:59

you know, like 60 %

21:01

of them came from people who had

21:03

started working on those here, maybe left

21:05

and took it further, whatever. But like,

21:07

there was a lot of like, catalyzes

21:09

here around bundler research doing this. So.

21:13

The big thing that we have discovered is writing

21:15

a bundler is actually not as hard as it

21:17

sounds. The real problem is the

21:19

API design and how that ends up

21:21

biting you down the road. So

21:24

when we started, we actually were like,

21:26

okay, well, the first version of RSPAC

21:28

actually was ES -filled and we rewrote ES

21:30

-filled. And so at a full time,

21:32

we're thinking of calling it GoPAC and

21:34

it was going to be written in

21:36

Go. the problem with Go that we

21:39

found is it doesn't do well with

21:41

bindings to JS with like very complicated

21:43

bindings. Mostly like you have a garbage

21:45

collected language to a garbage collected language

21:47

and that doesn't play so nicely. So

21:50

then we kind of looked, okay, let's look into

21:52

the Rust side of it, moving ES filled into

21:54

Rust. And let's just fix some of the problems

21:56

ES filled has because it was almost good enough

21:58

for what we needed. At

22:00

the time we were just building our links

22:02

apps with it. So we needed a, it

22:05

was originally called Speedy. So we needed a

22:07

Speedy. solution for length.

22:09

And that was, hey, ES Build can

22:11

almost do the job there, but if we

22:13

could just fix these issues, perfect. What

22:15

we ended up finding though is like

22:18

there were bigger challenges in like ES build

22:20

for example like if trying to fix

22:22

the code splitting so that it chunks the

22:24

code better or HMR There's like architectural

22:26

challenges that make that not just easy to

22:28

add like the dev just doesn't want

22:30

it in there But it seems to be

22:33

like well, you know, there's fundamentally it's

22:35

a little bit trickier to try and do

22:37

that So

22:39

we kind of ran to this wall a couple

22:41

times where it's like, oh, well, let's try

22:43

and create something new. And then it's like, OK,

22:45

well, then there's the explosion of what ifs

22:47

that come in that haven't necessarily been thought through

22:50

in its uncharted territory and so on. So

22:52

we had two main issues. One, we had a

22:54

lot of things using Webpack. We

22:56

were also investigating VIT at the time because

22:58

VIT was getting popular. We were like, hey, maybe

23:00

we could switch over to that. And

23:04

and you know maybe that could

23:06

work and so then one of our

23:08

infer teams ended up building I

23:10

don't know if you guys know farm

23:12

.fe Have you heard of that bundler?

23:15

I think I might have been

23:17

on the page before yeah farm .fe

23:19

so so anyway so farm actually started

23:21

out as ploy so our infer

23:23

team was split into two sections one

23:25

one half of the infer team

23:27

was building rstack the other half the

23:29

infer team was building ploy We

23:31

reorg folded the compiler teams together to

23:33

reduce redundancy. And then

23:35

I think the main guy

23:38

behind Ploy left the company

23:40

and released Farm, which was

23:42

like heavily, which is essentially like from

23:44

all the work that they had done in

23:46

Deploy, packaged it up and put it out

23:48

there. And from what I understand of Ploy

23:50

was the idea was to have like

23:52

almost a V -type compatible API just very quick

23:54

and solve the problems that we were impacted

23:56

by that. There wasn't a world out

23:58

at this point. So this was the way

24:00

that, you know, they were going out to

24:02

solve it. So we wrote, like, you

24:04

know, I think maybe five bundlers in total,

24:06

like, getting through to this point. The reason

24:09

we ended up on Webpack is, again,

24:11

design issues. Oh, we can extend it here

24:13

and there. But then, like, there's all the

24:15

unknowns and race conditions coming in, which

24:17

essentially just makes the risk too high to

24:19

look at. So what we thought is, OK,

24:21

well, probably the easiest solution would actually

24:23

be to take something tried and tested that

24:25

we know is guaranteed to work. for

24:27

all the business cases, and that was

24:29

Webpack, which is a lot more complicated.

24:31

But the nice thing with Webpack is

24:33

it's also got over 10 years of

24:35

testing behind it. And so

24:37

you know it's pretty solid to start

24:40

with that. So if we could port

24:42

Webpack into Rust and say we have

24:44

a foundation that we know has 10

24:46

years of like, here's all the things

24:48

that all works, it's all very well

24:50

tested. then we could start to enhance

24:52

and iterate on it knowing that we

24:55

actually have a stable replica of a

24:57

powerful bundler to begin with, which is

24:59

a lot less complicated than trying to

25:01

design one that could be that or

25:03

more in the future. So

25:05

2024 was largely get parity,

25:08

get stability with the APIs. A

25:10

lot of it was speed

25:12

doesn't matter. It's about artifact quality

25:14

and making sure we have

25:16

a one -to -one or make sure

25:18

it works. safely, like make

25:20

it safe and then make it fast

25:23

essentially. So

25:25

in 2025, now we're looking at speed

25:27

opportunities. So I would say

25:29

like things that we've been, we've been considering

25:31

as like, you know, time is going to

25:33

involve on. So there's,

25:35

there's a bunch of a bunch of

25:37

like various things, but we're quite interested

25:39

in a lot of what the turbo

25:41

pack. team has been cooking up. And

25:43

so we've had a lot of those

25:45

plans in our plans since like mid

25:47

2024. So things like

25:49

remote caching, function level caching,

25:52

cash, you know, cash

25:54

that you can share between different

25:56

developers. That's

25:58

something we're very interested in. I think

26:00

we already have like function level code

26:02

splitting as well so you can move

26:04

single functions out of chunks. which

26:07

these aren't super, like most people don't

26:09

really care about those type of minutia,

26:11

but basically it means you can make

26:13

a lot more fine grained implementation, a

26:16

lot better code splitting, tree shaking, stuff

26:18

like that. Another

26:21

big area, though, that we

26:23

want to look into, that

26:25

I think we've already started

26:27

the work, but is going

26:29

to be into a unified

26:31

build graph. Essentially,

26:33

saying I want to build to an edge

26:35

worker, a native device, a node server, and

26:38

the browser. And I want to do it

26:40

all from a single build. And then I

26:42

want certain imports in that build to remain

26:44

under certain boundaries. So

26:46

building the whole module graphic

26:48

control potentially three to four

26:50

layers of your deploy stack,

26:53

but it's understood as a

26:55

single system to the runtime.

26:57

So this is something TurboPak has also been working

27:00

on. What I would say probably is a

27:02

lot of the future things that we would consider

27:04

is going to be, we started with the

27:06

Lightning to Webpack, we have a stable core, then

27:09

now looking at things like what

27:11

Turbo is doing, how can those

27:13

be incorporated? Because we think a

27:15

lot of those problems again are things that

27:17

kind of align with the problems that we would

27:19

like to see solved. Some

27:21

other areas though, like that, you know,

27:23

it's kind of an interesting one

27:25

is... Like, there's still a lot of

27:27

room and tree shaking and dead

27:29

code elimination. Like, my personal

27:31

opinion has always been whoever builds

27:34

a compiler that produces the smallest

27:36

bundle would most likely win, like,

27:38

the bundler war. Because regardless

27:40

of how developers feel about it, or

27:42

if they say, oh, well, they love this

27:44

ecosystem so much, that doesn't

27:46

matter if you can produce 50

27:48

% less payload. to the

27:50

end user like the user wins and

27:53

if you can serve them twice

27:55

the light of the lighthouse score like

27:57

the business will override any engineering

27:59

just because of like the depending on

28:01

the industry but you know that's

28:03

what I would say if you can

28:05

produce a smaller artifact all the

28:07

other points are moot like everybody's going

28:09

to go for smallest thing to

28:11

ship to user best experience at least

28:14

that's how I kind of think

28:16

about it um But tree shaking in

28:18

dead code elimination is really tricky.

28:20

However, most modern bundlers still leave about

28:22

40 % to 50 % dead code

28:24

even after optimizing. So that's how much

28:26

still could be done. And

28:29

so one thing we've been looking

28:31

at as well, and we've been working,

28:33

I think, with KDY on some

28:35

of this too, but looking at how

28:37

could we use dead code elimination

28:39

and tree shaking by using the typescript

28:41

syntax to help inform the bundler

28:43

of what's going on. So usually when

28:46

you build things, how it works

28:48

is you take your TypeScript code, convert

28:50

it into JavaScript, pass it to

28:52

the parser, the parser reads it and

28:54

does whatever. So you lose

28:56

a whole bunch of things like, oh,

28:58

well, if there were private, you know,

29:00

is this class as private, you could

29:02

check, well, is that method actually used

29:04

in the implementation? If not, we know

29:06

that outside you can't use it because

29:08

it's marked as private. So it's safe

29:10

to tree stake if we don't find

29:12

any inner -brass linkages. So I think there's

29:14

a ton of information like that that

29:16

we can extract, which would really help

29:18

with how a bundler can understand the

29:20

app using a better syntax or a

29:22

more informative syntax. Some

29:25

other things that I know we've

29:27

been playing around with was we had

29:29

the idea of being able to

29:31

use hot reloading to redeploy production. So

29:33

HMR was designed for production use,

29:36

and nobody really did that. So something

29:38

that we've been looking into, well,

29:40

is imagine if you need to perform

29:42

certain hot fixes. Instead of

29:44

having to redeploy the entire code base,

29:46

what if you could just push the hot

29:48

update chunk into an existing app? So

29:50

if you just needed to add the patch,

29:52

and the patch was only one kilobyte,

29:54

you were essentially just pushing an extra KB

29:56

into the existing app, and all your

29:58

users could get it, and

30:01

you could. hot reload them,

30:03

not preserve state in the

30:05

browser, but you could effectively

30:07

do things like that where

30:09

your deployments just become hot

30:11

reloads to the pipeline. So,

30:14

you know, those are probably some

30:16

of the more interesting areas. And I

30:18

know we're also getting into stuff

30:20

with AI and other things like that.

30:22

So what I kind of see

30:24

is potentially somewhere down the line where

30:27

these things kind of like mash

30:29

into something like combined. where you essentially

30:31

have like a environment that's then

30:33

custom built and then potentially we could

30:35

bolt on some kind of like

30:37

aging system to it and we have

30:39

a dock site system that's designed

30:41

to be parsed by like a indexer

30:44

for like you know a question

30:46

and answer bot and you wouldn't be

30:48

able to have a code sandbox

30:50

because we have like a Yeah, like

30:52

essentially, we have enough of the

30:54

loose parts where we could probably do

30:56

some more interesting things like that.

30:58

I'm personally quite interested to see, I

31:01

know we started on it, but

31:03

like MCP, for example, hooking

31:05

up our build doctor, ours doctor to

31:07

MCP servers, and now your AI would

31:09

be able to understand what's going on

31:11

in the build. And what if that

31:13

could go a bit further and you

31:15

had like some knowledge grasp, so like

31:18

the compiler helps serve, here's the application,

31:20

here's how it's working. and

31:22

potentially kind of, you know, starting

31:24

to utilize the bundler almost like

31:26

as a language server of sorts

31:28

to find context and understand relationships

31:30

about like manually splitting chunks and

31:32

doing things like that. I think

31:34

a lot of problems that you

31:36

have in like AI and like

31:38

RAG is very much the same

31:40

thing as bundler. It's just you're

31:42

serving a different type of module

31:44

back, which is like a text

31:46

chunk versus a script chunk. But

31:49

yeah, there's some kind of interesting things that I

31:51

could see floating around here. But I think in

31:53

general, a lot of it's going to be on

31:55

how do we make it faster? I

31:58

think mainly the big things right now are speed,

32:00

improving the unified graph structure,

32:02

because that would open up

32:04

doors like RSD and other

32:06

areas like that. And so

32:09

something we've also been kind

32:11

of considering is, what

32:13

if something like RSD

32:15

wasn't bound to

32:17

react? But what if there

32:19

was like a bundler level protocol

32:21

of some kind that fits within you

32:23

know that kind of paradigm because

32:25

if you have like a unified graph

32:27

and you can build the server

32:29

build the edge build the browser and

32:31

The build is aware of every

32:33

like where every part is going to

32:35

be going but also the runtime

32:38

is aware of it as well So

32:40

the runtime could know that hey,

32:42

this is a server module per se

32:44

But what if you could kind of

32:46

bait that into, well, this is

32:48

just how like importing certain code works,

32:51

rather than like, oh, well, here's

32:53

React server components and you have to

32:55

pass it props. But I

32:57

mean, theoretically, you could do the same

32:59

thing where you say, hey, here's bindings

33:01

to a function that you get on

33:03

your end. And there's bindings that are

33:05

to translate into a network -related call or

33:07

call to a worker and then get

33:09

decoded on the other end. you

33:12

know, kind of using this similar

33:14

kind of principle as, as like

33:16

what RSC would do. So,

33:19

and I think particularly for something like

33:22

links, that would probably be very useful

33:24

because we already have this use main

33:26

thread and like using the background thread,

33:28

you do parallel like multi threaded processing

33:30

on there. And so being able to

33:32

do that more sophisticated without needing to

33:34

kind of glue certain parts together, I

33:36

think, you know, would be quite interesting.

33:38

I think this is where it would

33:40

be nice to say, oh, well, links

33:43

already use this thing where it's kind

33:45

of like RSC, but it's built into

33:47

links itself. Now,

33:49

what if the bundler itself had

33:51

universal way to handle this problem of,

33:53

here, communicate with resources that might

33:55

not be here, but to you, they

33:57

feel like they are? This

34:00

episode is sponsored by Meltrap, an

34:02

email platform that developers love. Go

34:04

for high -deliverability, industry -best analytics, and

34:06

live 24 -7 support. You can

34:08

get 20 % off for all plans

34:11

with the ProDemo code DevTools. Check

34:13

out the details in the

34:15

description below. Yeah,

34:20

Lynx is such an interesting project,

34:23

and I think the thinking about the

34:25

bundling... there is like really interesting.

34:27

This is something that we want to

34:29

talk more about in a second,

34:31

but before we move on to that,

34:33

I would like to ask you

34:35

a little bit about like, you know,

34:37

just recently announced a next RSpec

34:39

module and like kind of moving into

34:41

the next JS ecosystem, starting to

34:44

support that. And this seems

34:46

like sort of like an alternative. So

34:48

if like your team's not using

34:50

TurboPak or not ready for TurboPak, like

34:52

you have this alternative, can you

34:54

talk a little bit about like, to

34:56

work behind that, like how that

34:58

came about. And the introduction

35:00

post mentions like some collaboration with

35:02

Verso and at least like fundamentals

35:04

is like, what does that look

35:06

like for y 'all? Yeah.

35:08

So, so yeah, I think it

35:10

kind of, I think, well, I think

35:12

it kind of all jumped started a little

35:14

bit when, when about, I don't know,

35:16

like seven or eight months ago, when, whenever

35:18

I was in China, I, uh,

35:21

we were kind of looking for, hey, what should

35:23

our plan be for like the next year? Kind

35:25

of doing like mid -year planning, trying to think

35:27

about like a bit, you know, midterm, what our

35:29

roadmap's going to be. And

35:32

so we're all sitting around the table, like

35:34

putting out ideas. We had things like RS

35:36

tests, which is now kicked off to like,

35:38

you know, RV tests, but like integrated within

35:40

like all of our other tools. And so

35:42

we're going through a list of like things

35:44

we want to add the ecosystem or change

35:46

and then, you know, wanna, and then sarcastically,

35:49

I just threw out RS next. And

35:52

I don't think sarcasm translates

35:54

super well. So everybody was

35:56

like, oh, OK, that would

35:58

be interesting. And essentially, what it

36:00

ended up being was like,

36:02

oh, we've tested a

36:04

web RS pack on virtually everything we can

36:07

find. We just cloned down repos, see

36:09

if RS pack can build them. And that's

36:11

kind of how we've tested a lot.

36:13

But the one we couldn't test was next,

36:15

because you couldn't just clone it down

36:17

and replace web pack with RS pack and

36:19

you're good to go. So

36:22

then we decided to try it. And so

36:24

we forked next and yeah, I think it was

36:26

like we went out like over dinner somewhere.

36:28

We like went out for an evening and we're

36:30

like, okay, let's just mess around a little

36:32

bit like over a steak and just see, you

36:34

know, what we can get it to do.

36:36

And so, you know, within a couple hours, we

36:38

got, you know, pages root are working. And

36:40

of course, not all the tests were passing,

36:42

but it was like, okay, I could take,

36:45

you know, a series of random tests and

36:47

like, you know, a basic page of router

36:49

with some CSS and a couple of the

36:51

various things would work. That

36:53

was quite impressive to just

36:55

see, oh, wow, okay. It wasn't

36:57

that difficult and a lot

36:59

still doesn't work. But the fact

37:01

that you could get maybe

37:03

40 percent of test passing or

37:05

something like that from just

37:07

quickly trying it out to say,

37:10

hey, could it actually build

37:12

this? So ultimately, I think like

37:14

the challenges that we had with that is, hey, this

37:16

is really cool. And I hyped it up far more

37:18

than I should have just because I was so excited

37:20

to see it. But

37:22

the thing is we didn't have a use case for

37:24

it. So maintaining a fork of next is like

37:26

a tall order. But

37:28

it was really cool to prove that,

37:30

hey, for us, it was can the bundler

37:33

do the job? If it can, then

37:35

cool. I think we're hitting the right track

37:37

when we can build what Because next

37:39

is, I mean, really, next is just the

37:41

most complex webpack plugin ever created. And

37:43

that's Next .js, with some server

37:45

thrown in there. But it's eventually like,

37:47

you know, the goat of build

37:49

plugin out there. So it was the

37:52

perfect test case. So

37:54

yeah, so anyway, we kind of built that and

37:56

shelved it for a little while. A few people after

37:59

the RS Next thing went out, think a couple

38:01

of people from Versailles kind of reached out, like, hey,

38:03

what's your plans with this thing? And we're like,

38:05

it was just kind of like mostly for testing. We

38:08

wanted to see if it would work, and it

38:10

did work, so that was the end of it. And

38:13

they would ask, would you

38:15

consider upstreaming this? Because it'd be

38:18

great to have another option.

38:20

And hey, I think a big

38:22

challenge next has is they're

38:24

not necessarily closed off to other

38:26

options being presented. The

38:28

problem is people aren't just on tap

38:30

who can just quickly drop out a

38:32

new, just, you know. a brisk replacement

38:35

of Next .js as whole build infrastructure with

38:37

something else. So I don't really think

38:39

it's been a case of like, oh,

38:41

well, Next is really closed off. It's just,

38:43

well, how many groups are out there who are

38:46

just going to like, well, one, know how

38:48

to do it or what to do. And

38:50

like, two, like, you know, just, it's

38:53

complicated to do. So

38:56

yeah, when we had something that was

38:58

partially working, we started the conversations with them

39:00

and, you know, it kind of like.

39:02

died out and came back and died out

39:04

and came back a little bit over

39:06

time. And I

39:09

think ultimately like what we had

39:11

found is there'd be really nice

39:13

symbiosis here because regardless of if

39:15

like there's, if Turbo competes with

39:17

RS Pack or you know, whatever,

39:20

like the problems that RS Pack faces, so

39:22

like a lot of stuff at Bite Dance

39:24

is built in -house. And the main reason is

39:26

because when we run into a problem, there's

39:28

nobody we need to ask from the outside.

39:31

So, oh, you know, and that

39:33

can get a little crazy. Like,

39:36

you know, let's build our own

39:38

JavaScript runtime. But ultimately, if the

39:40

business needs a problem solved, you

39:42

don't have like, there's no no,

39:44

it's yes, we have everything we need.

39:48

So that said, there's still open source

39:50

stuff we depend on. And so

39:52

like a really big one for us

39:54

is SWC. So if,

39:56

and that's one that is

39:58

hard to get. access

40:00

to because it's largely like time,

40:02

like Katie wise, like the main guy

40:04

behind it. And if Katie why

40:06

doesn't have the capacity to do it,

40:08

we can't like then it doesn't

40:10

matter how many PRs you send in,

40:13

like you can't like help coordinate

40:15

with the author and cool. How can

40:17

we like. utilize a

40:19

mix of manpower and what did you

40:21

want to do here and then like

40:23

combine to try and like solve some

40:25

of these issues. So we identified there's

40:27

lots of like common shared foundations in

40:29

general that even if there is a

40:31

turbo pack here like if ours pack

40:33

is currently impacted by an issue in

40:35

SWC we know turbo pack will be

40:38

as well and beyond like competing in

40:40

the open source because again like we

40:42

don't have too much skin in the

40:44

game in terms of like Like, you

40:46

know, we don't need anything from these

40:48

tools. They're side effects of we have

40:50

our own problems to solve. And

40:52

by solving ours, they mostly work for everybody else.

40:54

So here's a copy of it. But

40:57

so I think what was interesting is

40:59

like, OK, well, we want really admire

41:01

TurboPak's work. Like, I still am a

41:04

big fan of Tobias and think the

41:06

guys, you know, like really next level

41:08

on bundler design. And I think a

41:10

lot of my teammates would agree that,

41:12

yeah, he's, you know, like. the epitome

41:14

of building bundle burst. So

41:16

I think it was just

41:18

like a really good opportunity. One,

41:20

we do admire the work that

41:22

they're doing over there. The

41:25

guy behind it, obviously, we're very

41:27

happy with his prior art since

41:29

we built our version of his

41:31

design. So essentially,

41:35

how does this become like a rising tide to

41:37

lift all boats? We're happy to pass more

41:39

of next tests and try to get this thing

41:41

into an upstreamable position. if

41:45

we can also have a greater impact that

41:47

solves some common problems we're having. So

41:50

it's kind of like, okay, well, we don't really use the

41:52

next plugin, but it would be really great for RSPAC

41:54

to be able to prove that it can build that. Obviously, that's

41:57

a getting kind of like a

41:59

informal bluffing on, hey, RSPAC is

42:01

good enough to we'll let it

42:03

run on here. I think it

42:05

was a big milestone for the

42:07

project just to hit. But

42:10

I think as well, one of

42:12

my colleagues had said that regardless

42:14

of any competition that might be

42:16

between the two build tools, the

42:18

fundamental layers are there's so much

42:20

more value to drive out of

42:22

working together to fix those, even

42:24

if we're at odds with the

42:26

top end build tool. An

42:29

example was FWC used to have

42:31

a kernel panic when you would

42:33

have a chunk over 100 megs.

42:35

Now, that's probably not a case

42:37

a lot of people run into,

42:39

but when you run into it,

42:42

you know, you're kind of dead in the water. And

42:44

so these are kind of things where we're like,

42:46

okay, well, we'd love to be able to fix

42:48

this, but we need to kind of be able

42:50

to collaborate a bit more. And so I think

42:52

this just created a really good atmosphere where, yeah,

42:55

we don't, you know, we're happy to kind

42:57

of help upstream, upstream this back end, think it'd

42:59

be great for the project, but we'd also

43:01

love to like not just, you know, Take

43:03

the RS next stuff kind of sink

43:05

a bunch of manpower into it just to

43:08

get it on the next JS Like

43:10

you know again, we don't use it so

43:12

there's really not much use for us

43:14

But we doesn't mean we wouldn't have loved

43:16

to see it get in there and

43:18

also the way that it's done is really

43:20

great But I think I think the

43:22

the next RS pack is really just kind

43:24

of like a nice gateway piece of

43:26

like cool Drew this we can now but

43:28

like you know It's we

43:30

now are supported next 15 .3. And

43:32

I think like the main thing is,

43:34

but we are going to be working

43:36

on shared problems that impact us both.

43:38

So like some big ones already, I

43:40

would say largely around SWC again. I

43:42

think since the past

43:45

few months that we've been

43:47

like collaborating, we've seen

43:49

the like performance improve like

43:51

just various like reliability

43:53

and performance improvements of SWC

43:55

like significantly. like

43:57

improve essentially and that's exactly what we

43:59

want is uh you know if we know

44:01

how to write the Rust code and

44:03

you know what you want it done then

44:06

perfect is there a way that we

44:08

can kind of work together on some of

44:10

these things so really you know I

44:12

think that that's that's primarily how it came

44:14

around is like hey would you be

44:16

you could we upstream this think it'd be

44:18

a great like community option I think

44:20

like the motivation behind it as well is

44:22

just you you have a situation where

44:24

There's everybody who wants to go and use

44:26

Starbopack, but a lot of the people

44:28

who are on Webpack are usually the big

44:31

like, you know, whoever stuff on a

44:33

Webpack build is going to be somebody who's

44:35

worth like a lot of money, like

44:37

company wise, because that means that they've created

44:39

this massive monster and it's not something

44:41

that you can just rip out in a

44:43

couple of days and pop something new

44:45

in. So if you're really coupled to these

44:47

build solutions. I feel like in

44:49

Next, it was also challenging because you

44:51

don't have an option. TurboPak with all the

44:53

love, it's getting all the speed and

44:55

WebPak can't get any quicker. And

44:58

so those users just don't get brought along.

45:00

So it kind of is counterintuitive

45:02

to like connect good DX thing

45:04

that it tries to promote is

45:06

like, hey, it's nice to work

45:08

with. But then it's like, oh, well, it's

45:10

nice to work with only if you're in the club. But

45:13

the web pack can't be fixed. So

45:15

your best move is to move the web

45:17

pack. And that's not a very nice

45:19

thing to hear from like someone who relies

45:21

on it. So I think this was

45:23

a really good way where it's like, cool,

45:26

people who can't migrate yet, perfect. Hey,

45:28

and if you prefer the web pack style

45:30

convention, like maybe you want Federation or

45:32

things like that, here's this solution that at

45:34

least now is going to be like

45:36

fast or comparably fast to what you could

45:38

you could get. So

45:40

yeah, you know, I think it really throws

45:42

the lifeline to anybody who can't move. They

45:44

can now get a nice DX improvement. We

45:47

get a lot more, you know, eyeballs looking

45:49

at it. And obviously we get like the

45:51

best battle test that we could want, which

45:53

is against that. Yeah, it's

45:55

cool to see more and more like

45:57

shared foundations popping up between these projects.

45:59

And it just lifts all the projects

46:01

up. I think I think the big

46:03

the big thing there is like there's

46:06

a surprisingly few people who. actually

46:08

like, you know, that own

46:10

a lot of these libraries or

46:13

something, like the clusters of

46:15

devs are really small. So it's

46:17

really, really helpful when there's

46:19

an opportunity to like work together

46:21

because, you know, especially

46:23

in Rust compared to

46:25

JavaScript, it doesn't feel like

46:27

you have the same like vast JS

46:29

devs everywhere. Like when you go to

46:32

conferences and stuff like that, like Rust

46:34

isn't quite there yet. So I do

46:36

think it's probably best for those

46:38

working in the language to try and

46:40

Work together if you're solving a shared issue

46:42

because really there's not as much manpower

46:44

to stretch like you would have on npm.

46:47

So Before we wrap up, I think

46:49

we should touch on a new

46:51

project from bite dance links It looks

46:53

like it's a react native Competitor.

46:55

I think I saw some CSS in

46:57

the docs So could you explain

46:59

to us what it is and like

47:01

is it like a native renderer?

47:04

Is it like a web -based thing?

47:06

What's going on there? Yeah,

47:08

so links is quite quite

47:10

interesting so so it

47:12

was so originally it was

47:14

built at bite dance

47:16

and then tiktok is the

47:18

one who's essentially the

47:20

funder and the like main

47:22

open sorcerer of it

47:24

currently and I think the

47:26

reason that we have

47:28

links is So so I

47:30

guess a one scenario

47:33

is like remember when Facebook

47:35

wrote react And what

47:37

was their first use case? It

47:39

was the like button. They

47:42

wanted to swap out a like button

47:44

in PHP somewhere. Now, I

47:47

believe that that is

47:49

essentially kind of like the

47:51

reason that we use

47:53

something like links was, okay,

47:56

well, we have a component that's maybe

47:58

not worth writing in Swift or C.

48:01

And bringing in React

48:03

Native is potentially like

48:05

too much overkill for

48:07

this thing. So we

48:09

need a lightweight solution that's

48:11

relatively low friction. And then

48:13

a big thing here is

48:15

like everything here is web.

48:17

Like it all is looks

48:19

web or is kind of, you

48:22

know, how do you make the web

48:24

type experience show up in things that

48:26

aren't necessarily normal web? because

48:29

I think just in China, everything's a lot

48:31

more client -side rendered. So there's a lot more

48:33

mentality around, okay, this is like how we kind

48:36

of work. But

48:38

it also just makes it familiar. So, yeah,

48:41

so links, some things that

48:43

were, okay, so the first thing

48:45

is, so links is actually

48:47

agnostic. So it's not like React

48:49

Native, but it has

48:51

React links, which is essentially bindings

48:53

to links that give you

48:55

JSX. And so I think under

48:57

the hood, it's technically using

48:59

pre -act. But essentially, here's the

49:01

lightweight react bindings to this. But you

49:03

can also do it with spelled. I

49:05

think you could do it to view

49:07

as well. And then I know I

49:09

just saw they announced they're working on

49:11

a vanilla one, where, hey, you don't

49:13

need any kind of UI framework, and

49:15

you could just use vanilla .js. So

49:18

is it web? Kind

49:21

of. But there's a custom renderer built

49:23

into it. So a similar kind of thing

49:25

where we actually render it down. So

49:28

things like, you know, I think you've seen,

49:30

we have like really good performance on

49:32

the virtual lists scrolling, or like doing all

49:34

the weird, you know, carousel things that

49:36

are easy to do on a web, but

49:38

really hard to do in native. Like

49:41

a lot of that stuff is also kind of

49:43

baked into it. But

49:45

yeah, like even when you, so

49:47

when you style CSS, I believe

49:49

that is converted. Yeah, that gets

49:51

converted into like the native equivalent.

49:54

So it would be the same

49:56

as like, you know, I've never

49:58

used much of React Native, so

50:00

I don't know much of the

50:02

styling semantics of it, but essentially

50:04

it's saying, okay, read this from

50:06

your CSS and make that happen

50:08

and create the final like rendered

50:11

element style correctly. We don't support

50:13

all CSS selectors, obviously, but we

50:15

support like a wide range of

50:17

them. But I think ultimately the...

50:19

that we were after was we

50:21

need a, you know, a native

50:23

solution that's fast, that's lightweight, that

50:25

we can sprinkle into views that

50:28

don't need all the effort or

50:30

all like the hard work that

50:32

goes into like making say the

50:34

mainline experience. So, you

50:36

know, I think like on TikTok, they

50:38

were saying like the TikTok app is

50:40

native, but the TikTok shop is links

50:42

or something like that. I'm not sure

50:44

if it was the shop, maybe it's

50:47

the studio. I have to go back

50:49

and read the blog post. I don't

50:51

work for TikToks. I don't actually know.

50:53

But essentially, it's this idea of you

50:55

have things that need to run super,

50:57

super well, and you'll write those in

50:59

native code. And then you have other

51:01

things that are like, it's not, you

51:03

don't need that much out of them

51:06

where a good kind of native web

51:08

feeling solution would be perfect to inject

51:10

these things, like banners or certain pages

51:12

that are, you know, out in the

51:14

flow, but maybe your main video scroller,

51:16

keep that in C. So

51:19

I think that was a lot of

51:21

what it was used for, like surgical

51:23

ways to make a app, have

51:25

more features in app

51:28

without necessarily having to

51:30

commit to all or

51:32

none type of scenario.

51:36

So yeah, so I think that was

51:38

kind of some of the main reasons

51:40

that we had done it. It was

51:42

very like... like you know surgically in

51:44

fact of existing apps we needed something

51:47

that worked cross platform because we have

51:49

to deal with like a lot more

51:51

devices as well so um so we

51:53

wanted you know something that truly works

51:55

on everything because we have so many

51:57

like hard i think you know we

51:59

even have like pico which is like

52:01

uh vr headsets and stuff like that

52:03

so you're thinking about i need a

52:05

cross platform solution the potential of

52:07

the platforms you're up for consideration are

52:09

beyond just like oh well it needs

52:12

to work on like a phone and

52:14

a desktop or something. So

52:17

I think that's where a lot of it

52:19

came in. Now it is still like in

52:21

its early days and all of that but

52:23

it has been really exciting to see like

52:25

what they're doing and I'm you know I

52:27

think they would love to collaborate with like

52:29

existing community I'm sure they

52:31

would love to collaborate with

52:33

React Native Group and stuff like

52:35

that on similar kind of

52:37

thing. Hey, is there any kind

52:39

of shared foundations that could

52:41

be helpful to lift native app

52:43

dev in general? But

52:45

if you have any other

52:48

specific questions in there, I kind

52:50

of got off on a

52:52

tangent. But that was generally what

52:54

Lynx was brought to do

52:56

in its current form is... Drop

52:58

in there. What I would love to

53:00

see is something like a router. I

53:02

think that's like a missing part But

53:04

I also understand like why it's a

53:06

missing part because we're not like making

53:08

your your normal like router app where

53:10

hey, everything is react native and it's

53:12

all expo or whatever it's more Like,

53:14

we have a app that's built for

53:16

this purpose, but this thing doesn't need

53:18

to be in the same language, because

53:20

it's not as mission -critical. Like, the

53:22

manpower to write it and see isn't

53:24

necessary. We could do it better if

53:26

we wrote it in a more web -friendly

53:28

language. And then that's also a lot

53:30

more portable across a variety of platforms.

53:33

Cool. Well, it sounds like you guys are

53:35

working on just so many different cool

53:37

things like Eat. We're out of time now,

53:39

but we didn't even talk about all

53:41

the different RS family members and all the

53:43

different permutations that you guys have come

53:45

out with. So it's exciting to watch

53:47

from the outside looking in. And thank you

53:49

for building all these tools and for coming on.

53:52

Yeah, yeah, it was great. It was great. Come on and

53:54

chat. Yeah. Thanks again, Zach,

53:57

for coming on. It was

53:59

awesome. Last time we talked you. to

54:01

you about all the module federation work

54:03

you've been doing, and great this time

54:05

to catch up on what the current

54:07

state of our spec is. It's

54:09

cool that you're breathing new life into

54:11

the Webpack ecosystem. It's such an important

54:13

ecosystem, and it's such a

54:15

broad ecosystem. So it's great

54:17

to see. It's something that you don't want

54:20

to see die just because times have changed.

54:22

And that was a big thing. It would

54:24

be really nice to just keep it alive

54:26

because there's so many good things on there.

54:28

it just needs to run quicker. I

54:31

would say like, I know we didn't get to

54:33

the R stack stuff, but I think like in

54:35

general, what we're just planning to do with our

54:37

thing, with what we've got is like, okay, as

54:40

you can see, we're bringing out a

54:42

lot of pillars of the infrastructure that we

54:44

would need. You know, that we're going

54:46

to be bringing out tests. We already brought

54:48

out library builds, like, you know, unbundled,

54:50

tree -shakeable NPM package builds. We have RS

54:53

build, which is the recommended way to use

54:55

it, which is essentially RVT, if you

54:57

were to say, our stacks build engine and

54:59

ours builds the V of the world. But

55:03

I think probably a lot of

55:05

this is going to be how do

55:07

we fill out that ecosystem to

55:09

provide kind of because this is from

55:11

our own internal unified infrastructure kind

55:13

of approach for everything. It just makes

55:15

sense to build like this. But

55:17

I think also it's something I would

55:19

greatly appreciate in the open source space

55:21

to say, hey, here's like a full

55:23

suite of tools. that I don't

55:25

have to buy into all or none,

55:28

but if I do want more, they're happy.

55:30

Like, you know that it's designed to

55:32

work together. And I think that's something we

55:34

still struggle with in, like, ecosystem

55:36

is. The pieces can

55:38

be glued together, but it's not necessarily,

55:40

like, one -shop thing. Here's testing. Here's

55:42

documentation. Here's

55:44

bundlers. Here's, you know, frameworks.

55:47

You know, all the other bits and

55:50

pieces. Library authoring. So it'd be

55:52

really nice to have a single pipeline

55:54

for building your packages, your apps,

55:56

and everything else. So again,

55:58

I think ecosystem as well. users who want

56:00

to use this, we want to make the ecosystem

56:02

a bit more welcoming and bigger. And

56:04

And I think that's also another key

56:06

factor in the future bundler wars is going to

56:08

be, well, well, what kit does it

56:11

come with? It really matter if the tool

56:13

is good, the whole bot needs to kind of

56:15

be there as well. Yeah, there seems like

56:17

there's a few different groups trying to hash out

56:19

that battle, so I wish you guys luck. Oh

56:22

oh yeah. Anyway, yeah, so

56:24

thank you for having me on. It was

56:26

good to catch up after such a long

56:28

time.