0:01

If you work in quality control

0:03

at a candy factory, you know

0:05

strict safety regulations come with the

0:07

job. It's why you partner with

0:10

Granger. Granger helps you find the

0:12

high quality and compliant products your

0:14

business needs to inspect, detect, and

0:16

help correct issues. And the sweetest

0:18

part is, everyone gets a product

0:21

that's as safe to eat as

0:23

it is delicious. Call 1-800 Granger,

0:25

click ranger.com or just stop by.

0:27

Granger, for the ones who get

0:29

it done. Hey,

0:35

welcome back to another

0:37

episode of JavaScript chamber

0:39

this week on our panel We

0:42

have Dan Shapiro from Tel

0:44

Aviv. I'm Charles Max Wood

0:46

from Top End Devs. Hello

0:48

from Lehigh Utah We also have

0:50

a special guest and that is

0:52

Jov Abrahami. I hope I got

0:54

I hope I got close. You

0:57

got it right Yeah I got

0:59

on when you guys were chatting

1:01

when I hopped on and I

1:03

was like, yeah, my Hebrew's atrocious

1:05

because I don't speak it. Yeah,

1:08

anyway. So your VP, did I

1:10

get that right? No, CTO of

1:12

Enterprise at Wix, right? I'm CTO

1:14

of Wix Enterprise, which is like

1:16

a, it's funny to say

1:19

it's like a small startup

1:21

of trying to take Wix,

1:23

which is mostly a consumer

1:26

product and designer product. and

1:28

adapt it to enterprise sales.

1:31

And it's exciting. Very cool.

1:33

So, uh... We actually had

1:36

you on before, just so

1:38

you know. Yeah. I was

1:40

going to say it. We

1:42

had you before. Yeah. We

1:44

had you on before about

1:47

two years ago, I think.

1:49

Yeah. That was exciting.

1:51

Was a very different

1:53

topic, I think. And

1:56

we had a very heated

1:58

debate there about... Yeah, clouds

2:00

and code ownership. Yeah, with

2:02

AJ, unfortunately, cannot join today.

2:04

Yeah, I'll put a link

2:06

into the, into the chats.

2:09

So if you're watching on

2:11

YouTube, you can pick it

2:13

up there and go listen

2:15

to that one too. So,

2:17

so besides your, I guess,

2:19

your title at Wix, what

2:21

else has changed last few

2:23

years? So, you know, the

2:25

first thing that the change

2:27

was that I used to

2:29

be. the end of a

2:32

weeks developer platform, a co-ed

2:34

of that and moved to

2:36

another position. I'm also working

2:38

on another initiative which part

2:40

of it is creating a

2:42

new web framework, which is

2:44

kind of why I'm very

2:46

interested in that topic of

2:48

web frameworks. And I think

2:50

those are two major things.

2:53

So when you talk about

2:55

Israel, there is another. big

2:57

thing that happened in the

2:59

last year and a half.

3:01

I think they will probably

3:03

leave that out of the

3:05

podcast. Yeah, the political situation

3:07

there is a little bit

3:09

brought in everything, but yeah,

3:11

the war. I keep hearing

3:14

about hostage just coming home,

3:16

which is a good thing.

3:18

So yeah, the last, the

3:20

last few weeks have been,

3:22

you know, kind of a

3:24

bright spot in this pretty,

3:26

dark tunnel that hostages that

3:28

have been held for coming

3:30

on 500 days are finally

3:32

being released basically year and

3:35

a half yeah yeah yeah

3:37

hopefully it will continue they

3:39

are being released you know

3:41

in small batches every few

3:43

every week and hopefully this

3:45

will continue anyway yeah let's

3:47

talk tech though yeah let's

3:49

talk tech though yeah let's

3:51

talk tech though yeah let's

3:53

talk tech though yeah let's

3:56

talk tech though yeah let's

3:58

talk tech So so framework

4:00

so you said you're building

4:02

your own framework which you

4:04

know I guess it's been

4:06

a week so we can.

4:08

use another one. Do you

4:10

want to just talk briefly

4:12

about that and what you're

4:14

pulling together? I don't know,

4:17

maybe Dan had a different

4:19

direction he wanted to take

4:21

this. No, it's fine. I

4:23

think, you know, what I'm

4:25

trying to solve is the

4:27

problem of designer and developer

4:29

collaboration. Oh, okay. So it's

4:31

trying to do a framework

4:33

that allows a designer. to

4:35

basically publish or deploy the

4:38

application. Okay. You know, think

4:40

about the designer changing the

4:42

application and deploying the application.

4:44

That's kind of what I'm

4:46

trying to solve. It's a

4:48

very, very big requirement. And

4:50

the funny thing is that

4:52

it actually turns. It

4:55

actually becomes evident in some

4:57

point that it is actually

4:59

the same requirement as allowing

5:01

you to consume third party

5:03

components in a safe way.

5:06

So think about using some

5:08

component of another company and

5:10

not being exposed to their

5:12

code in a way that

5:14

can create a risk to

5:17

your application. And in some,

5:19

in order to support designer

5:21

developer. collaboration, when you break

5:23

that requirement down into what

5:25

it means, you get that

5:28

other possibility as well. Again,

5:30

it's still work in progress,

5:32

it's very, very experimental, and

5:34

so I'm not going to

5:36

go and still the podcast

5:39

making announcements, go and look

5:41

and use my framework, that's

5:43

not the point. But this

5:45

is something of why I'm

5:47

very opinionated and why I'm

5:50

looked very deeply into different

5:52

frameworks. It's an interesting

5:54

thing that when JavaScript and

5:56

the dorm along with it

5:58

were created. They were created

6:00

specifically for designers or thinkers

6:03

The actual developers were supposed

6:05

to be using Java or

6:07

something like that And it's

6:09

interesting to see how the

6:11

developers have kind of co-opted

6:13

JavaScript, typescript, and with the

6:15

frameworks, the heavy duty frameworks

6:17

that we have today, they're

6:19

definitely here towards developers and

6:22

much less towards designers or

6:24

people like that. You know,

6:26

I'm thinking like, if I'm,

6:28

you know, somebody learning to

6:30

code and being thrown into

6:32

react, that's, it's easy to

6:34

drown, I think. I think,

6:36

it's even more than that.

6:38

Think. I'll take you in

6:41

two different directions. One, think

6:43

about the first and the

6:45

system 15 years ago. 15

6:47

years ago, a developer would

6:49

never deploy an application. That

6:51

would never happen. They would

6:53

build something up, then give

6:55

it over to the system,

6:57

they would do acceptance tests,

7:00

and then after testing, checking,

7:02

they would deploy the application

7:04

at some point. And then

7:06

with Devops, which changed the

7:08

way we worked, it moved

7:10

the way we worked. the

7:12

responsibility to deploy an application

7:14

from system to the developer

7:16

and it gave developers the

7:19

tools to make the application

7:21

work. And different tools than

7:23

the ones that System is.

7:25

And what I'm looking to

7:27

do now is to shift

7:29

it again from the developer

7:31

to the designer. Now just

7:33

think about it. A designer

7:35

that has no idea how

7:38

to code has no understanding

7:40

of creating and running an

7:42

application or stable application would

7:44

deploy your application. Would deploy

7:46

your application. That sounds scary.

7:48

But that's actually what happened

7:50

with system and developers 15

7:52

years ago. Now, it also

7:54

means that the tools that

7:57

the designers are using are

7:59

very different. They're not going

8:01

to write the HDML or

8:03

CSS. That's not how I

8:05

do all the work. If

8:07

you go and look at

8:09

what you're using, you know,

8:11

Photoshop, Figma, you know, there's

8:13

constable tools, it's not HTML

8:16

and CSS. So you need

8:18

to bridge a much larger

8:20

gap and then end over

8:22

the responsibility to them and

8:24

then offer the tools to

8:26

them so that they can

8:28

be effective and own the

8:30

application. That's what we have

8:32

AI for, no. Well, you

8:35

know, AI can do a

8:37

lot, but unfortunately up until

8:39

today, it didn't replace the

8:41

developer or the designer. We

8:43

still have a few years

8:45

for us, at least. You

8:47

know, when people ask me

8:49

if I'm worried about... AI

8:51

replacing development developers. I say,

8:54

well, you know, eventually AI

8:56

will replace everybody. So it's

8:58

just a question of time

9:00

when they'll get to you.

9:02

Nobody's safe. Anyway. Yeah. Yeah.

9:04

When people ask me the

9:06

question as, well, not yet.

9:08

I mean, some of the

9:10

tools are really nice, but

9:12

at the end of the

9:15

day, making the decisions that

9:17

I make, they just are

9:19

not there at all. I

9:22

think the easiest way to

9:24

understand that is if we'll

9:26

give an AI to fly

9:28

a jetliner, it would do

9:30

that very well, probably better

9:33

than any human pilot. It

9:35

would fly a plane in

9:37

a very correct way of

9:39

mountain. It would be very

9:41

correct and a very smooth

9:43

flight. But it's okay for

9:46

it to fly it into

9:48

a mountain. So

9:50

I think this kind of the

9:52

gap that we have with the

9:55

eye. You remind me I had

9:57

a friend who was an airline

9:59

pilot and he basically his job

10:02

to me once there's like 100

10:04

hours of boredom and five minutes

10:06

of pure terror. Yeah, we've had

10:09

autopilot for years and

10:11

it's been a tool that the

10:14

pilots have used for years

10:16

and it's worked great, you

10:18

know, we typically don't

10:20

see too many airline

10:23

catastrophes the last

10:26

week notwithstanding notwithstanding.

10:28

You know, but it's a different problem.

10:31

It's a different set of problems

10:33

than what we're talking about with

10:35

programming. Well, it's actually easier for

10:37

an AI to fly a plane

10:39

than to drive a car. But

10:41

you know, I would like to

10:43

pull us back to talk about

10:45

frameworks. And I would actually like

10:48

to start with something that I've

10:50

been thinking about a lot that

10:52

in fact, even had a kind

10:54

of a change of perspective about.

10:56

and I can talk about that

10:58

but I first would like to

11:00

hear you you of and that's

11:02

talking about what are in fact

11:04

framework what constitutes

11:06

a framework versus say you know

11:08

a library or a set of

11:11

tools or an application

11:13

or whatever. So you know

11:15

for me the definition is

11:18

actually pretty simple. Every

11:20

software Everything, any

11:22

kind of software in the

11:25

world can be split into

11:27

two kinds of interactions. There

11:29

is an interaction that is

11:31

going into your code, something

11:33

calling your code, and there

11:35

is an interaction where your code

11:38

is calling something else. You

11:40

have a choice. You can choose which

11:42

tool you are going to use to

11:44

call something else. You have a

11:46

choice. You can choose which tool you

11:48

are going to use to call something

11:50

else. to use a tool. There is

11:52

no way to call something else without

11:55

using a tool. Might be a system

11:57

library, might be a built-in library,

11:59

might... be some higher level

12:01

library like NPM or some

12:03

other package. But there is

12:06

always, you have the choice

12:08

almost everywhere of what you

12:10

use. That is where it

12:12

is a set of tools

12:14

that you can just choose

12:17

from. But when you are

12:19

being called, you don't have

12:21

the choice of who is

12:23

calling you. You are building

12:25

an application within some kind

12:28

of a container that runs

12:30

your code or some kind

12:32

of box. that calls your

12:34

code. This is what is

12:37

a framework. It is a

12:39

frame that is activating your

12:41

code on different entry points.

12:43

And then your code can

12:45

choose different things and give

12:48

and call some exit points,

12:50

some using some utilities and

12:52

some tools. So I had

12:54

the exact same outlook on

12:57

frameworks versus libraries, but then

12:59

my point of view shifted.

13:01

a little bit. And now

13:03

I think about it more

13:05

in the context of architecture.

13:08

When I think about when

13:10

you're dictating the architecture, it's

13:12

libraries. When the architecture is

13:14

kind of dictated to you,

13:17

that's a framework. But it's

13:19

kind of same same. Yeah,

13:23

there's a big overlap, but

13:25

it does shift the perspective

13:27

a bit. I think that

13:30

the best frameworks are the

13:32

frameworks that the architect that

13:34

they make the architecture of

13:37

the solution that you're going

13:39

to build more clearer. Let's

13:41

let's put it this way.

13:44

You know where the pieces

13:46

are supposed to slide in.

13:49

I think what you're talking here

13:51

is about something a little bit

13:54

different. When you talk about new

13:56

frameworks, there's a few. concepts that

13:58

have emerged over time to make

14:00

software to be easier to code

14:02

against. One is the ability to

14:04

make it easy to be tested

14:06

in a simple environment. Another one

14:09

is the concept of locality of

14:11

definition so that all of the

14:13

concerns are in one file and

14:15

not spread across multiple files. And

14:17

another thing that is a little

14:19

bit subtle is that the syntax.

14:22

is such that when you read

14:24

it, you can understand what it

14:26

does. People tend to call it

14:28

no magic, but I don't like

14:30

that definition because we as developers

14:32

consider everything smart that someone has

14:34

written as magic. So it's not,

14:37

I won't say that, I would

14:39

say that if it makes you

14:41

write in a syntax. that is

14:43

easy for the average developer that

14:45

is working with you to understand

14:47

what's going on, then it is

14:49

probably doing something good. The principle

14:52

of least surprise, basically. Yeah. So

14:54

it's no look. Yeah. So my

14:56

question with that is, so I

14:58

mean, folks that listen to the

15:00

show know that I do most

15:02

of my work in Ruby on

15:04

rails. And some of that. is

15:07

true, right? Some of it, you

15:09

read stuff, or you read the

15:11

code and is, you know, you

15:13

pretty intuitively know what it does.

15:15

But some of the stuff, you

15:17

pretty intuitively know what it does

15:19

because you've been doing rails for

15:22

20 years, right? And so you

15:24

look at it and you know

15:26

what the conventions are and you

15:28

follow it. So how much of

15:30

it's the other, right, with react

15:32

or view or any of these

15:34

other tools that might give you

15:37

that sense of, okay, I can

15:39

look at this code and know

15:41

what it, know what it, and

15:43

know what it is. Wow, it

15:45

clarifies that that's what's going on

15:47

here and how much of that

15:49

is I've been doing react for

15:52

long enough that I know what

15:54

that's what this code is. You

15:56

know the measure of o against

15:58

a very about that? When

16:00

you go into a new system and you're like, hey,

16:03

it's doing something really exciting. Then

16:06

you go into another and then you try to

16:08

make it do something and it doesn't work. Then

16:11

you figure, ah, it has to work

16:13

that way. That's not intuitive. That's

16:16

the measure. It's the measure of how much

16:18

times it's doing things in the way you expect

16:20

to be doing, versus how much

16:22

times it surprises you doing something

16:24

in a very unintuitive way. This

16:26

is kind of a measure for APIs

16:28

and developer tools to know

16:31

how good they are. Though

16:33

there are moments against the

16:35

U moments. Yeah, I would

16:37

like to add to that.

16:39

You know, at the end

16:41

of the day, I'm always

16:43

drawn back to the no

16:45

silver bullet article that talks

16:47

about essential versus what was

16:49

the other one, essential complexity

16:51

versus non -essential complexity. And,

16:55

you know, we are solving

16:57

complicated problems, at least

16:59

we strive to do. And

17:02

when you solve complicated problems,

17:04

even when there are

17:06

strong guidelines for what the

17:08

architecture should be like,

17:10

don't expect the solution to

17:13

be trivial. That's

17:15

point number one. And point number

17:17

two, you know, you try to

17:19

make a system idiot proof, but

17:21

then somebody goes along and invents

17:23

a better idiot. So people will

17:25

always find a way to surprise

17:28

you and work against the grain

17:30

of what the framework encourages. You

17:34

know, but I think, I

17:36

think Dan, sorry to cut

17:38

me over. No, go for

17:40

it. You need to look

17:42

at frameworks in three different aspects.

17:45

There is one which is the

17:47

functional aspect. Does

17:50

it do, is it doing what you

17:52

need it to be doing? And

17:55

are different frameworks

17:57

similar in terms of the

17:59

final... functional aspects of the framework, regardless

18:01

of the syntax. And then

18:04

there is a second question, which is

18:06

when you look at the

18:08

non -functionals, like performance, for

18:10

instance, are

18:12

they equal or do you

18:14

even care? Is the

18:16

difference significant? Now,

18:18

for example, is the fact

18:20

that Svelte is much more

18:22

efficient than React? Is

18:25

it something you really care about in your

18:27

specific case, your specific application? And

18:30

only after you're done with those two,

18:32

with the functional and non -functional, only

18:35

then you come to syntax. And

18:37

how now you are with the

18:39

developer? Yeah,

18:42

but look, when I think

18:44

about React, for example, for me,

18:46

the core of React are

18:48

few well -defined concepts. You know,

18:50

it's pretty unfortunate that a lot

18:52

of React developers may not

18:54

actually be familiar with these core

18:56

concepts. And the core concepts,

18:58

by the way, UI

19:03

as a function, regenerating

19:05

the entire UI from

19:07

the state whenever the

19:09

state changes and you

19:12

need directional data flow. Maybe I'm

19:14

missing one or another one, but

19:16

those are like the core concepts

19:18

for me when I'm thinking about

19:20

React. And then when I think

19:22

about, let's say, solid, it has

19:24

different core concepts, so if I'm

19:26

thinking about Svelte, it also has

19:28

different core concepts. So a big

19:30

part of ideally, of

19:32

choosing a framework, would

19:34

have been choosing the

19:36

framework whose architecture or

19:38

the architecture that it advocates

19:40

for building application best

19:42

suits your personal tastes. Now,

19:45

unfortunately, most of us

19:47

don't go through this process

19:49

because the framework choice is kind

19:51

of, Yeah, just to finish,

19:53

because in a lot of cases, the

19:55

framework choice is kind of dictated to us.

19:58

You're right. It's again,

20:01

it's assuming that the functional is

20:03

equal and assuming that the non

20:05

-functional is equal, then you come

20:07

to aesthetics. And what you're talking

20:09

about is still just aesthetics. And you

20:11

know, React, you brought the concept

20:13

of React. React is neither reactive, nor

20:16

functional, today. You

20:19

know, it

20:21

has done a lot. It

20:23

has done a huge

20:26

work moving us forward as

20:28

front -end developers. There is

20:30

a reason why it is the

20:32

number one firm of today in

20:34

the world. But it's

20:36

kind of not what it

20:38

aimed at doing. Context

20:41

is, you could

20:43

argue that props, context and

20:45

state are all different ways to

20:47

get data into the function and

20:50

two of them are not functional. Well,

20:55

you know, the DOM is

20:57

not functional, JavaScript is not

20:59

functional. And you're kind of

21:01

living within the framework itself

21:03

is living within the confines

21:05

of the environment that it's

21:08

built on. There, you

21:10

know, you could go with Elm, if

21:12

you know, if you really want to go

21:14

to the extreme, but that, you know,

21:16

there's a price to pay for that as

21:18

well, you know, let's say

21:20

ditching JavaScript in favor of

21:22

Elm or Reason or something

21:24

like that. No one

21:26

said that the aesthetics is simple.

21:28

Getting the aesthetics of a framework

21:31

in the right way is

21:33

super hard. And there

21:35

is reason why we have lots

21:37

of frameworks trying different directions and

21:39

different things. You know, there, you

21:41

look at what's happening today. There

21:44

is one major direction

21:46

going on today, which is

21:48

signals. Everyone except

21:50

React has signals today. There

21:53

might be some old frameworks that don't

21:55

have them, that they didn't adopt signals,

21:57

but almost everyone except React are using

21:59

signals. the main obstruction for state

22:02

management. And there is a

22:04

reason behind that. It's trying

22:06

signals on different places, different

22:09

frameworks, different syntaxes seems to

22:11

work. Trying signals in terms

22:13

of the non-functional performance, again,

22:16

seems to work. It seems

22:18

to be something that people

22:20

comprehend. By the way, signals

22:23

is not a trivial thing.

22:25

It takes time to understand

22:27

that once you do. it

22:30

becomes something that is very

22:32

robust to use. So again,

22:34

it's just aesthetics. Well, for

22:37

me it's more than a

22:39

static, actually, because it informs

22:41

the way that you deconstruct

22:44

or the problem and then

22:46

construct a solution. So, for

22:48

example, first of all, I'd

22:51

like to mention, by the

22:53

way, that when we had

22:55

the Joseavona and Satya from

22:58

Meta, to talk about the

23:00

react compiler, Joe said very

23:02

clearly that signals are not

23:05

in react's future. He basically

23:07

said, you know, if signals

23:09

become a part of the

23:12

JavaScript language, there's actually a

23:14

proposal for that, then we

23:16

will, and I'm speaking for

23:19

Joe, then we will support

23:21

it. But otherwise, no signals

23:23

for react, because that's not

23:26

their vision. for how front-end

23:28

applications should be built. Their

23:31

whole thing is about, you

23:33

know, reconciliation and stuff like

23:35

that. I talk with what

23:38

you're saying right now. You're

23:40

talking about opinions. Oh, of

23:42

course. Framework's our opinions. That's

23:45

kind of my point. Well,

23:47

I, to be honest, I

23:49

don't agree. I think that

23:52

this is kind of... This

23:54

is kind of a... This

23:56

is kind of a state

23:59

we arrived. by forgetting

24:01

the functional and unfunctional

24:04

requirements. And we're kind

24:07

of set at very basic

24:09

frameworks that are not really

24:11

that are just competing with

24:14

one another on aesthetics

24:16

and performance and that's

24:19

it. But there's a lot more

24:21

other stuff that you can

24:23

compete on. Such as? Let's talk

24:25

about web essentials. Web

24:28

essentials is a list of,

24:30

I think, probably 13, 14 items that

24:33

when you are doing, when you

24:35

are working as a web developer,

24:37

you need to take care of. And

24:39

there are things like creating

24:41

responsive design, being performance,

24:44

break points, multilingual,

24:46

AB testing. So AB testing

24:48

is actually not web

24:50

essential, but it's nice

24:53

to have. Accessibility regulation,

24:55

cookies regulation in the

24:58

EU. accessibility, the new

25:00

accessibility regulation in the EU

25:02

now, a GDPR, PIR, and there's more.

25:04

And all of those... Is there a list

25:06

somewhere that I could just publish? I

25:09

have it in my, I have it somewhere,

25:11

I can send it to you.

25:14

And basically all of that list

25:16

is anything you're doing, anything that

25:18

is customer facing on the internet,

25:21

you have to take care of all

25:23

of that list. If you're doing

25:25

an enterprise... behind the

25:27

login you need to take

25:29

care of most of it

25:32

and your SEO is

25:34

another one and all

25:36

of the cost a

25:38

lot of money why

25:40

aren't frameworks helping us with

25:43

all of that list of

25:45

stuff I think when

25:47

you start talking about

25:49

these things your Again,

25:51

and it's an interesting

25:53

distinction to make from

25:55

what I see. You're

25:57

starting to move from talking

25:59

about frameworks to talking about

26:01

meta frameworks from talking about react

26:03

to talking about the next js

26:06

we're talking about view to talking

26:08

about next and so on and

26:11

so forth at least that's been

26:13

my experience with these sort of

26:15

things most frameworks these days have

26:18

a much lower bar in the

26:20

in the functionality that they're trying

26:22

to provide they are more about

26:25

you know use us instead of

26:27

using just the dome But

26:30

keep in mind when you asked

26:32

about what is the definition of

26:35

a framework. The framework is not

26:37

defined as only something on the

26:39

client that interacts with the dome.

26:41

It is defined, as you said,

26:44

as something that imposes an architecture

26:46

on your application that guides you

26:48

into building better software. With that

26:50

definition, I would expect the framework.

26:53

to help me with all of

26:55

the web essentials as well, because

26:57

it's something I have to do.

26:59

It's something those are more constraints.

27:02

My application has to work with,

27:04

I would expect the architecture of

27:06

the framework to be such that

27:08

would take care of those concerns,

27:11

or at least help me to

27:13

take care of them. So I

27:15

have to ask then, because it

27:17

seems like, you know, if you

27:20

take this narrow definition of a

27:22

framework, you know, whether it's an

27:24

aesthetic way of putting together an

27:26

application or whether it gives you

27:29

the architecture, whether or not it

27:31

provides you with some of these

27:33

essentials, you know, that you would

27:35

expect it to, it seems like

27:38

that it, it seems like there

27:40

are various definitions and maybe various

27:42

expectations that people have of a

27:44

framework, right? Because I could expect

27:47

that, okay, for me, the framework

27:49

that I want, we'll do all

27:51

these things. For somebody else, it

27:53

may just say, hey. Here's how

27:56

you're going to structure your application.

27:58

Here's the understanding of here's where

28:00

the pieces go. Here are a

28:02

series of tools, libraries, toolkits, etc.

28:05

that make the API that I'm

28:07

building against that much more friendly.

28:09

Right? So there are all these

28:12

different pieces that people consider when

28:14

they have the framework. And it seems

28:16

like a lot of people are picking

28:18

it for different reasons, right? So some

28:20

people may be picking it because, hey,

28:22

I want a more aesthetically pleasing thing.

28:24

or I want to be more

28:27

efficient in my time use by

28:29

having the framework handle certain things

28:31

for me, or by fitting a

28:34

mental model that I can

28:36

sink my head into. And so,

28:38

you know, you're saying, well, it's

28:40

aesthetics, or, you know, it's aesthetics

28:42

and maybe some of these

28:44

other things, but how do you

28:47

really make that decision on

28:49

what people should consider a

28:51

framework? I think the role

28:53

of the framework is to help

28:55

us, to make us more efficient.

28:58

Right. And, because you know, I

29:00

could just use JQI and

29:02

that would work. I would encourage

29:04

applications. Yeah. And then

29:06

we decided to move to

29:08

react because it is more

29:11

efficient to write code in

29:13

react compared to JQI, both

29:15

in the first ramp up

29:17

and then in maintainability.

29:20

And then. When you're taking

29:22

just those two concerns, the

29:24

first ramp up and maintaining

29:26

ability, and you're also starting

29:29

to add things like

29:31

accessibility into the mix, and

29:33

you're asking, A, how much work do

29:35

I need to do in a react application

29:38

to make it accessible? Versus,

29:40

can I get a framework that

29:42

would help me to have lived

29:44

that burden and making me

29:46

more efficient there? And the same

29:49

can go for any of the other.

29:51

you know, with concerns.

29:53

My experience,

29:55

though, has been that

29:57

most people who use

29:59

use JavaScript frameworks for

30:02

the front end because

30:05

it pulls them kind

30:07

of away from the

30:10

actual semantic HDML and

30:13

up with mountains of

30:15

divs which is anything

30:18

but semantic and anything

30:21

but accessible and so

30:23

forth and that If

30:26

you want to get these

30:29

in the context of frameworks,

30:31

usually what you end up

30:33

is reaching for libraries that

30:35

are compatible with the framework

30:38

that you can use them

30:40

within the framework, or maybe

30:42

if the organization is large

30:44

enough, then it creates its

30:47

own design system or adopts

30:49

some external design system in

30:51

order to get everything you

30:53

described. Are these, should design

30:55

systems have been part of

30:58

the frameworks, the framework itself,

31:00

shouldn't they be blockable to

31:02

the framework? You know, I

31:04

think saying that the framework

31:07

allows the design system that

31:09

solves some of the concerns

31:11

is a way to support

31:13

concerns. Now, with accessibility, that

31:16

might work with multilingual or

31:18

with GDPR or cookies. you

31:20

might need something else. Design

31:22

system will not solve cookies

31:25

regulation for you. So I

31:27

think even though, you know,

31:29

react and all of the

31:31

frameworks allow design systems because,

31:34

hey, it just makes us

31:36

much more efficient to use

31:38

the design system components, it's

31:40

still not enough. So I

31:43

really think that frameworks will

31:45

need to take that into

31:47

account. We are in a

31:49

market that We're shifting in

31:51

light speed from an unregulated

31:54

market to a very very

31:56

regulated market and that means

31:58

that the price of creating

32:00

an application and

32:02

a website goes up very

32:05

fast because of those

32:07

regulations. And we don't know where

32:09

we're going to end up with.

32:11

And we didn't even start

32:14

talking about AI. What does

32:16

it mean for your framework

32:18

to make your application

32:20

AI ready by whatever going

32:22

to be the nominate AI

32:25

client application that could

32:27

going to be the next. you

32:29

know, big deal in the

32:31

internet beside Google and Facebook

32:34

and TikTok. By the

32:36

way, when you're saying AI

32:38

ready, are you talking about

32:41

using AI to generate your

32:43

code or about integrating AI

32:45

functionality into the actual end

32:48

product or both or something

32:50

else? I'm talking about something

32:52

else. It's clear to for

32:55

everyone that there is going to

32:57

be a... dominant AI

32:59

application over the internet.

33:01

Right now the internet is

33:04

about 100 billion dollars

33:06

market around search and about

33:08

another 100 billion dollars

33:11

market around social. You

33:13

can assume that it's going

33:15

to be another 100

33:17

billion dollars market around

33:19

advertising or discovery

33:21

or something like that

33:24

with AI. We don't know the application, we

33:26

don't know the provider, we don't know

33:28

when it's going to happen, but

33:30

it's probably going to happen something like

33:32

that. And then you want your business

33:35

to be listed there as well. You know, today

33:37

when you build a business or any

33:39

website, you have to be listed in

33:41

Google and in Social, you probably

33:44

want a mobile application as well,

33:46

because you want to cover all the

33:48

different fronts that you might get users

33:50

from. So what would be that next

33:52

front with the I? How will your

33:55

framework help you to

33:57

be there in the right way?

34:00

talking about having some

34:02

sort of presence within

34:04

an AI-driven interface, whatever

34:06

that might be, and

34:09

that's kind of similar

34:11

to how we currently

34:13

have, like you said,

34:15

let's say a page

34:18

on Facebook or something

34:20

or on Instagram or

34:22

something like that. Is

34:24

that what you're talking

34:27

about? Think about 2011.

34:29

Think about 2011. A

34:31

year before Facebook really

34:34

become dominant. If at

34:36

2011 I would say,

34:38

hey, websites, you need

34:40

to prepare yourself to

34:43

social. We don't know

34:45

what's going to be

34:47

the dominant social application,

34:49

but something is coming.

34:52

This is kind of

34:54

what I would sound

34:56

like. So we

34:59

know there's something coming.

35:01

We just don't know

35:03

what and who. And

35:05

again, maybe it's just

35:07

me or the terminology

35:09

that I'm familiar with

35:12

because of react and

35:14

things similar to it.

35:16

But react or view

35:18

or sveld or solid

35:20

have set their sights

35:22

much much lower than

35:25

that. As I said,

35:27

the things that you're

35:29

talking about are more

35:31

in the realm of

35:33

meta frameworks or even,

35:35

you know, meta meta

35:38

frameworks. I've heard the

35:40

term stacks sometimes used.

35:42

So for example, Ken

35:44

C. Dodds has his

35:46

epic stack, which involves

35:48

a certain, you know,

35:50

obviously... remix but also

35:53

and react but also

35:55

a particular authentication provider.

35:57

and a payment provider

35:59

and a database provider

36:01

and so on and

36:03

so forth and you

36:06

integrate all of these

36:08

things together hopefully more or

36:10

less seamlessly in order to

36:12

get a more holistic type

36:14

solution that might address the

36:16

requirements that you seem to

36:18

be talking about or at least

36:20

that's how it seems to me. But

36:22

I have to ask you a question.

36:24

When you look from JQI, up to

36:27

react. and up to angular.

36:29

Doesn't it seem the same? Now,

36:31

J-quarie is actually much

36:33

linear. It tries to do

36:36

much new, compared to react,

36:38

react is trying to so

36:40

much more compared to J-quarie.

36:42

J-quarie is just trying to

36:44

obstruct a little bit the

36:47

dumb APIs, that's all, and

36:49

it is a framework. And it is

36:51

another obstruction layer on top,

36:53

and angular is the same.

36:56

And then we're going to be

36:58

where we might add another obstruction

37:00

layer on top. You know, we're trying

37:02

to put labels on it, but

37:04

why are those labels important?

37:07

Well, I actually think that

37:09

labels are important. You know,

37:11

there's that statement that there

37:14

are two hard things in

37:16

computer science, cash invalidation, naming

37:19

things and off by one

37:21

errors. And so naming things

37:23

is actually pretty important. You

37:26

know, design patterns exist, are

37:28

basically ways of naming things

37:31

so that we have a

37:33

common vocabulary. So I do

37:35

think that having common

37:38

terminology is actually

37:40

important for us to

37:43

be able to converse

37:45

and exchange ideas and

37:47

concepts. I

37:50

can accept that. But I just,

37:52

but I think that even having

37:54

said that, a meta framework

37:56

is just another framework

37:58

that does more. Yeah. Again,

38:01

for me right now, again,

38:03

my opinion may certainly change,

38:05

but right, you know, you

38:07

seem to have a very

38:10

different definition. The definition that

38:12

I used to have for

38:14

framework versus meta framework was

38:17

basically that it straddles both

38:19

sides of the network divide.

38:22

That meta framework has a

38:24

service side aspect to it,

38:26

whereas a framework doesn't.

38:28

But your definition seems

38:31

again to be much

38:33

more holistic than mine.

38:36

But you know, but let's

38:38

work with your definition.

38:40

You know, I'm fine with that.

38:43

So when I'm saying that

38:45

frameworks may need to cope

38:47

with all of the web

38:49

essentials, it's a little

38:52

bit limiting, but you

38:54

know, I don't care. That's

38:56

fine. Now,

38:59

we can go to

39:01

more extreme things that

39:04

are happening with

39:06

frameworks. Again, metaphragmocks

39:10

might be. And I'm saying

39:13

two trends or two

39:15

lines that are kind

39:17

of intertwined together.

39:20

One is the

39:22

idea of gradual

39:24

rendering. When we

39:26

start seeing that a little

39:29

bit in frameworks, the

39:31

idea of gradual rendering

39:33

is that let's start shifting

39:36

rendering back as much as

39:38

we can. To the service, what

39:40

do you mean? To the server

39:42

side and to earlier timeline. Now

39:45

you already have frameworks

39:47

that are doing the normally

39:50

we would call that build

39:52

time rendering. or static

39:54

side generation, but actually

39:57

don't like this definition.

40:00

When you look at data,

40:02

you have data that changes

40:04

slowly, like blog posts and

40:06

products and I don't know,

40:08

there's many things that change

40:10

slowly. And then there are

40:12

things that change fast. And

40:14

then there are things that

40:16

change interactively when users clicks

40:18

on something and something changes

40:20

on the client. So interactive

40:22

things have state management and

40:25

run on the client. Fast

40:27

changing, you need to do

40:29

an SSO. Slowly changing you

40:31

can do an event of

40:33

something changed. Why can't I

40:35

combine all three of them

40:37

in one page in one

40:39

component? Now, you're starting to

40:41

see things like that happening.

40:43

The act several components lets

40:45

a developer to choose to

40:47

have one layer server rendered,

40:50

which is only server ended,

40:52

and then have another layer.

40:54

or another subcomponent that is

40:56

rendered on the server but

40:58

is also interactive on the

41:00

client. Quickly starting to do

41:02

stuff like that. Other firms

41:04

are starting to do stuff

41:06

like that. But I haven't

41:08

really seen that as being

41:10

a first class pattern in

41:12

any of the frameworks. I

41:14

would take it a step

41:17

further. It seems to me

41:19

that... and I'll be blunt.

41:21

It seems that framework makers

41:23

are solving a problem that

41:25

the market is not looking

41:27

for them to solve. I'm,

41:29

you know, I've spoken to

41:31

a lot of organizations in

41:33

this context who basically say,

41:35

you know, we want to

41:37

react on the front end

41:39

and something else doing restful

41:42

APIs on the back end.

41:44

and I don't and I

41:46

don't want to react on

41:48

my back end. And, and

41:50

next. and Vercel's

41:52

success notwithstanding,

41:54

the majority of

41:56

enterprise React

41:58

applications that I'm

42:00

seeing are

42:02

very much keeping

42:04

the framework

42:07

on the client

42:09

side only. You're

42:13

right. And yet, when

42:16

you go and keep in mind that

42:18

Vercel is building websites, in

42:20

a website you must have service at

42:22

rendering because of SEO, again, because

42:24

of web essentials. But

42:26

then even for the enterprises, they get

42:28

to a point where they say, hey,

42:31

but we have a performance problem or

42:33

we have a flickering or a text log

42:35

to load the page and

42:37

we need to do something

42:39

about that. Now, when

42:41

you run React on the server,

42:43

when React was not designed to

42:45

work on a server environment, what

42:48

Vercel were doing is actually very

42:50

smart, but they're trying to

42:52

take something that doesn't really fit in

42:54

that environment and make it work in that

42:56

environment. It wasn't designed for it. It

42:59

didn't quite happen if you actually

43:01

go and design a framework that would

43:03

work in such a way

43:05

and would support both the website

43:07

and enterprise use cases. Well,

43:11

I guess, Chuck, you're supposed

43:14

to say at this point that's

43:16

why we have Rails and

43:18

what's the name I've been refraining

43:20

from saying that this whole

43:22

time. Rails and what's the name

43:24

of the thing that you

43:26

use in Rails? Stimulus or the

43:28

other one. Turbo?

43:32

Turbo, stimulus, whatever. You've got a

43:34

whole bunch of terms. All wire? Wire,

43:37

I think that was the one. Rails

43:43

did a lot of really good

43:45

stuff and

43:48

it takes its kind of, when

43:50

you look at the, what I

43:52

would call the 1 .5 age

43:55

of the internet, which is basically

43:57

static, basically server -side rendering

43:59

everything. and a little bit of

44:01

JavaScript, a little bit of jQuery

44:03

on the client, your WordPress is

44:05

there, Shopify is there, Rails is

44:08

there, Rails is kind of the

44:10

best of the breed. But

44:13

it does suffer, and there

44:15

is a reason why we moved

44:17

to web 2 .0, which starts

44:19

with React and Angular, which

44:21

are client -first libraries, simply

44:24

because you want to be very

44:26

productive on the client and very interactive

44:28

on the client, and very fast

44:30

on the client. And then, you know,

44:32

when you start moving from front -end

44:34

libraries back to the back -end, why

44:37

would they use a different language

44:39

for the back -end and the

44:41

front -end? Why would they use React

44:43

on the front -end and Rails

44:45

on the back -end? It makes my

44:47

life much harder, and normally that

44:49

would be two different people. You

44:51

know Rails in a very good

44:54

way. For someone else that needs

44:56

to learn both React and Rails,

44:58

and how to connect them together,

45:00

that's harder than using Next .js.

45:02

And again, it's the principle the

45:04

quality. So...

45:06

Yeah, I thought you

45:08

were gonna go to

45:10

Express or something, and

45:12

I'm like... No, Express

45:15

it. If you're going

45:17

to React to Next,

45:19

I can see that.

45:21

Yeah, and I think

45:23

we're kind of converging

45:25

on is...

45:30

There's a term that I just

45:32

don't want to use, so instead

45:34

I'm going to say frameworks that

45:36

are designed both for the back -end

45:39

and the front -end as first -class

45:41

citizens, and when you... Okay. I'm

45:45

going to make a

45:47

conjecture. One

45:50

minute, I think

45:52

that what, or

45:54

at least what

45:57

I'll restate what

45:59

I seem to

46:01

be hearing you

46:04

say. You're... basically saying most

46:06

modern frameworks that we've seen started

46:08

there started out client side and

46:11

then evolved to work on on

46:13

the back end as well. So

46:15

next GS grew out of react

46:18

and it's effectively implementing a react

46:20

specification. Knox grew out of view

46:22

so on and so forth. What

46:25

you're saying is You know, we've

46:27

had no GS and whatnot on

46:29

the back end long enough so

46:32

that we can think about frameworks

46:34

evolving the other way around, starting

46:36

their life on the back end

46:39

and then evolving to support the

46:41

front end. Am I am I

46:43

getting the gist of what

46:45

you're saying? Almost. What I'm

46:48

saying is think about a

46:50

framework that is designed to work

46:52

on all three life cycles

46:54

of the web. and you have three

46:56

life cycles not two of them

46:58

you have one for slowly changing

47:00

data like product was updated

47:03

maybe once a day or once a

47:05

week you have a fast changing data

47:07

that you have to render for

47:09

a user directly on the server

47:11

like username or cookies and

47:14

then you have interactive data

47:16

or interactive interactions on

47:18

the client and state

47:20

management and state management

47:23

and It doesn't make any sense

47:25

that those are three different obstructions

47:27

that are done in three

47:29

different ways. Why can they do them

47:31

in one, why can they get a framework

47:34

that speaks in that language and

47:36

just does it all and not

47:38

force me to start messing up

47:40

different things and different concepts

47:42

to try and understand what goes

47:45

where. I

47:50

mean a lot of the things that

47:52

you're talking about are things that I

47:54

mean I kind of manage this stuff

47:56

so that it changes when it needs

47:58

to or gets you know You know, interaction

48:01

happens when it needs to.

48:03

I don't know that I

48:05

think of them as all

48:08

that different, right? They all

48:10

more or less use the

48:12

same mechanisms or am I

48:15

missing something? Well, let me

48:17

put it this way. What

48:20

I'm seeing a lot are

48:22

basically people dealing with this

48:24

problem by effectively ignoring it.

48:27

So for example, if they

48:29

build a wholly client side

48:31

render application and just make

48:34

calls... back to the to

48:36

end point to restful endpoints

48:38

whenever they need to get

48:41

more data so they don't

48:43

need to think about how

48:45

often the data changes so

48:48

they respond quickly to client

48:50

side interactions and then whenever

48:53

they need to get you

48:55

know data from the back

48:57

end they just call a

49:00

restful API and it comes

49:02

whichever way it comes. So

49:04

effectively they respond to both

49:07

types of interactions or all

49:09

three types of interaction in

49:11

essentially the same, the exact

49:14

same way by writing event

49:16

handlers in JavaScript that handle

49:18

events. These events might be

49:21

a mouse click or these

49:23

events might be some data

49:26

arriving over the network. It's

49:28

all the same. And I

49:30

agree with you of that.

49:33

I totally don't know how

49:35

many organizations are actually dealing

49:37

with it, basically saying, you

49:40

know, I'm rendering some stuff

49:42

on the server, I'm rendering

49:44

some stuff on both sides.

49:47

By the way, I totally

49:49

don't know how many organizations

49:51

are actually using... react server

49:54

components in production, certainly in

49:56

anger, let's say. It's an

49:59

interesting question. You know, as I said,

50:01

there's a growing, you know,

50:03

it seems that NextGS is

50:06

eating the React website market,

50:08

that the majority of new

50:10

React websites are being built

50:13

using NextGS, but I have

50:15

no idea how many of

50:18

them are actually using React

50:20

Server components, certainly how many

50:22

of them are actually using

50:25

React Server components correctly. That's

50:28

a totally different question.

50:30

It's an interesting one

50:32

and I don't know

50:34

how to get this

50:36

data. How do you

50:38

think a solution to

50:40

that might come along or

50:43

might look like that

50:45

actually solves that problem

50:47

with lower friction

50:50

and greater acceptance? You

50:52

can see what both

50:55

next and a... Well, forgot

50:57

the name. There's another framework. And

50:59

they're doing data loaders that, by

51:01

the name of the data loader

51:03

function, you know on which

51:05

environment to run it. You can look

51:07

at what Quicks is doing, where you

51:09

can, there is a different, a specific

51:12

API, which is very similar, but

51:14

specific API that says, hey, this

51:16

is something that runs on the server.

51:18

Or I think it indicates of Quick,

51:21

everything is by default running on

51:23

the server. and only being loaded

51:25

to the client if needed.

51:28

And the compiler is kind

51:30

of understanding what needs

51:32

to be downloaded to the client.

51:34

I think we need to figure

51:36

out the syntax. We don't have

51:39

it today. By the way, a

51:41

syntax, as far as I can

51:43

tell, seems to me the solution that

51:45

these meta frameworks, I'll use

51:48

that term, are adopting,

51:50

seems to be RPC-based. so

51:52

that when it's it's

51:55

it's called it's

51:57

functions that when

51:59

when they are executed

52:01

on the server, it's just

52:04

a function call. But

52:06

when they're executed on

52:08

the client, it becomes

52:11

serialized automatically over the

52:13

wire. So that's the

52:16

obstruction that I'm

52:18

seeing kind of being

52:20

adopted for addressing that

52:22

issue. Now even that has

52:25

different approaches associated with it.

52:27

So both, let's say we

52:30

had General Inslee talking about

52:32

what he's doing with the

52:35

10 stack start, and he's

52:37

also using RPC, but he's

52:39

doing it in a very

52:42

different way than the way

52:44

that NextGS is using. Even

52:47

though you might say that

52:49

in both cases, it is

52:51

kind of RPC. Anyway, I want

52:53

to take you even one

52:55

step more. You know, we

52:58

talked about design systems.

53:00

You're using components

53:02

from design systems.

53:05

Sometimes those components

53:07

have a large number of

53:09

configuration options. You know,

53:12

for instance, you might have

53:14

a gallery that might have

53:16

multiple layouts. And you

53:18

might be choosing one layout or

53:20

another. And if that choice is

53:23

static, it's basically a

53:25

constant. Or even if it is

53:27

a... a choice made by slowly

53:29

changing data. Why would you

53:32

download to the browser the

53:34

full component with all

53:36

of the different options?

53:38

Why not start looking

53:40

at the values of slowly

53:43

changing data, which

53:45

after defining what is

53:47

that the depth value,

53:49

it basically become constant

53:52

data after that first

53:54

phase of rendering? And then

53:56

let's start deleting all the

53:58

unnecessary code. So

54:01

all of the other layouts of

54:03

the gallery, they don't need to

54:05

be there. All of the other

54:08

style options, they don't need to

54:10

be there. It might have, you

54:12

might have, you know, different tabs

54:15

or different, you know, screens or

54:17

different options that you can just

54:19

delete and just remove. And it

54:22

might go all the way down

54:24

to your design system that they

54:26

might have lots of very complicated

54:29

components because they need to cope

54:31

with lots and complicated situations. a

54:33

drop-down with 50 different options of

54:36

how to open a drop-down, but

54:38

they only need one. So why

54:40

would you download the browser all

54:43

of the different options? So there

54:45

is also another potential here for

54:47

lots of very aggressive optimizations that,

54:50

to be honest, no one is

54:52

doing today. Well, I think Wikimedia,

54:54

as that you mentioned, is kind

54:57

of trying to do at least

54:59

some of the stuff. Basically, it's

55:01

using a compiler. to or bundle

55:04

or smart bundler or transpiler, call

55:06

it what you will, to decide

55:08

for you which codes needs to

55:11

exist where, effectively. And then, you

55:13

know, again, if we're talking about

55:15

stuff like, like, uh... the

55:19

hotwire that Chuck mentioned before,

55:21

you know, when we spoke

55:24

about, what's it called, HDMX,

55:26

it's basically saying, why do,

55:28

why send Jason over the

55:30

wire that I need to

55:32

have smart on the client's

55:34

side to be able to

55:37

process it according to, you

55:39

know, sophisticated logic and transform

55:41

it into HDML, when I

55:43

can just send the HDML.

55:45

And to an extent, again,

55:47

React Server components are kind

55:50

of going in that direction.

55:52

They're not actually sending HDML.

55:54

They're sending virtual DOM as

55:56

it is. were

55:58

over the wire,

56:02

but it's basically

56:04

the idea of

56:06

having a generic mechanism that

56:08

transforms it into UI rather

56:10

than having to download all the

56:12

custom logic. But

56:15

think about what's happening here.

56:17

You have lots of innovation

56:19

going on around, all around,

56:21

from meta frameworks around performance

56:24

and around making your application more

56:26

efficient. Quick is doing that,

56:28

Server Components is doing that, HTMX

56:31

is doing that, and kind

56:33

of all searching for what

56:35

would be the

56:37

right obstruction when

56:39

we want to build an application

56:41

or a website, I would say that. And

56:45

add to that all

56:47

of the web concerns and

56:49

you get like a

56:51

big area of activity

56:54

just around the existing frameworks

56:56

and the existing needs. So,

57:02

given everything that we've said

57:04

so far and giving everything

57:06

that you've explained, what

57:08

is the future of frameworks? So

57:12

I think

57:14

my bet, which

57:16

is, and again, I'm far

57:18

reaching, I think we

57:20

need to add two more requirements

57:22

into the mix. I think that if

57:24

the only reason to move from

57:26

React to another framework is aesthetics

57:29

and performance, it's not good

57:31

enough. That includes the

57:33

view and svelte and

57:35

quick and everything else, and

57:37

HTMX and so on. And that's

57:39

why no one would live in

57:41

React, to be honest, because

57:43

the need is not strong enough. But

57:46

I think there are two other requirements that

57:49

are very strong. One

57:51

is to be able to consume

57:53

third party components in a way

57:55

that you are both you

57:57

and the component are safe

57:59

from one. another.

58:01

And you know, just last

58:03

summer, we had an issue

58:05

where the VS code plugins

58:07

appeared to be very, there

58:09

was a published an article

58:11

that says that a research

58:13

group managed to put a

58:15

malicious VS code plugin with

58:18

hundreds of thousands of developers.

58:20

And then you have lots

58:22

of other cases like that.

58:24

And then you're downloading, you

58:26

know, all of the plugins

58:28

on this code are potentially

58:30

malicious. And then you have

58:32

a WordPress, which is known

58:34

to be, you know, all

58:36

of the plugins to be,

58:38

not all of them, but

58:40

a lot of them to

58:42

be real problematic. And then

58:44

you have lots of other

58:46

cases like that. And then

58:48

you're downloading free NPM across

58:50

your company, you know, all

58:52

around, talking about enterprises. you

58:54

have no idea what attack

58:56

vector are going on through

58:58

NPM and it is an

59:00

attack vector to get a

59:02

certain version of library to

59:04

be legit and then the

59:06

next one a minor version

59:08

to have a some vulnerability

59:10

or even some attack and

59:13

you just download it using

59:15

your code in your application

59:17

and you're exposed to it.

59:19

So what if I can

59:21

give you a framework? I'm

59:23

not saying that I can

59:25

give you that. But what

59:27

if the future framework would

59:29

protect you from that? automatically.

59:31

You know, that's one example.

59:33

But can a framework really

59:35

do that? Doesn't that need

59:37

to be solved at the

59:39

platform level? Or at least,

59:41

or at least have, you

59:43

know, for the platform to

59:45

provide building blocks that the

59:47

frameworks can then use to

59:49

provide a realistic solution to

59:51

stuff like that? I think

59:53

you're asking the wrong question.

59:55

The right question is... If

59:57

someone will make something like

59:59

that will be able to

1:00:01

create a framework that is such

1:00:04

a new requirement working within it

1:00:06

in some way and people are

1:00:08

innovative they'll find a way

1:00:10

for instance that that would be a

1:00:12

reason to move frameworks ending

1:00:14

two of the requirements that

1:00:17

they can put on the table

1:00:19

for frameworks to challenge that would

1:00:21

challenge our existing frameworks

1:00:23

is one the security

1:00:25

and the second one is designed

1:00:27

to code those are the two ones because

1:00:30

we both of either one

1:00:32

of those will challenge

1:00:35

everything we have today

1:00:37

in a significant

1:00:39

way. So it's

1:00:41

interesting because look so

1:00:44

for example the quick

1:00:46

gang made a bet

1:00:48

that that getting a

1:00:51

more performance solution would

1:00:53

get people to switch

1:00:56

and so far hasn't

1:00:58

really happened, certainly not

1:01:00

en masse. Whether or

1:01:03

not people will switch

1:01:05

for that, it's, you

1:01:07

know, maybe I have no

1:01:09

insight. But that's the

1:01:12

point. You know, when

1:01:14

the only thing

1:01:16

you're comparing

1:01:18

are non-functional,

1:01:20

it's very hard to

1:01:22

get someone to switch.

1:01:25

you have to be really, really

1:01:27

better and in a really pain

1:01:29

point. When you're starting to

1:01:31

move to eater, you know, functionals

1:01:34

and for a framework, allowing

1:01:36

designers to work in

1:01:38

a different way, that's a

1:01:40

functional thing. It changes the

1:01:42

old DNA of your framework.

1:01:44

Or when solving the big

1:01:46

problem like security, and

1:01:49

your security team is like,

1:01:51

hey, a dev team, you know, we can...

1:01:53

drop all of that a million dollar

1:01:55

deal of code scanning that we're doing

1:01:57

all the time to make sure we're all

1:02:00

of your NPM dependencies are working

1:02:02

and just use a secure

1:02:04

framework, then again, no one

1:02:06

knows what the future is

1:02:08

going to be. But my

1:02:11

bet is that a future

1:02:13

framework will not be just

1:02:15

about aesthetics and better performance.

1:02:17

There is going to be

1:02:19

some other need, some other

1:02:21

requirement or some other problem

1:02:24

that it solves on top

1:02:26

of... all of the existing

1:02:28

problems. It might be security,

1:02:30

might be designed to code,

1:02:32

might be something else. I

1:02:35

don't know. So I'll kind

1:02:37

of inverse your statement. What

1:02:39

you're saying is that there

1:02:41

are a couple of hard

1:02:43

problems that we need to

1:02:45

be solving that fall under

1:02:48

the umbrella term web essentials.

1:02:50

Current existing frameworks and even

1:02:52

meta frameworks are not. either

1:02:54

are not solving these problems

1:02:56

or are not sufficiently solving

1:02:58

these problems, something will come

1:03:01

along that will, and you

1:03:03

want to call that the

1:03:05

future framework. I would say

1:03:07

that with learning of the

1:03:09

aesthetics of our current frameworks,

1:03:11

that would probably be our

1:03:14

next big framework. I

1:03:19

would also very much, by the

1:03:21

way, like to have a link

1:03:23

to that list of web essentials,

1:03:25

by the way. I'll send it

1:03:27

for you. I think I edited

1:03:30

the react next presentation I did

1:03:32

last year. But I'll send it

1:03:34

to you. Okay. That'll be great.

1:03:36

I'll look at that presentation as

1:03:38

well. I think I did, but

1:03:41

I don't remember off the top

1:03:43

of my head right now. Yeah,

1:03:45

we're getting toward the end of

1:03:47

our scheduled time and I have

1:03:49

to go soon. So is there

1:03:52

some kind of overriding point that

1:03:54

you want to make or some

1:03:56

conclusion that you want to give

1:03:58

us? You all? I

1:04:01

think, I would say that there

1:04:03

is, we are at a

1:04:06

point where something is

1:04:08

going to happen with

1:04:10

web frameworks. You

1:04:12

know, when you look at

1:04:14

the, when you want to

1:04:17

predict the future, you

1:04:19

look at the history.

1:04:21

And, you know, our

1:04:23

web frameworks, you know,

1:04:25

age one was in 1995,

1:04:28

several rendering, age 1.

1:04:30

with J quarry quarry,

1:04:32

quarry, age two was with

1:04:34

angular react around 2010, and

1:04:37

then the metaphragm works and

1:04:39

the Edless CMS systems 2016,

1:04:41

that kind of the 2.5 age. And now

1:04:44

there's all kinds of

1:04:46

different innovations and ideas

1:04:48

floating around trying to

1:04:50

make something new. And at the same

1:04:52

time, we'll move in from a

1:04:55

non-regulated market to

1:04:57

highly regulated market. And

1:04:59

on the same time with AI coming

1:05:01

into the mix, and there is going

1:05:04

to be another something that is

1:05:06

going to challenge the internet

1:05:08

with AI. By the way, it's not going

1:05:10

to replace anything. It's just

1:05:12

going to be another distribution

1:05:15

channel based on AI that's going

1:05:17

to be a company in web and

1:05:19

mobile and social. So with all

1:05:21

of that together, something big is

1:05:24

going to happen with web

1:05:26

frameworks. What is it? I think that

1:05:28

is the big question. But I

1:05:30

can promise you is that it's not

1:05:32

anything like the frameworks we

1:05:34

have today. It's not going

1:05:36

to be just aesthetics and

1:05:39

a little bit better performance.

1:05:41

It's going to be something big.

1:05:43

All right, cool. Let's go ahead to

1:05:45

our picks. So one game that

1:05:47

my family's played a bit lately

1:05:50

is called the crew, mission deep

1:05:52

sea. Now I've picked the crew

1:05:54

before, that was the Quest for

1:05:56

Planet Nine. They're

1:05:58

effectively the

1:06:00

same, the difference is that with

1:06:02

the crew, the deep sea version,

1:06:05

what you wind up doing is

1:06:07

you still have the missions, right?

1:06:09

So it still gives you a

1:06:12

handicap of some kind. You can't,

1:06:14

you have to do things in

1:06:16

sort of order or, right, you

1:06:19

do so many missions. The difference

1:06:21

is that with the deep sea

1:06:23

mission, the missions you actually flip.

1:06:26

cards over just like you did

1:06:28

in the Quest for Planet 9,

1:06:30

but they can be anything from

1:06:33

you have to take two cards

1:06:35

of this color and two cards

1:06:37

of that color. Or you, I

1:06:40

mean, there are all kinds of

1:06:42

things. Whereas with the original version,

1:06:44

you flip it over and you'd

1:06:47

have to take that card and

1:06:49

then you had little tiles you'd

1:06:51

put on them. You have to

1:06:54

do this one first and this

1:06:56

one last. or you have to

1:06:58

do these three in order, or

1:07:01

you have to do this one

1:07:03

first, and the next two in

1:07:05

order after that, and then this

1:07:08

one has to be last, or

1:07:10

things like that. So, and it's

1:07:12

trick-taking. So, anyway, it's pretty simple

1:07:15

and straightforward as far as all

1:07:17

that goes. 2.04. So

1:07:19

it's right around casual gamer. You

1:07:22

could pick it up and have

1:07:24

fun with it. I like playing

1:07:26

these games with four people. You

1:07:28

can play three to five and

1:07:31

it's not bad at three or

1:07:33

five, but anyway, it's a fun

1:07:35

game. So I'm gonna pick that

1:07:37

for my pick. My wife and

1:07:39

I watched a movie this week

1:07:42

called Homestead. Let me get a

1:07:44

link for this and put it

1:07:46

in the... in the comments, but

1:07:48

we watched a movie called Homestead

1:07:51

and it's so essentially the premise

1:07:53

of the show if you go

1:07:55

watch the the trailer this is

1:07:57

about what you'll get from it.

1:08:00

There's a nuclear bomb

1:08:02

that goes off in California,

1:08:05

in Southern California,

1:08:07

and then there are other

1:08:09

terrorist attacks. It's a little

1:08:12

fuzzy on it, but the

1:08:14

just I got was that

1:08:16

there are major power outages.

1:08:18

The power grid goes out

1:08:20

on the East Coast of the

1:08:22

United States. And so,

1:08:24

there's this homestead,

1:08:26

essentially, it's some land. I

1:08:29

kind of gathered it was

1:08:31

in Montana, but I'm not sure

1:08:33

on that. But anyway, this guy

1:08:35

hires an ex-green buret to

1:08:38

put together a security

1:08:40

team just in case there's

1:08:42

kind of a worldwide catastrophe

1:08:45

and he needs to protect

1:08:47

his area and he's like

1:08:49

this uber-prepper, right? So they

1:08:51

have medical supplies and... you

1:08:54

know they they grow stuff on their

1:08:56

property and all kinds of stuff like

1:08:58

that and so you know this catastrophe

1:09:01

hits and so this guy

1:09:03

you know basically grabs his

1:09:05

family and heads up to where

1:09:07

this this homestead is and they

1:09:09

you know they they set things up and

1:09:11

or protecting the homestead

1:09:13

kind of thing it was really

1:09:15

good and then when we watched

1:09:17

it afterwards so we were part

1:09:19

of the angel guild which is

1:09:22

Angel Studios is the one that

1:09:24

put it out Angel Studios also

1:09:26

did the chosen and a bunch of

1:09:29

other movies that I've picked They

1:09:31

turned it into a series and

1:09:33

so we actually watched the first

1:09:35

episode of the series too and it's

1:09:37

pretty good. So I'm gonna pick that

1:09:40

if that's kind of your cup

1:09:42

of tea Kind of the it

1:09:44

kind of walks you through the

1:09:46

apocalypse and anyway, it's it's really

1:09:48

awesome. So I've been enjoying that

1:09:50

and Talk about the apocalypse.

1:09:53

I looked I've seen the

1:09:55

serious a Van Helsing recently.

1:09:58

Uh-huh, which is a you

1:10:00

know another adaptation of

1:10:02

the vampires taking over America

1:10:04

and but it's you

1:10:06

know it's very very fun

1:10:08

but you know my

1:10:11

pick are actually going to

1:10:13

be different a different

1:10:15

movie I would go with

1:10:17

themselves which is a

1:10:19

movie about a princess that

1:10:22

is you know basically

1:10:24

it's a common girl that

1:10:26

is a princess chosen

1:10:28

heir to be his wife

1:10:30

and it's like a

1:10:32

fairy tale story and then

1:10:35

after the marriage he

1:10:37

kinds of throws her under

1:10:39

into a pit to

1:10:41

be sacrificed to a dragon

1:10:43

and then it kinds

1:10:46

of goes off rails and

1:10:48

becomes a very different

1:10:50

movie which you know one

1:10:52

thing that actually I

1:10:54

liked about it is that

1:10:56

first it's very very

1:10:59

different and second it doesn't

1:11:01

go with the regular

1:11:03

style of the prince saves

1:11:05

the princess it actually

1:11:07

goes to other around which

1:11:09

is really encouraging and

1:11:12

really fresh I would say

1:11:14

it's for a game

1:11:16

is okay to choose a

1:11:18

cards game you know

1:11:20

there is a game that

1:11:23

really I really enjoy

1:11:25

a plane with my kids

1:11:27

called the Queens and

1:11:29

it actually starts becoming a

1:11:31

recurring idea of Queens

1:11:33

and Princess but it's actually

1:11:36

it's a it's a

1:11:38

game where there are a

1:11:40

there are 10 Queens

1:11:42

or so it's a 16

1:11:44

Queens on the board

1:11:47

which are upside down don't

1:11:49

know which card is

1:11:51

which Queen oh sleeping Queens

1:11:53

sleeping Queens yeah yeah

1:11:55

I played this with my

1:11:57

kids it's a fun It's

1:12:00

a really fun one and

1:12:02

my kids are very

1:12:04

enthusiastic about that and

1:12:06

very passionate so that's you

1:12:09

know just great game. Yeah it's

1:12:11

it's very approachable so my

1:12:13

daughter is nine now but

1:12:15

I think we got it when

1:12:17

she was like six or seven

1:12:20

and it's definitely

1:12:22

approachable for younger

1:12:24

kids but yeah there's enough

1:12:26

meat to the game to where adults

1:12:29

that enjoy playing with it. It's not

1:12:31

when I would pick to play with

1:12:33

my friends, but with my kids definitely.

1:12:35

And board game geek weights it at

1:12:38

1.05. So it's got fairly simple mechanics.

1:12:40

I think it plays two to five

1:12:42

people too. That's what it says here.

1:12:44

And yeah, terrific game. Yeah, it's a great game.

1:12:47

And you know, my kids are 9 and 11,

1:12:49

which is just the right age. And it works

1:12:51

wonders with them. Yeah. I had somebody

1:12:54

ask me ask me on, I think it

1:12:56

was Ruby robes. Ruby robes last week.

1:12:58

They asked me what games

1:13:00

I recommend for kids and

1:13:02

I listed a whole bunch there,

1:13:05

but there are a ton of

1:13:07

just terrific games you

1:13:09

can play with kids. Yeah, I

1:13:11

wonder if Board Game Geek

1:13:14

actually has a list for kids.

1:13:16

I know they have categories

1:13:18

here, here we go, categories.

1:13:21

Yeah, I actually never tried

1:13:23

that board game, board game,

1:13:25

board game. Yeah, board game geek.

1:13:28

So I'll just do that as a

1:13:30

pick and I'll just throw it out

1:13:32

as well. So board game geek,

1:13:34

the way that it works is

1:13:36

it's essentially kind of this database

1:13:38

of board games. And they do

1:13:40

board games and card games. And

1:13:42

then what you can do is they have

1:13:45

forums as well. So if you, a

1:13:47

lot of times I'm on board game geek

1:13:49

because I'm going, what? You

1:13:52

know what what what is the I

1:13:54

have a question about a mechanic in

1:13:56

a game, right? So they didn't

1:13:58

they didn't clarify And so,

1:14:00

you know, you know, I

1:14:02

need to know, hey, how

1:14:04

does this work or that

1:14:07

working? I have to say

1:14:09

the director I'm looking at

1:14:11

is whiskey base. And it's

1:14:13

a little bit different. It's

1:14:15

a kind of give ratings

1:14:17

for different whiskey drums. And

1:14:19

so you know, you can

1:14:21

know which spirit to get,

1:14:23

especially when you go to

1:14:25

more unique ones and more

1:14:27

little ones. Just have a

1:14:29

Glenn Gary 29 on its

1:14:31

way to my house, which

1:14:33

is supposed to be 95,

1:14:35

15 cone whiskey base, which

1:14:38

is kind of amazing. We'll

1:14:40

see how it goes. Very

1:14:42

cool. Yeah, I don't drink

1:14:44

alcohol at all. But yeah,

1:14:46

I mean, we used to

1:14:48

have somebody who would pick

1:14:50

beers every episode, so. Right,

1:14:52

it's like, hey, you have

1:14:54

to try this one and

1:14:56

sometimes they were local bruise

1:14:58

and sometimes yeah, I could

1:15:00

definitely see myself getting into

1:15:02

that if that was my

1:15:04

My thing but yeah Very

1:15:06

cool. Well, you have is

1:15:09

if people want to check

1:15:11

out Wicks Enterprise or they

1:15:13

want to see what you're

1:15:15

working on or catch you

1:15:17

at a conference or anything.

1:15:19

How do they find you?

1:15:21

And you know, just give

1:15:23

me a call. You know,

1:15:25

reach out to me on

1:15:27

Twitter or LinkedIn. I'm there.

1:15:29

I'll be up to up

1:15:31

anyone. Sounds good. All right.

1:15:33

Well, I'm going to go

1:15:35

ahead and wrap us up.

1:15:37

Thanks for coming. Oh, thank

1:15:40

you for having me here.

1:15:42

Let's be super fun. Yeah.

1:15:44

Until next time, folks. Maxa.