Today in this all panelist episode, we talk about JS features you should avoid using.  However opinions don't always align, and some come with much debate!  Although we couldn’t cover them all, today we discuss:

Hey everybody and welcome back to another episode of JavaScript Jabber. This week on our panel we have Steve Edwards.

 

Hola from Portland.

 

AJ O'Neil.

 

Yo yo yo coming at you live from no hairsville

 

I'm going to go ahead and turn it off. I'm going to go ahead and turn it off.

 

No hairs, Bill. What are you talking about? You got plenty of hair in your head.

 

Yeah,

 

Hanging out with you guys.

 

Unlike some of us.

 

yeah,

 

Yeah.

 

yeah, ah, you're making fun of us. Okay, I get it.

 

Actually, it's that I, in case you can't tell, my hair's gone. I mean,

 

You've.

 

Gone.

 

yes, I still have about a thousand times more than any of you combined, but

 

Mm-hmm.

 

I used to have nice

 

Ah.

 

lion-like locks of hair, and now

 

Yeah.

 

summer hit, and woof!

 

So is

 

I had

 

that

 

to

 

a lot

 

have an

 

of

 

emergency

 

gray I'm

 

haircut.

 

seeing or just bleached out?

 

Oh, that's gray,

 

Okay.

 

that's gray.

 

Ha ha!

 

That's beautiful, Greg.

 

Yeah, I lost mine before it went gray. We also have Dan Shapir.

 

Hey from nice, warm and sunny Tel Aviv.

 

Awesome, I'm Charles Max Wood from Top End Devs, and I just wanna tell people to go check out JavaScript Remote Conference, it's gonna be the end of October. And yeah, we're starting to fill in spots, the CFPs open, so. Anyway, looking forward to putting that together. This week we're gonna be talking about features of JavaScript not to use. I think AJ's list is probably longer than Dan's.

 

Ha ha!

 

And this was, I guess, inspired by a tweet that AJ put out. So I'll let you guys fight over who gets to start first. And yeah, let's dive in and talk about what's in JavaScript that we should avoid using anymore.

 

AJ it was your tweet, you wanna start?

 

Oh, absolutely not. People have heard me rant about this tons of times. I think you should start and then I'll be the devil's advocate as to why we should have those features.

 

Okay, cool.

 

Mix it

 

So,

 

up, keep it fresh.

 

yeah, I do want to say to begin with, you know, there's this saying that only Sith deal in absolutes. So, it also pertains to this list. I mean, I'm going to list a whole bunch of things that I, you know, argue that you shouldn't use when coding in JavaScript or TypeScript, by the way. But, you know, I undoubtedly, you know, listeners we ourselves might say, oh, I used that feature once, and it came out really handy. And that could definitely be the case. The top of the list is probably eval. And I personally have used eval a few times where it did make sense. So every rule has, how would I say it, has its exceptions. There are exceptions to every rule. Yeah, but still, it's a list of things that overall I think are better left unused in JavaScript.

 

I think that I'm going to first counter with taking my normal position, actually. There are many things in the language, which if you don't use them, there is no difference other than the letters that you type. And those are primarily the things that I think ought to be eliminated because there is never a case where using them. than something that is purely cosmetic.

 

You know, we'll see. Okay, let's start going down the list and we will see, I guess.

 

Okay.

 

Although I'm looking at the size of this list, I'm going, okay, after we get to this list, what's left?

 

Ha!

 

I know right

 

No,

 

Yeah,

 

seriously,

 

it's a pretty

 

like it

 

long...

 

reminds

 

This.

 

me one time my, uh, my wife is, is sort of a picky eater and she doesn't like a lot of the things that, uh, will be extra be put on food and she likes stuff on the side. You know, if you've ever seen when Harry met Sally always on the side. And, uh, so one time we went to this Greek deli, uh, Greek deli in Portland. And so the waiters asking what she wants and she wants a hero. You know, it's not gyro, it's hero. And she says, well, I don't want this and this and this. And she goes, what's left? She goes, the meat. You know,

 

Ha ha ha 

 

there

 

Hahaha!

 

is nothing left. So I'm looking

 

Well...

 

at the list going, hmm, okay, this will be interesting.

 

What's left?

 

Bye.

 

The important part that you need to live.

 

meat.

 

You know what's offensive about that when I go out with my wife because she's the same way is that I'll order hers with all the stuff not on it and then I'll order mine with all the stuff on it and they'll give us two of them without the stuff on either of them and then I have to

 

Hahaha

 

take it back and go, no, I want all the good stuff on mine.

 

I'm sorry. I'm sorry.

 

Yeah.

 

So, yeah, so Dan, what are you taking away from us? No candy,

 

Oh,

 

huh?

 

yeah. Let's start, as I said, let's start with the obvious one. Let's start with the Ival, which is often said that Ival is evil and should be avoided. So what do you guys think? Should Ival be avoided? Or maybe

 

I'm just

 

we

 

glad

 

should speak

 

you

 

about

 

didn't

 

it.

 

say never because... anyway.

 

Like I said, I've actually used it on occasion because

 

Mm-hmm.

 

very rarely it does make sense. It's one of those things that when you need it, there really are no alternatives. I mean, yeah,

 

Right.

 

you can execute code using a function constructor instead of eval, but I

 

That's

 

just use

 

a synonym.

 

it. Yeah, essentially.

 

Yeah.

 

essentially the same. So when you do need Ival, there really are no alternatives to Ival.

 

Well, you could just ship a parser with your code like Angular

 

Ha

 

does

 

ha!

 

and doesn't react to that as well.

 

Oh god.

 

Well, not with

 

Just

 

the

 

ship

 

code,

 

a parser

 

it's...

 

in the browser. Everybody's got maximum bandwidth these days. Why would, why would you need to, why, why not just have your own implementation of JavaScript? Then you can include TypeScript and all the other syntaxes and you can

 

Well,

 

exercise all your artistic liberties.

 

and do it in WebAssembly so it'll even run fast. But seriously.

 

Yeah!

 

But yeah, but then effectively you've just re-implemented eval. So you've not gotten away from

 

Yeah.

 

it. I would consider it to be effectively the same. So for those of you who somehow don't know, eval takes a string and then parses and executes that string as JavaScript. And even more than that, eval is executes that string in the current scope. So it has access to all the local variables, not just the globals and whatnot.

 

Right.

 

And the big problem with the eval is the fact that it's potentially really unsafe because you're using data as code. And who knows where your data came from and where it's been. is effectively impossible. So really the problem with eval is that it's risky, it's potentially dangerous, especially if used on the server, and

 

Hmm

 

and that's about it. Any comments about that?

 

Well, I think we know that especially early on in order to get great performance, template libraries would do metaprogramming to the max, right? And that's the benefit of JavaScript is you can do all this metaprogramming. You can, you can generate code that you, that you don't know what it does and then just, and then just run it with more generated code. So

 

Funny that you should mention that because way, way, way back in the 90s, I wrote what I consider to be the first ever in the whole world progressive web app, which could even work offline inside the browser. And I would, to get better performance in that, because it ran on IE4, I would actually to eval just so that I could get the best possible performance out of it. But it turns out that these days, this is actually an anti-pattern. Because when you execute JavaScript inside eval, you're not getting the benefits of the JavaScript optimizer. It's just interpreting the code. the JavaScript engine from optimizing that function that contains the eval. Because again, no point in getting into all sorts of technicalities. But at the end of the day, if that's your justification, then it's no longer valid.

 

But can't you generate really highly optimized functions that then you use eval to attach to an object then you don't have any of that pesky branching logic that slows you down by micro ticks. And then the JIT can optimize that function.

 

Yeah, but that's a thing. First of all, let's put it this way. I've yet to see the case where that was in recent years. I'm now talking back in the 90s. In recent years, if you think that that's your performance issue, then you're probably wrong. But beyond that,

 

Ha ha ha

as I explained, it's no longer the case because the JIT, in fact, does not inside the product. So performance

 

But

 

is.

 

once it's been evaled, and now it exists in a namespace, and you could call that function that you created, why are you sure that the JIT

 

Could

 

can't?

 

they optimize it? Perhaps. I doubt that they'd bother.

 

But it'd be the same as just reading in the JavaScript

 

Uhhh...

 

on first run. It's

 

yeah.

 

not optimized on the first run, but it should be optimized if it becomes a hotspot, because it would

 

Yeah,

 

just be code like anything else.

 

theoretically, but practically, let's put it this way. You should use eval when there is no choice except using eval and not under any other circumstance, including thinking that maybe you're gaining a couple of microseconds, which you probably aren't. So that's the thing I have to say about eval. You shouldn't use it unless you have to use it.

 

Right, well, yeah, and I think the primary concern over it isn't the performance, it's the security implications of it.

 

But real programmers write perfect code, so you don't need to worry about security. That's a bogus argument.

 

Uh...

 

If you know what you're doing, you're not going to write bad code.

 

Yeah, in a couple of weeks, by the way, we're going to have a guest that I invited to talk about Tomer Lichtas, to talk about a famous, well, should be famous story, story about, called the story of Mel, about this amazing programmer way back in the 50s. And I'm reminded of that because he actually said, and it's a quote in that story, of code that cannot rewrite itself. So I guess there are some crazy use cases out there. These days, I think it's handled automatically in machine learning and stuff like that. But there is no justification, I think, for a human developer these days to write self-modifying code by hand, again, unless they really have to. Anyway, let's move on to the next one, I think.

 

Yeah, let's break somebody else's heart.

 

Yeah, I don't actually this one is is what I consider to be the only JavaScript language feature that's been so effectively deprecated that it's essentially suppressed to the extent that I think most JavaScript developers these days don't even know that it exists within the language. And that's

 

But I think they're going to be excited now, Dan, though. I think

 

Ha!

 

this is going to be a reason not to use

 

You can't use that!

 

import syntax. Oh, no,

 

Okay

 

once once you explain it, we're going to have so many listeners that are just they're going to try it out. They're going to try it out for sure. And they

 

Ha.

 

might start using it in production because it's so great.

 

Anyway, that language feature is called the with keyword or the with statement.

 

Uh huh.

 

And it's effectively deprecated because if you're in strict mode, you can't use it. And I will remind people that in ESM, in ES modules, they are strict mode by default and that strict mode cannot be turned off. So in ES modules, you just can't use that with statement at all. Anyway, the idea with with actually sounds really nice, like AJ said. Once you hear it, you say, hey, I could use that. The thing is this. When we write JavaScript code with objects, we have a lot of code that is like x.y.z or a.b.c. lot. And if we're writing object-oriented JavaScript, then we have this dot something again and again and again. And what with does is that with basically sets the scope in such a way that instead of writing x dot y, you can do with x and then just y. Within that scope you don't have to explicitly put the X dot in front of the Y. It's like it's implicitly there. So it kind of transform an object into a scope, you might say. I

 

Yeah,

 

hope.

 

so basically it's just as good as let.

 

How do you

 

It

 

mean?

 

creates scope for things.

 

Well,

 

Thanks for watching!

 

let is defined at quote unquote compile time, whereas JavaScript objects are wholly dynamic. So you can add properties onto them. And in fact, that's the big problem with width, the fact that it's a dynamic scope. It's a scope that cannot be inferred at compile time. It can only be inferred at runtime based on the properties of whatever object use for the width.

 

Well, we'd like dynamic. That's, that's why we like JavaScript. We like having loose weak types. We like being able to assign something to, uh, you know, as a number and then as, as a string we like, we like being able to just pull things into scope. Willy nilly.

 

I get that you're being sarcastic, but in reality, the fact that you can do something doesn't mean that you should do that thing. The MDN, by the way, gives a pretty good explanation of why width should be avoided. If you go to that section on width, there is a link right at the top about why it's bad idea to use it and why it's been deprecated. And the reason, as I explained, is that it creates a dynamic scope. And the dynamic scope, it turns out that that's a bad idea. Again, if we look at the history of programming languages, it turns out that many programming languages, instead of using static scopes like most programming languages use these days, actually use dynamic scope. The original version of Lisp, for example, did that. The scope was kind of determined by the color of the function rather than the scope in which a function was declared. And with kind of does that because the scope within the width is determined by that variable, by that object that you use with the width. And it turns out that it's just a bad idea. It's one of those things that people thought might be a good idea, but then turned out to practically be bad ideas.

 

Well, you could, you could just not have so many other things in scope and you could use with and put it past in your object. And if you're not, I mean, I'm looking at this MDN example, but they're, they're, they're really contrived, right? I mean, you, you know what your variables are named. Um, so in, unless it's something that you, that you got from eval, then you should know what's on the object and you'll, and you'll know, and you could even use, you know, JS

 

Ah, yeah.

 

doc. And.

 

That's the thing about JavaScript. We always know what's on our objects, because nobody else can modify our objects. But really, the thing is this. The JavaScript optimizer, once it's saw with, would have to totally bail, because it can't. The fact that you have a variable declared, let's say, using let or using var, it doesn't really matter. script engine sees that at parse time, it's aware of all the variables that were declared within the scope. So it can do all sorts of optimizations. It can, you know, it doesn't need to do a

 

Thanks for watching!

 

named lookup to get it a variable. Whereas once you've got with, then every scope becomes like a dictionary and effectively you've got named lookups for everything. So yeah, it was a very bad idea in terms of performance. It led to bad coding practices. And it's a Effectively been removed from the language because like I said when you're in strict mode. It's just not there. So so yeah

 

Well, you know, I get that Angular came out with strict mode and maybe view has changed too, but for a long time in Angular one and view one

 

Thanks for watching!

 

and two width was used in the

 

Thanks for watching!

 

templating system so that you didn't have to have a root object that you had to access every time. And

 

Oh yeah,

 

another

 

for

 

benefit,

 

sure.

 

another benefit of

 

Thanks

 

this

 

for watching!

 

is not only is it more ergonomic, but then you get shorter stack traces. So

 

you

 

you're not wasting as much memory when there's an error

 

you

 

and you only

 

Thanks for watching!

 

of the evaluated code where stuff comes from rather than getting the full stack trace that would lead you to where the bug is.

 

I would put it this way. First of all, JavaScript is not the only language that has this construct, or had this construct. JavaScript actually borrowed it from other programming languages. I recall Visual Basic, I think, having the word construct. And when it's a class-based programming language where object structure is kind of well known, because the optimizer doesn't have a problem with it. It's the dynamic nature of JavaScript that made it problematic. But again, it was problematic from the implementation perspective and from some usages perspective. I'm totally not saying that there aren't scenarios in which it saves you typing and makes the code potentially more readable. It definitely does. There is a reason why it exists in various programming It's just that in JavaScript it turns out it wasn't such a great idea. And again, it's essentially removed, so whether we wanted it or not, it's not there anymore. Anyway.

 

I wanna try eval with with.

 

Well,

 

That sounded weird,

 

you probably

 

yeah.

 

could.

 

That is how view two was done. But it actually, it caused a number of, but when I was using view two, I think it was view two, it might've been view one, I'm pretty sure it was view two. I would encounter these bugs and they originated from my code, but because of the use of width, coupled with the use of eval, it was literally impossible because all you would see is something like But you wouldn't know where foo wasn't defined because when you use with, then the you lose the context object. So you don't know, oh, foo is undefined of a person. Because you see this all these time, all the time in these templating languages where they emulate this, even either in their own compiler, or using something like with an eval. you lose the context of the, say the person and then, but you can access the properties of the person, the name and whatever. But then when you get the error, it's, you just

 

Yeah,

 

end up getting name is

 

and

 

not defined and you have no idea where it is.

 

in this case it's even worse because foo might either be a missing property on that object using the width or it might be a local variable that you somehow mistyped a name or something, so it potentially gets even worse. And

 

Yeah.

 

you really can't tell the difference. Okay, anyway, the next one that I've got on my list is the arguments object. It was the way to go because you really didn't have any choice. If you had a function that had a variable number of arguments, for example, the only way to get at the arguments was using the arguments object. These days, we've got the spread operator and it's, from my perspective, so much cleaner, more readable, et cetera, that I don't really see any justification for using the arguments object anymore.

 

So this

 

You want

 

is

 

to describe

 

one where I'm.

 

what the arguments object is, Dan?

 

Well, it's an object that exists within a function scope. So if you, and when you invoke the function, it's this kind of thing that, we actually spoke about it in the past, in previous episode, it behaves as if it was an array, even though it isn't really, and it actually is missing some array methods on its prototype, so that's another problem with it. variables through it, but it feels like it's close enough to an array that it's as if it's an area of the arguments that were passed to the function. So the first argument would be in arguments 0, the next one in arguments 1, and you've got arguments.length to get the actual number of arguments that were passed to that, in that function call. And it's, like I said, it was totally needed. But these days there's just a better mechanism. You know, once we've got the spread operator on arrays, you can do the dot dot dot rest or whatever, or dot dot dot args or whatever you decide to call it, and you access the arguments as an array that way. And in that case, it will be a real array, and it's just that much better.

 

Well I would argue that the spread operator is something that you never need to use for a couple

 

Oh,

 

of reasons.

 

that I would actually disagree with, but go on.

 

Ah, ha ha ha ha.

 

Uh, so

 

Do go on, AJ.

 

if you need, if you need an array, just use an array. I really, really dislike it. I think it's very immature because I think, I think you'll agree with me on this one, Dan. If you

 

I'm immature.

 

have an optional array, then always pass the array. Don't sometimes pass one element that there's only one, but then pass an array when there's 10. Just always pass an array. And.

 

you're saying that functions with a variable number of arguments are generally a bad idea I would tend to agree with that

 

And I think that the, I don't like the spread and collector syntax in JavaScript because it doesn't follow what every other language does. And I assume it does that because if it did, it would create more syntax ambiguity and would lead to these problems where the tooling and whatnot can't figure out what you intended to do because it's some weird situation where it's valid to have a triple dot. Uh, you know,

 

Well,

 

after

 

the

 

something

 

spread

 

in

 

operator

 

JavaScript.

 

in JavaScript is kind of overloaded, and we spoke about it in those episodes that we talked about the things that JavaScript developers should know, because we talked about the spread operator, so I would refer our listeners to those episodes. I don't want to go down that rabbit hole simply because we have such a long list of items still to discuss, but I would tend to agree with you that in most cases, using a variable number of arguments is not a great idea, that you should pass in an area instead. The only cases I think that where it does make sense is when you're kind of wrapping functions for some reason. So for example, you've got things like Sentry or that can identify problems and report them. So for example, you're making an Ajax call and it fails and it logs that to some system or whatever. And, you know, their generic wrapping function needs to be able to handle, to be able to wrap functions with different number of arguments, so they kind of have to be able to deal with variable number of arguments.

 

Well then you're not dealing with an array as much as you're dealing with a tuple of unknown size.

 

Yeah, effectively.

 

But again, this is exactly what arguments is for. And I get the argument against arguments in that it's the whole pointer issue. The references of

 

We

 

an argument

 

spoke about

 

don't

 

that

 

work

 

as

 

the same.

 

well. That

 

Yeah.

 

was deprecated as well. If you're using strict mode, then that whole pointer thing doesn't exist. And again, I refer our listeners to that episode where we discussed that. Let's move on to the next one if you don't mind.

 

Yes, it sounds like we're getting argumentative here.

 

Well,

 

haha

 

wait, I just, I just calling, calling the slice method, but you know, do, do square brackets dots dot slice dot call arguments gives you back an array. You can use the arguments. I, I use arguments for exactly what you described. The reason that I wouldn't, the, the, the case, I don't like the whole. Yeah. Syntax around the, the splatty do where they've got the dots on the wrong side, but I, I use arguments. with it, but I agree. Uh, you have to use it with caution because you don't, you can't use it directly.

 

Thanks for watching!

 

I'll agree with that. Don't use arguments, object, direct.

 

Thanks for watching!

 

Can we call this episode Splatty Do and Other JavaScript Things You Shouldn't Use?

 

Yes.

 

For sure. The next one on my list, I wonder how many of our listeners actually even are aware that it exists in the language. It's do while. And I don't think you should use it for the very simple reason that I never really encounter scenarios where I need to use it. So if there's something in the language

 

you

 

that doesn't really serve a purpose, then language.

 

Well, isn't the reason that you'd need to do while is if you need the first iteration of the loop to run, regardless you're checking

 

Exactly.

 

an initial condition.

 

Yeah.

 

And if you don't use the do while, then you have to lift that initial condition up top and then repeat the condition inside the loop. So you have the condition and then you have your check and then you have the condition again, or you have to put the logic for checking the condition inside your loop, in which case, you don't need the while either.

 

So yeah, you're totally correct. And I would also add that JavaScript did not invent do-while, do-while exist in C. So it got it from Java or C++ or whatever. Brendan Eich got his inspiration for that from. But I'm just saying that I'm trying to think during the past decade, if I've ever really use do while in my code, and I'm coming up short. I can't really think of any instance where I said, oh, yeah, this is exactly the situation where I would need a do while for. And my experience usually is either that I need a test at the top of the loop, or in some cases, I need a test in the middle of the loop. I'm hard pressed to think of a scenario where I need the test exactly at the bottom of the loop.

 

So this is where I would also argue, you don't need while, while is superfluous.

 

Essentially, you mean like have like a sort of a do loop construct and just break out of it or something like that or just use four?

 

Just for just use for you don't for any situation where you'd need that this is this is the reason I say this. People get so confused about loops, right? That because in their, you know, intro to programming 105 or whatever, they're they're told, Oh, yeah, you're gonna need to know the difference between a while and a do while and a for and a loop and an until and you know, we have all these different syntax sugars, it's all just a for loop. That's all it is. And if you understand how use the for loop, then you, I mean that it's, it's less mental overload. Just it's one tool that always works. And if, you know, if you want a quote unquote, while loop, it's just for semi-colon condition, semi-colon, right?

 

Well, I would

 

Mmm

say this. I would say this. The for loop in JavaScript is heavily inspired by the for loop in C. And the for loop

 

Mm-hmm.

 

in C is essentially a sort of a syntactic sugar around the while loop, where you've got the initialization, the test condition, and the increment that would, in a while loop, be placed all over the place. They're like bunched together to make it more readable. while is the more primitive incarnation, as it were, of the loop construct, looping construct. And again, JavaScript basically just inherited it from C. But I totally get where you're coming from. And I would even argue, I would also say that I generally tend to avoid these type approach. By the way, it kind of reminds me that I recently, I did a poll on Twitter a while back where I asked people if they prefer while true or for with an empty test clause. And it turns out that a lot of people were wholly unaware that an empty test clause in a for loop is like a while true.

 

We need more people exposed to languages like go. And I mean that,

 

Ha

 

I

 

ha

 

mean

 

ha!

 

that so sincerely, I think one of the best ways you can learn a programming language is by learning another programming language and go is probably the most constrained. Uh, language and, and it's, it's probably second to JavaScript in terms of popularity. I mean, you name a service you use that doesn't have, uh, all of its infrastructure written in go or that all is a strong word, but doesn't have its infrastructure predominantly written in Go.

 

But here's the thing, we don't really know what our infrastructure is implemented in.

 

Yeah.

 

It's running on the back end.

 

Yeah. One thing that I just want to step in here with, cause, uh, you know, the, the do while. I know I've used it and I know I've used it because it was the most natural fit for what I was trying to do, but I can't think of when, it's been a while. The other thing though is that,

 

Pun intended.

 

you know, argue, pun not intended, but realized as soon as it came out of my mouth. But the other piece is, is if you're gonna argue against having a while loop at all, typically I'm looking at for loops and a clear way of iterating and a clear stopping place. And I guess while loops have that as well, but I'm not always operating on something that's just a clean set of iterations like that. A lot of times it feels more natural to me to just say, hey, just keep doing this until this condition is met, as opposed to, you know, here's how I'm gonna set up my iterator, which is what you do in a for loop. So

 

But taking Ajay's

 

what...

 

position, at the end of the day, unless you're intentionally writing an infinite loop, something can change the clause.

 

That's true.

 

And that would be the operation that is the thing that progresses you through the iterations.

 

Mm-hmm.

 

But you know what? Building on everything that we talked about, I would actually move one of the items from, you know, way down to here. And that would be that I would tend to avoid 4i type loops. Those are loops that use numeric indices.

 

Mm-hmm.

 

You know, 4i equals zero, i less than something, i plus plus or whatever. I find myself not really using these anymore. At least in JavaScript.

 

Yeah.

 

How about you guys?

 

So how do you handle the async await in a loop then? Because they gave us no, they gave us all these cute little functional things for the array,

 

No,

 

That's

 

but then

 

a

 

no.

 

nightmare.

 

I'm

 

I've

 

not

 

dealt with

 

saying

 

that before

 

not to use four. You've got four of, which is great for that use

 

Oh,

 

case. I'm

 

Mm-hmm.

 

okay.

 

saying don't use the numeric indices. Instead, just use a four of to iterate over an array or a sequence or whatever. It might be a four of or for a weight of or whatever is appropriate. But yeah.

 

Yeah, I- I agree. I almost never use the 4i blah blah blah. And that's not to say you have to either, right? Because you can initialize i to anything, right? And you can iterate. You don't have to do a plus plus. You can iterate that anyway too and have any kind of condition for your, you know, to end. But yeah,

 

It's...

 

the 4 of is more natural and it reads easier for me.

 

Yeah, it's just that the 4i, it's a throwback to the C days. It's when

 

Yep.

 

the array is effectively just a memory block, and you're iterating

 

Mm-hmm.

 

through that memory block. In a modern programming language, you want to work at the higher level of abstraction. So it's a sequence or whatever. And then a 4 of or something like that, I think, is the more appropriate construct videos.

 

it in that vein, plus plus, I, I, great languages don't have it. For example, no plus plus in

 

Somebody's

 

Python.

 

been reading Crockford.

 

Uh, yeah, but the, the, the plus plus is for semantically. It doesn't make sense. It's an abuse. It's an abuse of the language, right? Because it's, it's not to increment something by one. It's to increment an array in hardware memory by the size of an element in the array. That's why it's plus plus rather than plus a number is that the compiler is calculating what the size of the thing is you so you don't have to do a size of and then a plus equals that size.

 

But again, that C thing in JavaScript.

 

which

 

In JavaScript

 

has no place

 

plus,

 

in JavaScript.

 

in JavaScript, it's just equivalent to plus equals one.

 

Mm-hmm.

 

Right. But it doesn't, it doesn't make any sense. It's counterintuitive because if you knew what plus plus did, you would say, well, that doesn't make any sense in JavaScript because you're not incrementing by the size of a struct in JavaScript. You're incrementing by number.

 

Let me put it this way, almost the only use that I had for the plus plus operator had been in 4i loops and once I more or less gave up on 4i loops I more or less gave up on the plus plus as well.

 

Oh, you know what I really hate when people do

 

You

 

it,

 

hate things?

 

you know, occasionally, yeah, occasionally you need to recursively call something. So say you're going to do the Fibonacci sequence or whatever. Maybe that's not one of the ones where you do this, but occasionally you recursively call something and then people will pass in, um, you know, I either plus plus I or I plus plus, and then, you know, it's the, it's a shortcut to I plus a shortcut to increment on the next line. So it actually passes in the current value, but then increments it for the next iteration of the loop. I think that's the most confusing thing ever. And then plus plus I is equally confusing, but at least does the thing that intuitively would make sense is that you would increment the thing that you're passing in. But I've seen, I've seen bad loops where somebody's passing in a plus plus, and actually nothing's or you know

 

You

 

it's doing

 

know

 

the

 

what?

 

wrong condition.

 

I'm

 

I like

 

going...

 

using plus plus I just to mess with people, but

 

Yeah,

 

that's

 

That's

 

just

 

but

 

good.

 

me.

 

I'll totally take your position on this, AJ. In modern JavaScript programming, I don't think the plus plus operator, whether prefix or postfix, really has a place. Especially, like I said, since I've essentially given up on the 4i, I really don't see a use for it anymore.

 

Well, I'll give you one real use for a plus two or a plus three when you have data that's interleaved, for example, audio data

 

you

 

or video data, where one segment of the track is going to be the right channel, another segment is going to be the left channel, another segment is going to be the subwoofer. And so you are, you're taking interleaved data and you're iterating through each channel of the interleaved data.

 

you

 

That's one case where. I mean, that's, it's not super common. people aren't dealing with interleaved data, but when you are dealing with interleaved data, it is the right tool for the job.

 

As I said at the very beginning, you know, there are no absolutes. You're likely going to be able to find use cases where any one of these things that you shouldn't use actually makes perfect sense.

 

I'm going to put in a proposal to add plus plus three and plus plus two just so AJ has a shortcut.

 

But that, because the plus equals two, how?

 

Yeah, plus plus two would be plus equals two, anyway.

 

Yeah.

 

Or plus plus plus. Hey, we'll add them both. Plus plus plus plus.

 

Yeah, that would be cool.

 

Yeah, instead of putting a number, just put the number of pluses that you want to add.

 

That's

 

So

 

right.

 

instead of being instead of being zero indexed, it's two indexed. Two pluses is one. Three pluses is two.

 

Uh

 

This

 

huh.

 

will be it will increase readability for sure.

 

Yeah,

 

Yeah,

 

that

 

definitely.

 

wouldn't be confusing at all.

 

I wanna add 50 pluses. The frame rate's 24, so you add 25 pluses.

 

That's nice. Another, going back to my list, another one that I would like to eliminate out of JavaScript coding, and again, I've hardly encountered it in recent years and I don't really use it in my code at all, is the continue keyword. To the extent that I think that a lot of JavaScript developers, especially the newer ones, let's say, it exists. Do you all remember what Continued does?

 

I haven't used it in so long, I'm not sure

 

Yeah,

 

I remember what it does.

 

I think

 

I-

 

it's in, it's, was it when you're inside a loop and you tell it, okay, just keep going, even if some conditions

 

Yeah,

 

been met.

 

it jumps directly to the next iteration of the loop. So it

 

as

 

skips.

 

compared

 

I

 

to

 

use

 

break,

 

continue

 

which breaks

 

all

 

out

 

the

 

of

 

time,

 

a loop.

 

like an early return.

 

I don't...

 

But I guess the argument could be made that that should be a function because the loop's gotten too long.

 

Probably.

 

That's, that's the one thing I'd say is if you're using continue, there's a, there's a high likelihood that your function is too long, but also, I don't know. I find it to be very useful as, as an early return. You're just saying, Hey, if you meet this condition, skip this one, go onto the next one.

 

to the

 

Cause

 

next

 

I wouldn't

 

iteration.

 

want to wrap that whole thing in an if, you know,

 

Like you said, when I get to the point that where I continue to make sense, I probably rip up the entire content of that loop into a function and just have an early return out of

 

Mm-hmm.

 

it.

 

Mm.

 

The bottom line is this, you know, I guess it's a stylistic decision, but I've just not used continue in such a long time. I don't see continue in code written by other people. And I think there's a pretty good chance that if you do use it, people just won't even know what it does. I mean, I-

 

So in other words, we shouldn't continue to use it.

 

Interestingly though, everybody still uses break.

 

I was gonna say, Steve, give me a break.

 

This is going to be a really pun-filled episode, so it seems. Anyway, so these, I think, were the easy ones. Let's move to some items that are more contentious, perhaps. Although, so far, we've managed to argue about some of them, and even some cases that I didn't expect. So does anybody really like classes in the language and thinks they should be used all over the place?

 

So my first Vue app that I did when I was working full time was one that I had taken over for somebody else who had already started to build it. And he used classes extensively. And this was in Vue. And we used them primarily inside Vue X. And I got used to it after a while, where he used classes and adherence. And it made sense and just turned to the way it was built, because you had certain things that You didn't want to have to repeat another classes at the same time there were other ways to do it within JavaScript in terms of imports and so on so I Didn't think it was particularly problematic. It took some muting getting used to but you know, it made sense Once you were inside of it and got used to using it I don't know if there's you know, if if something is readable and it works and there's not for instance major performance hits or like that, I don't see a problem with using it. I'm curious to hear your reasons for

 

Thanks for watching!

 

it. There are people that are, you know, like any topic in JavaScript, there are people that are very adamant about classes. No, they should never be used and yes, they can be used. So there's always gonna be somebody on either side of the opinion, but it worked.

 

Y-yeah...

 

So here's my position. There are a few cases in JavaScript or the browser where classes do make sense. For example, the API for web components was created in such a way that classes are the easiest and most natural way to implement web components. So if you're implementing web components, but as a general programming construct I really don't like them they encourage implementation inheritance and that's generally a bad idea

 

Yeah, so... It's interesting to discuss also from the standpoint of how they've kind of been used in the past. And the other thing I would bring into this argument is TypeScript, because TypeScript does encourage class usage more than regular JavaScript.

 

I kind of disagree with that. And I know that it came up in that discussion that you had on TypeScript, where unfortunately I wasn't able to join. Originally, that was the case. So

 

Mm-hmm.

 

when TypeScript came out, they were heavily inspired by Java, by C-sharp, classes, interfaces, the whole shebang. And

 

Right.

 

to me, and I know to a lot of other people, it made TypeScript look and feel poor man's Java and I really didn't want anything to do with it. I think that over the years they've realized that that was a bad idea and what I currently see is that most people who are using TypeScript are using TypeScript without using classes. They're just

 

Okay.

 

using declaring a whole bunch of interfaces and classes and stuff like that. Now, again, I might be mistaken. Maybe that's the code I'm seeing and other people are using TypeScript that way. But that is what I'm seeing. And especially since React made that hard drive turn and gave up on class

 

Mm-hmm,

 

components

 

it did.

 

and shows hooks instead and effectively inspired all the other frameworks direction as well. It seems

 

Not

 

that

 

all of them.

 

it's never all of them, but it seems that classes in JavaScript are on a steep decline. At least that's

 

Right,

 

the way it seems

 

so.

 

to me.

 

It would be nice if React would update their documentation.

 

Yeah,

 

I

 

so.

 

think that they have. The React, if there's one good thing I have to say about React is the fact that they do have excellent documentation.

 

I can say, the last time I looked at the React documentation, and granted, it's been a while, was a little after that transition, and they showed you how to do it both ways. But React has definitely made a hard right turn and said, no, we're gonna opt for hooks, we're gonna do it this way. I know that a lot of the Vue community has been adopting TypeScript. Angular has had TypeScript in it for a long time, and they still, like if you go look at their documentation, to build classes. And there's not really a way that they tell you to do it different. So that's kind of where some of the context that I'm coming from is at, is that I see people using this, and I see people building their entire app, including their components and everything else, in Angular using TypeScript classes.

 

Well, if you're using Angular, then apparently you have no choice. So, you know,

 

Yeah.

 

you may

 

Yep.

 

like it or not, but it's

 

No,

 

a fact

 

it's true.

 

of life, you know.

 

Yep, and I'm sure that they have reasons for it. I just, I guess, you know, it doesn't feel that unnatural to me to use it that way. But they give you a lot of other things that make it easier to build your apps, right? As far as just straight up classes, if I'm building something that's just straight up JavaScript or TypeScript, yeah, I'm typically not using classes. But if I'm, you know, working in an Angular app, classes and it doesn't feel weird.

 

So the argument I have against classes is simply that classes are designed for languages that are procedural and synchronous. And that doesn't make sense in JavaScript because the state of the object changes asynchronously. And so you have to add a whole bunch of extra hoopla around class-based objects because the JavaScript is, it's really about JSON. You serialize

 

Mm-hmm.

 

and you deserialize. You hydrate. hydrate, right? You just, you just need to shift data from this point over here to this point over here. And all of that fluff in the middle, if it gets in the way of that, I think it's bad. And that's, that's classes. Classes require that you instantiate something that it's going to, it's going to split

 

Mm-hmm.

 

you. You can't just take, you know, you can't just call two Jason on any old class and then call the whatever it is trick goes either way.

 

Well, you

 

And

 

can,

 

that's

 

since

 

something

 

it's JavaScript

 

that.

 

and you can do anything in JavaScript. But I totally

 

See?

 

get where you're coming from. Classes, encourage a more structured and static type of objects.

 

No, it's not about being structured and static because being structured and static is great. What

 

No,

 

I'm saying is that

 

I'm talking that the structure of the class is more specific. It's like I'm searching for the appropriate phrase.

 

Uniform.

 

It's more uniform, less likely to change, less dynamic. It's

 

then.

 

also the relations between objects are more specified, hard-coded,

 

Mm-hmm.

 

But but again for me the key thing is that implementation inheritance just turned out to be a pretty bad idea from my perspective

 

Yeah, there are definitely trade-offs with inheritance, right? I mean, even in some of the languages like Ruby that's very, very object-oriented

 

2

 

class stuff, there are a lot of times where you wind up pulling things together and kind of constructing things as opposed to inheriting things in order to get the behavior you want. And the reason is, is because sometimes when you inherit the ability interact with another class, it just, it turns into this giant headache where instead if you can just, um, you know, insert a module, you know, you dynamically add, you know, an interface or dynamically add functionality as you go, then it, you know, it, it, it does that a lot more cleanly. And so there are, like I said, there are definite trade-offs to, to the approach. And if you don't need that heavy level of structure, then classes kind of feel like a weight around your neck as you're trying to move.

 

I, I, I, first of all, you say trade-offs. What are the upsides of inheritance? I have, I'm not aware of any of those. And second, you can have really good structure. You

 

Yes.

 

can have types. You don't need classes for types. You can, JavaScript has always had types. JS doc has supported types for a long time and TSC makes that work the way that you want.

 

I don't think we're going to argue on it. I think at the end of the day, we're mostly

 

Yeah.

 

in agreement on this. So let's move to the next one. Prototypes. I don't think we should discuss it a whole lot. The appropriate reason to use prototypes is for polyfills. Unfortunately, people also sometimes use it for quote unquote performance reasons. And unless you're creating a trillion instances of a particular object quote unquote type, there's absolutely no reason for it and you shouldn't deal with that.

 

Wait, but how would you build a testing framework if you couldn't extend every object to have a dot should dot be dot above?

 

Ha!

 

Ha ha ha

 

How could you possibly? Are you just... you're throwing away every testing framework that exists!

 

I don't think so. But again, like I said, there are reasons. Some of them really contrived, some of them less so. Some of them, like I said, are even reasonable. I mean, like I said, if you need to implement polyfields, then you absolutely positively need prototypes. But

 

Mm-hmm.

 

generally speaking, just create object literals and put it in factory functions and and you don't need prototypes.

 

Well, that's the argument for against classes as well too. I mean,

 

Right?

 

that's cause there's kind of the syntax, but, but, but

 

Yeah.

 

seriously, but seriously, how would you write a testing framework? If you couldn't

 

you

 

take every single primitive of the language and add dot should dot B dot whatever.

 

Usually what I see is that they actually usually wrap the original object. So you don't invoke should or whatever directly on the original object. You like wrap it in something like expect something and then do a dot

 

Mm-hmm.

 

should. So you create a wrapper around that object instead of modifying that original object.

 

Yeah,

 

Which

 

or

 

brings

 

you do

 

us

 

some

 

to...

 

kind of functional comparison that effectively does the same thing without the wrapper where it's, you know, expect X, you know, expect equal XY kind of thing, right?

 

Yeah.

 

And so

 

But.

 

then you don't necessarily have the wrapper like Dan's talking about, but it does the comparison or the check or the lookup or whatever.

 

I think that adding properties on the original objects is way, way dangerous and problematic. It's likely

 

You're

 

to create

 

asking for problems.

 

conflicts and stuff like that. No, I happen to create a totally reasonable method on my object that's called should or whatever, and all of a sudden I'm conflicting with the testing library.

 

Mm-hmm. Yep.

 

Anyway. Oh, that's a bit of a contentious one. I think we also talked about this in the past. So let's make it short and that's this I'm claiming that you shouldn't use this, but I know, AJ, I know that you love this. So

 

Yeah.

 

what's your rationale for using this everywhere?

 

Well, it's pretty simple, right? If you want to know all the lines on which something is an instance of something else, if you just grep for this, you'll get most of your program. But if you were to give things names that are descriptive of what it is you're talking about, say person, or maybe just P for short, if you were to try to search your code for that, then you'd only get the limited scope of things that are actually related. and not be able to see it with the full context of every line of your code.

 

I love it when you're cynical. Yeah, for sure. I totally agree.

 

And then whenever you show someone a snippet of code, they can always tell, Oh, this is an instance of something. Even if that three line snippet doesn't show the full context, they'll know it's an instance of something. If you just show them person.name. They won't, they won't know what that's an instance of.

 

Yeah, I will say one thing though. You know, sometimes when I see code that makes extensive use of this, I feel like the itch to fix that code. And I really need to restrain myself because if there's one thing that you should not do is you should not try to refactor large portions of an application for no good reason. And you should generally abide coding practices within the code base. So I do support the, what's it called, the, oh, maybe we'll need to edit that because the word, the Boy Scout rule, that you should leave code better than you found it,

 

Then

 

but

 

you found

 

you should,

 

it, yep.

 

yeah, but you should not go around the application just to make it look more pleasant to you because you prefer some other coding practices. So if there's a lot of this everywhere, you know, it is what it is. But generally speaking, if you're writing new code, I would highly recommend avoiding this. Moving on to the next one. Basically, what I'm going to say is either use var or use let. Don't use both. It's a question of taste. I know AJ prefers var. I prefer const and then let. Use one or the other. Mixing them together is just a source of confusion. People start thinking about why is he using this here and why is he using that there? probably are reading way too much into it and it's just a source of confusion. So pick your poison and stick with it. And it seems that most people are picking constant let over var.

 

That's what I'm seeing too.

 

The next one, the delete operator. Don't use that because it doesn't do what you think that it does if you actually have any idea that it exists. I know that a lot of JavaScript developers aren't even aware of it, but those that are aware of it because they're familiar with the delete operator from other programming languages usually, it does something that's totally different than what delete does in those other programming languages. Are you familiar with the delete operator?

 

The only reason I use the delete operator is when I need something to not appear in the. So if you check, if you do a object dot keys on something, if you've set it to undefined, it'll still show up. Now, if you're passing this through a rational stringifier, it won't show up. For example, when you, when you json.stringify things, that's undefined will be copied over things that are null will be copied over but not things that are undefined but if you do using something that was created I don't know long after

 

Thanks for watching!

 

uh json.stringify that had every reason to behave as you would expect such as url query params

 

Thanks for watching!

 

that will stringify things that are undefined and so if you need uh something where you know but you don't always

 

Basically,

 

pass the...

 

what you're saying is that when you're using an object as a dictionary, it makes sense in some cases to use delete in order to remove something from the dictionary. In which case, I would

 

What?

 

say that in most cases where I'm using an object as a dictionary, I should probably be using a map instead if I'm using modern JavaScript.

 

Hmm.

 

if only in order to show intent.

 

Hmm. But then you have to deal with all the special methods and stuff. You can't use the normal. Then I have to learn a completely different set

 

Ha

 

of

 

ha!

 

functions for

 

You have to learn things,

 

Now

 

oh no.

 

I have to work!

 

Well, no, I mean, I mean this sincerely though. I mean, I, I don't want a lot of mental overhead. I do get the argument for. We want to separate maps from structs because maps and structs fulfill different functions. Just like we want to separate arrays from tuples cause they fulfill different functions. But in JavaScript, we have one syntax. We have the array syntax for raising tuples and we have the object syntax for maps and structs.

 

I will say just as an aside that there's a proposal for adding real tuples into JavaScript.

 

with parentheses, that would,

 

I think

 

ooh, that's gonna break the parser.

 

they're going to try to put the proposal to put like a hash bang in front of the open bracket.

 

They're gonna

 

of

 

create

 

an array.

 

a tuple class.

 

Mmm.

 

I'm just kidding.

 

Anyway, but but but that's

 

That would that would be oxymoronic and

 

Yeah.

 

that's that's actually a really funny joke

 

Ha ha!

 

Because you

 

Well,

 

have to

 

I thought

 

understand

 

it was, but nobody laughed, so anyway.

 

No, but you have to you have to get the tuples and

 

Uh-huh.

 

classes just don't

 

Anyway.

 

Because you unrelated things in a structured format

 

Yeah,

 

Mm-hmm.

 

but anyway, what delete does, just to clarify to our listeners in case they don't know, delete removes a property from an object if it's on that object. That's all it does. And it's generally a bad idea because you generally don't want to use objects in such a dynamic way because, like I said, if you want to use an object as a dictionary, you probably should be using a map. And the other thing is that it gets in the way of the JavaScript optimizer because it When you're playing fast and loose with object structure, then it has to do actual name lookups rather than just using offsets within something called the hidden class. So it just generate less efficient code for property access on that object, whatever. Anyway, that was the delete. Yeah, go on.

 

So Steve, I just have to ask if you use the delete operator to remove behavior from an object, does that make it dysfunctional? Sorry.

 

I think we're starting to run out of time and I have a whole bunch of items left in the list actually some

 

Yeah.

 

of the

 

Two!

 

Some of the more contentious ones. I'll give like a preview the else keyword. I think you shouldn't be using else And and there are a few more so so I guess you'll need to schedule

 

That's heresy.

 

I guess you'll need to schedule a part two

 

That's clean code.

 

Yeah, we'll have to. But this was really good. And I mean, the thing that I like about these is that in some cases, I feel like we made the case, well, if you're doing this, then you may want to consider using these, you know, anyway. And then the other thing is, is even if you completely disagree with us, or disagree with Dan or disagree with AJ, there's enough of an argument there to where you should at least be thinking about why you disagree, right?

 

Yeah,

 

So...

 

for sure. You know, to each their own. It's just based on our own personal experiences and, you know, wholly subjective. But

 

Yep.

 

you do need to take into account not just your own personal opinions, but also the opinions of people who are likely to be looking or reading your code.

 

Mm-hmm.

 

You know, most people don't work in a vacuum, and if you use a certain fairly uncommon or effectively even deprecated, you need to take into account that there's a good chance that the other people on your team just won't understand what you're trying to do.

 

Right. All right, well we'll schedule Splattydoo part two,

 

Hahaha

 

and let's do some picks. Does that mean that if we have like three or four of them, then we can use spread operator to,

 

Yeah.

 

anyway. All right, Dan, what are your picks?

 

Oh, I'm going first this time. Okay. Let me see. Ah, okay. So my first pick is, I guess everybody who's listening to this podcast is probably familiar with the Can I Use website. I mean, how could you

 

Mm-hmm.

 

develop for the web and not know about Can I Use? So if somehow you've been living under a rock, this is this amazing service where you can go in a script function or a CSS attribute or a DOM API or whatever, and then see what the support is like for that feature capability so that you know whether you should or shouldn't be using it or should be careful about using it. And for the longest time, the table that is shown when you look up a feature like that IE as the first browser and now it's the last browser because IE is deprecated so we don't really need to support IE anymore at least are we the lucky ones among us then consequently it's no longer on the left it's now the last one on the right in the desktop section so that would be my first pick the fact is like going away and cannot use is an example of that. My second

 

YAY!

 

My second pick is the one that I usually give as the last pick in in my picks and this time I'll give it as the one before last and you'll see why in a second and that's the ongoing war in Ukraine, which is just

 

Thanks for watching!

 

terrible and an example of of how bad and evil people can be and how destructive. And it just keeps on going on and on. And I'm afraid that we're kind of getting desensitized to it, even though terrible atrocities are happening there on a regular basis. And it just doesn't seem to be heading towards an end. If anything, it seems to be just getting worse. So I don't know. It just makes me really, really sad. The reason that I didn't have it as my last pick is because my last pick is actually an example of the good in people and the ingenuity in people, and that's the James Webb telescope, space telescope. I guess that I'm one of those people who have been amazed by the pictures that are coming. It's mine to it and it's quite an astounding technological feat. By the way, I don't know if you know this, but there's actually a bit of JavaScript in the James Webb Telescope. Apparently they're using some sort of outdated JavaScript parser that supports ES3 or something like that and it's within the James Webb Telescope so we now have JavaScript in space.

 

Oh my.

 

Yeah, and somehow it works.

 

JavaScript in space.

 

It's running IE, but you know.

 

Yeah, no, I don't, yeah, whatever. Anyway, so that would be my third and final pick, and those are my picks for today.

 

Yeah, the James Webb telescope is really cool. I'm super excited about that. So thanks for pointing that out. I wasn't even on my radar to pick. Steve, what are your picks?

 

Sorry, I had to unmute there. Found a really funny post on the Babylon Bee. I'm a big fan of the Babylon Bee, a satire

 

They're

 

site.

 

so

 

Oh,

 

funny.

 

gosh, they're so good. But here's one that I think is very relevant and something I've heard among other people, standing desks. And the title is, the coworker standing at desk obviously just hasn't learned about chairs yet. So,

 

hahahaha

 

uh... Witnesses claim to have walked past co-worker Clarence Quail Bryant's office multiple times to confirm that yes, he had been in an uncomfortable standing position at his desk for hours, apparently oblivious to the fact that the company offers chairs to all employees. And he goes on for there.

 

There's this episode on Family Guy where he works for his father-in-law, who forces him to stand at his desk and call everybody else the chair people, just so that everybody will hate him.

 

Yeah, it's funny apparent a publishing time it was revealed that quail Brent was bringing Oxygenated Mongolian glacier water to work because he was obviously unaware of the free dr. Pepper in the break room But anyway, I will I will post that in the the show notes is pretty good Dad jokes the high point of the podcast at least for some listeners. Oh side note, Dan Did I understand you correctly on Twitter that you? and somebody actually mentioned the dad jokes.

 

Yeah, yes they did. You do have fans out there.

 

Yeah, probably not many, but I have a few.

 

Ha ha ha!

 

And they're diehard Ardent fans too, so I appreciate them very much.

 

I won't call them weirdos in public.

 

Ha!

 

I still remember the post from the guy who was complimenting the podcast and said, yeah, I like all the smart people and that funny guy. Thank you. Thank

 

Well,

 

you.

 

he did call

 

I think

 

you

 

that's

 

funny.

 

called.

 

Again, assuming he was talking about you.

 

Right.

 

It's yet to be determined.

 

Mm-hmm.

 

Well, I think of it as a backhanded compliment, if anything, but anyway, so I had a conversation with my wife the other day. I said, honey, I just saw a wolf. And she said, where? I said, no, the regular kind.

 

Okay.

 

Sorry, dang it, wasn't ready with the delayed rim shot. Sorry. Two mouses here. Let's see.

 

to mouses

 

And then

 

and to

 

I

 

mice.

 

went to see, mounted different computers, work,

 

No,

 

personal.

 

I get that, but shouldn't you say to mice?

 

Oh mice, mouses, Mises. I think Mises from the cartoon character. The two Mises. Anyway, I went to my doctor recently and he told me I have some really bad news. I'm afraid your DNA is backwards. And I said, and? Dan has a straight look, I'm hoping he got that one. Why doesn't Batman have supervision? Like supervision, you know, like Superman? Because his parents died. Somebody told me too soon on that when I'm thinking Batman's been around for how many decades?

 

It's not too soon, it's

 

And

 

Wait,

 

finally.

 

just

 

doesn't

 

not

 

have

 

that

 

super

 

funny.

 

oh supervision supervision doesn't

 

Yes,

 

have supervision.

 

Mm-hmm, mm-hmm, mm.

 

Got

 

his

 

it.

 

parents died,

 

Got

 

yes.

 

it. Okay.

 

And finally, this is today's joke. What is more disgusting than finding a worm in your apple?

 

Finding

 

Finding

 

half

 

half

 

a worm in

 

of

 

your...

 

a worm in your apple.

 

Well, that's as old as time, I think.

 

Does it? First time I've heard it, believe it or not. But anyway, those are my picks.

 

All right, AJ, what are your picks?

 

Well, first of all, I'm going to pick this. Canute cha. Virginica. There's there's a weird moth that showed up in my. In my room that is it's quite pretty and distinct and apparently easy to describe. So I just did a brave image search. For black moth with orange head and it it is unquestionably this this. the new cha virginica moth and it just looks, it just looks cool. It's friendly. I didn't realize this because I don't most moms that when I think of moms, they're, they're ugly. They're kind of this gray drab. The ish kind of like get out of here. You're sucking the color out of the room. But this one it, you know, it looked a little prettier because I had this splash of orange and, and it's got little in and tin. that moths

 

For

 

have antennae

 

our listeners,

 

that look like feathers.

 

just so you know, AJ is now putting his fingers on the top of his head to simulate antenna.

 

Yeah, he's pantomiming the

 

You just

 

antennae.

 

just just like that the character in that end game movie like that. That's what I'm doing.

 

Oh, Mantis?

 

Yeah, I think maybe I don't know actually, but it, and it moves, it moves them in opposite directions anyway, it's just, it's just kind of neat. It's been flying around and landing on stuff. Oh, it's back on the screen again. Now it's now it's back on my screen again. It looks kind of like a firefly, but a big firefly, but it's, it's a moth anyway. So yeah. kind of cool nature, gonna pick nature making its way inside. Cause I've been working on the four wheeler and I was working on it last night and I was leaving the door open because if I'm using any of the chemicals, the fumes are really bad and I don't want them to get in the house and there weren't mosquitoes out last night. Thank goodness. But as a result, now today I have a lot of extra wildlife, um, in the form of insects and in the office garage here with me. And then after that I'm going to pick a miss born yet again, I'm going to be listening to the second book or I guess listening to it for the first time because the first time I read it I think but yeah going through the Well of Ascension and gosh they're just great books. Oh excuse me great books. Also I'm going to pick Pitch Gauge

 

Yeah,

 

and

 

those are really... You want exciting books!

 

Yeah, you get it. You get you get me. I'm also gonna pick there's this thing called a pitch gauge. Turns out that measuring measuring bolts and screws is not is not so hard. Well, particularly bolts bolts are quite standard. It seems screws have a lot more variety to them. But anyway, just thing called a pitch gauge and it's like a set of 50 little teethy where you find the right one, it tells you what the pitch of the threads on the bolts are so that if you need to go replace say an old rusted broken bolts, you can get one that matches and be confident that it's the right one even when you put it into the rusty bolt socket bolt head. I don't know what you call what's the receiving end of the bolt, you know, and it doesn't go

 

A

 

in

 

nut?

 

because it's old and rest. No, not the nut. But because if the bolt

 

Okay.

 

goes into the block of the

 

Yeah,

 

engine.

 

I reach ya. Yep.

 

Yeah. So there, anyway, having a pitch gauge and then a little $2 thing with the whole sizes from from Lowe's makes me feel a lot more confident and also a thread repair kit. So there's these things that are basically like bolts, but much stronger and sharper. And if you've had a bolt that's, you know, like I and didn't come out easy and just a lot of gunk in there. You can put the thread repair kit through and it will clean out the way because it's got slots in the side. It's not solid spiral all the way around. It's a spiral with slots cut in. So the gunk and the corrosion and the nastiness that's keeping things from going in cleanly. You're going to put that in and pull it out and get all that out. So this is my foray into mechanics. That's my latest

 

Ha ha ha ha ha!

 

hobby. But the

 

Yeah.

 

four wheeler will ride again, I believe it. Even though I hooked up the battery backwards, blew a fuse and the only computer on the thing and now I need to get a replacement for that. Because there was dirt on the battery and I thought that I hooked the plus but I turned it around because yeah. But it will ride again, I'm certain of it.

 

I have screwed up cars working on cars. I've never put the battery in backward. I will just

 

Well, good. Normally one terminal is much larger and the other one's

 

Yes?

 

much smaller, but these are very small and

 

and they're usually clearly marked.

 

This one, it just has a raised indentation of a circle and a plus and a raised indentation of a circle with a minus and with the right dirt in the right places, the plus can look like a minus and the minus can look like a plus. Maybe I should clean that off, but, um, yeah, I just, I just, I got, I got turned around and I forgot that I had got that. I.

 

Mm-hmm.

 

Yeah. Moved it in that way. And. So

 

Yeah.

 

no spark, no spark.

 

So I'm gonna throw out some picks. The first one is I always pick a game. And the game I'm gonna pick, this is a relatively simple game. It's called Antidote, and it's a card game. And what you do is you pass out a certain number of cards and everybody gets two cards that are either a poison card or a syringe card. And sometimes you get two of the poisons. And what you're trying to do is you've pulled one of the poisons out, you're trying to identify the right one so that you can have the antidote because everybody's been poisoned. And so then you have basically antidotes and there are five antidote cards of each kind and you pass all those out too. And then you go around and every time somebody takes a turn, they can either trade a and pass a card to the right or the left, and everybody passes a card, or you can make everybody discard a card. And you're trying to figure out which antidote you need and get the highest number of that antidote that you can. And so whoever gets the highest number out there, so if somebody discards the five of that number, then whoever holds onto the four at the end of the game, that's their last card, they win. And that's how you play it. 25 minutes. But it's a lot of fun. You wind up, you know, looking at what people are discarding, you wind up trading a bunch of those cards, they have X's on them. So we call them X cards, but they're the poisons. And it was a lot of fun. It was really fun. And yeah, I forgot to look it up on board game geek. So I'll do that real quick. But Anyway, it was a lot of fun just to kind of play. And we played it a couple of times. Played it with the teenagers. Has a weight of 1.62. So fairly easy to pick up. It says on here 20 to 30 minutes. So we were right on par with that. We played it with about five people. I think that's probably a good number. You can play up to seven people. I'm imagining with two people, it's a little less interesting. Antidote is my game pick. I've been mentioning the JavaScript conference I mentioned at the top of the show. You can go to topendevs.com slash conferences. You can click it. I'll also get jsremoteconf.com pointed over there. That way you can go and check it out. The CFP is open. It'll be open through the end of September. I've already had a few people say they're interested, but I haven't finalized, and so I don't wanna announce, oh, we have so-and-so coming if I, you know, that's the week they're on vacation with their family or something. So we'll work that out. Really, really looking forward to that. If you're into Rails, we're doing a Rails one in September. And then we're gonna do some for some of the other frameworks and technologies that we cover on our shows, you know, So keep an eye out for that. If your company wants to sponsor, that would be awesome. You can just DM me on Twitter, email me, Chuck at topendevs.com. But yeah, that's kind of what I've been working on lately. And then I finished 1883, so I'm going to pick that as well. So good. So good. I think I liked it better than Yellowstone. Which is saying something because I really enjoyed Yellowstone. So I'm going to pick that too. I think that's pretty much it. So thanks everyone for listening. Until next time, Max out.

 

Bye!

 

Adios!