Today, Steve talks with Lane Wagner, creator of boot.dev, and online programming school. After getting distracted by the fact that Lane's first name reminds Steve of "Better Off Dead", they discuss how the concept of functional programming is or isn't actually used in the composition API in Vue 3, along with the awesomeness of Vite and Lane's experience in upgrading from Vue 2 to Vue 3.

Hello everybody and welcome to a thrilling episode of Views on View. I am Steve Edwards, the host with the face for radio and the voice for being a mime, but I'm still your host. Today I am flying solo again and I have a special guest with me. His name is Lane Wagner. How you doing Lane?

 

Doing great, thanks for having me.

 

So as a little bit of background, I also am a panelist on the other dev, top end devs, excuse me, podcast JavaScript Jabber, and we recently had Lane on to talk about a number of things that had some crossover to View 3, and so I thought this would be perfect for views on view, seeing View 3 in view and how that all nicely fits together. So I thought, let's talk about some of that great stuff here too. So before we get started, Lane, why don't you tell us, excuse me, who you are, what you do, why you're famous, and a little just your background.

 

Yeah, absolutely. So I'm Lane Wagner. I am the founder of Boot.dev. As of just a couple months ago, I've gone full time on Boot.dev. It's a e-learning platform for back end development in Python, JavaScript, and Go. It's been a side project for a couple of years. I've recently just started focusing on it full time, like I mentioned. And our front end is written in Vue 3 now. We recently did a migration from Vue 2. And so I have a lot of opinions on the view subject.

 

So what's your, I'm always a geek into the details. So what's the full stack for boot.dev? I think we talked about Go yesterday. So is Go on the backend with Vue 3 or?

 

Yeah, there's a couple moving parts. So we use Hugo to build the

 

Oh really?

 

static site for our blog. So our

 

Oh.

 

blog actually gets quite a bit of traffic. It's basically where most of our students come from. So that's a static site. Hugo's a Go compiler for static sites. The front end of the application itself, so instead of blog.boot.dev, but boot.dev proper, is a single page app written in view 3. We're not using any frameworks like SSR frameworks at the moment, like Nuxt or anything, though we may end up moving that way at some point. So it's just deployed on Netlify as a single bundle. And then it reaches out asynchronously via fetch requests to our backends, which is hosted on Kubernetes. It is a Go rest API that is backed by a Postgres database on GCP.

 

So if you're not using SSR, how do you handle SEO concerns? Is it good enough as it is for JavaScript frameworks? Or do you use Netlify's pre-rendering service?

 

We do use Netlify's pre-rendering service, which works okay. I do think we would get some benefits by going the SSR route, which is why we were thinking, that's like really the only reason we're considering at some point moving to a Nuxt or something like that. But to be perfectly honest, our app, like boot.dev proper, at the moment I'm not super concerned about ranking it. I mean, it would be nice. but the blog is kind of what ranks and drives a lot of inbound traffic. So that'll probably be a project for 2023.

 

So curious as to your choice of Hugo versus, you know, Nuxt maybe or maybe some of the other frameworks out there as a disc, cause it's been old and around and solid as a rock and something you're familiar with or what was your logic there?

 

Good question. So I started on WordPress about three years ago when I started blogging, just for the simplicity of the whole thing. Um, it was nice having a CMS. Um, I moved us to Hugo when we rebranded to boot dev. So we weren't originally the, the, the blog used to be called Q vault. Um, and when we kind of released the product, which was the courses, we decided to find a more fitting name. So at the same time that we rebranded the site, I re-architected it because I'd been reading a lot about static sites. Obviously, they're very, very fast. They're not very complex. A lot of things get, when you're a developer, a lot of things actually get much easier moving away from a CMS because, for example, now when I want to make updates to all my blog posts, they're all just plain text markdown files that I can grep through or do whatever I want. Whereas, when I was on WordPress, it would be fairly complex SQL queries, dealing with kind of the inner workings of WordPress. So that's been really, really nice. But the reason I chose Hugo over say Jekyll or Gatsby or one of the kind of equivalent static site generators is that it's very, very fast, much, much faster in terms of building and hot module reloading. And it's written in Go. And I'm, Go is my primary language. So

 

Oh, that

 

familiarity.

 

would explain it. Hugo, right. I'm sure that's

 

Yeah,

 

where that came

 

yeah.

 

from, right?

 

Yep.

 

So, and then one last question before we get into our topic of the day. Have you ever seen the movie Better Off Dead?

 

Oh yeah, John Cusack,

 

Yes,

 

right?

 

a cult classic, love it, have it on DVD.

 

Hehehe

 

In fact, I have some younger friends that I occasionally enlighten on that movie because they've never seen it. And it always blows my mind that people haven't seen it. But anyway, so all that saying, the main characters, the name there of course is Lane Meyer. So when I hear

 

Yes.

 

Lane, that's always the first thing I think of.

 

That's a great one. Also one crazy summer. If you

 

Yes,

 

haven't seen that, you should. Very

 

oh

 

good.

 

of course that's awesome. A very very young Demi Moore or Demi Moore however she says it. The classic stand-up, one of the ultimate stand-up comedians Bobcat Goldthwait you know with his very unique style and of course John Cusack. The interesting thing here though and we're going to go down this rabbit hole a little bit is John Cusack when he first saw Better Off Dead hated it and to this day will have nothing to do with that movie. They'll have get togethers, um,

 

What?

 

with all the cast, you know, booger from, uh, uh, from Revenge of the Nerds, uh, Curtis Damaris his name in the movie and I forget his real name. Um, and you know, uh, Diane, I forget her name that they played the French girl and everybody, but everybody but him will get together and he hated it. And when he, for whatever reason, uh, when he first saw it, he was like, oh, this is a piece of crap, I don't like it, it's awful, yeah, he won't have anything to do with it. And he had to do One Crazy Summer, which was the next one they did because he had already signed a contract with Savage Steve Hall and the director. So that's the only reason he did it. But yeah, One Crazy

 

That

 

Summer

 

like breaks

 

also.

 

my heart a little bit actually to hear

 

Oh,

 

that

 

I

 

story.

 

know, it's so disappointing, it just breaks my heart. But yeah, Cusack's sort of gone off the deep end in the last few years, at least from what I've seen. He's got so many good movies. from back then, you know, Gross Point Blank and stuff. But yeah, and then what's even more interesting is you know the Camaro? If you remember the black Camaro, you know, that he fixes up.

 

Yeah, yeah.

 

So there used to be a website that I found a long time ago and I don't think it's still around. It was called Better Off Dead Camaro and it was all about that car and it had the information on shooting locations and stuff. And apparently after the movie, they had just let it go. somewhere and dumped it somewhere. And some fan of the movie found it and restored it to its former glory and he's got it. Last I saw it, it lives in Durango, Colorado. And I have a friend who lives there and she said, yeah, I think I've seen that car around like at car shows or something like that.

 

That's awesome.

 

But it's sort of funny. Yeah, I love that movie's got more good one-liners. I once built a bird house in Woodshop and it was condemned by the Fair Housing Committee. You know, I have two shirts. I have one that my kids have given me that says, I want my $2 and shows the newspaper boy. And then the other one says, you know, the K-12, go that way really fast. If something gets in your way, turn, you know, so. Anyway,

 

So

 

all that

 

good,

 

because

 

yeah.

 

of your first name, you should feel really honored that your name triggers such great memories.

 

Yes, I feel great.

 

So, onto the topic of the day. So, the topic that we had initially discussed was regarding View3 and functional programming, and whether or not the Composition API truly is functional programming, and we were comparing it to React hooks. I know that came into the discussion as well. So, since this is your baby, I'll let you talk on the background and your thoughts on that, and we can go from there.

 

Yeah, sounds great. So I'll kind of recap. Actually, the discussion yesterday on JavaScript driver was great and now has got me thinking even more things. But the premise goes something like this. I don't think that the, that, you know, Evan Yu and the maintainers of Yu have necessarily made any claims that I think are incorrect about functional programming. But the composition API, I think, and the way the community has talked about it. And maybe this is just bleed over from React Hooks because the two, the Composition API and React Hooks get compared a lot because they're quite similar in terms of moving away from class components. The word functional programming is thrown around quite a bit when talking about the Composition API. And I think that's a problem because I don't think the Composition API is very functional at all. The, you know, if you look at the setup function, for example, in many components, in many stateful components, the setup function doesn't take parameters, right? Yet every time the stuff in the setup function is happening, values are changing, right? The things that the setup function returns that are being exposed to the template change as state updates internally, which is like the complete antithesis. functional programming. The whole idea behind functional programming, I would argue the biggest idea behind functional programming, is that you compose pure functions where every time they're called, assuming they've been given the same inputs, you get the same outputs. And I love functional programming to the extent that it's possible to use it because it makes really easy code to test. So pure functions are notoriously easy to write. unit tests for. You never have to, you know, mock anything. You never have to inject dependencies. It can be really, really a straightforward suite of tests. So that's kind of the, I guess that's how I would explain the kind of the overhead of the problem.

 

Okay, so. As you've been saying, it's not the view creators that have claimed this to just support the view community and saying, hey, this is really functional. So why is that a problem?

 

Yeah, I think it's a problem of terms. The way we talk about things, development and programming is a huge, huge field, huge industry. And the term functional programming has always had this definition that I think most of us have agreed on. It's what powers functional languages like Haskell, OCaml, F-sharp. And it's something you learn in a CS degree. You learn what functional programming is, why it's important. And I teach it to newer developers on boot dev because I think it can, when used properly as a tool in your tool belt, result in much better software. Even though I've never worked professionally in a purely functional language, I've always encouraged my team to write pure functions as often as possible. Again, mostly for testing purposes. So... I just want to make you like, the fact that like the composition API isn't like functional isn't necessarily a problem in and of itself. I just wish we had a better word to describe what we're talking about. So for example, I like the composition API more than I liked the class based API. Like I do think it was an upgrade. And I'm happy that we moved away from classes.

 

That's the options API. Sorry, I

 

Yes,

 

think that was

 

sorry.

 

the name.

 

Yeah, that's the name. So I'm happy that we moved to the Composition API. But just because the Composition API is based on functions, specifically the setup function, I don't think that that's a good enough reason to start using the term. functional programming. I think we're conflating some words there. Honestly, the big problem is just one of confusion. I think we're confusing ourselves, and more particularly, we're confusing newer developers that are entering the space.

 

Okay, so if it's not appropriately being named or labeled as you say, how would you appropriately name or label what it is?

 

Composition API is a great name. And I would just describe it that way. The post on, I think it was put out by Evan Yu, like on vuejs.org, that describes the benefits of the Composition API is spot on. It's all about composition. In fact, I think that the name Composition API is better than the name that React used with React hooks, because it more appropriately describes the benefit. in terms of now, instead of having one mounted lifecycle hook as a method on an object, we were able to use the on mounted function as many times as we want so that we can compose our logic around the business logic of our application rather than around the specific lifecycle hooks. So I think that's a great way to talk about it. You know, things like custom hooks, or sorry, it's not, that's the React term. What do we call them? Custom composables in Vue, where

 

Composables,

 

we,

 

right?

 

yeah, kind of the custom composable functions that we would like start with the word use, right? Not, they're not, they're not functional. Again, they're functions, which is great. That's totally fine. But it's not really a step towards functional programming. And, I encourage as much functional programming as we can get within view. So I do think that we should be writing, um, in our view code, many more pure functions, placing them outside of, uh, the scope of the, you know, object that we're exporting in our view files. Uh, and, and, and just using that pure logic as much as we can, again, kind of the main reason being it's, it's easier to test, it's easier to understand. if functions aren't sharing state between themselves.

 

Okay, so let's go back a little bit here. You mentioned that the, I think if I understood you correctly, that in view three, the view version of a functional program would be composables. Did I understand that correct?

 

No, the opposite. Sorry.

 

Oh, the

 

So...

 

opposite. Okay, that makes sense. Because if you look at the definition of composable, it actually handles stateful logic, which means that the inputs and outputs are gonna vary every time you call it based on what's in state. which makes

 

Yes,

 

it non-functional.

 

exactly. This has always been my big gripe with when people in the community refer to Composition API or React Hooks as functional is that the main thing, custom composable functions, in React's version, use state and in Vue we have things like use store or whatever. These functions are the farthest thing you could get. from functional programming. There's objects and methods that are more functional than this.

 

Okay, alright. Alright, edit here. Alright, so where are we going with this? I guess, is there any more to say on V3?

 

I think this is, I think we've covered the important bits about functional.

 

Mm-hmm.

 

I think that maybe we could go down a route of like maybe what have been some of my gripes moving from view two to view three.

 

Oh, okay.

 

That migration might be kind of fun to talk about.

 

Okay, all right, let's end the edit. Okay, so now we've addressed functional programming in Vue 3. You've mentioned before that you've done migrations from Vue 2 to Vue 3, which I think the attempt to make that migration easier has been made, in particular, with the version release of 2.7, which has a backport of not everything from the Composition API, but... at least important parts of it. So I'm guessing that was a fairly recent, I think. So I'm guessing you did your migration before that was in place. So as someone who's gone through the pain of upgrading and it's not a small undertaking, what was your experience migrating from Vue 2 to Vue 3?

 

Yeah, I have a lot of things to say, both good and bad. So obviously in hindsight now, I migrated too early. I should have waited for 2.7 probably. We had to do a lot of things kind of all at once, because there wasn't this slower upgrade path. I think that specifically with 2.7, isn't it that they've kind of backported a lot of the composition functions into Vue 2, so that you can upgrade more? more slowly.

 

Yeah, I mean, the way I see it, as someone who's gone through migrations before, is that in completely different frameworks. But migration is still migration either way, is that what this allows you to do is implement composition API methods and functionalities in view2 in your existing code base, so that when you do actually do npm update view3 or whatever you do, then you have much less... to deal with from a migration standpoint, which I think is a great idea.

 

Yeah.

 

And I know, you know, Vue 3 was written so that you could still write Vue 2 code. You could still use the options API in Vue 3. But either way, you still got to refactor your methods if you're going to use everything that's in Vue 3.

 

Yeah, the big pain for me was dependencies. So we did, obviously, when we upgraded to Vue 3, we did not immediately rewrite, like we didn't rewrite all of our options API components into composition API before upgrading because Vue 3 is backwards compatible in that way. But we did have a lot of issues with some dependencies because a lot of dependencies, in fact, when we upgraded, I definitely think that, like, looking back, I did it a little too quickly. A lot of dependencies didn't support V3. So we either had to rewrite them ourselves or try to find V3 alternatives. So that was a bit of a pain, but that's pretty classic migration stuff.

 

Yeah, for sure. I mean, you mentioned WordPress. I came from the Drupal world and watching the migration from uh, six to seven, seven to eight was huge just because of a complete gut and a rewrite of the internals. And so, okay, core has done great, but how many of the things do we depend on in the ecosystem that have to be upgraded, you know, uh, from a, from a front end framework, from a front end, uh, system, they're just now getting caught up, uh, as of this. writing for instance, Vutify 3.0 just came out this week, first part of November. And I know another big one is Bootstrap View, and that's still being worked on too. And so that's holding up some people from being able to upgrade. So yeah, the surrounding ecosystem is huge when you do a major upgrade like that.

 

Yeah, yeah. So this is where we get to my first gripe, I guess, is we spend a lot of time and resources upgrading to Vue 3. Obviously, that doesn't actually, that almost in no way provides business value to boot dev. We're just trying to keep our technology up to date. No users of boot dev were super excited to hear that we were on Vue 3. But the bigger concern I had was you know, we spent all this time upgrading, and now I have a concern about fracturing in the, this is actually a concern in Vue and React, but a fracturing of the possible ways in which you can accomplish something. One of the things I really like about the Zen of Python, that pithy poem, is ideally there should be one way to do a thing, and that way should be good. It doesn't necessarily need to be the best way. but it needs to be a good way, and there should really only be one, because it gets really confusing, I think needlessly kind of confusing when there's many different ways to accomplish the same thing. So, like, from that perspective, I really don't like that we now have an options API and a composition API that are drastically different in terms of the way the code looks and, you know, how many things you have to understand. So now, new... View developers being onboarded, they don't have to just learn one thing. They have to almost learn twice as much, because almost any project they enter could have both Composition API components and Options API components. So the scope of things you needed to learn to be productive in View is now much larger. So is that worth the trade-off? I'm not necessarily convinced that it is. Like I said, I do like the Composition API. I do like it better. but I don't know if I like it enough, I don't know if I like it enough more, enough better. That's like a really weird way to say things, to warrant that scope creep of the framework. And now there's like a third way, which is like not nearly as big of a difference, but you can write the script setup syntax, which is again, just like slightly different from writing a giant setup function. Again, it's better. I like it, but now there's three ways to write your component. And I find that needlessly confusing. Not being a maintainer of you myself, I understand that I'm coming from a place of ignorance, so forgive me for this. But I really would have, like in my head, it would have made a lot of sense to release a new framework and just call it a new framework and do it a different way. Maybe that's impossible for other reasons, but.

 

You think the changes were big enough between new and three that it's almost a completely different framework?

 

I don't know. But what I do know is I don't like the backwards compatibility with the options API. I understand that it's being offered as a feature. And I think a lot of people will see that as a great thing. I don't. Like, I wish there weren't multiple acceptable, like, undeprecated ways to do things. I think that there should be basically one way to do things. And maybe that means just a maybe a major upgrade, maybe it means a whole new framework. But I guess I'm just complaining about the current state of affairs and I'm not very useful because I don't necessarily have a solution to it.

 

Yeah, it's a sticky wicket for sure, to use a British phrase. I think it's, maybe it's Australian,

 

Hehehehe

 

I'm not sure. But either way, yeah, I mean, that's a tough balancing act from a framework standpoint. I think what's gonna happen and what I've seen happen, you know, around the open source community. or I'd be willing to bet is as they go along, then that older stuff will be removed, you know, as people have had time to adjust to the new way of doing things. Because otherwise, you know, obviously you end up with a very bloated code because you gotta maintain everything going forward. That's my guess, you know, I don't speak out of any inside knowledge or anything.

 

That's my hope. I guess now I do have something concrete to complain about. That's my hope, is that it's like, okay, we have a five-year transition plan, in which case I'd be much more comfortable with this, like, we'll keep it view, right? We'll keep it view three. There's like a five-year plan to deprecate the options API. But I wish that that was more transparent, because right now, both React and Vue, as far as I can tell from reading the official docs, have claimed that there is no plan to deprecate. options or class-based APIs and that they will be there. They're just as they're just as Supported as like the newer stuff which to me seems wrong Like the whole reason for this new stuff was to replace the old stuff So I feel like we should at the very least encourage people to be moving albeit. Maybe, you know slowly and responsibly

 

Okay, so other than that, Gryphes, what other issues, I think you mentioned before, you had some good and bad, so what was your migration experience like? Maybe, for instance, did you go from Webhack to VEET? Or

 

Yeah.

 

other parts of the upgrade?

 

I can't remember if we went to Webpack from Webpack to Vite before or after migrating to Vue 3. I know it was around the same time. I have nothing but good things to say about Vite. It's just been so much better. So Webpack was slow. That was a huge problem. I mean, the boot dev code base at that time wasn't huge, but it would take like a good 10 or 10. 12 seconds to start up. And then hot module reloading would take a second or two. And now with V, startup is instant, sub one second. And hot module reloading is measured in milliseconds, which is just our productivity has gone way up. But that's only part of it. People always talk about the speed. That's great. But actually, the thing I like even more about V is how non-configurable it is. Like, you'll hear this. If you talk to me a lot, you'll hear this pattern. I hate diving through endless options in different ways of doing things. Like, I just want some same defaults that work out of the box. And that was probably my favorite thing about moving from Webpack to Vite, was instead of just having this nasty Webpack configuration, it pretty much works with a very basic... kind of eat config file.

 

I think the term there is opinionated.

 

Love it. I love opinionated. That's how you can tell I'm a Go developer. Go is very opinionated in the way the environment works and everything.

 

The other framework that comes to mind is Ember. I haven't worked with it, but in any discussions I've heard about it, Ember is very highly opinionated in terms of everything, like your folder structure, and this goes here, and that goes there. So there's not a lot of wiggle room. And for, as someone who's... multiple times had to learn new tools and new frameworks. Having something opinionated when you're first learning is awesome, because you're like, okay, I don't have to worry about, figure that, I just do this and do this and it works and I can go code my app. And then as you, you know, maybe as you go along and get more experienced and know what's going on, then you like something that's, you know, gives you a little more flexibility to do things the way you like to do it, you know.

 

Yeah, I mean, so at boot dev we teach several different programming languages, JavaScript, Python, Go. And I think a lot of times when someone spends a lot of time in one programming language and then moves to another one, I think that very often a kind of a trap is, that people fall into is taking all of the things that you're used to from your old programming language and trying to shove them into the new programming language. Right? Where you, like usually that's not the way to do it. Sometimes, sometimes truly the old programming language you're coming from had some great ideas that maybe should exist more in the new one. But I think very often it's actually the case that the new programming language works in a different way and is good for different things and you should figure out what those things are. And... I forgot where I was going with this, but I'm used to the opinionated way of doing things, and I just wish every ecosystem I was in was opinionated in the way that made sense for it to be. You know, Vue has a very specific use case, so I feel like it should be able to be opinionated about that use case.

 

OK, so we got View 3, we got Vite, Migrate. So out of curiosity, when you went from View 2 to View 3 on your application, what were you using for a front end structure, your CSS and your forms and all that stuff using a framework

 

Oh yeah,

 

like

 

I could.

 

a Vutify or Bootstrap or just plain vanilla CSS, maybe some SCSS?

 

That's a good question. We were on SCSS at first, and I actually ended up moving to Tailwind, which if you're not familiar with Tailwind, first of all, I highly recommend it, especially for smaller projects. But I think Tailwind often gets misappropriately compared to Bootstrap or Vutify. And there's a very key difference in that Bootstrap and Vutify have opinions about styling, right? They come with same defaults. Tailwind is not. Tailwind is not a styling library. It doesn't come with like, you know, it won't make your app pretty out of the box. It's the way I think of Tailwind and the way I use it is actually just a way to write cleaner CSS and a way to write CSS a little faster. That encourages kind of good. good CSS practices. So that's why I use it. I don't think it was a part of like our upgrade to view three. I want to say we switched to Tailwind actually, maybe even before we upgraded to view three.

 

Tailwind, I mean, it has some predefined stuff in terms of, for instance, its color palette. but you can override those if you want to. You can add your own custom colors and make them available, CSS classes, which is pretty slick. And then they also have the add-ons of hero icons and what's the other component library? I can't

 

I'm not

 

believe

 

sure.

 

I can't remember it off the top of my

 

I

 

head.

 

customized everything right out of the box. To me, the selling point was the utility classes, right?

 

Mm-hmm.

 

Like instead of, you know, with Bootstrap, you have like a button class or whatever that like kind of bundles everything into like one class. It's like, no, I just have like, it's like the way you would have written the CSS anyway, but it's just like sane names for the classes, right? Like P1, P2 for paddings and things like that. So you're right. They do have some, some defaults that you can use. I actually never even. used them so I kind of forgot that it had them. I immediately like

 

Hehehehe.

 

put my branding colors in there and and all that stuff so.

 

Cool. Any other maybe little details about your upgrade that you can

 

Oh

 

think

 

yeah,

 

about?

 

let me whine about view three for a second. So even

 

We're back

 

though,

 

in wine mode.

 

yeah, we're back to complaining. So like I said, I do think view three is, the composition API is an upgrade generally speaking, but that doesn't mean it's not worse in some ways than the options API. My big complaint, my biggest complaint when moving from view two to view three. is the dot value syntax that gets really cumbersome and in my opinion, cluttery throughout the code. So in view two, you know, everything was on the class objects. So you like for your state and for your computed properties for everything, you'd just be doing this dot kind of the name of the property all throughout your code. In view three, whenever you're dealing with a ref, like a computed property, for example, the way you unpack that value in your setup function, is by using the dot value property on that variable, which is immediately just also a little confusing because in the template, you don't have to do that. The template automatically unwraps refs. The setup function does not. So that's inconsistent to me and just feels weird. And I'm sure there's a billion technical reasons that the maintainers had for doing it the way they did, but as a user, I'm just whining as a user, that's been one of my biggest gripes. And to go along with that, one of the most confusing things was moving from view two, we just lazily took our state object and wrapped it in a reactive, the reactive function from the composition API that makes it reactive. And when you do that, when you access and change the state variables, you don't use dot value as like a getter. But again, you do for a computed property. And really early on in the ecosystem, when we were using Viter, for example, It didn't even get mad at us if we didn't add that dot value to the, to the properties that we need or to the computed like refs that we needed to add it to. So we had tons of bugs in our code where it was just like painstakingly going through the component and trying to figure out which properties or sorry, which variables needed that dot value access or in which ones didn't. That was painful. That was probably the single most painful thing. about Vue 3. And it's better now with Volar, the new VS Code plugin, but the code is still fairly verbose.

 

Cool, or maybe not so cool. I guess

 

Hehehehe

 

that's just sort of my jump in word there. All right, cool, man. Yeah, yeah, I've messed in the little that I have messed around with, with view three and the setup function. That value thing was something I kept bumping my head up against and had to be reminded if I had that value to access your method there.

 

Yeah, like I said, it was really painful in the migration. Writing new components, it's not so bad. You kind of get used to it. And Volar is the new, so, even you, I guess, has come out and kind of officially deprecated Viter as the recommended view plugin for VS Code, and now Volar is the new one. It is kind of cool in that it actually auto-completes the dot value for you. If it detects that you're using a ref, it'll just throw that. kind of onto the end. It's actually thrown me off because I'll just start typing.value and then I have two.values.

 

Ha ha ha 

 

That's a problem. But yeah, I would recommend using that plugin if you're in VS code. I think, well. Yeah, I don't know. Again, I wish I understood the internals a little better. I wish I had time to understand the internals a little better so I could understand that decision because it does seem to be fairly painful. And I know that in React, you don't have that, but the way React hooks work and the way composition API works are fairly different. So.

 

Okay, so before we move on to picks, anything else you wanted to cover that I'm not thinking of? I think we've been fairly exhaustive.

 

Yeah,

 

Hopefully not

 

no,

 

exhausting.

 

this has been fun. It's good to air my complaints, and I'm sure... Well, I don't know if there's a comment section anywhere where this is posted, but I'm sure I'll be ripped apart in comments somewhere.

 

Maybe on Twitter or something like that. Oh my gosh.

 

You can

 

Right.

 

at me on Twitter if you have complaints or can point out why I'm wrong. I'd actually love to be told why I'm wrong so that I can do it better.

 

Right. Okay, well, that's been a good discussion. Like I said, it's so good we did it on two, count them, two podcasts. So with that, we will move on to picks. Picks are part of the show where we get to talk about. other things if we want to or we could still talk about tech things, books or blog posts or you name it. Before I get to the high point of every episode which are my dad jokes, one pic that I did have and I thought this was interesting. Discussion being had here recently in the past couple days I happen to see it when it about 30 minutes after it came out because I happen to be looking on Twitter, but There's a new web pack. I guess replacement Being touted and it's called turbo pack. So the packs the same it's just I guess turbo makes it faster and turbo pack is touted as The web excuse me the rust based success for successor to web pack and they put out a blog post That basically said making the claims that measured against VEET. It is 10 times faster than VEET and it talks about architecture and and the fact that it's based on rust and so on and so of course Evan you the creator of VEET got wind of this and did some testing on his own and created a GitHub repo with a discussion where he goes into great detail about his tests and how he'd tested and benchmarked things and his opinions on the claim that TurboPak was 10 times faster than Veed. And his conclusions were, yeah, maybe if you got up to 30,000 modules, but that's an extremely unlikely scenario for the vast majority of users. And when you're using... RSC versus SWC, which I am not that low level enough to understand to be honest, then no, it's really not a fair comparison. And TurboPak apparently got wind of this and made an updated blog post and clarified some things. So anyway, I will put a link in these show notes to the blog post and the GitHub repo and you can read the results for yourself. So with that... Dad jokes of the day. Today's dad jokes is actually a comparison of deep thoughts for any of you who remember Saturday Night Live and deep thoughts with Jack Handy. This is sort of along those lines. Hold on, I gotta get my drumstick out and make sure that I'm ready to go. So first of all, in limbo, setting the bar very low means you're actually setting the bar very high. If you think about it, okay, you know, putting the letters okay together is a stick figure lying on its back. And, where are you is a question that has never been asked in sign language. think about it because you can see the, anyway. I know the joke loses it when you have to explain it, but I thought that was worth it. And then, you know, I was thinking about, you know, careers and hobbies and stuff, and I thought, you know, I really should think about becoming a tightrope walker, because even the bank says my balance is outstanding. And then finally, this is a sort of story that came from my daughter. She's working on her teaching degree. And she was in class one day taking attendance and she comes across this name that spelled H-I-J-K-M. And she's sort of confused. She says, I'm sorry, I'm not sure how to pronounce this name. And she spelled it out. And one of the girls in the class raised her hand and said, that's me and it's pronounced no L. because there was no L in there. Anyway, I love that one, it's so good, so good. If I know some girls, I know a girl named Noelle, I'm gonna tell her she should try that sometime. Anyway, those are my picks. Lane, your turn, what do you have for us for picks?

 

I'm hoping I'm not destined for those jokes now that I have a daughter who's 20 months old. We'll see.

 

Oh, dad jokes are a must. My daughter loves them. She shares them with me. In fact, I have a dad joke calendar on my desk that she gave me for Christmas. So it's good when they share with you.

 

That's awesome. Let's see, yeah, picks. All right, first thing. Oh, I just need to plug the fact that Vite uses ES builds. Is it ES build or roll up? Crap. Now I'm going to say things that are wrong.

 

It uses Rollup for the bundling and ESBuild for the HMR.

 

That's what it is. And yes, build, I believe, is the one that's written in Go. That's why it's fast. So just gotta plug my favorite programming language again.

 

Yeah, I guess you could say it goes very fast, right?

 

Yes, go goes fast. It's the name of one of the chapters on boot dev. Anyways, okay, plugging boot dev. I'm definitely gonna do that for one of my picks. If you're interested in backend development, so obviously you're interested in frontend development, which is fantastic, but if you're interested in more, getting more of a full stack, rounding out your experience, so to speak, with some full stacks and backend, we'd love to have you check out boot dev. Python, JavaScript, and Go. So that's gonna be one plug. The other pick I'm going to make is Better Call Saul. My wife and I just finished it. Weirdly enough, we haven't finished Breaking Bad. We got three seasons in and we thought it was okay. We got distracted by something, probably The Witcher, which we also liked, but Better Call Saul has been amazing. So if you have, I think it's Netflix or Amazon Prime or whatever, that's a really good one.

 

Yeah, interesting enough, I myself have never watched Breaking Bad. Um, there's probably a number of things that people would say, what? You've never watched this, you know, like the Sopranos or. some of these other well-known series, but my son, who's just 20, recently binged it. And so I'd jump in and sort of watch little pieces here and there and he'd explain to me what's going on. So I'm a little more up to speed on what it was and how it works and stuff, so I'm familiar with Saul. You know, if I understood it correctly, the, better call Saul a sort of before and during, breaking bad, is that right? Is that how it works from a timing standpoint?

 

It's kind of a prequel. At the very end, it really starts to kind of tie into the events of Breaking Bad. But

 

Okay.

 

yeah, the first couple seasons, you wouldn't even know that it really had anything to do with Breaking Bad. It's all just backstory on Saul, the sleazy lawyer.

 

Right. Or as,

 

But yeah, it's

 

as,

 

good.

 

as what's his name? Jesse in Breaking Bad says, you don't need a criminal attorney. You need a criminal attorney, a criminal who is an attorney. Right.

 

Yes, exactly. Oh, it's so good. And you know, the thing that I love about it, you'll really like it if you love shows that have just amazing character development, like not just Saul, but almost every character in that show just has an amazing, you know, development arc to who they are. And so that's what I really loved about it.

 

Yeah, I've seen Brian Cranston, the guy that plays Walter White, interviewed a number of times on Dan Patrick show, which is a sports talk show that I listened to. And he's talked about, you know, that show. And it's sort of funny how the way he even got it was that, if you remember the show, The X-Files, with David Duchovny and Jillian, I forget her last name. It was a big paranormal show back what 90s early 2000s. I think anyway, he did a bit part, you know on one episode you know, he's a guest character whatever it was and One of the people that happened to work on this show was the Creator director of Breaking Bad his name starts with a V. I forget his name Vincent or something anyway, and It was ten years after the X-Files appearance that he started breaking bad. And he remembered Bryan Cranston from that back and really liked that far back and really liked him and said, hey, do you wanna do this show with me? And he said he read the script and he was like, oh yeah. Yeah, and this is

 

Ha ha

 

after

 

ha!

 

he had done Malcolm in the Middle

 

Yeah.

 

with Frank

 

Yeah.

 

portray him in Malcolm in the Middle going to Walter White. And you're like, whoa.

 

That was actually part of the reason my wife didn't love Breaking Bad. And part of the reason we ended up giving up was she's like, I just can't, he's the Malcolm in the Middle dad. Like, I just can't get

 

You just

 

over

 

can't

 

this.

 

see him as a different O, right?

 

Yeah, I'm sure

 

You know,

 

he'd hate to hear that.

 

yeah, the guy that, that to me has always stood out, who's been really good along those lines of Bryan Cranston, who's, you know, you've seen him in such incredibly different roles to me is John Lithgow. Um, and he's not like a really crazy, well-known, uh, uh, actor. He will, he used to be a well-known, but there's three different things that I think of one, there's a movie called Ricochet that has Denzel Washington. as a cop and as a district attorney and iced tea as a bad guy. And Lane's looking this up on IMDb right now. And he plays this crazed serial killer who gets put in jail and gets out of jail and hunts down dens at Washington and that whole back and forth. And just a crazed lunatic. Then you go to Third Rock from the Sun, which was the TV show that was on for years and completely different character. And then you think of even before that, first time I can recall seeing him, he was the dad in Harry and Henderson's but go back to Footloose, where he's from 84 with Kevin Bacon where he's the pastor and how the pastor is portrayed, that's a different story. But if you look at the different types of roles and how versatile he was in those different roles and how well he did them, that sort of reminds me of Bryan Cranston between Malcolm the Middle and Breaking Bad. You get some actors, boy. We're probably going down the movie route today, aren't we?

 

Hehehe

 

You get some actors who are like, no matter what role they play, you can tell it's them. The ones that come to mind are like a Nick Cage or a Hugh Grant.

 

Yep.

 

No

 

Tom

 

matter

 

Cruise.

 

what character or movie they're in, they're always sort of the same. They're really different versus someone that can really stand out in very different roles. ["The Last Supper"]

 

Yeah, couldn't agree more. I wasn't actually, I mean I recognize John Lithgow now that I look him up, but I can't think of many movies I've seen him in, so maybe I'll have to go check him out.

 

Well, you young whippersnappers, you know, haven't been around that long. I guess that's confusing you sort of an old school guy from when I was growing up for

 

Yeah,

 

sure.

 

this list is long of stuff that he's in.

 

Yeah, for sure. All right, well that has been another good episode, so we will put a wrap on this baby. Before we go, how can people contact you or follow you or give you money if they wanna give you money because they like you so much? How's all that happen?

 

Yeah, so first and foremost, if you want to give me money, then

 

Hehehehehehe

 

you should hopefully, hopefully you can also get some value out of it over on boot.dev. That's the name of the website, but also the domain name. So if you want to learn backend development, head over to boot.dev. And then you can always find me on most social platforms at Wags Lane, that's W-A-G-S-L-A-N-E, primarily on Twitter. But you could also follow me on LinkedIn, pretty active there. And then my personal website where I post blog posts that sometimes aren't about tech, you can find at wagslane.dev. Same handle, but.dev.

 

So out of curiosity, last question. How did you come up with the name boot.dev? Is it just because

 

That's a good question.

 

it's languages that you use when you're booting up your computer or?

 

We really like the name for several reasons. It kind of conjures up several images in my mind, at least. One being boot camps, which is kind of tongue in cheek because we're not really a traditional boot camp. We're more of an e-learning platform. But I digress on that. Yeah, booting up computers was one that we thought was interesting. Oh man, there were a couple others that I can never remember. Do you remember Alan? Bootstrapping. Oh yeah, it's a bootstrapped company. That was something that we thought was kind of funny. And then the.dev obviously is the kind of the developer part of the name. And it's just,

 

What?

 

it's a great domain name. Four letters was kind

 

Oh yeah,

 

of cool.

 

it's hard to find those anymore. But with all the new top level domains that are available, it's a little easier than it used to be when it was just.com,.net and

 

Mm-hmm.

 

you know, what other, you know, funny enough, when I think of the term boot, two things came to mind when I first saw it. One was that's the British term for a trunk of a car. You know,

 

Huh.

 

you put things in the boot, but it was also a term that I used to hear when I was in college about vomiting after drinking too much. So, you know, take that.

 

We have wild after parties. All of our course releases, yeah.

 

All right, all right, good deal. Well, thank you everybody for listening. I hope we did not, I hope we were able to actually entertain with the digressions down the movie routes today, but it's fun. We don't hold ourself tightly to too many guardrails here other than as long view being discussed at some point in the process. So with that, we will wrap it up and talk to you next time.