Jack Herrington is a Principal Software Engineer. Misko Hevery is the Chief Technology Officer at Builder.io. They join the show to talk about "Qwik v1.0". Misko takes the lead as he shares its exciting new features. He explains what is the Panda CSS and how it works. Moreover, he dives into some of the "Qwiklabs projects", its benefits, and many more!

Links

Steve:

Hello everybody, welcome to another exciting, thrilling episode of JavaScript Jabber. I am Steve Edwards, the host with the face for radio and the voice for being a mine, but I'm still your host. Today we have a returning guest plus a new guest. First of all, I'd like to welcome back Mishko Hevery. How you doing Mishko?

 

Miško Hevery:

I'm doing great. Thank you for having me again.

 

Steve:

Good, good to have you. This will be a rather quick conversation, so they say.

 

Jack Herrington:

Womp Womp

 

Miško Hevery:

Ha ha ha.

 

Steve:

Thank you. And then also we're welcoming a new guest, Mr. Jack Harrington. How are you doing, Jack?

 

Jack Herrington:

I'm great, how are you?

 

Steve:

Fabulous. Nice to have you. So before we get going into our panelists and our subject, why don't you give us a little background on yourself, such as who you are, why you're famous, why people should give you money, et cetera.

 

Miško Hevery:

Should I go first or is Jack going first?

 

Steve:

Everybody knows you, Mishko, we just want to hear about Jack.

 

Jack Herrington:

Oh, okay. Yeah, I'm Jack Harrington. I'm a react YouTuber. And yeah, do I'm doing content full time now. And so that I guess is, I don't know if I'm famous. That's why. But I am actually on another podcast that's on this particular network react roundup. So you can go check that out or my YouTube channel. And yeah, here

 

Steve:

Alrighty.

 

Jack Herrington:

I want

 

Dan:

Yeah,

 

Jack Herrington:

all cool

 

Dan:

blue

 

Jack Herrington:

things

 

Dan:

color

 

Jack Herrington:

react.

 

Dan:

code, right?

 

Jack Herrington:

Right? The blue collar coder. Exactly.

 

Steve:

Today

 

Jack Herrington:

I'm wearing

 

Steve:

it's

 

Jack Herrington:

blue

 

Steve:

a blue

 

Jack Herrington:

today.

 

Steve:

shirt coater, but...

 

Jack Herrington:

Exactly. Yeah, yeah, yeah. And it's got a blue collar.

 

Steve:

Right a little blue and white actually

 

Jack Herrington:

There you go.

 

Steve:

miss go will come back for those who might not be aware of your ever-increasing fame Why don't you give us a little? background on YouTube

 

Miško Hevery:

Yeah, so hi, I'm Misko. I guess I'm famous because of this thing called AngularJS and then Angular. And now we're working on a new framework called Quick and I'm currently a CTO of Builder.io. Builder.io is a headless visual CMS. The headless part means it's running on your infrastructure and visual means it's a drag and drop editor that you can have using your own components that you build using your own framework, whether it's React, Angular, View or Quick.

 

Dan:

I

 

Steve:

All

 

Dan:

love

 

Steve:

right.

 

Dan:

that explanation because

 

Jack Herrington:

Yeah.

 

Dan:

often when I hear the terms headless and visual together it kind of throws me off but you gave an excellent explanation of how these two can work together.

 

Steve:

And before

 

Miško Hevery:

Thank you.

 

Steve:

we get into that, let's welcome our panelists. Surprisingly quiet until now. AJ O'Neill, how you doing, AJ?

 

Miško Hevery:

I'm out.

 

AJ:

I'm not gonna dignify that.

 

Jack Herrington:

Hahahaha!

 

AJ:

Yo, yo, everybody. What's happening? Coming at you live from freaking 95 degrees.

 

Jack Herrington:

Where?

 

AJ:

It's getting hot

 

Jack Herrington:

No,

 

AJ:

here

 

Jack Herrington:

but

 

AJ:

in Utah.

 

Jack Herrington:

where in the US has 95 degrees right now? I'm just curious.

 

AJ:

It's it it's

 

Jack Herrington:

Texas?

 

AJ:

a Utah

 

Jack Herrington:

Oh, oh, OK.

 

AJ:

Valley Although the whole valley is heating up. I think today's high Today's high is predicted to be 93

 

Jack Herrington:

Woohoo!

 

Dan:

Whoa, that's more than Tel Aviv.

 

AJ:

But in the, well, it was crazy because we had a super long winter. Winter lasted until about three weeks ago. And then all of a sudden it was, no, that's not true. Sorry. We had a really long spring. We had a really late winter and a really long spring. And spring, summer started about three weeks ago and it just got, it just got hot. It went from like months of pleasant weather which is incredibly unusual to just boom, burning hot. And

 

Jack Herrington:

There you go.

 

Steve:

Alright.

 

AJ:

My AC can't keep up with it in the shed.

 

Steve:

Alright,

 

Dan:

Hmm

 

Steve:

real quick, pause here people. Brenda, edit. My mic sounds like crap because I'm on the wrong mic. So let me see if I can switch that.

 

Dan:

Oh, there he goes.

 

Jack Herrington:

We still recording? Oh yeah, we are still recording. Okay. I figured as a host you might have

 

Dan:

No, but

 

Jack Herrington:

dropped

 

Dan:

if a

 

Jack Herrington:

off.

 

Dan:

host drops it still goes because you know if there's technical issues why stop their show

 

Jack Herrington:

Makes sense. Keep rolling!

 

Dan:

Ha ha. Yeah.

 

Jack Herrington:

I'm sure Miesko, man, you really have that, you know, the intro down. I'm

 

Miško Hevery:

Oh,

 

Jack Herrington:

not

 

Miško Hevery:

thank

 

Jack Herrington:

sure.

 

Miško Hevery:

you.

 

Jack Herrington:

Yeah,

 

Miško Hevery:

I'm

 

Jack Herrington:

not

 

Miško Hevery:

always

 

Jack Herrington:

the first

 

Miško Hevery:

tweaking

 

Jack Herrington:

time, obviously.

 

Miško Hevery:

it. Ha ha ha.

 

Jack Herrington:

Yeah.

 

Dan:

Yeah, I was going to ask, have you presented about this topic recently?

 

Jack Herrington:

Hahaha!

 

Miško Hevery:

What do you mean? It's my job!

 

Dan:

Hahaha!

 

Steve:

Okay, does that sound better AJ?

 

AJ:

Yeah,

 

Jack Herrington:

You should go talking

 

AJ:

Steve,

 

Steve:

Yeah.

 

Jack Herrington:

about

 

AJ:

you

 

Jack Herrington:

quick,

 

AJ:

sound

 

Jack Herrington:

no!

 

AJ:

like a normal Steve again.

 

Steve:

Yeah, it helps to get the right microphone.

 

Jack Herrington:

Whoo!

 

AJ:

before you really did have the voice for being a mime.

 

Steve:

Oh, I did. Well, that's the microphone just makes that a little less. Let's see. All right. Picking up where we left off and coming at us live from Tel Aviv is Dan Shapir. How are you doing, Dan?

 

Dan:

I'm doing fine. It's not as hot as Utah, surprisingly.

 

Steve:

That's a first.

 

Dan:

Yeah, no, it's a nice 80-something degrees here in the evening. It's on the warm side, but I'm okay with it. And I've got the AC running, so all's good.

 

Steve:

Good. All right, so since we last spoke with Mishko, QUIC has had a 1.0 release. Let's see, sorry, I forgot about the studio audience too. So we're here to talk about what has been going on quick since the last episode with 1.0 and any other topics we might rabbit trail into. So Mishko, take it away.

 

Miško Hevery:

Yeah, so 1.0 was in early May and we are super excited about it. To us, 1.0 means that the APIs of Quick and Quickcity are stable. We're not planning to change it. Certainly, we're going to be adding new things, but it's all going to be backwards compatible. And so yeah, we're super excited because it means the world can start using us in production and we're supporting them. I think since 1.0, we had some cool set of features that came out. One of them is the image optimization. We had image optimization before, but like this is a whole new level of image optimization. And we integrated, one of the philosophy we have with QUIC is that we want to be, you know, the performance framework without the developer having to jump through any kind of hoops. So kind of out of the box, just do the easy thing. The easy thing is the performance thing. And one area where frameworks typically don't have an opinion on. is CLS, right? Commutative Layout Shift, because that's really a problem with the styling, rather than a problem with the framework. But

 

Dan:

Yes.

 

Miško Hevery:

with QUIC, we now hook into the Chrome Dev, and we collect information, and we automatically tell you that your code might have a CLS issue. And there's

 

Dan:

Mmm.

 

Miško Hevery:

even a button to push. Like it comes up in the red box and says, hey, this thing shifted on page load. Like, did you intend this? You might want to

 

Jack Herrington:

Wow,

 

Miško Hevery:

look at it.

 

Jack Herrington:

that's

 

Miško Hevery:

Yeah.

 

Jack Herrington:

slick, man. I mean, okay, I'm

 

Miško Hevery:

And

 

Jack Herrington:

gonna

 

Miško Hevery:

in

 

Jack Herrington:

have

 

Miško Hevery:

the

 

Jack Herrington:

to

 

Miško Hevery:

corner,

 

Jack Herrington:

try this.

 

Miško Hevery:

if it's an image, then we say, hey, it's an image, so it looks like you forgot to do width or height or something like that. And there's a button that says AutoFix, and we go and change the source code as well.

 

Dan:

Wow that's really

 

Jack Herrington:

Nice.

 

Dan:

cool, that's

 

Jack Herrington:

Yeah.

 

Dan:

really

 

Miško Hevery:

Yeah.

 

Dan:

nice

 

Jack Herrington:

Right. You can do the same thing for custom fonts.

 

Miško Hevery:

See you again.

 

Jack Herrington:

You can do the same thing for custom fonts at some point.

 

Miško Hevery:

Yeah, I think we're looking into custom fonts right now. And of course, we integrated Panda CSS,

 

Jack Herrington:

Mm-hmm.

 

Miško Hevery:

and I started using it. I absolutely love it. It's like emotion, but without some of the drawbacks that emotion has with server-side rendering.

 

Jack Herrington:

So when you say

 

Dan:

Yeah,

 

Jack Herrington:

integrated,

 

Dan:

so...

 

Jack Herrington:

what does that mean? Does that mean like it's now you have to use Panda or?

 

Miško Hevery:

No, you could use whatever CSS technology

 

Jack Herrington:

Oh,

 

Miško Hevery:

you

 

Jack Herrington:

okay.

 

Miško Hevery:

want, but now it's integrated in. So one of the choices you have, you can use Tailwind, you can use post-CSS, you can use vanilla extract. Now we have an additional one called Panda and it's a atomic CSS space system. So it's kind of like Tailwind in that sense. But it doesn't have the, what's the word I'm looking for? The thing that makes Tailwind controversial, right? The thing that,

 

Jack Herrington:

Oh, the bloat of like

 

Miško Hevery:

the blobs.

 

Jack Herrington:

100 classes

 

Miško Hevery:

Yes.

 

Jack Herrington:

in your in your class name. Yeah.

 

Miško Hevery:

The country was your party is not included in inside of that, which is kind

 

Jack Herrington:

Hahaha

 

Miško Hevery:

of

 

Dan:

So I was actually not so familiar with Panda CSS before you mentioned it to me when we last spoke. So can you maybe, and I'm assuming that if it's true for me, it's also probably true for some of our listeners. So even though we are here to talk about QUIC, can you tell us a little bit about Panda CSS and

 

Miško Hevery:

Sure.

 

Dan:

why is it worthwhile to use this technology? What's interesting about it?

 

Miško Hevery:

Yeah, so first of all, let me just like preface it with, I am not a styling expert, okay?

 

Dan:

Who

 

Miško Hevery:

Just

 

Dan:

is?

 

Miško Hevery:

to kind of put it,

 

Dan:

Just Lea

 

Miško Hevery:

but

 

Dan:

Peru, that's it.

 

Miško Hevery:

I can barely center a text, okay?

 

Jack Herrington:

Haha.

 

Dan:

Nobody.

 

Jack Herrington:

Oh, yeah. Yeah. No, hold on to horizontally. And that's easy, but vertically.

 

Miško Hevery:

Hahahaha

 

Dan:

Nobody can send their text vertically.

 

Jack Herrington:

Yeah

 

Miško Hevery:

Anyways, so, okay. So what's cool about Pandas CSS? I think CSS has gone through a couple of iterations and I think EmotionJS or Emotion CSS, I don't know what the proper name is, I think became popular because it's the styling inside of your code. And I think there is something to be said for like, I am coding, I made my div and now I need to style it and I can just do it inline. I don't have to make a separate file. And then figure out like, what do I name the file? And like, it just breaks the flow, right? Like if you want to center something to go through like making a new CSS file and then importing it into it and then referring to it and giving a name, it's just too much work. And so there is something to be said for this niceness of just like inlining the styling directly into your, into your source code. And I think that's the reason why emotion has become so popular. I

 

Dan:

I

 

Miško Hevery:

think.

 

Dan:

think if I can interject, I think

 

Miško Hevery:

Yeah.

 

Dan:

there's like a kind of a disconnect or an impotence like mismatch between developers and designers where developers have been trained to look at things like locally and encapsulate things and componentize things. Whereas designers often looked at things like holistically and globally and across the entire scope of the page. And CSS is originally more modeled to the designer outlook. And we developers keep struggling with that. Like how do I put my rules specifically on the component? How do I encapsulate my layout and stuff like that? And I think this is like a recurring issue and that's kind of the reason I think for all of, at the end of the day, there are other technical reasons, but at the end of the day, seems to me that that's the primary motivation for a lot of these

 

Miško Hevery:

Mm-hmm.

 

Dan:

utilities built on top of CSS.

 

Miško Hevery:

Yeah, absolutely. I want to just add to it is that there are kind of like two ways to think about styling, right? There is this atomic CSS and then there's the classical way of doing CSS. A classical way is like you have a, you know, element and you give it a name through a class name. And then inside of the class name, you add a bunch of things that's what it is. And so when you have a design system, it's very common that everybody has the same padding, like padding 10, padding 10, padding 10, right? you keep repeating that everywhere in all your styles. Whereas Atomic CSS says, well, how about we break this up? And we basically say that, hey, the padding 10 is going to be just one style. And then margin might be another style, or centering could be another style. And then you just combine those styles, kind of what Tailwind does. If you think about it, Tailwind is Atomic CSS, because you're saying, I want padding, I want margin, I want all these things. But it bloats your classes. So What Panda is, is kind of a mixture of both. Like it's atomic like Tailwind, but it's inlined like emotion. And I think putting those two together is kind of a mix up for a really nice combination. And I really enjoy using it.

 

Dan:

And I think that Manu recently added some nice integration between you and Panda, I seem to recall.

 

Miško Hevery:

Yeah,

 

Dan:

Kind

 

Miško Hevery:

quick

 

Dan:

of experimental,

 

Miško Hevery:

now, Hazard.

 

Dan:

yeah, kind of experimental, but really cool.

 

Miško Hevery:

That's right. And so the niceness of atomic CSS is that the amount of CSS grows, but it reaches a plateau no matter how big your app gets. There's a plateau that you reach because you've already specified the padding ones, you've already specified the margin and you already have the so on. So it's a limited scope.

 

Dan:

And does it also kind of avoid the problem of adding rules that you can then never remove because you don't know what you might break?

 

Miško Hevery:

Right. So Panda CSS is a compile time thing. So emotion is runtime, right? Like as the code is running, it's generating the styles and that creates problems for, you know, server-side rendering and things of that sort and adding and removing the rules can cause styling reflows. Whereas Panda CSS basically executes all these things statically ahead of time during the compilation and sets up all the styles ahead of time. And then the only thing you're doing is just kind of a tailwindy thing. So think of it like, it's like tailwind in terms of the runtime, but it's like emotion in terms of the syntax.

 

Jack Herrington:

Hmm

 

Dan:

Hmm, interesting.

 

Jack Herrington:

I'm excited.

 

Miško Hevery:

I like

 

Jack Herrington:

I'm going

 

Miško Hevery:

it. I'm really

 

Jack Herrington:

to go to

 

Miško Hevery:

enjoying

 

Jack Herrington:

try.

 

Miško Hevery:

it. I'm really

 

Jack Herrington:

All

 

Miško Hevery:

enjoying

 

Jack Herrington:

in all,

 

Miško Hevery:

it.

 

Jack Herrington:

use Quick to do it.

 

Miško Hevery:

There you go. There you go.

 

Jack Herrington:

So what else is new on Quake?

 

Miško Hevery:

Let's see, we talked about the styling. One of the things I started working on, we started this thing called Quick Labs. And Quick Labs is basically our area where we wanna experiment with things, right? Once you reach 1.0, it kind of makes it difficult to experiment because it's like, well, we can't break this, but at the same time, we wanna try different things. And so where do you put the things that you wanna try? And so for that, we created a brand new package called Quick Labs. And the idea is that... Over there in QuickLabs, we can experiment. We'll break things. We're not making any sort of guarantees, but we're also saying this is not production ready. This is just for us to kind of try and get feedback on. And then at some point, it will graduate from QuickLabs into the actual production code base.

 

Dan:

or

 

Miško Hevery:

So

 

Dan:

not.

 

Miško Hevery:

we have two things, or not, or not. It could be dead end, right? And so we have two things going on in there right now. One is the type, the route, the strongly typed routes.

 

Jack Herrington:

Hmm.

 

Dan:

Oh!

 

Jack Herrington:

Ooh, yeah.

 

Miško Hevery:

Yeah, the goal I would like to have is that when you make links or URLs or anything of that sort, I want the TypeScript to scream at you and be like, that's not a thing that points to anything. But not just about URLs, but also query parameters, kind of like React router from 10stack.

 

Dan:

Yeah, we actually had Tanner Lindsay on the show a couple of episodes back talking about it and explaining

 

Miško Hevery:

Yeah.

 

Dan:

the benefits of type routing. So if our listeners are interested, they should go back and listen for sure.

 

Miško Hevery:

So I think what he's trying to do, I think he's totally on the right track and I really support his work. So we wanna have the same kind of an idea within QUIC. There are reasons why we can't use a 10 stack. I would love to be able to just use it, but it doesn't like decompose into the quickness of lazy loading, et cetera. Like the 10 stack kind of implies that it's running client side rendered rather than this server client metaphor that QUIC has. And so we want to be able to do all of these things inside of it. So that's one, one Qwiklabs project. The other Qwiklabs

 

Dan:

So

 

Miško Hevery:

project.

 

Dan:

just to clarify in case that does graduate, does that mean that type routing will become the de facto standard routing mechanism for Quickslash Quick City?

 

Miško Hevery:

Yeah, going forward we would add that, yeah.

 

Dan:

Cool.

 

Miško Hevery:

That's exactly the idea. I mean, I've always been a big proponent of TypeScript. I think TypeScript is great.

 

Dan:

Hmm.

 

Miško Hevery:

I'm a big fan of it, right? I think Angular helps. I'm not saying we should take a lot of credit, but we did a little bit to help popularize it with,

 

Dan:

Yeah, that's for sure.

 

Miško Hevery:

which by adding it into Angular early on before it was that popular.

 

Dan:

Yeah, everybody was kind of surprised that like the big project that implemented Microsoft's TypeScript was Google's Angular kind

 

Jack Herrington:

Hehehehe

 

Dan:

of thing.

 

Miško Hevery:

Yeah, but I think it was totally the right thing to do, like in retrospect, that was absolutely right. The other thing that's,

 

Dan:

Oh

 

Miško Hevery:

yeah.

 

Dan:

yeah, not implement Angular in Dart?

 

Jack Herrington:

UGH

 

Miško Hevery:

Why did you have to go there?

 

Jack Herrington:

she liked art. But yeah, okay.

 

Miško Hevery:

Dart is fine as a language. It's that's

 

Jack Herrington:

The

 

Miško Hevery:

not

 

Jack Herrington:

language

 

Miško Hevery:

what the

 

Jack Herrington:

is great. Yeah.

 

Miško Hevery:

yeah, it's not. Anyways, moving on.

 

Jack Herrington:

hahaha

 

Miško Hevery:

So the other thing in Quick Labs, which I'm super excited about right now, is what we call insights. And insight is stuff that we have talked about for a while that we wanted to do, but now it's actually in there. And the idea of insights is that as you're using the application, we collect statistical information about which symbols are getting loaded when, and we send it back. to some database and then inside of the database, we then analyze it and basically tell you what are the ideal bundles? How should you set up your bundles so that you would have the least amount of code being shipped to the client, but also don't have any latency delay for the end user? And the insights will give you not just that, but also tell the system which components even make it to the client and which components never make it to the client. So there's a lot of benefits. to it. And so that project is underway. And I'm super excited. We have all kinds of visualizations that show off, you know, how the histograms to show off the different latency of different symbols and then correlation matrices that like say like, oh, it looks like whenever this symbol shows up, also these other symbols also come up. And so tricks like that.

 

Jack Herrington:

Is that actually out there? I mean, can I try this today? Because that sounds fascinating. Heck yeah. Okay. Yeah, please. Ah, ha. It's a Mishko special, huh? OK, well, so

 

Dan:

I really

 

Jack Herrington:

I mean,

 

Dan:

like

 

Jack Herrington:

it's the

 

Dan:

it.

 

Jack Herrington:

idea I like run my E2E tests against the app, you know, basically. And then at the end, we go, oh, look, OK, we didn't need that. We didn't need that. Ooh, right, yeah.

 

Dan:

Yeah, slicing and dicing bundles has always been kind of challenging, coming up with the ideal bundle size, because if the bundle is too small, you're losing out on compression. On the other hand, if the bundles are too big, you're potentially losing out on cache invalidations. There are all sorts of challenges with coming up with ideal bundle size. So if you can optimize both the bundle sizes, What actually gets bundled together, the order in which things get downloaded. And again, offload that effort off of the developers, make it kind of something that developers get, you know, free of charges, it were then. Yeah, that's definitely a very good thing.

 

AJ:

Now this is something I've wondered about.

 

Jack Herrington:

You locked up video-wise, like, a couple minutes ago. That's weird, because the audio is coming through just fine. But you were locked up video-wise.

 

Dan:

Yeah,

 

Jack Herrington:

Sure.

 

Dan:

yeah, go for it.

 

Jack Herrington:

I'm actually kind of, I want to talk to him about the bundle thing because I thought the whole point of quick was that you didn't actually run bundles or didn't download bundles until you needed them.

 

Dan:

Go

 

AJ:

So

 

Dan:

for it.

 

Miško Hevery:

Okay.

 

AJ:

this is something that I had been, I've been wondering about for years. It seems like we create all this sophistry for exactly the audience that shouldn't be dealing with it. The people that are doing web devs should not be doing the, this is more of a infrastructure thing in my mind. We should have web servers. This should just be standard in web servers that there's some sort of statistical analysis that it does a genetic algorithm. to serve to a few different browsers, see what the actual use looks like, store that in a tiny amount of RAM, write it out to a cache file, and then when you update the page, when any of the resources change, just break the caches and then start

 

Dan:

Thanks for watching!

 

AJ:

with a best guess again.

 

Dan:

So I'll make a comment about this, because something like three years ago, we actually had Joav Weiss from Google, you know, who works on like infrastructure things at Google, talking about web bundles, as I recall. And there was like this sort of a push to make this sort of a thing part of the actual infrastructure. But unfortunately, it didn't happen. It couldn't happen. There are all sorts of issues. You know, you can't even get everything from all the CDN providers yet. They don't all support, you know, like prioritization properly and stuff like that. And you're talking about way more sophisticated things. There are some, there are some advantages in the infrastructure,

 

Miško Hevery:

Thanks for watching!

 

Dan:

for example, like sharing the compression dictionary means that we'll get much better compression with smaller bundles going forward. So you won't have to bundle as much. So. So the platform is moving forward, but obviously it's moving forward at a slower pace than, you know, people like quick and Mishko can move, can move at.

 

Miško Hevery:

I want to add to it a little bit, which is that, you know, there's a lot of things you can do in terms of optimizing things in general, but your life of optimist optimization is going to be much, much easier. If the developer is in on it. What I mean by that is like, if the developer does things to help you along, then your life just gets tremendously simpler. Right. And so I think the philosophy that quick has is, is that

 

Jack Herrington:

that

 

Miško Hevery:

like

 

Jack Herrington:

like out

 

Miško Hevery:

out of the

 

Jack Herrington:

of

 

Miško Hevery:

box.

 

Jack Herrington:

the box.

 

Miško Hevery:

we want to make sure that the developer, we set up set of rules that force the developer to write the code in such a way so that we have all these options for optimization, right?

 

Jack Herrington:

Mm-hmm.

 

Miško Hevery:

And I think this is the kind of the big difference with existing approaches, is that existing approaches basically say like, we will somehow magically optimize later, we don't know how to be determined,

 

Jack Herrington:

Hehehehehehe

 

Miško Hevery:

right? And of course then afterwards, they're having a really hard time because like, it's, you know, the developer is not in on it, right? And so I think the big thing or the big innovation here in the quick is that like we set out a set of rules and the developer doesn't really have to think about it in terms of like, oh, I need to do this because I have to whatever, so that it can be optimized, right? These rules are just there and they have to follow them. And because of that, you know, later on you get benefits.

 

Dan:

Can you give an example of such a rule that you force developers to follow?

 

Miško Hevery:

Yeah, so there's really comes down to, in my opinion, to

 

Dan:

So again, can you give a rule that they need to follow with regard to the dollar sign? What is not serializable?

 

Jack Herrington:

functions. Okay, all right. But yeah, just random one off functions. So that's Sure. Yeah, okay. Yeah.

 

Dan:

Hmm. And what happens if there's something in the closure which is not? You get like a compiler error or something like that? And just, and I think it's worthwhile to again, to clarify to our listeners what we mean by civilization in this context. It means that something can usually start its life, life cycle on the server. And then at some point or another, make, you know, cross the network divide to the client and continue running there. Bye

 

Jack Herrington:

I mean, as

 

Dan:

again,

 

Jack Herrington:

long as you

 

Dan:

it's...

 

Jack Herrington:

would have it in the in the dollar and follow the rules. Yeah.

 

Dan:

But again, it's not just about isomorphic code. It's not just about the same code can run on the server or run on the client or run first on the server and then run on the client. It's about the state that you had when you ran on the server persisting as you run on the client.

 

Jack Herrington:

Super excited. Which kind of gives me back to what yeah, well, it kind of gives me back to where I was thinking right after you mentioned bundle optimization was, I mean, the whole point of quick is to have like super small bundles. I mean, yeah, it's very, it's the fine grained updating thing that we saw in solid combined with this rooms immobility. And so you don't expect to have mega bundles in quick land, everything's gonna be these tiny little things that are dynamically loaded whenever you hit a button or preloaded or whatever. So why any interest at all in bundle optimization? Sure. Okay.

 

Dan:

And here's an interesting architectural or implementation, I don't know at which level to put it, distinction between what you guys are doing and what the React guys with React Server components seem to be doing. That they are really intentionally trying to enforce a really clear separation between the server only code and the... client code, you know, with the whole user client and you server and having it in separate files and an import that you can put in that intentionally breaks if you accidentally try to download to the client something that should only live on the server or conversely if you put the stateful hooks in server only components and so on and so forth. And you. seem to be trying to avoid or trying to not make these kind of distinctions. Like, I could, I believe, write all of the quick, an entire quick application if I really wanted to as a single file, almost. And so the question that becomes maybe their... Yeah, exactly. So for example, let's say I'm using some sort, you gave an example of using some sort of an image processing library inside the code. With the quick approach, there is a higher potential risk that you will accidentally import or access the library features from code that does need to go to the client and end up pulling the library to the client. That's kind of what I'm reading. And your mechanisms are designed to say, you know, warn you that, hey, you're pulling down code that you might not want to pull down. And even if you do want to pull it down, we'll bundle it in such a way that it will either arrive much later or maybe not even arrive at all. Oh yeah!

 

Jack Herrington:

Oh, yeah, all the time. No Transcribed

 

Dan:

Oh

 

Jack Herrington:

by

 

Dan:

yeah,

 

Jack Herrington:

https://otter.ai

 

Dan:

for sure. I recall a project when I worked at Wix, when it turned out that we accidentally downloaded three different versions of Moment.js into the client bundle. Yeah,

 

Jack Herrington:

Mm

 

Dan:

fun times.

 

Jack Herrington:

hmm. Yeah. And they never get they never get. And here's the thing about that. They never get picked up like on the PR. Right. They always get picked up three months down the line when somebody goes, Whoa, wait a second, our bundle is how big? And then, you know, then it's this whole thing of like trying to figure out when it happened or what's in there and all that. And so I love this idea of it's kind of a DevOps thing. I'm like, hey, it's in your face all the time. It's like, you know, you get these this update. It's like, hey, whoa. What you just did brought a lot of code in,

 

Dan:

Yeah,

 

Jack Herrington:

by the way, like right now,

 

Dan:

but I do have

 

Jack Herrington:

you

 

Dan:

to

 

Jack Herrington:

know.

 

Dan:

ask about this. I mean, obviously you can analyze the user code within the context of the project that's been built in quick because as you said, there's like an onus on the developer to put in the dollar signs and whatnot. But if I'm bringing, yeah, but if I'm bringing in a third party library via NPM, what then? Yeah, but there's still a risk that when I click the button, because that button for some reason used the function out of Moment.js, I'll end up pulling Moment.js when the user clicks the button. Oh yeah, but on the other hand there's a risk that I might not notice because my tests don't actually click the button or something.

 

Jack Herrington:

Ha ha ha

 

Dan:

So maybe like

 

Jack Herrington:

Maybe

 

Dan:

a warning

 

Jack Herrington:

like a

 

Dan:

like,

 

Jack Herrington:

warning

 

Dan:

hey,

 

Jack Herrington:

like.

 

Dan:

you know, you need to notice that a certain bundle is, you know, maybe too large or something like that. There's another topic that I wanted to bring up, which we kind of touched on before we started recording, and we said we might want to talk about, which is, you mentioned quick and quick city. So I think that for some of our listeners, at least, the distinction between these two might not be clear. So can you kind of explain, like... Do I need, do I have to use Quick City if I use Quick, or can I use Quick without Quick City? Where does one end and the other begin? Why is this distinction even being made? So the routing is part of Quick City.

 

Jack Herrington:

Yeah.

 

Dan:

So... So here's the thing, though. I recently did a conference talk where I compared the performance of various frameworks, or more accurately, the likelihood that you'll build a performance website using any of the frameworks. So I basically looked at the ratios of websites having good performance built using any of the frameworks. And when I... looked at meta frameworks, I actually included QUIC as it were as a meta framework. Because from my perspective,

 

Jack Herrington:

Oh, I see.

 

Dan:

it's highly unlikely that anybody will decide to actually use QUIC and not use it with the SSR capabilities that are associated with it. So theoretically, there are a lot of organizations using React without any meta framework. Currently, only approximately some 13% of all React websites out there actually use some official, quote unquote, meta framework. Most of them are just maybe client-side rendered or whatever. There is a good question whether

 

Jack Herrington:

question

 

Dan:

this

 

Jack Herrington:

whether

 

Dan:

will persist

 

Jack Herrington:

this will

 

Dan:

going

 

Jack Herrington:

persist

 

Dan:

forward,

 

Jack Herrington:

or

 

Dan:

as it

 

Jack Herrington:

not.

 

Dan:

seems that

 

Jack Herrington:

I think that

 

Dan:

Next.js

 

Jack Herrington:

the next GSB

 

Dan:

is the future

 

Jack Herrington:

is the

 

Dan:

of

 

Jack Herrington:

future

 

Dan:

React.

 

Jack Herrington:

of science. But that's a good

 

Dan:

But

 

Jack Herrington:

question.

 

Dan:

that's the situation right now. And therefore, that's why I kind of questioned the need for this distinction in the context of QUIC, because I'm asking myself, why would I ever use QUIC without Quick City?

 

Jack Herrington:

Well, can I defend a little bit, actually? I mean, there's solid and there's solid start, which is very similar. There is, you know, view has its, you know, view and then I think it's got a, there's a router that is

 

Dan:

Next,

 

Jack Herrington:

independent and

 

Dan:

View Next.

 

Jack Herrington:

yeah, yeah. So everyone has this kind of thing. And there

 

Dan:

Yeah,

 

Jack Herrington:

is always that distinction.

 

Dan:

but for different reasons, by the way. We can, you know, and anyway, I'm kind of, you know, we're pulling the discussion in a different direction. We want to focus on quick. Hmm.

 

Jack Herrington:

Yeah, exactly. Right.

 

Dan:

We actually interviewed, it recently came out, an episode where we interviewed Kyle Simpson, Getify, talking about the company is currently working at socket supply. The reason that I'm bringing it up is they're doing a really interesting peer-to-peer thing where there are no servers. It's all clients talking to each other without any servers. It's all peer-to-peer. So yeah, I guess in that context, in the context of something like that, Or like you said, Chrome extensions, it makes a lot of sense. But it still seems to me like that the sweet spot, the where you guys are mostly promoting Quik, I think. It's the benefit of when it is used with a server.

 

Jack Herrington:

Oh definitely.

 

Steve:

So Mishko, let me ask you, one of the examples that I think of when you talk about separation of client side versus server side is an app, say that's just an administrative app. You don't give a rip about server side rendering or SEO because it's behind a login. You know, I've been working on one myself here for the past few months. And so is that something that, you know, based on what Dan was just describing about the whole reason for quick or a lot of it? unless I'm misunderstanding, is to have that synchronization and quickness, no pun intended, between, well actually I did intend it,

 

Jack Herrington:

Ha ha ha.

 

Dan:

They intended

 

Steve:

between,

 

Dan:

it when they came up with the

 

Steve:

and

 

Dan:

name.

 

Steve:

resumability between the back end and the front end. Is that even a valid use case for something like quick, where you only need the client side rendering, and if so, why?

 

Jack Herrington:

Yeah.

 

Dan:

And I'll add to that, that very often, you know, the fact that these kind of apps have really poor performance is justified by the fact that it's not worth the effort. But if there is no effort, if you get the good performance for quote unquote free, then everybody wins.

 

Steve:

Well, you're not alone. You know, one of the things I'm a big proponent of is inertia, uh, JS. And that does a lot of what you describe. It handles the browser communication between your chosen front end and your backend and it's smoking fast. I've been amazed about how fast it is. And I didn't have to do anything. You know, all I do is I write my backend code. I write my front end code inertia handles, uh, the browser interaction between the front of the act and hijacking the post request and that kind of stuff. So, so yeah, it's. That's another similar tool, you know, to my mind that does the same thing that you're talking about. Obviously, there are some different tools and things that you're using, but the end result is still the same. I agree.

 

Jack Herrington:

Yeah, absolutely. Yeah.

 

Dan:

Oh yeah.

 

Jack Herrington:

Mm-hmm. Oh, yeah.

 

Dan:

Doors, lots and lots of doors. Mm.

 

Steve:

Well, there's a whole rabbit trail we could go down considering I was just reading a report of a well-known crash in Hawaii that happened a few years ago. It was on Hacker News about a cargo plane that had crashed. And the whole point of the report was how the human interactions prior to the flight and during the flight was what caused it. There were processes. There were everything in place. They didn't follow them.

 

Jack Herrington:

Hmm.

 

Steve:

So. you know, whether it was checklist, whether it was trusting the other person too much, you know, and not relying on the stuff that was in place. So that might be sort of a rabbit trail. But to your point, yes, a lot of times you blame the, the person, oh, they screwed up, somebody did something wrong. But at the same time, a lot of times you're saddled by the infrastructure, you know, with browsers, what are we saddled with? We're saddled with the post request and how it works and the interaction and all the caching and things you have to develop, you know. rely on if you're doing server-side rendering stuff, which is what you're trying to address. And so we're constantly coming up with tools to overcome the infrastructure and the tools we have in place, partially because if you look at the time that these tools were developed, they had a very small goal in mind. We want to make documents available on the web.

 

Jack Herrington:

Ha ha ha.

 

Steve:

They didn't give a rat's patootie about performance because a lot of that wasn't an issue at the time. And so... because of the way things were initially developed and because of all the technical debt you have on relying on those things for so many years, now you're developing tools to try to overcome it. Whereas, you know, hindsight's 20-20, right? If we were to look back at this point and say, okay, if I'm starting over with the World Wide Web and Tim Berners-Lee is still, you know, creating the web browser or, you know, Brandon's still doing JavaScript, whatever, we would do it completely different

 

Dan:

Yeah,

 

Steve:

because now

 

Dan:

you

 

Steve:

we

 

Dan:

would

 

Steve:

have technologies that would allow us to do things much quicker and much easier and faster.

 

Dan:

So here's the thing, I remember a talk from a long time ago by Ellen Kay, the amazing Ellen Kay. And if you guys don't know who that is, you know, you should, or our listeners, you should immediately like at the end of this podcast, drop everything and check out the stuff that he's done over

 

Jack Herrington:

Hahaha

 

Dan:

the years. Creator of Small Talk just to start, he basically invented the concept of object oriented programming. He was really annoyed with the web as an application platform. And I remember from something like 15 years ago, he tried to propose an alternative web, an alternative distributed application development platform. And he showed how much more amazing it was, and so on, and so forth. But what are we using today? We're using the web. not the amazing thing that Ellen Kay envisioned and designed. So in retrospect, going back, maybe Tim Berners-Lee and Brendan Icke would have built something else, but maybe that thing would have failed. So we've got what we've got. But going to the concept of performance, of getting performance for, again, for quote, unquote, free out of the framework or the platform. We've been primarily focusing about performance as in startup performance or loading performance. What about execution performance? Is that something where quick is providing value as well when compared to frameworks such as, I don't know, like react

 

Jack Herrington:

Ha ha!

 

Dan:

or, or view. So we've had Ryan Cognato on the show talking several times about fine grain reactivity and signals. So I encourage our listeners to check that out if they're interested in the topic. But just to give a really brief overview, basically the main contrast here is between is today is between systems like SOLID or like WIC which use the concept of fine grain when this particular value changes, that change triggers a mutation of the relevant part of the DOM. And contrast that with systems like React, which take a more immutable type of an approach where you generate the entire state that you want as a virtual DOM, hand it over to the framework. and the framework reconciles the difference. That's like the main distinction here, right? And you're kind of quote unquote forced into using fine-grained reactivity because it's kind of tied to the way in which you deliver down the code. That you only deliver the code that is needed to perform the mutation that needs to happen.

 

Jack Herrington:

Yeah. Hahaha

 

Dan:

But just to give a balanced viewpoint, there are people who prefer the React approach because it kind of avoids the coupling that exists between the state and the updates. Like you basically re-render the whole approach of re-rendering everything on any change makes the system potentially or often less performant. or less optimized in terms of performance, but simpler to grasp in terms of state transitions. So unless people object, I want to pull our conversation while we still have some time to a different direction, one that is slightly less technical or totally not technical, but has

 

Jack Herrington:

Hehehehe.

 

Dan:

to do a lot with the potential success of QUIC. It seems to me that a big factor for the current success of React was that at a certain point in time they got all the boot camps to teach React. that if you finish, if you go through a boot camp, there's a good chance that you learn some basic DOMs, some basic JavaScript, just enough to learn React, and then they taught you React. And consequently, when you get to your first job, React is what you know how to do, and also employers may prefer React because they know they can get people who know React to work on their projects. How will you be able to, how are you looking to, you know, circumvent, to like address this? Like do you foresee boot camps teaching quick instead of react? How would you like elicit this transition? Interesting. I do have to say one thing about the about react simplicity or suppose simplicity So I spoke at a recent react next conference at the end of the conference. We had this sort of In a question the other audience played the game where we are they got asked questions and you know, the winner got the prize And something like $500 Yeah

 

Jack Herrington:

Ooh!

 

Dan:

And I contributed some of the questions to that contest. And one of the questions was, how many built-in hooks does React have? not custom hooks or hooks introduced by third-party libraries, but ones actually built in to the core framework. Do you know? You're absolutely correct.

 

Jack Herrington:

Now he's gonna guess 11.

 

Dan:

Exactly

 

Jack Herrington:

Yeah.

 

Dan:

15. So

 

Jack Herrington:

Wow.

 

Dan:

how can React be super simple if it's got 15 built-in hooks? well

 

Jack Herrington:

Yeah, like a few of them are for library authors.

 

Dan:

yeah a

 

Jack Herrington:

Honestly,

 

Dan:

few of

 

Jack Herrington:

I

 

Dan:

them

 

Jack Herrington:

think like seven of them are for library authors,

 

Dan:

yeah

 

Jack Herrington:

at least.

 

Dan:

but that means that eights are actually needed and that's still a lot Yeah, just use effect everything.

 

Jack Herrington:

Oh no, God no. Oh, yeah. Yeah. I mean, I will say that the mental model of that stuff, I mean, I teach this a lot. And I have this long videos on literally just use effect. And people don't get it. It's really hard. And I actually think that it was interesting. A lot of people actually prefer not a lot. I don't know whatever some representative number still prefer classes, because they just actually for their the mental model, I think is just a little bit easier for them.

 

Dan:

When Ryan kind of pushed solid, one of the selling points was no use effect.

 

Jack Herrington:

Yeah, yeah. It's a huge foot gun. And it's just lying out there, you know, kind of in the middle of react land. What did it become? Okay.

 

Steve:

Alrighty.

 

Jack Herrington:

Yeah, absolutely. Yeah, yeah, for sure. That makes more sense, yeah.

 

Steve:

Alrighty, I'll jump in here. We're hitting about an hour or so. We need to start wrapping up. Before we move on to picks, any last things that we missed that you wanna mention real quick, Mishko?

 

Dan:

quick.

 

Steve:

Sorry, I really didn't attend that pun. It just worked out.

 

Jack Herrington:

Ahahaha!

 

Steve:

I'm just so good at it that it comes naturally.

 

Jack Herrington:

Ha ha ha!

 

Steve:

You know, being at the child of the seventies and eighties, when I first hear that, I think of Nestle quick and the rabbit and the whole, you know, chocolate milk song, I, I think it's Q W I K, uh, I've looked it up, but, uh, yeah, that's, that's how I remember it. So anyway.

 

Jack Herrington:

I know I have like a quickie mart in my town. Why?

 

Steve:

Oh, okay.

 

Dan:

Yeah, otherwise you would have had like

 

Steve:

At a trademark

 

Dan:

a trademark

 

Steve:

issues,

 

Dan:

issue

 

Steve:

yeah.

 

Dan:

with Nestle.

 

Steve:

Yeah, that's a good point. Right, so, all righty. Well, thank you for coming on again, Mishko. Thank you, Jack, for joining us as well.

 

Jack Herrington:

Glad to be here.

 

Steve:

With that, we'll move on to picks. Picks are the part of the show where we get to talk about anything we want within Reason, of course. Doesn't have to be tech-related. Can be anything, books, movies, food, you name it. So we'll start with AJ today. What do you got for us, AJ?

 

AJ:

Well, I've been playing tears of the kingdom. I spent about 20 hours so for the weekend on the big bow quest Uh, I don't know if Is I don't know if

 

Steve:

That's... Is that the new Zelda game? Is that right?

 

AJ:

Yeah. Yeah,

 

Steve:

Okay.

 

AJ:

I don't I don't know if that's good or bad, but

 

Dan:

Which system

 

Jack Herrington:

Ah

 

Dan:

are

 

Jack Herrington:

ha!

 

Dan:

you using

 

AJ:

it's

 

Dan:

for it, by the way?

 

Jack Herrington:

switch probably

 

Dan:

Are you using

 

Jack Herrington:

with system.

 

Dan:

a switch?

 

AJ:

Well, yeah,

 

Dan:

Okay.

 

Jack Herrington:

I think

 

AJ:

let's

 

Jack Herrington:

it's the only thing you can use.

 

AJ:

go. Yeah,

 

Dan:

Okay.

 

AJ:

it's the only thing. It's Nintendo, man. We're not PC gamers over here. Zelda is not a PC game. Where have you been at? You're too old, Dan.

 

Dan:

I'm not,

 

AJ:

You got to get with

 

Jack Herrington:

Oh

 

AJ:

the times.

 

Dan:

let's put it this way, I don't know how many of, I actually worked in the video gaming industry for a while. How many here can say that? That being said, I'm actually totally not a gamer. I don't know, I just don't enjoy it that much to be honest.

 

AJ:

Yeah, I'm not a gamer either. I only own Nintendo. So,

 

Jack Herrington:

Oh

 

AJ:

so

 

Dan:

I

 

AJ:

when

 

Dan:

only

 

AJ:

people

 

Dan:

own Nintendo

 

AJ:

ask me.

 

Dan:

and spend countless hours on it, but I'm not a gamer.

 

AJ:

It's look it's

 

Dan:

Ha

 

AJ:

been

 

Dan:

ha!

 

AJ:

a very long time since I've since I've sunk time into a game. So yes, I am a Zelda er when a Zelda comes out. I will probably sink some time into it and tears of the kingdom. I don't know. It's it's such an addicting game. I don't know if that makes it a great game. I really like it, but I'm also it's been 10 years. I want. Is it has it been 10 years? I think it's been 10 years. I want a Triforce and iron boots and left-handed sword. I in a green tunic I Want I'm hoping that the next game I'm glad that they did here's the kingdom, but I'm hoping that the next game is Got a story where you need to finish one thing in order to progress to the next to some degree They broke the formula a little bit with link between worlds where you could go to any of the seven dungeons in any order But no matter which one you went to there was something about having an item from one of the previous dungeons that would have helped you in that dungeon had you had it and so there was still a little bit of I Don't know but I'm so tears the kingdom is bittersweet for me as excellent as it is I I'm craving a traditional Zelda game with Triforce, Rescue the Princess, Boomerang, Left-Handed Sword, and Iron Boots for good measure. But I'm glad that they made this the greatest hits. They've got the Poe quest. They've got the Glee. I don't know how you say it. The three-headed dragon that hasn't been in the game since the original game and the like 85 or 87 or whatever it was. So, but. But, uh. I apparently they beat every record for game sales. They did

 

Jack Herrington:

Oh

 

AJ:

something

 

Jack Herrington:

yeah.

 

AJ:

like 10 million sales in the first weekend. So it's the most that any game has ever sold ever. And it's, it's great, but it is, it's hard to pick a path.

 

Jack Herrington:

Yeah.

 

AJ:

It's, it's like, they want you to be a DD, which I guess is great. Cause Because the generation of children raised on phones, that's all they know how to do. No offense to everyone that I obviously just offended.

 

Dan:

So you're basically saying that

 

Jack Herrington:

I think they

 

Dan:

there's

 

Jack Herrington:

know.

 

Dan:

a point in the game where what's his name, Link, basically pulls out the mobile phone and starts walking around the world, ignoring everything and just looking at his phone.

 

AJ:

That actually is part of the game.

 

Steve:

Hahaha

 

Jack Herrington:

I was gonna say that's like Final Fantasy, but okay.

 

Steve:

All right. Is that your pick AJ?

 

AJ:

Yeah, that's my, that's my,

 

Dan:

Well,

 

AJ:

my bittersweet pick.

 

Dan:

he doesn't have time for anything else.

 

AJ:

I don't

 

Steve:

That's

 

AJ:

have time

 

Steve:

what it

 

AJ:

for

 

Steve:

sounds

 

AJ:

anything.

 

Steve:

like for sure. I could see your wife and your kids, daddy, no, I'm sorry, I'm playing Zelda, man. I'll get to you later.

 

AJ:

sometimes.

 

Jack Herrington:

Mwahahah

 

Steve:

All right, Dan, your turn. What do you got for us?

 

Dan:

Yeah, mine is not that much fun and it's less a pick than an unfortunate observation, statement of a situation. So at the time of this recording, the Israeli government is starting to pass a set of laws that are going to transform us from a vibrant democracy into something that's starting to look more like... a government which is not a democracy and more starting to look like some sort of dictatorship, maybe not quite yet, but not a democracy either, and legitimate elected government into an illegitimate regime. And as a result, tomorrow, with a lot of other Israelis, I'll be doing a lot of demonstrating in the streets. And hopefully we'll make it back home safely by the end of the day. We will see. And that's my unfortunate observation for today.

 

Steve:

Okay, so moving right along with that cheerful note, I'll try to resurrect things with the dad jokes of the week. For those of you who aren't familiar, I offer amazing dad jokes that I receive accolades from all over the world. It's just truly amazing. So first of all, question, why didn't Han Solo, Star Wars for the uneducated, enjoy his steak dinner? It was chewy.

 

Jack Herrington:

Uhhhhhh

 

Steve:

That's gross. I know.

 

Jack Herrington:

I'm sorry.

 

Steve:

Second one, this is more of a piece of advice. Never use a double negative. They're a big no-no.

 

Jack Herrington:

Shhh

 

Steve:

And finally, this is a story from when I was job interviewing a couple years ago. The guy who was interviewing me says to me, your resume says you take things too literally. And I said, when the heck did my resume learn to talk? All right, so those are the dad jokes of the week. Jack, your turn. What do you got for us for picks?

 

Jack Herrington:

My pick for the week is monkey type. It's a site that you can go to that will help you learn how to type faster and more reliably. And I've been doing it for, I don't know, a couple months and it slowly kind of builds you towards being a better typist. And I mean, I learned to type when I was 12 or something like that. And it's terrible. So I started to learn some better habits and become more reliable typist, which is certainly helpful when you're doing a lot of screencasts.

 

Dan:

Yeah, if there's one thing that I'm kind of annoyed with the school system, and it seems to be the case in the school systems of essentially almost every country, is that they don't teach touch typing. And I

 

Jack Herrington:

Yeah,

 

Dan:

just don't understand

 

Jack Herrington:

yeah.

 

Dan:

why it seems like such a useful skill to have.

 

Jack Herrington:

In my generation, they did but they did it with selectrix,

 

Steve:

Right.

 

Jack Herrington:

which were insanely loud typewriters back in the day.

 

Steve:

Yeah.

 

Jack Herrington:

And I'm pretty sure that part of my hearing loss is because

 

Steve:

Ha ha ha 

 

Jack Herrington:

of huge rooms full of selectrix on bang, every time that you know, anyway, typed.

 

Steve:

Yeah, that was one class that I never took. It was an elective and I wished I had, because I've started to learn to type by necessity and it's not the prettiest thing.

 

Jack Herrington:

Yeah

 

Steve:

Monkey type. Alrighty, and last but not least, Mischko.

 

Dan:

I think it's excellent that somebody who's so involved in the framework world, in the building of frameworks has this mentality. I think that

 

Jack Herrington:

Yeah.

 

Dan:

we constantly strive, seems to be that we strive to make the developer experience easier and simpler. And certainly, a lot of videos that Jack does show how quickly you can create really sophisticated things, but at the same time... It also shows that a lot of these things are still pretty complex and require a lot of knowledge in order to get right.

 

Jack Herrington:

Yeah, I think,

 

Steve:

Yeah,

 

Jack Herrington:

you know,

 

Steve:

I mean.

 

Jack Herrington:

primary framework authors, sometimes they that's their job all day long, every day is to build this framework. And so they live in this kind of ethereal world, like, oh, functional programming, and this and that. And, you know, when it comes to actual like boots on the ground, people building an e commerce site, right? What does an effect mean? I what is that? You know, what is that? And so that there's this kind of disconnect and it's and you end up needing people that kind of teach. teach and build that bridge between those things. And it would just be a whole lot easier if the framework authors were kind of in the world of actually using their frameworks kind of daily. And so they can just see that those are the issues and being in discord and seeing people ask like, What the heck is this? I don't even understand. You know, because I'm like, God, I have, wow, I have a lot to teach some framework authors about how these things are used.

 

Steve:

Yeah, you know,

 

Jack Herrington:

I misunderstood.

 

Steve:

it's interesting when you talk about design, there's a couple of things that sort of strike me. Mishko, you mentioned the book about everyday things. My wife was watching a news piece from CBS this morning the other day, I think it was last night that I happened to see it. And it was talking about how we design roadways and sidewalks in such a way that they prevent pedestrian deaths and automobile accidents. And there's so many little things that you don't. think about when you see a road. The one example that stands out to me from this particular piece was having space between the sidewalk and the street. So you have a little bit of a buffer, something, a car goes off the road or something like that. Little things like that you normally don't think about, but when you start looking at it, it's design. And I think the other thing of design that's always struck me, as I mentioned that earlier, is When you're designing, are you designing to fix an issue right now and address that issue right now? Or are you designing in such a way that you can do that and also think down the road, okay, is this design going to be short-term fix, but if I was to design for ways that people might possibly use something, how am I going to design it? Is it going to be totally different? One of the things that I think that people don't appreciate is that they're not going that was designed in such a way that has certainly had very long-term uses of the IP system, IP addresses. You know, that was designed, what, late 60s, early 70s?

 

Jack Herrington:

Mm-hmm.

 

Steve:

And to this day, it's still the way the internet is addressed, right? And we had to go from IP4 to IP6 just because of there's so much use of the system, but it's worked for so long. And it was fortunately designed in such a way that it was able to be somewhat future-proof. Right. And so for people that are designing and trying to think ahead, if you can get it right, Hey, my hat's off to you because that's gotta be, uh, very difficult to, to be able to do something that addresses a need, but also future bruises for down the road. So that's the end of my rambling and babbling. Thank you again, Mishko and Jack for coming on. It was a pleasure to have you.

 

Jack Herrington:

Happy to be here.

 

Steve:

And we will talk until next time on JavaScript Jabbr.

 

Dan:

Bye.

 

Jack Herrington:

Bye.