Lane Wagner is the founder of a startup company called Boot.dev. He teaches backend development online in Go, Python, and JavaScript. Lane joins Chuck and Steve as they talk all things Functional Programming. They also talk about its importance and share their thoughts about it. Moreover, Lane also shares his experience with creating boot.dev and the different teaching strategies he uses on his online learning platform.  

Hello everybody and welcome to another thrilling, exciting episode of JavaScript Jabber. I am Steve Edwards, the host with the face for radio and the voice for being a mime, but I'm still your host. Now with me, our normal host is here today, Chuck Wood. What's up, Chuck?

 

I have a little bit of a sore throat thing going on, so

 

So yes,

 

not

 

I am covering

 

talking

 

for

 

a

 

Chuck

 

lot.

 

today. Yes, I'm covering for Chuck today while he is feeling under the weather, but we got to give him kudos for being here today and showing up and doing the job. So we appreciate Chuck. So with that today, we will introduce our special guest. His name is Lane Wagner. How you doing, Lane?

 

Doing great. Thanks for having me.

 

Our pleasure. So Lane is here. And before I forget, also, I was sometimes I forget to introduce them. But I'd also like to say hi to our studio audience. So how you doing, everybody? Okay, great, yeah, they're always there in the background but I always like to give them kudos. So anyway, Lane comes to us courtesy of our own AJ O'Neil and he knows AJ, we haven't determined if that's good or bad yet, but we shall see. So before we get started, Lane, why don't you give us a little intro, tell us about yourself, why you're famous, what you do, who you do it for, et cetera, et cetera.

 

Yeah, super famous. So I'm the founder of a new startup called boot.dev. We teach back end development online in Go, Python, and JavaScript. It's kind of a 0 to 60 back end development career path. Who I do it for? At the moment, I do it for me. Hopefully, that ends up working out. I've been full time on the project for about two months now. It's been a side project for about two years. So it's been a lot of fun.

 

OK, so we are here to talk functional programming and what is and what is not and whether things are functional or whether they're not. AJ and Lane had talked about this topic a little bit, and so we'll just let Lane give the intro where this came from and where we want to go.

 

Yeah, absolutely. Kind of a high-level overview of the discussion. So AJ and I were at lunch a few weeks ago. And as we all probably know, React and Vue have made big changes over the last couple of years. React introduced the new Hooks API. Vue with Vue 3 released the new Composition API. And now I've been reviewing the claims made And I don't actually think that I have any bones to pick with the claims made by the teams themselves. But that said, the discussion from the community surrounding hooks and Composition API have been that they enable functional programming, that they are more functional than the old class-based kind of way of doing things. And I do take issue with that. I don't think that that's true. recently wrote object-oriented programming and functional programming courses. And kind of the first controversial thing I have to say is I don't think functional and object-oriented paradigms are actually in conflict very much, even though you don't see things like classes and objects in purely functional languages. But we can dive into the specifics of maybe why View 3 and React Hooks, and it might be easier just to take the example of View 3. or React Hooks, I don't know, whichever one we prefer, and start diving into details of why, why they're not functional in the first place.

 

OK, well, before we go down that road, let's define

 

Yeah.

 

terms for a minute. I think, you know, anybody who's been in programming will know object oriented programming, functional programming. I don't think people know as well. So let's start out with defining terms. What would we mean by those two, those two terms?

 

Cool, I'll give my definitions. Hopefully they align with your guys' definitions. So when I think about functional programming, the most important thing, if we think about like Haskell, for example, a purely functional language, then the most important thing is this concept of pure functions. So functions where the inputs and the outputs are deterministic. If I put the same inputs into my function, I should expect to get the same outputs. mutating global state. Ideally, I kind of have taken all of my IO, these pesky real world details, and shoved them in some corner. And the rest of my program can be purely functional. So that's kind of what I think about when I think about functional programs.

 

Yeah, I was going to say a lot of the like Elm, for example,

 

Mm-hmm.

 

on the web, people go out and they tout how it's functional, it's purely functional, the whole thing is purely functional. And it's like, no, it relies on side effects because it's on the web, right?

 

Yeah.

 

But yeah, they shunted off into, you know, this corner. And so you have to be deliberate about your side effects. It doesn't mean they're not there. It just means that we recognize that we need them. And so we are going to give you a mechanism to have them. but we're going to restrain them so that the rest of the code can be purely functional. Thanks for watching!

 

Yeah, I mean, purely functional apps would be really, really boring. They wouldn't be able to do much cool stuff because you wouldn't be allowed to do things like persist to disk or

 

Lots of

 

make

 

recursion.

 

network calls. Yeah, and the code would be, I mean, I don't know. This is debatable, but no iteration makes code hard to read, says Lane.

 

Okay, so then how do we define object-oriented programming?

 

So the way I think about object-oriented programming, there's kind of four pillars or four main topics. The first is encapsulation. So you want your classes and your functions and things to be like black boxes, right? Good principles of encapsulation, you're writing good APIs. Second principle that's very tightly coupled to encapsulation is abstraction. Are you abstracting at the right level in your code? The third thing is inheritance. It's my least favorite part of object-oriented programming, being a Go developer and not a game developer. I tend to have, I seem to have fewer use cases for inheritance. But then polymorphism also super, super important. The idea that you can write, for example, an interface that many different types implement. The idea of duck typing in certain languages falls nicely into the category of polymorphism. So when I think of object-oriented programming, of like, am I practicing good rules of encapsulation and polymorphism and abstraction, things like that.

 

It's funny that you reacted to inheritance the way you did, because what I find is that the more experienced a developer seems to get in an object oriented language like Java or Ruby, the more they kind of reach for constructing objects instead of inheriting them. just because

 

Yeah.

 

they're more predictable.

 

Yeah, it is about predictability. I have a hard time. I think that inheritance is appropriate. And there are certain domains where it makes a ton of sense. Like building games and having, for example, you've got a unit type. And then maybe you have a soldier that inherits from a unit. And then you've got an archer that inherits from a soldier. I feel like there are definitely domains where it makes a lot of sense. Being a web developer, I've actually like never had like a real use case for inheritance, like literals and structs and things like this seem to just make so much more sense when I'm trying to just, you know, get data from a database and back to the UI.

 

Yep, I agree.

 

OK, so what is it that you see? Obviously, there's some things about OO that you don't like. And the object-oriented versus functional debate has been raging for a long time, years. It's probably one of those things, like anything else in web development, where you see pendulum swings,

 

Mm-hmm.

 

whether it's the stacks you use, and the tools you use, decoupled, monolith. Here we've got object-oriented. for a long time, and then we're to functional, and that debate's always going to rage. So it sounds you prefer functional over object-oriented. Is that what you're saying? Is that your take? Or is that each one has its appropriate use cases? And that, in some cases, maybe object-oriented, like you mentioned in games, is better, whereas maybe other times functional is more appropriate.

 

So this is like, I guess my first controversial take is that I actually don't think that they're really at odds with each other. I think that, you know, good developers, good engineers can take kind of the best parts of each and that those best parts don't really conflict too much. So as an example, Go, the language I do most of my work in, doesn't have objects or classes, but it does a pretty good job, especially now that generics have been implemented, of supporting these other three pillars oriented programming, like the fact that I can encapsulate things nicely within a package and behind an API, that I can get good levels of abstraction through that encapsulation, and then that through interfaces and generics, I can have kind of polymorphic reusable code. Really the only thing missing is inheritance, which again, I would argue is that's not all of object-oriented programming. It's maybe a shame that object is in the title of object-oriented programming, but if you like in an OOP class, only one of them really has to do with like the concept of classes. So if you kind of just ignore inheritance for a second, like those three concepts are not at all in conflict with the idea of like pure functions and immutable state, which is really, I would argue, that kind of the big important idea from functional programming. The only thing about object-oriented programming that fights with pure functions is the idea of mutating an existing object. If you were to, say, define a function that takes an object as input, does a change, and returns a new object, great, now you're back to following the rules of the function.

 

I segued right into that one. That was good. And

 

Hehehehe

 

I didn't even plan that. OK, so now I guess the point that we discussed at the top of the episode that we wanted to get into was view through and react hooks. And

 

Yeah, let's

 

if

 

start

 

I understand.

 

the React bashing.

 

Yeah

 

And so what you're saying is they claim to be functional, but to your eyes, they're not really as functional as they claim to be. Is that correct?

 

I actually don't think they're claiming that it's functional. I think the community is. So I don't want to put words in the React team's mouth. But yeah, I think there's been a big misunderstanding that especially newer developers that are learning hooks for the whole time or for the first time and are learning that the old class-based way of doing things is evil, it's the old way. I think there is part of that sales pitch that's wrong, which is that hooks are functional. And if we want to jump right into an example, is the best example of this. So you've got, with React Hooks, the idea is your component is a big function, right? And every time the page renders, this function reruns. Like the core tenant of functional programming is that when you have a function, it has inputs and outputs, and for the same inputs, you always get the same output. But the useStateHook in React is a function that returns two things. the value of the state that you care about. So say you have like some input on the screen, so like a username input. So you've got the username value, and then you also get back from this useState function, a setUserName function. And every time the component runs, the values you get back are different. That setter is the same, but the value for username changes as the user is typing. So it's like the least functional thing Like, I actually can't come up with something that's less functional than React hooks at their very core.

 

Okay.

 

So when they came out with React Hooks, I was frequently on the React Roundup podcast. And it's funny to me still because I really haven't written that much React. I've written React Native a bunch, but not React itself. But when it came out, they, yeah, I mean, effectively what changed was that keyword, right? Because your stuff all lived in classes. Your components were classes. they're just not really structured that way. In fact, I think the key word now that you wind up seeing is function. And

 

Thanks for watching!

 

so, especially for the hooks. And so, I think people just kind of assume the mental model without, you know, understanding all of the implications of it. And so, yeah, I think it, I think you could make the case that it's possibly more functional. in that class. But I mean beyond that, I mean React is all about the side effects because it's all about the UI. And so

 

Yeah.

 

I don't see how it could become, you know, move much more in the direction of being functional without causing you some major headaches getting done what you want to get done.

 

To be clear, I think React Hooks are better than the old class API. I just think that a lot of the discussion around React Hooks

 

Oh, that's for

 

is

 

sure.

 

wrong.

 

That's

 

Yeah.

 

yeah, it's definitely easier to reason about. But my point is, is that if they had made it, you know, if they adopted too many more of the functional programming ideas and tried to, you know, sit them on top of React, React's a UI library and it just wouldn't work.

 

Yeah, I think, I mean, I completely agree. The bone to pick I have is with how we talk about it. I don't think that, you know, React Hooks is a bad way of doing it. I do have, like my complaints with React and with Vue and the way they've done things is more one around fragmentation than like how the changes were implemented because now it feels like we have, you know, two giant ways of doing things, Python fan, like I am, I'm a big fan of like kind of having one way to do things. There should be one good way to do things. It kind of sucks when we start having more and more good ways to approach the same problem.

 

Okay, so then the other framework that you mentioned was my tool of tools view and view three. Now, is this the case, a similar case where it's not so much that the team said it's functional, but the community seems to be pushing dysfunctional programming or what's the, where's the discrepancy lie with view three?

 

As far as I can tell, it seems to be the same idea. And I think Charles is right. Like at the end of the day, React Hooks and Vue Composition API are functions. Like they are functions, the keyword is function. And so if that's the definition of functional that we're using, then yes, they definitely are more functional, right? I think the problem arises when, you know, people coming from like a, which programming paradigm are we talking about? That's when it gets a little more confusing. So with Vue, with the Composition API. Basically, we've moved away from this class-based way of defining components. We're doing it with a function. That composition function, it's the setup function, is a little different than the React one. It doesn't run, it's not like the whole function runs every time the render happens. To be honest, I'm actually a little more fuzzy on exactly how often it runs and the way you can define things in there doesn't necessarily have to be in order. But again, It's not a pure function. Like the setup function doesn't, like the arguments it takes are props. It returns things for the template, but every time it runs, theoretically, the state's different.

 

Yeah, I think composition API is actually a better way of putting it. And I kind of wish that React had named React hooks something like, you know, React composition hooks, because yeah, when we're talking about the paradigm, the paradigm shift was the way that you compose these systems, right? And it works through composition, right? You know, the reality is, is it's easier to reason about what's going and you know it's easier to reason about what's triggering the hooks but at the end of the day I mean that's all you're doing is you're just composing a set of hooks based on what's going on in the app and so it doesn't have to do everything it doesn't have to do all the work and it's not encapsulated in classes which people don't reason well about in JavaScript anyway and so anyway that that's the that's the advantage I'm seeing so I I think view aptly named what they were doing when they moved to composition API because it It really does reflect that hey, we've got these pieces that we're going to stick together in these meaningful ways We're going to make them invented so that it makes sense

 

Yeah, I mean, I completely agree. I just went back and watched the React Hooks announcement talk at ReactConf, I think it was 2018. And the main value propositions, there were three main value propositions for hooks. Yeah, one was composability, which I would argue is the biggest one. The fact that now you don't have to shove everything within lifecycle hooks at the top level, you can make as many lifecycle hooks as you want. That's number one. Number two is reusable state, which I like that you're able to do it now, although some of the nastiest code I've ever seen is like, giant React hooks that are getting, like, custom React hooks that are getting reused across components. But I don't think we can blame the library too much for just our bad application code. And then the third thing was just that classes, the claim was classes are confusing humans. Like the way this works in JavaScript is frankly confusing. So, you know, I don't really have any issue with those three like main value propositions of hooks and the composition API. you

 

So

 

Yeah,

 

right, I think.

 

the other issue you brought up was having both ways of doing things right. I'm not necessarily opposed to having more than one way of doing things. If one better expresses certain kinds of code and the other better expresses the other kinds of code.

 

When

 

If

 

would you

 

the

 

use

 

two

 

a class

 

diverge,

 

component?

 

yeah, nobody uses class components anymore

 

Ha ha!

 

in React. But my point is that, you know, for backward compatibility, I'm upgrading I can see them maintaining it but yeah if the two diverge in capability or something between you know between versions that's where you're gonna have the problem right where you can do something with the the functions API that you can't do with the classes API

 

Yeah, that's my big concern. So if you go look, I mean, the last time I went and checked, both of you and React are taking the same approach of, we are never deprecating classes, and we're going to support both indefinitely. I mean, I like, I love the idea of backwards compatibility. I almost wonder if this should have just been a new framework. Like, you don't even call it React anymore. It's just something new that if you want to, because yeah, the idea of

 

Angular.

 

going Yeah.

 

Angular 2, right? Anyway.

 

No, yeah, it's, it's, it's a huge problem, but the idea of like going forward, every library supports both APIs. It just seems like, I don't know, it just seems like a huge maintenance burden to me.

 

Yeah, unless you can stack one on top of the other, right? So the class API is just a thin veneer over the top of the functional API. Anyway.

 

Yeah, that's a good point. I mean, not that maintaining the library itself is my problem. My problem is

 

Right?

 

figuring out how to use things in effective ways for sure.

 

So, in what ways then are you finding, you know, the... Functional is being talked about that is a misnomer for the way that you actually compose apps, right? Because we've kind of talked our way around, hey, this is composition, not functional. But how are people talking about it in terms of functional programming that's incorrect? Or at least is going to lead people down the wrong path.

 

I think this is a bigger problem in the entry-level developer space, which is one that I'm very familiar with running boot dev. I work with a lot of people that are working towards their first job. And I don't think this is a problem at the more experienced JavaScript levels. I don't think when you talk to senior developers that there's any confusion about whether or not React hooks or the Composition API have Haskell-like properties in terms of being more purely functional. But I do think to newer developers, it can be really confusing. And again, maybe it's just a problem of terminology. Maybe functional programming is a bad word, is a bad term for this paradigm we talk about when we're talking about purely functional programming. Kind of like how I think maybe object-oriented programming isn't the best word to encapsulate all four of those things that are really important, encapsulation, abstraction, polymorphism. So I guess to answer your question more directly, I see it with newer developers learning that because functions are what's used in hooks, this must be what functional programming is. And I think that's potentially a big problem when you later in your career encounter the actual, I guess the older definition, I don't know, the more traditional definition of functional programming.

 

I feel like I'm hogging

 

Thanks for watching!

 

the mic. Steve, did you want to jump in?

 

Uh, no, I guess I just want to go back and clarify the question, uh, that's come to my mind when we were, you know, when we first started discussing this is, uh, and I think you might've already addressed it is, is this a problem and why, you know, that somebody is saying it's functional and it's really not, you know, it's, it's like, uh, I feel like I'm a kid in grade school sometimes, you know, when hearing some of the arguments that go on in the coding world, you said this, but it's not true. Well, okay, sorry. So if I understood you correctly, you see that the misnomer as being a problem more for somebody who's learning to code versus somebody who's more experienced and actually knows what's going on. Is that correct?

 

Yeah, I think it could be confusing to newer developers. And to be clear, yeah, really my only problem when it comes to this functional thing is how we talk about it. I have some other problems, like we mentioned, like fragmentation, but really when it comes to what React hooks are, what Vue is, and how it relates to functional programming, I feel like we have a problem of terms that's super confusing to newer devs that are learning React or Vue for the first time.

 

Yeah, I can see that with hooks. And I remember when the term hooks first came out, you know, it seemed to be, and not being a React Dev myself, but listening to other people talk about it, what React is defining as hooks seems to be a misnomer as compared to what hooks really are. You know, I lived in the Drupal world for a long time, as I've mentioned, and hooks were huge in terms of how modules were built and how interactivity between modules, what in WordPress you would call plugins, you know, whatever compartmentalization term you want to use. And so a hook was basically, okay, I'm coming to my point in the code. I want to create an opportunity for any other program, any other module, any other piece of code to interact with my code. So I'm going to put it out and say, okay, anybody that implements this function, function. And then maybe they just do something or they pass back some data or whatever. But the term was that they're hooking into the process. But yet the way React defined what they called hooks really wasn't hooks in that meaning of the term. Is that correct? Again, I'm not a Reactive, so I'm not familiar with how they really work. But I'd heard that said by other people that more familiar with it that, yeah, they're called hooks, but they're hooks in the classic definition of the term.

 

So like, and now you'll have to answer my question because I'm not as familiar with WordPress. You're kind of describing like life cycle hooks. Is that correct? Kind of like when X happens, here's a callback and I'm gonna do this thing. Kind of like the view life cycle methods or the react life cycle methods. So, I'm gonna do this thing. I'm gonna do this thing. I'm gonna do this thing. I'm gonna do this thing. I'm gonna do this thing. I'm gonna do this thing. I'm gonna do this thing. I'm gonna do this thing. I'm gonna do this thing. I'm gonna do this thing. I'm gonna do this thing. I'm gonna do this thing. I'm gonna do this thing. I'm gonna do this thing. I'm gonna do this thing.

 

Yeah, sort of. Um, you know, the ones that you're talking about are the life cycle of a component, right? When it

 

Mm-hmm.

 

gets created, when it gets mounted before destroy, after destroy that kind of stuff in the life cycle of a component, a hook to me could be at any point in the code process, maybe not in the mount or unmount, but anytime some code is running and that's what, you know, think about as like plugins for lack of a better term, you know, I think when Drupal went, when Drupal went to symphony in version eight, that's plugins. was the way to hook into a process. It's basically saying, hey, I'm at this point in my code. Do you want to do something here? Great, let's go ahead and do it. So yeah, it's basically lifecycle hooks, but just in more than just the lifecycle of a component. So

 

Yeah,

 

anyway.

 

I tend to agree with you. I like the naming is a bit confusing. It's a good thing I went back and watched that talk from ReactConf because when, I think it was Dan Abramov was introducing hooks, the reason that he gave for the naming of hook was because before React hooks came out, you could write functional components in React. They were just like really silly and kind of useless because they couldn't do anything with internal state. So you could write pure, maybe, I guess this is kind of ironic. You could write pure functional components before hooks came out. You could write a component that just took props and deterministically rendered something on the screen, which is a very purely functional thing to do. What Rehacked Hooks enabled was for you to not do functional things. It's a way to hook into the state. So the reason he used the term hook was like, OK, now with the useState hook, we can management of React and do that within kind of a functional. So I think that's where the term hook came from. But yeah, to me it's non-obvious. I wouldn't have known that without reading, watching.

 

So it is hooks, but not in the classic sense of the term, I guess. But React being the big dog has sort of said, OK, we're going to use hooks whether it's a hook or not. Now that's what everybody thinks of when they think of the term hook, at least in terms of React or in terms of JavaScript.

 

Yeah, it seems that way. And I mean, it's kind of funny that we're having this discussion and like, you brought up the fact that like, well, wait, what's the big problem here? Well, I guess at a certain level it is one of naming, but like, what other problems are there in programming? Like naming things is like the hardest part of programming.

 

Well, no, remember the two hardest things in, I always use this adage because it's so true. The two hardest things in programming are cache and validation, naming things and off by one errors.

 

Right.

 

So, you know, so yes, naming is very important.

 

Yeah, couldn't agree more. So that to me is like the ultimate irony. The fact that we had functional react components, albeit they were very useless. And I guess this comes back to like the whole functional programming discussion of like, well, is functional programming even useful? Like we do have to manage state a certain level. And Elm is a great example. Like Elm is really trying, like they're doing their darndest to be a functional framework for like front-end UI development because the UI that they're treating, all the nasty bits about front-end development, things like asynchronous network calls. And they've put that all in the corner. And they've said, OK, you can do this data-fetching stuff. But every time you get new state, we're going to have a pure function that takes the entire internal state from your app and renders something deterministically to the screen. So again, I don't use Elm. I've messed with it and read about it, and I think it's interesting. But like it is much closer to what functional UI programming would look like in my opinion than what we've got with React Hooks and the Composition API.

 

Yeah, one of my former co-panelists on Views on View, Lindsay, has left View and is living in the Elm world

 

Okay.

 

and has talked about how it's, as I understand it, functional, using the functional paradigm for programming. Again, I haven't had a chance to delve into Elm. I guess you could say I haven't been barking up that tree. But yeah, that's my understanding

 

If you did,

 

of Elm.

 

it would be a nightmare on Elm Street.

 

Yes it would.

 

Thanks for watching!

 

Thank you, Chuck.

 

You're

 

So

 

welcome,

 

anyway,

 

I know you like the dad jokes.

 

so actually, OK, going to throw in an edit here real quick, so whoever's editing this. So we wanted to talk about, I don't know, was there anything more you wanted to go down that road? Or there were some other, all the, I still don't understand AJ's line of questioning about JavaScript and Python and Python being a terrible back end language.

 

I think he's referring to boot dev in this line of questioning. Like, why do you teach Python if it's terrible for back end?

 

Yeah, that's

 

Okay,

 

fine.

 

do you want

 

We can pivot

 

to go down that

 

to

 

road

 

boot

 

and just

 

dev.

 

talk about boot.dev then?

 

Yeah, yeah, and if you want, we can transition via the fact that like I use view to to to write boot dev whatever you want to do.

 

Oh, OK, sure. Yeah, we've got to get you on Views on View, by the way. We're going to do this because I need guests

 

Yeah.

 

anyway.

 

Cool.

 

OK, let me think about this for a minute. OK, here we go, end of the edit. So we've been talking about View and React and functional programming. But we also mentioned earlier, you mentioned at the beginning of the podcast that your current thing is boot.dev. And I believe you mentioned to us, that it was actually written in Vue.

 

Yeah.

 

So I'd be curious to hear about boot.dev, both in terms of what you're teaching and what tools you're using to teach and also the tools that you use to build boot.dev.

 

Yeah, absolutely.

 

And white pick view.

 

So,

 

I'm just kidding.

 

Ha ha ha.

 

great question. I picked view actually, because I wanted to learn view.

 

I'm gonna disconnect Chuck right now, I'm kidding.

 

It, it, it, it, I'm just kidding.

 

Wait, are you a React fan? I have to know what your overview alternative is. stimulus.

 

wire stimulus anyway continue

 

Isn't

 

this

 

stimulus what

 

is

 

Alpine

 

about your

 

came

 

thing

 

from?

 

not my thing

 

Okay,

 

what

 

Chuck, correct

 

fair

 

me if

 

enough.

 

I'm wrong, but didn't Alpine come from stimulus? Was that right? Or am I remembering

 

maybe

 

things wrong?

 

stimulus was written by DHH, the guy who wrote

 

Oh, okay.

 

Rails.

 

Rails, yeah, okay.

 

And

 

Oh, that's right. You're in the rails world. Okay.

 

it's more along the lines of like, I don't want to say jQuery, but the ideas are, it's super simple and you just kind of sprinkle your JavaScript in where you need it so you're

 

Right,

 

Got it.

 

yeah, that sounds like.

 

wire up your controllers to an element in the HTML, and then it will work off of the HTML from there. And so then you just write JavaScript functions that are triggered by events and that's it. And

 

Right,

 

it just

 

that's

 

listens

 

very much

 

in this

 

the

 

little box.

 

Alpine paradigm

 

Yeah.

 

for sure. We've actually had him on JavaScript, Java last year

 

Yep

 

and PetitView is trying to address that type of thing too. And yeah, that's a whole different road we can go down. But

 

Yeah.

 

anyway,

 

Anyway.

 

he's stimulus lane.

 

Okay, well, for my next project, I'll be working in stimulus. But I did start in View 2 mostly to learn View. There were some things that looked pretty cool. I really liked the idea of single file components, to be honest, I think that was the main draw for me. So anyways, started in View 2, we made the upgrade to View 3 probably early, but I'm a big fan of staying up to date on things. of when we update. But boot dev is an interactive coding platform. So you write Python and JavaScript and go in the browser, so it needs to be very interactive. So a static site generator wasn't going to work. I needed something that could do a lot of JavaScript, do a lot of interactivity. So that's why I chose Vue 3. My experience with Vue has been fine. I haven't really run into many like slow down the business to, you know, do an upgrade. That albeit I like the code better now, it just wasn't that big of a deal to me. But yeah, so boot dev, let's talk about that.

 

Actually, real quick, I thought

 

Yeah.

 

that's an interesting point where you talk about migration. And the app that I work on a daily basis is huge in terms of hundreds of components and so on. And that's been one of the sticking points, is the migration. But I'm not sure if you're aware of this, but when View 2.7 came out a couple of months ago, two or three months ago, I believe, it was a backport of a lot of the View 3 stuff into View 2.

 

Hmm, yeah.

 

A lot of composition API function. But if you look at the release notes, it's basically a backport. And so I think the point of that is to make migration easier, because you can implement stuff in Vue 2.7. And then when you go to Vue 3, you don't have quite the large leap into the whole

 

That's

 

Composition

 

way better

 

API.

 

than I've seen other frameworks

 

That sounds

 

do.

 

amazing, yeah.

 

Yeah, yeah, yeah.

 

Because

 

So anyway, I just thought I'd make that point.

 

yeah, I've seen

 

No,

 

some

 

that.

 

frameworks take that approach, but Angular, when they transitioned, they set it up so you could side load AngularJS alongside Angular 2 or vice versa. And so you would then, as you upgraded your components, it would just run on the other engine. But the problem is you were effectively maintaining one code base that a whole lot like a schizophrenic two code based system. So.

 

Yeah, that sounds rough. I like what you're describing. I didn't have to do it obviously because we just kind of upgraded cold turkey, but the Python 2.3 split like was so awful for the ecosystem that anything we're gonna do to avoid that sort of situation

 

Yeah.

 

seems like a

 

Well,

 

good

 

what you

 

thing.

 

want is you want to be able to inch your way up as close to the line as you can so that when you flip the switch, everything just kind of keeps working and you have a minimum amount of work to do to get all the goodies from the new system.

 

Yeah, couldn't agree more. So I'm glad they're doing that now. I guess I did it the hard way. Cool, so that's how our front end works. The back end of boot dev is all written in Go. I'm kind of a Go developer by trade. And boot dev is all about training people up on back end development in Go.

 

That's why AJ likes you. You're a go guy.

 

Yeah, that's how we met. That was through the Go Meetup here. So AJ's question is around, why are you teaching Python? So we start, the way the boot dev curriculum works is we start students in Python. We teach things like basic syntax, how coding works, object-oriented programming, which is something we've been chatting about here, data structures and algorithms, that you would learn in your first year of CS education. And then we move into, fairly quickly, we move into some more practical stuff that has to do with what you would actually do in a back-end job. So we use JavaScript to teach what a back-end is. So you learn all about the fetch API and how to interact with a server. That's why we do JavaScript. It's very commonly people will look at the site and it's like, this is a back-end site, and then see JavaScript and go, oh, it's a place to learn Node. We actually don't do any Node, really. Because right after you're done writing some client code to interact with an API, you're building an API in Go. It moves pretty quickly through those three languages.

 

Yeah, I guess that's

 

Um,

 

one thing

 

yeah.

 

that I'm seeing a lot out there is a lot of the boot camps. I don't know that I'm aware of too many that are teaching Go. Initially, when I was seeing them come out, and I don't know if this is confirmation bias because I'm so heavily involved in the Ruby community or whatever, but a lot of them were teaching Rails. And then I saw a lot more of them start to take a React approach and realize that they didn't want to teach a different backend and frontend language. you know, they went to Node and Express. So I think it's interesting to kind of come at it from a different approach where it sounds like you're almost trying to teach them more the I guess the concepts and fundamentals of programming as opposed to here's how you spin up a React app as fast as you can humanly do it.

 

I mean, I think your first take was also true. Boot camps, I think, generally were Rails-based. And now they seem to be generally node-based and full-stack JavaScript.

 

Yeah.

 

One way we differ is that I actually, ironic, I kind of chose the name boot.dev tongue in cheek. It's not really a boot camp. It's kind of just like an online learning platform. Boot camps tend to be a little more cutthroat, skipping fundamentals. You mentioned the fact that we were taking a fundamentals approach that that kind of is the idea. But it's also important to point out we don't do anything front-end or full stack. It's just backend development and it's done through the lens of computer science. That's why we take that fundamentals first approach. We teach backend stuff and we have the luxury of not having to teach JavaScript as the primary language. If you're going to teach full stack development, you basically have no choice at this point other than to teach JavaScript, it feels like. Because you need JavaScript on the front end, you might And so the really nice thing about just focusing on training up back end developers is that we get to do fun things with Go. I don't know if you guys are Go fans or not.

 

Uh, no, you could say I haven't

 

I've

 

really

 

played

 

gone

 

with it

 

there.

 

a little

 

Yeah.

 

bit.

 

But, uh, so yeah, I guess I'd be curious to learn about go, uh, myself, the, the nearest competitor or similar language I hear about is rust, I guess. And the idea with go and rust obviously is, and Chuck's making faces at me. And that tells you how much I know.

 

Hehehe

 

Um, but I think the ideas behind go and rust, as I've seen them in the community right there, a lot there than a Java or PHP or maybe even a node. So could you give us, I guess, the high points on why go? What is it about that that makes it a popular, I guess, back-end language? And maybe is it geared mostly towards the web? I mean, would you use it in a non-web type of application,

 

Good.

 

et cetera?

 

Yeah, great questions. I'll try to do it from a Node and JavaScript context because after all, this is JavaScript Jabber. So the last place I worked, last several places actually, were Node and Go shops. Kind of used both on the back end. And the reason for that is, as you pointed out, we used Go for more compute-heavy workloads. So very often, the app team that was would build their own REST APIs in Node and be full-stacked developers in that way. But then, at a lot of the companies I worked at, there was this big data component of things going on. And there was a lot of compute-heavy stuff happening, and like ETL, extract, transfer, load data pipelines. And that's what we used Go for, because it was just much more performant on the CPU, because Go is a compiled language. There's no interpreter step. machine code. With that said, from a compute standpoint, it's not quite as efficient as a Rust or a C or a C++, because it's got this runtime that manages. It's a garbage collected language. But so its compute isn't quite on the same order of magnitude as a Rust or a C, but its memory is much, much lighter weight than the other languages in its speed class. C sharp that are often used on the back end for enterprise back end in Java, you can save a lot on memory resources by using a lighter weight language like Go. So to put it in a nutshell, we used JavaScript when IO was the bottleneck on the back end. If all you're doing is grabbing stuff from the database, making HTTP requests, you don't need a language like Go. I mean, you can use one. There's nothing wrong with it. But you can stick with Node if you're developers of JavaScript devs. But we swapped out our services for Go to be more compute efficient.

 

Mm-hmm. That makes sense. I think for me the reason that I kind of made a face when the comparison was made between Go and Rust is that you structure your programs differently. From one to the other. And the garbage collection to me is kind of a major difference between languages. I guess at the end of the day it's memory management one way or the other. gives you some ways of doing that to help you do it. But yeah, I just think of them in different classes of things, because Rust is super close to the metal, lightweight. And yeah, Go compiles that way, but it doesn't run that way in the same arena. But anyway, and I've only played with them I haven't done a ton with them. I think it'd be fun to dive in and see how far you can take it. But.

 

Yeah, I think Go and Rust get thrown together as competitors often, but in practice, I've actually never seen that happen, other than like there's the one famous blog post from Discord where they swapped out a Go server for a Rust server. The reality that I've found is that it's much more often that a C-sharp or a Java monolith is being

 

Mm-hmm.

 

migrated to a Go system,

 

Yeah.

 

again, for memory purposes usually.

 

Yeah, you get pretty major performance. advantages

 

Thank you.

 

that way. And you get a lot of the stuff that you're used to in a C sharp or a Java. Then you do in Rust. Um, one thing that I'm curious about though, you know, going back to

 

Thanks for watching!

 

boot.dev is, cause I'm working on a learning platform too, right? You go to top end devs and, you know, the,

 

Yeah,

 

the

 

I was

 

menu

 

just checking

 

options

 

it out

 

are,

 

today.

 

you know, podcasts, courses, workshops, meetups, you know, we're starting to move the needle on that stuff. We're putting on some conferences next year. Um,

 

Yeah.

 

know, we're doing a lot of the same things. And one thing that I'm curious about is that, you know, for me I'm much more focused on here's a technology and how to use it, right? And so, you know, I kind of lean a little bit more toward the boot camp thinking, I guess. But yeah, you know, so when you're teaching these concepts, these programming concepts, what's your approach to make people, make sure people really understand them? Because as I've gotten into like Pluralsight or Egghead or some of the other ones, they just give you a video and that's the end of it. And I feel like, you know, sometimes that works and sometimes that doesn't. And so I was just curious how that works for you and what you're doing over at boot.dev.

 

I love this question. I've done a ton of thinking on this subject. That doesn't mean I have the answers, but I've done a ton of thinking. So I think that video has a very important place in learning to code, but that it's been drastically overused because it's a simple thing to distribute. You make a video course, it's really easy to publish it wherever you want. You don't have to build like any complex platforms You can just publish an MP4 or whatever. I love video for certain things. I'm actually going back right now. Just a couple months ago, Boot Dev had no videos on it. It was all text-based, like markdown instructions, and an in-browser code editor. And then in between those interactive courses in the browser, you would do projects on your local machine. So you'd follow step-by-step text instructions, so like get VS Code installed, up and running and then you build something. Which I love that approach for like, I would say the 80% of things that you need to learn in programming. But I love video for like high level concepts. So I actually started publishing a few videos about things like how to count in binary numbers or like to visually describe how a binary tree works or something like this. That you don't like, yeah, you need to see the code with it later, but it's just really important to visually describe how some concept works, maybe visually drawing a stack or a queue or something like that. I think the best learning platforms in 10 years will be the ones that just do, like, use the best medium for every individual thing they want to teach.

 

Yeah. So I'm just going to pile on here a little bit because, yeah, I feel like for the most part, it's not just about here's how you, you know, code a thing in Vue or code a thing in React, right? People need to get their hands on it. They need to, you know, nail it down. They need to, you know, fiddle with it. And so two approaches that I've seen, and I like them both, one is that you provide them a Git repo and they can use whatever editor they want. But if I'm going to do that, I'm also going to provide a, hey, if you're taking any of our courses, go check out our VS Code course or whatever. So you have things set up so you can get the kind of feedback you need from your setup. The other one that I've seen is... Oh, I can't remember the name of it now, but it's the in browser editor that Eric Simons and Albert Pye put together, StackBlitz. And so people will

 

Yeah,

 

embed a StackBlitz

 

I've been talking to them

 

into

 

actually,

 

their

 

yeah.

 

app. And, you know, I've known, I've known those guys

 

Ahem.

 

for a long time, you know, from the Angular community, but yeah, so you embed it and then you basically have an interactive setup with your code in it. that kind of walks you through it. But yeah, for the videos and stuff, so the first course that I'm building, I'm building two of them, and one of them is how to stay current on technology, right? And so, you know, there's a lot of demo involved, but yeah, you're going to be using stuff that you're already familiar with, you know, Trello and junk like that.

 

Yeah.

 

For the other ones, resume and cover letter course, and it's an upsell if you go get my dot com slash resume. You just enter your email address and it'll email you and tell you how to get it. But then, you know, it'll give you some more information if you stay subscribed and it'll encourage you to go get the course. You know, and I'm not going to try and tell people on the course. I think it's fairly priced and I think it's good content, but you know, go check it out anyway. But the idea is, yeah, on both of those, I'm just to build your resume and write your cover letter, or to go do internet research, right? And so you already have a lot of the skills you already need in order to do the job. And so video on its own, along with, hey, come download these couple of templates, works great. But yeah,

 

Mm-hmm.

 

for the code, I just don't think people really understand it until they have spent some time working on it and thinking about it and understanding the concepts behind it. A few years ago, I came up with an acronym and it was Hello World. And basically it's writing code, you know, the oh, I can't remember what it was, but it was something with like committing code, right? So you're putting it up on your reading code. You're anyway, so you know, you're listening to podcasts, and you're, you're reading about it in blogs and books, right?

 

Mm-hmm.

 

consume it in different ways because each medium has its own strong suit, right? You

 

Yeah.

 

know, if you're reading a book about it, they can go into a ton of depth, right? On the concepts and show you code examples and the whole nine yards. If you're reading code, like code that people are actually using in production, then you get an idea of what it looks like for somebody to actually use the thing that you're learning, right? If you're committing code, then you're putting it out there for somebody to give you feedback. If you're writing the code, muscle memory, you know, if you're listening to podcasts, a lot of times we cover things at a high level and we can ask some of the questions that you would ask of the experts and you can pick up some of that stuff. So all these things kind of work together as kind of a learning system and I'm trying to incorporate a lot of that stuff in as I teach people.

 

Yeah, I think that's a good way to think about it. Like I said, I think there's definitely places where videos make a ton of sense. One of the things that I'm always very concerned about with my videos is skimmability. So when I take video courses, I tend to not

 

Mm-hmm.

 

for programming. But sometimes I do. And when I do, I really like ones that are broken up in very small clips Because

 

Right.

 

it's really hard to skim, like, free code camp, I love them. But they have like 12 hour videos sometimes. And it's just like really,

 

Yeah.

 

really hard to skim through that content. So I really like the idea of like small clips that are maybe organized in such a way that you can kind of get to the meat that you really care about.

 

Yeah.

 

You brought up another point in there that I think is really interesting and kind of fun to talk about. And it ties into, I think the discussion you guys had, it was just like one or two podcasts back with Kent Dodds

 

Mm-hmm.

 

about this idea of an interactive code in the browser situation versus build it on your local machine. And I have several thoughts here. The first is that I don't think you can get away from coding it on your local machine. You have to do that at some point. And that's why in boot dev, we've taken the approach of, basically, every other thing you do is a project on your local machine. of a

 

Mm-hmm.

 

guided project. But I do actually really like the in-browser editor experience, even though you make some trade-offs. So for example, the big obvious trade-off you make when you ask people to write code in the browser is that they're not in the environment that they're typically in,

 

Right.

 

which is especially painful for more experienced devs. It's

 

Mm-hmm.

 

actually not painful for new devs. They kind of like it. They don't have to configure things. before getting started. But it does start to, especially as you get kind of towards the end of, in the case of boot.dev, the end of the career path, it starts to get annoying being in the browser. But one of the big advantages of being in the browser is you can do things that you couldn't do otherwise. So for example, I can check people's, like I can check every step of the way if you're on the right path. So when someone's building a project

 

Right.

 

on their local machine, they're kind of verifying themselves, right? maybe, they're running it themselves. The nice thing about breaking things up into tiny lessons in the browser is, oh, I can check your code, tell you if you're doing it right, tell if you're doing it wrong. And then the other thing that's like, I guess could work on your local machine, but I don't think anyone's cracked this nut, is like, I love gamified learning. Like, I love progress

 

Mm-hmm.

 

bars and achievements and quests and this kind of stuff. Motivation is one of the, it might be the biggest and you can do all of that quite easily in like a sandboxed environment in the browser. That's something that's a lot harder to do, you know, when someone's kind of learning on their own on their own machine.

 

Yep, yeah, I agree. I mean, it could be interesting if you had, and this is just something that just popped into my head, so you know, it may be an insane idea, but having a VS Code plugin for each of your lessons or courses, right? And so then when you pull it in, it can check your work, right? And so as you write the blah, blah, blah test, you know, it has some script that it sticks into your app, spin it up in your browser, you know, it says, okay, you know, go ahead and click the button and then, but you can do that a lot of that with just a Git repo too. So anyway, there are definitely things you can do, but yeah, I agree with you. You definitely make those trade-offs and I'm so addicted to my Emacs keybindings at this point that

 

Hehehehe

 

it hurts to use stack blitz.

 

Yeah, yeah, I get that. I mean, so that's an interesting idea. I've never thought of the VS Code plugin. I have thought about a CLI tool that would do the things. So you

 

Yeah.

 

could have your instructions up in the browser, and you'd interact with the environment via the CLI to test, and you'd still get your achievements and crap that's happening over in the browser, but you get to code in your environment. That seems enticing to me, but again, hard? So maybe in the

 

Yeah,

 

future?

 

well, exorcism.io did that, right? So you run everything on there, exercises through, you know, through the browser or through the command line, sorry. And so it'll give you the, it'll give you the tests that you have to make pass, you know, in JavaScript or,

 

Mm-hmm.

 

you know, Elixir or whatever, right? But the issue is, is that, And it's not that familiarity with the command line is a bad thing, but yeah, if you're trying to get new people in, and in a lot of cases they're teaching fundamentals that new people need to understand, you know, then they have to figure out how to get onto the command line and install homebrew and install all the other things that you need for the language. And so it requires a level of setup that VS code just doesn't write because you can get with their language service and in some cases it actually installs the language engine for you and so yeah

 

It's almost like we need different tools for different types of learners.

 

Um, yep, I think you nailed that.

 

Yeah, but yeah, I definitely see this space hopefully getting much better over the next 10 years. I wish it were a lot better in its current state. It feels like it should be.

 

Yeah, but I mean, we were talking earlier about moving from like the view two way of doing things to composition API, or moving from, you know, using class based hooks to function based hooks, right, and react. And the reality is that we have to go through the thing that works and it's okay. And, you know, I wouldn't even say that they're painful. It's just that we came up with a better way to do it. And I think we're going to go through the same thing with teaching code.

 

Yeah.

 

have now and that's fine. It's more than fine, right? It's good that we have something out there that we can use to enhance people's skills. But yeah, eventually I think we're going to come up with better and better ways of approaching this stuff.

 

Yeah, totally. So anyways, I think that we kind of wrapped up how boot.dev works, what it is. The other thing that we could potentially talk about, if you guys want to, is this idea of WebAssembly. So one interesting thing about boot.dev is on the front end, all the code runs in your run anything on my servers, which has been really nice when it comes to server costs.

 

Mm-hmm.

 

Uh,

 

Yeah, we can

 

good.

 

do it really quickly. We're kind of getting toward

 

Yeah.

 

the end of our scheduled time. So, and

 

Yeah,

 

I have

 

yeah,

 

a hard

 

no problem.

 

stop at noon. So if you want to just hit that for like two or three minutes, then we'll go to picks.

 

Yeah, sounds great. Yeah, it's just something worth mentioning if you're really interested in front-end development. Python and Go and tons of other languages now have the ability to compile to native WebAssembly.

 

Mm-hmm.

 

So a lot of other sites that work in a similar way to boot dev will take your code that you write in Go or Python or whatever, ship it to their back-end server and run it there, and then give you a result. It's been really fun to instead compile that code to WebAssembly on the backend and give you basically a wasm bundle to run. And it's just fantastic for performance and for dollars in my pocket because now when someone writes an infinite for loop I don't have to figure out how to kill that on my server. The browser, I just give them a cancel button in the browser. So yeah,

 

Yep.

 

that's kind of the last bit of technology I guess that we use in the boot dev architecture that might be interesting.

 

Very cool. Yeah, Wasm is another area I want to dive into some more.

 

Sweet, thanks guys, I've had a lot of fun with this.

 

Alright. Steve, do

 

All

 

we

 

right.

 

want to do pics?

 

Let us do picks for the uninitiated. And we get millions of new listeners every week, I know, so we should clarify this.

 

wish. I mean, of course we do.

 

Picks are where we get to talk about things that are cool, that have nothing to do with JavaScript and tech, or could have something to do with it. Books, food, games, you name it. I will start out and this is for the regular listeners know that this is the high point of every podcast is my dad jokes of the week. So we'll start out. This is a story my daughter is studying to become a teacher. She's in her last year of school. And so she was telling me a story the other day where she was doing attendance at the first part of the year. And she comes across this name. KM and says, I'm sorry, I'm not sure how to pronounce this name. And she spells it out. And, uh, a little girl raised her hands in the back says that's me and it's pronounced Noel. Uh, for those who can't see, Elaine is doing a face palm. Uh, so yes, no L get it. There was no L. Um, so pre Halloween we're recording this the day after Halloween. Does anybody know why the black cat was so small? Cause it only drank condensed milk. Right. And then for the last one. I finally decided, oh, let me see, edit that. Let's try that again. I like my joke for today. Okay, here we go. So I decided that I really should think about becoming a tightrope walker because even the bank says my balance is outstanding. Thank you, thank you. So with that, those are my outstanding picks. We will move on to Chuck. Chuck, do you have any picks for us?

 

do. So first of all, I just want to let people know if you want to get a copy of my resume template, this is the resume that's gotten me dozens of contracts, jobs. This is the resume that I help new people format the same way and it's worked for them. So this has probably gotten people hundreds of jobs. You can go get it at topendevs.com slash resume. So I'm just gonna let people know if you want to go get it. And it's free. You just have to enter your email address. As far as like board game picks, so I'm gearing up to go to Timcon this weekend. And that's down in Provo for those of you who live in Lane and my neck of the woods. It's at the Utah Valley Convention Center Friday and Saturday. And you know, basically the way these board game conventions work, this one, Saltcon, I think those are the two that I've been to or been around. Anyway, the way it works is you show up and you can bring your own games, you can borrow games from the convention, you can buy games there, but they have board games, card games, you know, whatever. I think there was a game from Parks and Rec that people had like recreated and they were all sitting in the back of the room playing on homemade game boards with homemade pieces. You get all kinds of stuff. You get people playing tabletop games like D&D, and there are a handful of those. You also have vendors there, right? So you have people who sell board games, people who rent board games, people who design board games or card games. And so, you know, you kind of get all types, but I'm gonna pick Timcon again. I'm gonna shout out about the board game conferences. They have them all over the place. and they are a ton of fun. I wound up playing some games with people I had never ever seen before or since, right? But we all went and grabbed a game and then kind of went, hey, who wants to play this? And you know, so we had three or four people get up and come play it. Last year when I went, the other thing that was funny as I walked through and ran into somebody I know and that was my accountant. So, you know, the guy that does my taxes, he was there. know he's going but he's there. So anyway when we go my buddy owns a board game shop. or co-owns it and so he sets up, the conference has like four or five tables with games on it that we've all prepped to teach people and so I'm picking up a four-hour shift on Friday night teaching people how to play these games and one of the games that we've played through that is kind of fun that I'm going to pick it's called Dice Miner and this is a game you have a mountain and you stack all the you stack you know dice on it and then you take turns pulling the dice off or you can if you pull the beer off of it you can roll the beer and give it to one of your friends and then you can take two dice off and then the next thing you do is you you have magic dice that you can roll or that give you rerolls and so then you can reroll some of your dice to try and score higher and then you tally everything up you reroll the dice in your... what do they call it? Your... horde basically of dice, and then you do another round, and you do three rounds. So it's pretty simple. Board Game Geek weights it at 1.78, right? So that's a little less complicated than what most people kind of clock in at a casual game. My wife and I really enjoyed it. We played it twice. It took us about 20 minutes both times. Two people. You can play it up to four people. Um, so yeah, it was, it was, it was a fun game. So I'm going to pick dice minor and then, um, I'm just gonna, I am gonna pitch you guys on something real quick and that's a top end devs membership. So I've kind of changed up the way that I'm doing things initially when I was setting it up. I was thinking, okay, well, I'll have like a Ruby community and a JavaScript community and an Angular community. But I recently joined an entrepreneurship group that did it a little differently and I'm really liking it. So what we're going to do instead, and I'm going to kick this off here within the next for an hour and a half to two hours every week talking about some topic that's relevant to programmers, right? So it could be careers, it could be like containers, DevOps, etc. And then every month we're gonna have a call for each of the communities that we have, right? So we'll have a call for JavaScript and a call for Ruby and a call for Angular and a call for Vue and a call for React, right? And so then, you know, maybe it'll be related to some of the other topics sessions, or it may be something completely different, right? And we're pretty well connected around here to the people that you're going to want to hear from, so we're going to have them come and walk you through stuff. But the other thing is, is that I feel like a lot of the communities out there for programmers don't treat a lot of the other areas that programmers are interested in, like a lot of folks work for companies that provide them with 401k. What in the hell do I do with my 401k? We'll have somebody come and talk about it. Right. I want to be an entrepreneur. Right. We're going to have somebody come talk about it. We have a freelancer show that I'm going to bring back. So we're going to have monthly calls about that. Right. And then I'm, I'm going to be building courses and bringing in people to help put out weekly content in the different content areas as well. So that, if you want to stay current on Vue JS, right, we'll have somebody who's authoring a 10 minute video on something to view JS every week so that you can go and pick that up and just kind of stay on top of what's going on so that's that's what I'm imagining at this point the videos will kind of be in the vein of if you go check out drifting Ruby which was patterned after rails rails casts way back in the day but yeah they had a video every week I'd like to get it so that it's two videos every week and then one of them is part of the membership and the other one's out there free to kind of Anyway, that's what we're putting together. So if there's a topic you want to hear about, let me know. If you want to join up, you can join up right now. The price is set at $39. I intend to raise that to $75 for the basic level and the $150 for everything to just get access to everything. And if you do $150, you'll also get member pricing on the remote conferences and other stuff we're putting on. So anyway. put all that out there. I am still doing like the masterminds and stuff, but that's kind of a tier above that where you get direct and consistent access to me so that I can help you with your career and where you want to go. But yeah, I'm going to pick that. And then I'm also going to pick a book series real quick. I've been listening to a book. The first book is called Keeper of the Lost Cities. And I believe that's also the name of the series. It's written by Shannon Messenger. It is kind of a team level book, right? So think like Harry Potter or Percy Jackson. The main protagonist is when it starts as a 12 year old girl who finds out she has special abilities, you know, it sounds pretty familiar, but it's kind of a, it's a little bit lighter fare than like a Harry Potter, but yeah, I'm enjoying it. My kids are enjoying it, so I've been listening to it on Audible, and so I'll put a link to the those you can all find them. And yeah, if you have a, if you, if you like kind of not the epic fantasy or the, um, heavy fantasy, you like something that's kind of a, an urban fantasy, that's, you know, kind of fun, then this is one to pick up. And I think my 13 year old daughter really likes it cause she kind of identifies with that main character, right? Cause they're about the same age. So, um, anyway, um, it. Yeah, those are my picks.

 

Alrighty, so Lane we're finally to you. What do you got for us for picks today?

 

Sweet. I'll do a couple. So because you mentioned board games, I actually have a friend from our area. He's down in Vineyard who makes games. And my guess is he'll be there at that conference. He's got a game

 

Odds

 

called

 

are

 

Life

 

good.

 

of the Chameleon. Yeah. I know he was at SaltCon, but he has a game called Life of the Chameleon. His name is Jake. It's a great game. My wife and I have a copy. So check that out. It's kind of a euro. I think the category is called Eurogames. It's a quick play, about 20, 25 minutes. So that'll be one. My next pick, I just have to say really quick, I need to go check out Top End Devs. That sounds really interesting. So I'm definitely going to go check that out

 

Well,

 

after

 

this is the

 

this

 

first

 

call.

 

time I've talked about the way I'm setting that up. So, but yeah.

 

Well, that's what sounded interesting, so I'll have to stay tuned, I guess. The other thing that I'm going to pick very selfishly is obviously Boot Dev. If you're interested in

 

Mm-hmm.

 

backend development in Python, Go, and JavaScript, you can go check that out. Just to make pricing, like be aware of pricing, the first three chapters of every course are free and then after that you need to be a member and membership start at 24 bucks a month. So yeah. Thanks for watching. Bye picks.

 

All right, so before we go, if people want to contact you, yell at you, say, hey, you're awesome, or give you money, where's the best places to contact or follow you?

 

You can follow me on Twitter or anywhere, I guess, at wagslane. That's almost always my handle, W-A-G-S-L-A-N-E. And then if you want to give me money, you can do that on bootdev, but you should probably only do that if you actually want to learn the things there.

 

Well, don't say that. I mean, I would think you would not have a problem. People just wanted to give you money to give you money. But, you know, if

 

We'd

 

you

 

love

 

don't want

 

to have

 

that.

 

it. Love to have it. Yeah.

 

All right. And then I am wonder 95 on Twitter. Follow me if you want to get at least five dad jokes a week, except when I'm on vacation. And Chuck, you're on Twitter, right? Cmax would. I

 

Yeah, CmaxW.

 

lose track of your Twitter. CmaxW, sorry. And top in devs, of course. And then finally,

 

Yeah.

 

before we go, I'd like to say thank you to the studio audience. Thank you for coming, people. They always add so much to the show. So with that, we will wrap up this episode of JavaScript Jabber. Thanks for listening and we'll talk at you next time.