0:00

Vue is a popular JavaScript front-end framework,

0:02

and Nuxt is an open source meta-framework

0:05

on top of Vue. Anthony

0:07

Fu is a framework developer on the Nuxt

0:09

team. He joins the show

0:11

to talk about Vue, Nuxt, open source

0:13

development, and more. This

0:16

episode is hosted by Josh Goldberg,

0:18

an independent full-time open source developer.

0:21

Josh works on projects in the

0:23

TypeScript ecosystem, most notably TypeScript

0:25

ES Slint, the tooling that enables

0:27

ES Slint and prettier to run

0:29

on TypeScript code. Josh

0:31

is also the author of the O'Reilly Learning

0:34

TypeScript book, a Microsoft MVP

0:36

for developer technologies, and

0:38

a live code streamer on Twitch. Find

0:41

Josh on Blue Sky,

0:44

Mastodon, Twitter, Twitch, YouTube,

0:46

and.com as joshuaKgoldberg. Anthony,

1:02

welcome to Software Engineering Daily. How's it going?

1:05

You're having good. Thanks for having me. Oh,

1:08

and it's our pleasure. Could you give the

1:10

audience a little introduction? Who are you and

1:12

what's going on? Yeah, sure. So

1:14

my name is Anthony Fu, and

1:17

I work for Nuxt Lab.

1:19

I'm kind of really active. I'm

1:21

a very enjoying doing open source. So

1:23

as for the title, I'm the coding

1:25

member of Vue, Vue, and Nuxt, of

1:27

course. And then I

1:29

made some open source project.

1:32

So I made no testing

1:35

framework VTest and CSS, framework,

1:37

Windows CSS, and

1:39

a slide maker for that, that you

1:41

use Markdown to do the slides, which

1:43

called Slide Dev. And

1:46

yeah. That's quite a few projects.

1:48

How often would you say you start a new

1:50

project that's open source? I think

1:52

it depends on the scale of the project,

1:54

right? So it can be a

1:57

small library, where that it can be a few

1:59

lines of code. So it can happen every

2:01

week, I guess. But for a big

2:03

project, it's like, I would love to do more. But

2:06

it really depends on when you

2:08

got the inspiration. So not often, maybe

2:11

one or two a year, I think. Sure.

2:14

Only one or two big projects a year. It's not

2:16

that big, I guess. Let's

2:18

take a step back, though. How did you first get into programming?

2:22

For me, I think I got

2:24

into programming quite young, I guess.

2:27

So I think I started as a primary school

2:30

five grade, which is like 13. So

2:33

I got into open source because I

2:35

got a friend, the same name as me, who

2:37

somehow got to know how

2:39

to do the programming. And he shows

2:42

me how he got to do with

2:44

Visual Basic. And I feel like that

2:47

cool app is like recording your keyboard on

2:49

the background and saving to a text file

2:51

so that you can treat your friend to

2:53

enter their password. And later on, you can

2:55

get their password. Something like that. So

2:58

this is very cool. I didn't know this is

3:00

possible, and you can write it. So

3:02

that's how I get into writing

3:05

code. So I started by learning

3:07

Visual Basic. And then that time,

3:09

it's like 6.0, which

3:12

is like compiled directly to Windows. But

3:15

I think the very good part compared to

3:17

now frontend is you got a visual.

3:20

So you can drag the button and find the

3:22

events, something like that. So which is you've

3:24

got the feedback very quickly. So that really

3:27

helped me to get on board like programming,

3:29

because you can see what you've got, and

3:31

you can show your friends what you made.

3:34

And then I took the computer science degree

3:37

at college. And after

3:39

getting college, I think, OK. It seems like

3:41

everybody is saying that if you do open

3:43

source, it's a direct proof of your skills.

3:46

And they're probably good for looking jobs, something

3:48

like that. So that's how I started

3:50

to try to do open source. And

3:53

interestingly, I ended up staying

3:56

at open source. And now I've been super

3:58

lucky. to

4:00

work for Knapp Lab, which now is

4:02

again being working full time on

4:05

open source. So I wouldn't

4:07

expect my career to be like that, but so

4:09

far I'm pretty enjoying that. Would you

4:11

give that same advice to folks who are now in

4:14

college that open source is good for your career and

4:16

finding a job? Yeah, I think I

4:18

still do. And so

4:20

I think open source is something

4:22

that it's basically building public, right?

4:25

So it's basically what you did

4:27

and how you communicate

4:29

with each other also do. It's also

4:31

present on open source. So it's like

4:34

even though you don't get into working

4:36

ready for open source, it's still like

4:38

when doing open source, you've got to

4:41

practice your skills and you

4:43

can try to learn and see a lot

4:45

of problems in different ways. So I think

4:47

that really helped. And

4:50

so even you got into enterprise

4:52

to work on something different, still

4:55

like the skill of solving problems or

4:57

skill like trying to, even like creating

4:59

issues, you also need to know how

5:01

to face your problem, face

5:03

your questions and how to communicate, collaborate

5:06

with each other. And

5:08

I think that really helpful. And if you are in

5:10

college, I think that for me, that

5:12

can probably be the perfect chance to

5:15

get into open source because you have a lot of time and

5:18

you can purely focus on

5:21

those different tasks. So

5:23

yeah. Yeah, it's funny.

5:25

There seem to be different stages of growth

5:27

and joining open source. The first one is

5:29

doing it at all, whether it's your first

5:31

issue or sending your first pro request or

5:33

just open sourcing a repo. And

5:36

then after that, some people stick in and

5:38

keep doing things, more issues, more repositories. Is

5:41

there any particular point

5:43

or motivator that you

5:45

found particularly effective for getting people from

5:47

that first issue to continuing in open

5:49

source? If you mean as

5:52

a maintainer, I think what I could do

5:54

is like I trying to encourage

5:56

people to try to solve their

5:58

problem their own. I mean, that

6:00

really depends on the issue as well. For

6:03

me, I find that whenever you have a problem,

6:05

or you have an issue, you have a block

6:07

of a certain library, you are actually

6:09

the one that knows this problem the best. And

6:12

also, you kind of have the most

6:14

incentive to improve that, because it

6:16

affects your problem eventually. So,

6:18

but if you kind of throw a

6:20

kind of challenge or a task to

6:23

maintainer, the maintainer might be interesting in

6:25

implementing that as well, but it

6:28

can be like the maintainer doesn't need that feature, but

6:30

you are the one that need it. So,

6:32

I would encourage that the original creator

6:34

of that issue to try to solve

6:36

this problem, and if that's in the

6:38

scope of the project. And

6:40

so I think to doing that is

6:43

like, even though sometimes like they

6:45

kind of being afraid like saying, you

6:47

know, I'm not good at creating issues,

6:49

not good at like sending code or

6:51

sending PRs or an IPR gallery drive

6:53

it or something. So they usually it's

6:55

like, it's hard to do the first

6:57

step to know that you can actually

6:59

contributing to that, to open source for

7:01

development, actually everyone could. And

7:03

it's not that hard to do

7:05

so. So at least you can try.

7:07

So I just, as a maintainer, I will

7:10

try to encourage people to do that. And

7:13

so I think if you are the

7:15

one that's creating issues, I think the

7:17

first thing is like, you maybe try to

7:19

describe your problem better and to

7:21

try to provide the more information as you could.

7:25

And maybe at least I think, I think

7:27

before you working on that, maybe you should ask

7:29

for the maintainer if the problem or

7:31

the future is like in the scope of

7:33

that project. So I think that would help.

7:36

Yeah, for sure. It's funny, you

7:38

know, very, very large companies, multi-thousands

7:41

of workers, in some ways

7:43

are closer to open source than a small

7:45

startup. Because when you're at a very large

7:47

company, you might not have any personal or

7:49

professional rapport with the people you're interacting with.

7:51

So I really respect and appreciate and agree

7:53

with your point earlier that, you

7:55

know, those skills of being able to report

7:57

an issue effectively are pretty transferable to day-to-day

7:59

life. life as a software developer in the

8:01

industry? Yeah, I think so, yes. Do

8:04

you think there are any other particular skills that

8:06

translate to and from open source and corporate life

8:08

particularly well? I'm not super

8:11

sure, but because I think I like,

8:13

actually after I graduate, I got the

8:15

offer from the next lab. So I

8:17

never got a chance to work on

8:19

a real corporation. But I think communication

8:22

skill is really important. I think it's

8:24

very kind of covered with describing issues

8:26

as well as part of that, I

8:28

guess. And then

8:31

I think it's like, so I

8:34

think in working open source project, because

8:36

the open source project can be owned

8:38

by different people or different teams.

8:41

And they may have different principles

8:43

or guidance or rules

8:46

to be. Or even for code

8:48

style, the code style can be different. So

8:50

whenever you're contributing to a project, I think

8:52

it's just maybe similar

8:54

to going to the other project or

8:56

something, they have their own rules. So

8:58

the first thing is when you're going

9:00

to contributing a project, you have to

9:02

read how they prefer contribution to

9:04

be made. Or what is code

9:06

style they prefer. And it's

9:09

best you follow their code style to

9:12

have a consistent look of the

9:14

whole entire project. So I think

9:16

that may also relate to it.

9:18

I agree. As

9:25

a listener of Software Engineering Daily, you

9:27

understand the impact of generative AI. On

9:30

the podcast, we've covered many exciting aspects

9:33

of gen AI technologies, as well as

9:35

the new vulnerabilities and risks they bring.

9:38

HackerOne's AI Red Teaming addresses the

9:40

novel challenges of AI safety and

9:42

security for businesses launching new AI

9:45

deployments. Their approach involves stress

9:47

testing AI models and deployments to make

9:49

sure they can't be tricked into providing

9:51

information beyond their intended use. And that

9:54

security flaws can't be exploited to access

9:56

confidential data or systems. Within

9:58

the HackerOne community, a Over 750

10:01

active hackers specialize in prompt hacking

10:03

and other AI security and safety

10:05

testing. In a single recent engagement,

10:07

a team of 18 HackerOne hackers

10:10

quickly identified 26 valid findings

10:12

within the initial 24 hours

10:14

and accumulated over 100 valid

10:17

findings in the two-week engagement.

10:19

HackerOne offers strategic flexibility, rapid

10:21

deployment, and a hybrid talent

10:24

strategy. Learn more

10:26

at hackerone.com/AI. That's

10:29

H-A-C-K-E-R-O-N-E dot

10:31

com slash AI. Let's

10:39

continue down your personal story towards Nux

10:41

and Nux Labs. So what was the

10:43

first big open source project that you

10:46

worked on or created that was popular

10:48

in the dev community around you? Okay,

10:50

for me, it's actually in VS

10:53

Code extension called IAT in ALLE.

10:56

Back then time I was working at a college,

10:58

I gathered with a few of my friends to

11:01

try to build an app with Vue.

11:03

So it's like, what the app is, it's

11:05

not important, but it's like we want to

11:08

add some different language into

11:10

it. So we want to

11:12

do internationalization. And because

11:14

we also have some friends who are

11:16

learning foreign language, they are majoring in foreign

11:18

language. So we're thinking that we can gather

11:20

all those friends to do the translation for

11:22

us and we can kind of

11:25

collaborate to create an app.

11:27

And I found that the

11:29

experience of doing translation

11:32

is not easy,

11:34

especially for non-programmers.

11:37

And so I was thinking, okay,

11:39

maybe I could do a VS

11:41

Code extension for that. They just

11:43

replace all your extension, all your

11:45

IAT usage into a real text.

11:47

So you can preview directly for

11:49

the content of the text rather

11:52

than the key in the map

11:54

or something. So that's how I get

11:56

into open source and I got a

11:58

lot of feedback, actually. So I

12:00

try to share my project and people

12:02

really liked it. And

12:04

then because initially it was only for

12:07

Vue, and because

12:09

I only use Vue, and I only do it for my

12:11

knee. And people started asking, is that

12:13

working for React? They have their React project,

12:15

and they want to use it as well.

12:18

So then I started thinking, OK,

12:20

how I can do it? How I can

12:22

make this open source project serve for multiple?

12:25

So that kind of takes some

12:28

big refactor and make it universal.

12:30

So in the end, it kind of

12:33

works for 20 different frameworks, and it's

12:35

also extendable. So you can create it

12:37

for your custom framework. So something like

12:39

that. And during that, I find

12:42

that open source is very interesting and kind

12:44

of rewarding because people kind

12:46

of send appreciation to your work.

12:48

Well, that's the initial work is that

12:50

I do it for myself, and I

12:53

do it for us. So that's how

12:55

I get into this. And

12:57

also, that kind of get my

12:59

kind of confidence to say, OK, maybe I

13:01

could do more. So that

13:03

kind of being more active in

13:06

the Vue ecosystem, and then eventually

13:08

join Vue. And then

13:11

the next. That's

13:13

really lovely and also something that I've somehow

13:16

found. The internet has a reputation for

13:18

not particularly great emotions being thrown at folks.

13:20

But in the open source community, it

13:22

is actually surprisingly positive at that many

13:24

times, where folks who are doing notable

13:26

note work that benefits people do actually

13:28

receive a lot of praise. They can

13:30

be very rewarding and encouraging as a new

13:32

maintainer to do that type of work.

13:35

Yeah, that's true. Yeah, that motivates me a lot.

13:37

Yeah. Cool. Let's talk

13:39

about Nux then. So you mentioned Vue earlier,

13:42

and we've also talked about Nux. Now, not

13:44

everyone particularly works

13:46

with front-end frameworks or meta frameworks. Could you tell

13:48

us what is Vue and then what is Nux

13:51

and how does this stuff all fit together? Yeah,

13:54

I'll try. So I think the

13:56

definition is sometimes ambiguous. And

13:58

so Vue is from Nux. framework

14:00

that renders your data into

14:03

a DOM, which is, let's

14:05

say, the view of the web page. And

14:07

we will also provide some component features so

14:09

you can do separation of concern. So you

14:12

can provide different components to do

14:14

different tasks and then compose them together

14:16

to create, eventually create your app and

14:18

that can be interactive and can be

14:20

feature rich. So that's

14:22

view and we also have quite a

14:25

few alternative like React

14:27

and survey out

14:29

Angular, something. And then

14:31

for Nux, Nux is a meta-framework

14:33

on top of view. So let's

14:35

say that meta-framework for view. What

14:37

a meta-framework is, to me,

14:39

it's also hard to define, but it's just like,

14:41

it's just trying to providing you a bunch

14:44

of different solutions together and

14:46

to solve different needs. So for example,

14:49

like view itself is only focusing on

14:51

how to synchronize data with

14:53

your UI, with your view. While that

14:55

meta-framework care more about that, on top

14:57

of that is like how you define

15:00

your data, how you deploy your app

15:03

and how you're communicating with the

15:05

server to send data or retrieve

15:07

data and how you do like

15:09

search engine optimization, something like that. So

15:11

Nux is a meta-framework on top of

15:14

view and it providing feature like SSR,

15:17

which is server side render, so that

15:19

you can have the initial request from

15:21

the server that's already pre-rendered with your

15:23

UI. And then we

15:25

can have the client side render, which is just

15:28

how view works, but we can mix them together

15:30

so that you can write

15:32

your code once and your code can run some

15:34

both server side and client side, which if

15:36

you set up your own, that can

15:38

be quite a lot of work. So we handle that for

15:41

you. And then we're providing

15:43

some kind of like integration for

15:46

you to make it easier. So like if you want

15:48

to deploy to anywhere, it's just like

15:50

you can just do it without any configuration because

15:52

we handle all the things for you. And

15:54

then if you want to install some sort of like third party inspiration,

15:57

we also have like module system. so

16:00

that you can use it. So yeah,

16:02

basically, it's more like, I don't know

16:04

how to say, maybe it's like enterprise

16:07

solution, but it's also open source. So

16:09

it's a package of different

16:11

solutions for different aspects. And

16:13

we consider that for you. So it's just

16:16

trying to make your development experience

16:18

easier and more efficient. This

16:27

episode of Software Engineering Daily is brought

16:29

to you by Vantage. Do you

16:31

know what your cloud bill will be for

16:33

this month? For many companies, cloud costs are

16:35

the number two line item in their budget

16:37

and the number one fastest growing category of

16:39

spend. Vantage helps you get

16:42

a handle on your cloud bills

16:44

with self-serve reports and dashboards built

16:46

for engineers, finance and operations teams.

16:48

With Vantage, you can put costs

16:51

in the hands of the service

16:53

owners and managers who generate them,

16:55

giving them budgets, alerts, anomaly detection

16:57

and granular visibility into every dollar.

16:59

With native billing integrations with

17:01

dozens of cloud services, including

17:04

AWS, Azure, GCP, Datadog, Snowflake

17:06

and Kubernetes, Vantage is the

17:08

one FinOps platform to monitor

17:11

and reduce all your cloud bills.

17:13

To get started, head to Vantage.sh, connect

17:15

your accounts and get a free savings

17:18

estimate as part of a 14 day

17:20

free trial. data

18:00

changes, you can call it state. It depends

18:02

on the type of the data. But it's

18:04

just like when the data changes, you should

18:06

reflect to the UI, right? It's

18:09

like you're saying that if the

18:11

button is being clicked or not, and

18:14

you should present, when you change

18:16

the data, you should present it in the view. And

18:19

so I think for me, the difference

18:21

between view and the React is a

18:24

lot, actually. It's not too much, but

18:26

it's also a lot. If you're taking

18:28

it very detailedly. So I

18:30

think the difference is that view has its

18:33

own syntax. It's called view single file

18:35

component. We call it SFC. That

18:38

you can have your template, which

18:40

is the HTML code, and your

18:42

script, JavaScript code, and your style

18:44

CSS into one file, so

18:46

into one component, so that we kind of

18:48

have the solution for you to say the

18:51

logic, the UI, the structure, and

18:53

also the style is all in one single

18:55

component. So you only

18:57

need to concern about this component, where

18:59

that React does not handle it. React

19:02

doesn't handle it for you. But React

19:04

instead, I like to say, oh, we don't care

19:06

about this. And we've got a community to do

19:08

it. And then in the

19:10

React, you have, I don't know, maybe hundreds

19:12

of different solutions for the same thing. And

19:15

it's also good in another way. It's like you

19:17

have a lot of choice. But for me, it's

19:20

like in some technical taste

19:22

or decisions, I kind of prefer view.

19:24

And also because I'm learning, I'm kind

19:27

of starting to learning view. Because

19:30

I heard, they say that in the

19:32

journal lab, they

19:34

will say that view is easier to learn. So

19:36

at that time, okay, I pick view, and then

19:39

I stay at view, because I also

19:41

find that the later decision of view that

19:43

make more sense to me. But I think

19:45

in the end, it doesn't really matter.

19:48

It's like when you're looking at a website, you

19:50

won't tell it's a front view already, unless you're

19:52

looking to it. And so I

19:54

think both sides is like, depends on what you

19:56

use, depends on what you need,

19:58

you can choose different framework. And I

20:01

think on the high level, they are

20:03

interchangeable in a way. I

20:05

think the way you've answered that, correct me

20:07

if I'm wrong, is somewhat informed by how

20:10

a lot of online discourse about these competing

20:12

front-end frameworks has evolved over the last decade,

20:14

where back in the day, folks tended to

20:16

be very aggressive, very, no, you can't use

20:18

X, you have to use Y. View sucks,

20:20

react great, react sucks, view great. But

20:22

no, you're right. A lot of the

20:25

shared ideologies between the frameworks are common.

20:27

Things like the concept of a component

20:29

is somewhat similar between them. And

20:32

they've all learned and grown through and from

20:34

each other. Yeah. And I think that

20:36

you can see that also like framework trying

20:39

to evolve and to

20:41

add new features, and we

20:43

will learn from each other. So I

20:45

think as the view one, the components

20:48

concept, it doesn't exist. And

20:50

like view two, we have

20:53

the virtual DOM concept from

20:56

React. And view three, we

20:58

take the view comes to the unit,

21:00

which will be similar to React hook.

21:03

And then React also takes on inspiration

21:05

from view as well. I think they

21:07

have like use transition API or something,

21:09

which is they care that it's inspired

21:11

from view. And I think that it's

21:13

basically like we are learning with

21:16

each other. And the newly framework is

21:18

also like, they build on the

21:20

concept that they already know that's the different

21:22

trade off of different framework and they

21:24

build from scratch, but they still based

21:26

on the knowledge that we kind have

21:28

different experiments or different trade

21:31

off. Yeah. So I think that's

21:33

also like, I why I'm joining open

21:35

source because they it allows different opinions

21:37

to exist. But also like, eventually, we

21:40

are building good stuff for for people for

21:43

everybody to use. Yeah, it's a real

21:45

strong counterpoint, I think against building these things

21:47

in close source, who's trying to determine what

21:50

company's visibility, it's harder to let people learn

21:52

from you. And then it's harder to let

21:54

people contribute. This

22:03

episode of Software Engineering Daily is brought

22:05

to you by Starburst. Struggling

22:07

to deliver analytics at the

22:09

speed your users want without

22:11

your cost snowballing? For data

22:13

engineers who battle to build

22:15

and scale high-quality data pipelines,

22:17

Starburst Data Lakehouse platform helps

22:19

you deliver exceptional user experiences

22:21

at petabyte scale without compromising

22:23

on performance or cost. Trusted

22:25

by the teams at Comcast,

22:27

DoorDash, and MIT, Starburst delivers

22:29

the adaptability and flexibility a

22:31

lakehouse ecosystem promises on an

22:34

open architecture that supports Apache Iceberg,

22:36

Delta Lake, and Hootie, so you

22:38

always maintain ownership of your data.

22:41

Want to see Starburst in action?

22:43

Get started today with a free

22:45

trial at starburst.io/SED. Let's

22:54

talk about NUCST. NUCST is

22:56

a meta-framework for a view, if I've understood

22:58

right, and it adds in features such as

23:00

server-side rendering, nice integrations with data, fetching. Are

23:03

there any particular parts of NUCST that you've

23:05

been working on recently that you're excited about?

23:08

So NUCST comes from... React

23:10

also has a meta-framework called NUCST,

23:13

and then recently you remit. So

23:16

I think NUCST comes up

23:18

around the same time with NUCST,

23:21

which is around seven or eight years

23:23

ago. So now we are on

23:25

NUCST 3, and while NUCST 2 was for

23:27

view 2, NUCST 3 was for view 3, and

23:30

at NUCST 2 we kind of built on

23:33

top of Webpack. And I

23:35

think Webpack is super popular at that time,

23:37

and that's probably the only valid solution at

23:39

that time. And then for NUCST

23:42

3, because of the rise of VIT, so

23:44

we're thinking that maybe we should also support

23:46

VIT for the better developer experience

23:48

and the faster hard-market

23:50

replacement, and maybe also the ecosystem.

23:53

So in NUCST 3, we try to

23:56

integrate VIT to be supported in NUCST,

23:58

but we also don't want abandon the

24:00

existing user of using webpack for them

24:02

to transfer my workflow from NUC2 to NUC3.

24:06

So then we end up to support a bit

24:08

like agnostic layer of builder so

24:11

that you can use VTO webpack

24:13

as you want. You can switch

24:16

two different underlying bundler. And

24:19

then also we kind of create

24:22

a kind of universal layer of

24:24

plugins called unplugging that you can

24:26

write your plugin once and that

24:28

works for webpack and lead and

24:30

also like the other like ES

24:32

build and RSpec or something. So

24:34

then it's very interesting. It's like,

24:37

and then we also have a server layer

24:39

because we need to handle the, like your

24:42

API request when you host it and

24:44

how your servers are rendered and how

24:46

you deploy to different platform for the

24:48

kind of like serverless functions. So

24:51

they are output and they are format

24:53

is a little bit different. And then

24:55

we have the nitro, which is the

24:57

underlying server engine that we made from

24:59

NUC3, but then we make it universal.

25:01

So it decoupled from view and decoupled

25:03

from NUC2 so that everybody can

25:06

use it. And then now analog, which is

25:08

a angular framework. Now it's

25:10

using nitro to do this thing and

25:12

solid for solid star. They're also using nitro.

25:15

So what I want to say is like,

25:17

we take the concept of making things universal

25:20

and we're peeling some like features

25:22

that kind of complex problem outside

25:25

of our NUC project

25:27

to make it as another open source

25:29

project. And that can be universal beneficial

25:31

to the others. While that's

25:34

not itself can be specific to the

25:36

problem you're trying to solve while the

25:39

underlying things can be shared with the

25:41

rest of the community, even though they

25:43

don't use view. So

25:45

yeah, I think that's really excite

25:47

me about, we don't see it

25:49

quite often in open source in

25:51

the front end of the field.

25:53

Yes. Yeah. I hope folks learn

25:55

from you before we get into each of those awesome

25:58

pieces of tech you mentioned. I want to shout. about

26:00

is there's a really interesting design principle.

26:02

You just mentioned here that if you

26:04

build your layer on top of composable

26:06

components that can be swapped out and

26:08

made available, that A, lets

26:10

you focus on the thing you want to

26:12

do more, and B, makes more good open

26:15

source projects other folks can use. And that

26:17

almost feels to me like an extension of

26:19

the classic coding philosophies, single responsibility

26:21

principle or the Unix philosophy of say, do

26:23

one thing and do it well, or only

26:25

have one reason to change. That you're making

26:27

these composable blocks that sound like good software

26:29

principles in general. Yeah,

26:32

I think so, yeah. And I think

26:34

also like if you're making your

26:36

logic or something that

26:39

can be independent from the original problem

26:41

yourself, is actually you will find a

26:43

better, even better, how to

26:45

say architecture or structure of

26:47

your problem. It's like you can see the problem

26:49

more clearly. That's why you want to do

26:51

this, or like how you can do it

26:53

better. And then like with a different

26:56

solution or different approach trying

26:58

to use your solution, is

27:01

like you can make it more universal

27:03

and maybe more robust. And

27:05

I think, yeah, I think that that's really

27:07

like, also like when maintaining this piece of

27:09

a block is actually a

27:11

lot easier because you can only focusing on this

27:13

scope and you don't need to worry about the

27:16

others as long as the scope,

27:18

inside the scope, the input output is how

27:20

you expect it. And then on the higher

27:22

level integration, you can just use it as

27:24

a block to build something else. Absolutely.

27:28

Let's dive into that as some of the

27:30

building blocks you mentioned. The first was switching

27:32

from Webpack to Vite. And for those who

27:34

aren't familiar, could you give us a brief

27:36

intro on what our Webpack can be in

27:38

similar bundles? How do those fit into the

27:40

stack? Okay. And

27:43

so Webpack comes

27:45

out with a, actually

27:47

I think at that time it's a

27:49

very innovative idea. It's like trying to

27:51

bundle everything into JavaScript. And

27:53

so like, I think back then, that is

27:55

how you need to serve your HTML by

27:57

yourself and then JavaScript and then CSS. you

28:00

need to kind of handle all the relationship

28:02

between each other and how you serve those

28:05

files. And I think that works

28:07

well when you serve only one HTML file or

28:09

the other HTML file is like static and

28:12

should be relatively easy to maintain.

28:14

When you adding some like dynamic

28:16

generated blocks or like when your

28:19

website structure becomes very complex, it's

28:21

really hard to manage those things. And

28:24

what that comes up when I do is

28:26

like, I will bundle in CSS and

28:28

HTML as part of JavaScript.

28:31

And then I can just based on this page,

28:33

how many different stuff you use, I would just

28:35

make it one bundle or

28:37

several bundles of those different chunks.

28:40

And then whenever user visit a

28:42

page, the page one knows that

28:44

which blocks to be grabbed and

28:46

then serve those things automatically. And

28:50

that can really make the front

28:52

end to be, how

28:55

to say, it's like from something that

28:57

it can be only handles a small

28:59

scale of project becomes server. It allows

29:01

you to do much more complex project

29:03

in a manageable way. So

29:05

that really evolves the front end world a

29:08

lot. And then

29:10

the problem becomes like, because this allows

29:12

you to do more complex projects, so

29:14

then people will do more complex projects.

29:16

So for sure, right? And that makes

29:18

sense. And then

29:20

we kind of have some like a bottleneck

29:22

is like, when you have too much files

29:25

and the bundling and the transpiling

29:27

process can be very slow. So

29:30

that maybe when you're starting a

29:32

dev server, so you're trying to preview the

29:34

website you are working on locally, it takes

29:37

a lot of time and like

29:39

taking two seconds fine. But like, what if it

29:41

can be like two minutes or five minutes and

29:44

then it's like, you need to wait for

29:46

to doing another work. But I think in

29:49

the traditional development or maybe like compiling it

29:51

just like that, I guess, but

29:53

fully web is something is like, when

29:55

you also have different type of content,

29:57

different type of app. also

30:00

want to change something. So for

30:02

example, like if you're adding a document, and

30:05

the document, whenever you type some word

30:07

of the content, it can take two

30:09

minutes to react to be showing some

30:11

the webpage, it's not really acceptable, it

30:13

kind of breaks your, your

30:15

workflow and trying to like

30:17

mind flow. It's like when you're trying to think something,

30:20

but you're getting to arrive by kind

30:22

of annoying because the tool doesn't catch up

30:24

your mind, something like that. So

30:26

then for VIT, so VIT console is like,

30:29

because webpack is doing a lot of

30:31

work to trying to bundling all your

30:33

package, and when your page is relying

30:35

on a lot of things, it will

30:37

kind of repackaging all these dependencies. And

30:40

VIT is trying to do another way, it's like we do

30:42

like a bundle list, it's like we don't bundle your code,

30:44

we just serve your code as is, but

30:46

we transfer it to be consumable by

30:49

the browser. And whenever you change your

30:51

content, it's only changing that file, it's

30:53

not causing the whole bundle to be

30:55

recalculate. And it also like doing these

30:57

things on demand. So that means

30:59

if you have a website that has a

31:01

million of file, and you

31:03

enter one page, you don't bundle the whole one

31:06

million files, you just only bundle like 10 files

31:08

that are related to this page. And

31:10

that kind of solves a lot performance

31:12

issue from webpack. So yeah,

31:15

I think that there are many difference. And

31:17

then I think VIT now

31:20

kind of grows as the right is

31:22

still right even using and it's built

31:24

on top of the consumption is like

31:27

browser can consume yes modules. While that's

31:29

like I think five years ago, it was not possible.

31:32

So VIT will only be possible when

31:34

the new spec of JavaScript comes out.

31:37

And reasons is still a relatively new

31:40

tool. But now it's like has a

31:42

very vivid ecosystem. Just

31:45

a current of information by ESM

31:47

you're referring to ECMAScript modules, the

31:49

ratified JavaScript modules format? Yes.

31:51

Well, yeah, that's

31:54

amazing that it's a direct

31:56

reflection of work being done on the JavaScript

31:58

language in the ecosystem. making

32:00

its way to the platform to allow better tooling

32:02

to be built than what was there before for

32:05

users. Yeah, exactly. Yeah. Beautiful.

32:08

All right, let's go to the next one. You

32:11

mentioned after that the unplugging universal

32:13

layer. So there's, if I understand

32:15

right, a kind of general plug-in

32:17

layer that folks can write plug-ins

32:20

for, for Nux and similar. Is

32:22

that accurate? Yeah, kind of.

32:24

Yeah. So we basically,

32:26

because Nux also needs some like

32:29

internal plug-ins to make the

32:31

Nux convention works. And

32:33

because we want to support both Webpack

32:35

and VIT. And then

32:37

basically means that for the internal plug-ins,

32:39

if we're going to support both fund

32:41

dollars, that means we probably need to

32:43

write our code twice. And

32:45

that kind of debate the principle of not,

32:48

do not duplicate your code, right? And

32:51

so we kind of think maybe if

32:53

we could have a universal layer that

32:55

you can write code once and that

32:57

can work for both bundle. And

33:00

that kind of save us a lot of effort to

33:02

maintain those things. And also like

33:04

the misalignments between two implementations, which

33:06

is really hard to kind of

33:08

solve, right? And that can

33:11

also affect the user experience because a

33:13

different platform can have a different behavior,

33:15

which is quite confusing. So we're trying

33:17

to do that. And for

33:20

unplugging is initially is trying to build a

33:22

layer between Webpack and VIT. And

33:25

because VIT is also inherent on Roa

33:27

app, so then we can also naturally

33:29

support Roa app plug-ins. And then

33:32

because we have these layers and

33:35

we made it open source and people

33:37

say, okay, this is maybe a good

33:39

idea. And they, they starting to integrating

33:41

more funders or more build tools into

33:44

this plug-in layer. And then

33:46

now I think we have

33:48

ESPute support and also

33:50

RSpack, which is experimental. And

33:52

then all these things, they are like low

33:55

level build tools. And

33:57

then that means like with this layer, the plug-ins are

33:59

very easy. you, you, you also, I said,

34:02

it works for those build tools and also

34:04

works for every metaphor I built

34:06

on top of those tools. So

34:08

that means if you are targeting

34:10

for VIT and that means Nux

34:12

would also benefit from it and

34:14

then the VEL kit and solid start

34:17

and yeah, maybe remix. Remix is also

34:20

like migrating to VIT recently. So that

34:22

you are able to use the plugins

34:24

to be like, to use for all

34:27

those things. And now also

34:29

like saves a lot of this, like you

34:32

don't have like, if you want to do

34:34

some plugin, you don't have a VIT plugin

34:36

version and webpack plugin version from different author

34:39

or like with different implementation, a bit

34:41

like it's not really vendor

34:43

locking, but they just like you are being locked

34:45

into this ecosystem when you want to migrate to

34:47

the others, it'll cause you a lot more to

34:49

do it. So I'm talking just

34:52

like trying to find a common feature.

34:54

It's like a common part of

34:56

different tools. So it's not as capable

34:59

as a native V2 native plugin, but

35:01

it's just like in general,

35:03

trying to providing the common part

35:05

of different build tools as

35:07

for the plugin. Yeah. If I were

35:09

an end user on a team, what would be an

35:11

example of a plugin that I might want to

35:13

write that would then work with the unplugging system?

35:17

So we have, if you've heard

35:19

of Sentry, it's a telemetry, telemetry

35:21

library or something, and I

35:24

think they made unplugging Sentry. So that they

35:26

are a central integration with unplugging. It can

35:29

work for VIT, for webpack and for the

35:31

others, while that they only need to maintain

35:33

one single code base. And

35:35

I think that at the end user, you're probably not going

35:37

to use it directly, that

35:39

for a library author, that would be

35:42

more relevant. That's really nice. Sentry

35:44

is also in particular with open source, very

35:47

good about publicizing what they're doing. They've got

35:49

a great open source program headed up by

35:51

Chad Whittaker. So shout out Sentry. Let's

35:54

continue. So you've been

35:56

talking about what's currently happening in Next with

35:58

Next3. Is there anything coming up

36:01

on the horizon that you're juiced about for NUC

36:03

in general? Yeah. So

36:05

for the last year, my main focus on

36:07

NUC is trying to build the NUC step

36:09

tool. Because when you say

36:11

that meta-framework is trying to provide

36:14

different solutions, it can

36:16

be a little bit like it's adding

36:19

too much sometimes. It's not very obvious

36:21

what the framework is doing or what

36:23

it's doing under the hood. And

36:26

whenever you have some bug from the internal of

36:28

the framework, it can be very hard to debug

36:30

and you don't know why or you don't know

36:33

why this is caused or you don't know the

36:35

relationship between each part. So I

36:37

would call it lack of transparency.

36:40

So it's like the framework becomes a black box

36:42

and you don't know what is going on. And

36:45

it's really hard to find things from

36:47

outside. So we want to improve

36:49

the transparency of this black box. So

36:52

we made a dev tool which lets

36:54

it's trying to tell you more

36:56

information that the framework knows how

36:58

your components is being located and what's

37:00

the relationship between each of your components.

37:03

And also, so for user facing,

37:05

it's like how your route being

37:08

how your navigation is being constructed

37:10

and how your components being constructed

37:12

and how your logic is being

37:15

organized or something. And

37:17

at a bit low level, it's like internally

37:19

we will tell you how each hook, internal

37:21

hooks of the NUCs, like how long they

37:23

take or how many times they go so

37:26

that you can know better of the

37:28

internal things. And then we

37:30

also have that third party modules, right?

37:32

And modules can also provide their own

37:34

dev tool integration to providing a view

37:38

of how the modules is doing. So

37:40

for example, like we have an OG image

37:42

module that can generate a dynamic

37:44

OG image for different routes. And

37:47

if you want to preview your OG image, it's like

37:49

you need to, the traditional way is like you need

37:52

to check your source of the page and to grab

37:54

the link and try to access the link. And

37:57

that's okay if you do it once, but that would be too

37:59

tricky if you want. to try different

38:01

multiple routes. And it's providing it. So

38:03

with the module, it's providing a UI

38:05

in the DevTools for you to preview.

38:08

And whenever you navigate a page, it will

38:10

just preview the content of it. And whenever

38:12

you change some title or something, the OG

38:14

image will be updated automatically. So

38:16

that's something that we are trying to

38:18

improve the overall developer experience and

38:21

to make these things easier to use

38:23

and easier to understand. Do

38:26

you see a medium to long-term

38:28

future where other meta frameworks, like you

38:30

mentioned Solid Start earlier, would also be

38:32

able to use this kind of DevTooling?

38:35

So we actually have quite a

38:37

few frameworks. He's already doing so.

38:40

So Astral, I think they announced

38:42

a kind of Astral tool bar

38:44

or something, which is following the

38:46

similar idea. And Midian,

38:48

Midian is a React library

38:50

to improve the rendering performance. It

38:53

also providing a DevTool. And

38:55

then I know Quick is working

38:57

on their own DevTool. And

39:00

then ModernJS, ModernJS is also

39:02

another React framework, Metafine

39:05

or Firebase, and they're

39:08

also working on their own DevTool. So

39:10

I would be really happy to see that

39:12

the more and more frameworks is trying to

39:15

providing such integration and trying

39:17

to make the debugging or the

39:20

overall things better for you to

39:22

understanding or manage your project. And

39:25

we have a relative long-term

39:27

goal to say if we can

39:29

make a kind of DevTool kit,

39:31

which is like infrastructure for DevTool

39:33

that works cross-front work, that

39:36

we need to take some time to

39:39

deal with the details of it. And it

39:41

may be tricky doing permanent ideas. But

39:44

we'll see. Yeah, to your point earlier, there

39:46

is a lot of quote-unquote duplicate work

39:48

happening. All those different Dev

39:50

setups, toolbars, and so on are the

39:52

implementations of the same idea. But

39:55

is it possible to unify before

39:57

all these implementations have experimented? Is

40:00

there any work that can be done now to unify them?

40:03

I think it depends on what

40:05

a different framework would need. And

40:07

I think maybe not unifying too

40:09

early would be better for allows

40:12

different ideas to come up. So

40:14

I think for us, it's like we were kind of

40:16

saying that for DevTool, it's still

40:19

a relatively new thing that's

40:21

not being explored a lot. So

40:23

for example, we have a lot of

40:25

data internally when we're bundling things or

40:27

when we're serving content. If

40:30

we got the data and how we present

40:32

it, how we visualize it, and how we

40:34

make it interactive is something that no one

40:36

did that before. And also

40:39

like no one have exactly same data you

40:41

have. So that can be a challenge that

40:43

you can, you basically try and arrow and

40:46

you can view something for the open source

40:48

and then people will use it and give you

40:51

feedback to say if they want this better or

40:53

if they kind of need some different

40:55

information and then we improve and

40:57

iterate later. So I think it's

41:00

still a very new field. And so

41:02

I think different frameworks, they are now

41:05

trying to present those data in a

41:07

different way and probably not unifying those

41:09

things too early might also help them

41:11

to say they can work there, like

41:14

they can do more different type of

41:16

visualization presentation rather than you have to

41:18

use this kind of the friend or

41:20

something. It's like you don't need to

41:23

be limited by the API that

41:26

the layer, the universal layer provide.

41:28

So I think it definitely depends

41:31

while that's universal is a good thing, but

41:33

it's not always the best in many cases.

41:36

Sure. You mentioned the

41:38

dry philosophy, don't repeat yourself earlier. There's

41:40

a corresponding philosophy function in the front

41:42

end also sometimes like to say wet,

41:44

right, everything twice. You

41:46

can't really know what you're doing until you've done it. Sorry.

41:49

Yeah. Like render

41:51

twice. Yeah. Cool.

41:55

So that's a lot on Nuxt and I do wanna

41:57

ask also any other particular projects you're working on. Have

41:59

you been... playing an open source recently on stuff

42:01

outside of NUC, so you want to talk about? Yeah,

42:04

for very recently, I've been working on

42:07

a rewrite of another open source project.

42:09

So my project called Shikiji and

42:11

the project so that it will

42:13

be a ESM rewrite of Shiki

42:15

and Shiki is a syntax

42:18

highlighter that's based on

42:20

VS Code text-made grammar.

42:23

So that means that it can reuse all the grammar

42:25

you have for the VS Code. So

42:27

to say that if someone build

42:29

a extension, a VS Code extension

42:31

for a certain language and

42:34

Shiki can use that language syntax to

42:36

highlight the code, you answer. So

42:38

you don't need to do the work

42:40

twice, while that it can provide a

42:42

very accurate syntax highlight that

42:45

the other approach may not be easy

42:47

to approach because as the VS Code

42:49

evolve, this thing will also evolve as

42:51

well because it shares the same engine.

42:54

So the reason I'm doing this thing

42:56

is because I'm actually also

42:59

a maintainer of Shiki, but we

43:01

have some long-term issue about how

43:03

we're loading those grammars or how

43:05

we're loading the Wasm dependency. Wasm

43:08

is WebAssembly, which is VS Code

43:10

uses. So we have to

43:12

use the same WebAssembly in order to achieve

43:14

the same effect. But this is a kind

43:16

of static asset that we need to import

43:18

it from somewhere. So originally we

43:20

used the file system to read it and

43:23

then it kind of coupled with that because

43:25

we use the file system, that means this

43:27

code can only run on node. But

43:30

we also have some demand as to

43:32

run on the browser or run on

43:34

the age environment in a worker so

43:36

that it can be relatively low cost

43:38

faster. And then this dependency of our

43:40

system or the file path kind of

43:43

blocking that. And while that's in another

43:45

way, if you want to change all

43:47

these things, you need to break a

43:49

lot of things. So that will

43:51

break the existing user. So I'm thinking, okay, maybe

43:53

a safer way is I would do it from

43:56

scratch as another project so I can break as

43:58

much as I want. And and

44:00

I can try different ideas. And

44:03

then after these things, okay, this kind of

44:05

actually works out. So I can use the

44:07

ESM. Oh yeah, by the way, at other

44:09

times probably ESM is not popular enough for

44:11

Shiki to adopt it, but now it is.

44:13

So now I'm able to load a lot

44:15

of things from ESM. And

44:17

ESM is also trying to support the web

44:19

assembly natively, but that's the spec for the

44:22

future. So it's not yet now. So

44:24

basically with the whole rewrite, it

44:26

can achieve more efficient and more

44:29

environment agnostic thing. And

44:31

then because I break a lot of

44:33

things, I try to think creative and

44:36

trying to use the cutting edge things

44:38

as much as possible. And

44:40

then looking back, if I compare to what

44:42

I break and what is breaking, and actually

44:44

I can provide in a compatible layer. So

44:47

for Shiki-G it also has a Shiki-G Compat

44:49

project, a package that's just

44:51

using the same engine, but

44:54

it just trying to providing the legacy

44:57

format, input and output. So you

44:59

can basically swap the original Shiki

45:01

without changing any code. And

45:03

then it also works, but more efficiently.

45:06

And while that's if you prefer the

45:08

new things that you can migrate over, so

45:11

something like that. So we are

45:13

trying to find a way to merging

45:16

the Shiki-G project as the next version,

45:18

a major version of Shiki. So

45:21

eventually these two projects might be merged

45:23

together so you don't have these

45:25

different things. And I'm still

45:28

talking with the original author and we

45:30

are trying to find a way. So

45:32

that's what I've been working on. Good luck.

45:35

Yeah, thank you. Well,

45:39

I wish we could dive into more, but unfortunately we

45:41

have a non-infinite amount of time. And I do want

45:43

to get to a few questions at the end. You

45:46

have what is probably my

45:48

favorite personal website background of

45:50

all time. It's this beautiful little

45:52

visualization that slowly grows when one

45:54

visits antfu.me. Can you tell us

45:56

about that and what generative art

45:59

is? Oh,

46:01

thank you. So I

46:04

think that in 2022, no, it's like

46:06

2021, I said something. It's like, I

46:11

was with my friend to say maybe you

46:13

should do a like generative arts challenge. So

46:16

generative arts is like you're writing some

46:18

code to draw something to

46:21

generate in some graphics that looks interesting.

46:23

And because you have the program, so you

46:26

can, the input can be randomness. So you

46:28

can use some random function or you can

46:30

use something programmatically to generate in

46:32

these things. And with the cameras, you can do

46:34

it dynamically. So you basically can, you can draw

46:36

an animation or even with, you

46:39

can do some interaction. So you can grab

46:41

the position of your mouse and take

46:43

that data to do something. So

46:45

generative art is like just creating some and

46:48

any graph with some code. So

46:50

at that time, so we are trying

46:52

to do a 100 day challenge to

46:54

say every day you're going to make

46:56

generative art. So every day can be

46:58

a different. So I'm trying to think

47:00

about different way of doing that. So

47:02

that's why I have a website to

47:04

hosting all my, my experiments. The

47:06

link is like 100 dot NTFU dummy

47:10

is my website. But yeah, unfortunately I

47:12

didn't finish the 100 day. I think

47:14

I end up at 41 day or

47:16

something, but the background of my website

47:19

is coming from one of the

47:21

day. It's a growing tree. So

47:23

I call it plum because the branch is

47:25

very short. It's more like a plum, how

47:28

plum grows. So the logic itself is very

47:30

simple. So also that's why I love it.

47:32

So it's like, you grow a branch and

47:35

you draw a branch and after

47:37

drawing a branch, you decide to kind of

47:39

roll the dice. 50% it will

47:41

grow a left branch and 50% will grow

47:43

a right branch. So eventually some

47:45

branch will end up with no new branch and

47:48

some branch will continue growing. And

47:50

then with iteration, so like every

47:52

500 milliseconds you, you

47:54

draw a new branch and then it's

47:57

growing and start growing. And

47:59

that's really interesting. So the rule

48:01

is simple, but the outcome, I really like it.

48:03

So I put it as the background of

48:06

my website. So yeah, I

48:08

think I should do more. I think. That was

48:11

my next question. Do you ever plan on resuming

48:13

that 100 days challenge? Yeah, I

48:15

do. But it's

48:17

really, yeah, I think I really enjoying

48:19

that period. It's like you trying to

48:21

be creative and trying to think of

48:23

different approach. But also really

48:25

tiring, to be honest. It's

48:27

like you have the pressure to be, today

48:29

you're going to finish it. And if you want

48:31

to be easier next day, you

48:34

have to think before. So

48:36

after you finish today's mission, you

48:38

start to think about the tomorrow.

48:41

If you can't have the rest of the day,

48:44

you can think about it. It's like, it'll be

48:46

easier for you to like having half a day

48:48

or like, of course you have a life to

48:50

go on, you have work to do. So you

48:52

have to find time to think about it. But

48:55

it's like, I think idea doesn't come from hardworking,

48:57

I guess. You don't think it really hard to

48:59

come up with the idea. You got the inspiration.

49:02

So yeah, I think probably that part

49:04

really scared me out. So maybe I

49:06

should try it. But

49:08

I just like think about that day that it's just

49:10

really hard for me to go back to these things.

49:13

But yeah, I think that also like challenged

49:15

me a lot on my programming skills. Like

49:18

how to do the animation, how to do it

49:20

in a session way and how you can, yeah,

49:23

I think especially evolve with the

49:25

graphs. Graphics is like, because you

49:27

have the metrics, you have like

49:30

millions of dots to deal

49:32

with. And you have millions of

49:34

loop. And you also like, you

49:36

need to optimize it in order to not

49:38

running on a very low frame rate, something

49:40

like that. So I think that's a very

49:42

fun. And yeah, I don't,

49:44

I cannot give a promise, but I

49:46

probably should continue doing that. Well,

49:48

let me know if you do, that'd be lovely. There

49:50

is, I think, an interesting parallel or

49:52

a contradiction, almost a dichotomy in how

49:55

one writes graphics or graphics intensive code

49:57

versus traditionally what you would want in

49:59

open source. source, you want your

50:01

code to be clean and readable and someone who

50:03

has no idea anything else in the project can

50:05

come in. But then a graphics code, the opposite

50:07

priority comes into play, it needs to be efficient,

50:10

and you need to micro optimize and that can

50:12

really harm readability. Yeah, that's true. Yeah.

50:14

And I think that's kind of quite a challenge that

50:17

you try to looking for the balance

50:19

of both. It's like, what if you can

50:21

write a clean code that can be efficient.

50:23

And yeah, that's a, for

50:25

me, it's like a really fun challenge

50:28

to me to work with, because in

50:30

the end, you got the fast and

50:32

also clean code. And that's really interesting.

50:35

I mean, that's based on the fact that you're

50:37

going to you end up with that, but it's

50:39

not always the case. On the other

50:41

hand, do you ever feel a sweet happiness from

50:43

no longer having to worry about writing clean, readable

50:46

code for the prospective newcomer to just hack some

50:48

crap together and get it onto the page? Yeah,

50:51

I think yes. But also, like, one

50:53

thing I find is interesting is like, there

50:55

are some like hacky code, right? And you

50:57

will feel bad about it. But if you

50:59

extract it into a library, and you just

51:01

import it from a library, you don't you

51:03

don't mind it anymore. Because the complexity is

51:05

hidden in the library. So the hack is

51:08

not here, it's there. I

51:10

don't care. Yeah, that's beautiful.

51:12

But I think hack is also like a relative

51:15

turn to me. It's like, at

51:17

this moment, when you think about an idea

51:19

is hack, but it's like, when you will

51:21

maintain or well test by some library to

51:23

say it can be a reliable thing. If

51:26

you deal with that, and someone's maintaining that

51:28

and probably it can be a valid solution

51:30

to something. The industry is constantly

51:32

learning how to do stuff better. The most beautifully

51:34

written code today in the latest and greatest meta

51:36

frameworks, we would probably consider that to be a

51:39

hack and looking back at it 20 years from

51:41

now. Yeah, exactly. Yeah. Well,

51:43

that's a lovely note to end on. Last question

51:45

for you. Where would people be able to

51:47

find you online? So

51:49

I have my website, ntfu.me,

51:52

ntfu is my handle. So

51:54

on GitHub, I'm also ntfu. And

51:57

Twitter is with the sevens or ntm. I've

51:59

used And I think basically you

52:01

can find all the links on my website. And

52:04

it's very pressure to be here. Oh,

52:07

it's a pleasure to have you. Thank you so much. And

52:09

to any users of any of your software

52:11

who are listening, I'd highly encourage them to go sponsor you on

52:13

a lot of sponsorship platforms. Actually

52:15

are you currently on GitHub sponsors? Yeah, GitHub

52:17

sponsors, yeah. Well, that's great. Thank you again

52:20

so much, Anthony, for hopping on the podcast.

52:22

This has been a pleasure. Cheers. Yeah,

52:24

thank you. Thank you.