PAUL: OK, glad you asked, because I did

think a little bit further than you, since you started driving

and you have no idea where you're going.

I thought, since we went to the boozer in England,

we could, this time, continue the trend,

but go to a vineyard.

JAKE: Ooh, that's--

PAUL: Keep it classy.

See now, look at this.

Right, I kind of feel like, yeah, all right,

like we did the pub before, back in England,

but I do think this has a slightly better view.

JAKE: How qualified do you feel?

PAUL: Not at all.

JAKE: Yeah.

PAUL: I know you're going through this.

I know it's red, or it's a clearish kind of color.

JAKE: It's nice, and it's not nice.

It's one of those.

Very binary with my wine tasting.

PAUL: And I have an upper limit of about five pounds, or $8.

And if it's more than that, it's probably not worth it.

JAKE: Anyway.

PAUL: Right.

So since we're here--

JAKE: Yes.

PAUL: --we tend to talk about the web.

And today, I think, is no different.

I want to talk about libraries and frameworks.

JAKE: Ah.

Yes, because you're not big on the frameworks, are you?

PAUL: No, and neither are you, honestly.

JAKE: On the other hand, I am not big on the frameworks.

PAUL: Yeah, so I don't think there is going

to be much of an argument.

But I do want to talk about it, because it bothers me

that I perceive that the default state of developers

is, I've got a blank page here, how am I going to fill it out?

Ah, I need a framework.

Which one do I use?

JAKE: That is a problem I have with frameworks, that they have

a way of starting projects.

Like, there's an expectation to use them from the offset.

And I think if you're thinking, what combination of frameworks

should I use to render this blank page,

then I think something has gone wrong.

PAUL: Gone wrong.

JAKE: Yeah.

For me, it's entirely from a performance point of view.

PAUL: Oh.

JAKE: Well, no, it's not, actually.

OK, step one, performance.

If your page has to load a ton of JavaScript

in order to make a request for the actual data it's

going to display, You've lost performance.

And you can sort of say, oh, but next time it's

going to be cached.

It might not be.

You might have changed the code, busted the cache.

PAUL: And it's an assumption that somebody's

going to come back again.

Right?

Well it--

JAKE: It's your goal, I would say.

PAUL: It's your goal, but you don't

know that somebody's going to.

It's like paying a big hefty tax on the assumption you're

going to get a repeat view.

JAKE: That's true.

PAUL: And you might not.

You might not.

JAKE: Yep.

And stuff falls out of the cache all the time.

PAUL: Yeah, exactly.

JAKE: Not the service worker cache, though.

PAUL: Oh, you and service worker.

Here we go again!

JAKE: Service worker.

PAUL: Dun dun dun.

One trick pony, Jake Archibald.

JAKE: All right, come on, it's got a cache,

you can rely on it.

PAUL: OK, performance, that notwithstanding,

I think for me, it's about code ownership somehow.

It's about a level of trust that I don't necessarily feel.

And what I want to do is, I want to be

able to feel like my application code is the thing that's

running.

That I'm not running through something else,

that I don't necessarily understand.

JAKE: Well, running through something else

is fine, because that's what a library is, right?

You've got--

PAUL: No.

JAKE: You've got a hold of both ends,

and you're running through bits of library

that you don't understand.

PAUL: Yep.

JAKE: But that's fine, because if one of them

starts misbehaving, rip it out, either code it yourself,

or find a replacement library.

PAUL: Yes.

But when you're going through something else, to--

JAKE: Well, you're in something else,

I think, with a framework.

And the framework, it will give you scraps.

PAUL: (IN A HIGH VOICE) Please, sir, can I have some more?

I'd like to work with this application.

JAKE: (IN A HIGH VOICE) Yes, can you please send this data over

here?

PAUL: (IN A LOW VOICE) More?

Pfft.

Get out.

JAKE: But then, you're sat in a tiny bubble

of the overall application with a framework.

And I feel that to get the most out of a framework,

you need to understand how the framework is built.

And these frameworks are huge.

So it's really difficult to do that.

PAUL: They are.

I actually feel-- and maybe this is wrong--

but it feels to me like it's kind of, the decision is

an ergonomics one.

Like a developer's saying, my ergonomics

trumps the user's requirements.

I want to feel like my job is easy,

and what the user gets is what the user gets.

And my whole approach is very much the other way.

I'd rather go the extra mile and all my users

benefit than my life is a bit easier

and I'll take some of the bad performance,

or the tacks of using that framework.

So I don't think that frameworks are inherently evil

and to be avoided.

But I think you want to be able to transition to one

and say, yeah, now it feels like we're getting to the point

where we're going to reinvent that.

And I think you can only do that when

you've got to a certain point with the build.

JAKE: So for you, it's start light, start with libraries,

as and when you need them, and then

make the jump to frameworks only if you have to.

PAUL: Agreed.

[MUSIC PLAYING]