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

 

Hi from Tel Aviv.

 

We also have Steve Edwards.

 

Hahaha

 

Right, I'm Charles Maxwood from Top End Devs. We have JavaScript Remote Conference coming up in October. And I've confirmed so far for us, Abuka DJ, he's gonna come speak, working on getting the rest of the speakers lined up. If you wanna speak, the call for proposals is open through September. So go check it out, jsremoteconf.com. Yeah. Yep. Yep. I think Dan froze up, so I'm going to pause this upload for a minute. Yeah.

 

Well, I've been promised by, I've got a call like a few days ago from one of the representatives from one of the ISPs here that they're laying

 

Uh

 

out,

 

huh.

 

you know, laying out fiber in my street finally. So hopefully that will be eventually addressed, finally addressed.

 

Yeah, oh that'd be great.

 

Yeah. No, the last mile. They're literally supposed to connect my home. Yeah, exactly. No, there,

 

Yep.

 

there are a couple of streets nearby that already have fiber. So they're supposed, so it's just a question of, you know, like you said, the last mile or last kilometer or whatever.

 

Yeah, I'm

 

crossing

 

not gonna

 

my fingers.

 

talk about my city council pulling their heads out of any collective orifices,

 

Ha!

 

but they decided that they were gonna install fiber across the whole city. And we're one of the tech hubs here in Utah. I don't know what they were waiting for, but anyway. So apparently we're gonna get fiber sometime within the next forever. So they are not moving fast on it at all, but I guess I can't complain. I live all the way on the West side. So anyway, let's talk about what not to do in JavaScript some more. Because we kind of had that discussion before. We'll put a link to that episode in the show notes. I think it starts with splatty do because AJ said that and I thought it was funny.

 

Yes it was.

 

So I named it. Anyway, so do you want to give a little bit of context though as to why we're talking about these things, Dan?

 

Yeah, for sure. So again, we gave an intro about it in the episode as well,

 

Yeah.

 

but I'll give it again. So it kind of started with AJ tweeting out, you know, what are the JavaScript language features that you intentionally avoid using. And as we all know, AJ likes to take a minimalistic approach to programming languages in general. You know, he's a big fan of Go of JavaScript, partially because of the way in which that language has expanded to such an extent. And I responded to AJ with a whole list, and somebody says, well, it seems like you dislike most of the programming language, which is not true, which I don't think is the case. I actually like programming languages to be expressive. But anyway, so I thought especially given how we had conversation about the things that JavaScript developers must know and should know and should use or not and stuff like that. So I thought it would be interesting to talk about things that maybe they should know, but they should know better than to use. And that's how we

 

Yeah,

 

got here.

 

it's like that Ken has cheeseburger meme, right? Why you hate JavaScript? Dan, why you hate JavaScript?

 

You know, there's an interesting thing about JavaScript. I've been listening to this interview with John Carmack of ID Software fame, and he also talks about JavaScript. This will be one of my picks, so, you know, an

 

Mm-hmm.

 

advance notice for that. But he was also talking about JavaScript, and he was asked what he likes or dislikes about the language. is actually two things. It's a programming language, but it's also a runtime. And when you consider it that way, then you realize that it kind of serves multiple purposes. And being a runtime, you generally do want to be kind of minimalistic, but being a programming language and especially one that's being used by so many people, you want to be more, I kind of shifts your attitude towards what JavaScript should or contained or maybe shouldn't. Anyway.

 

Yeah, well it's interesting too because a lot of what we wind up talking about basically boils down to, you know, should they have added this or shouldn't they have added this to the language as far as AJ goes. And then some of it is also just, yeah, there are different ways that different things operate within JavaScript and they don't always align with what people think they do. And so sometimes it's... It's a word that's similar written and spoken, similar to English, but means something completely different. And so people often mistakenly use the word to mean the English meaning instead of the French or Italian meaning in the case that I'm thinking of. And so it would wind up confusing people. In other words, they would expect one outcome from the thing and get a different one. which the feature in JavaScript was created, and people assume that it works in all general cases the same way. So a lot of the things we're talking about is just, hey, look, this is going to keep your headspace clear. This will do what you expect every time. And then, yeah, some of the features maybe were less well-designed when they got in, or they didn't completely understand the tradeoffs when it made it through the TC39.

 

And there's another really important aspect here, which is the fact that in JavaScript, unlike many other programming languages, once something makes it in, it can never be removed. Because we distribute JavaScript in source code form,

 

Mm-hmm.

 

because everything in the web is supposed to keep working, you're never supposed to break existing stuff whenever things update. to JavaScript to CSS, once it's there, it's there for good

 

Yep.

 

in most cases. And that's not the case with many other programming languages that are compiled where you can choose whether to update the version of the language that you're using or not. So if

 

Mm-hmm.

 

you rely on some older feature, they can decide to remove a feature from the language rely on that feature and you can't remove it from your code, then, you know, worst case scenario, you stick with the older version of the compiler, you know, and take your

 

well.

 

time about getting rid of it. And

 

Yeah,

 

that's

 

the

 

something.

 

other thing I've seen is

 

Yeah.

 

that a lot of times those get pushed into libraries similar to what we do with like polyfills and stuff. And so you can include it in and as long as it doesn't create some conflict when it compiles with the rest of the language, a lot of times you can keep those features around but they drop them and you can't count

 

Yeah,

 

on them being

 

for sure.

 

there.

 

For sure. And again, that's something you just can't do with JavaScript. I think one of the features, language features, that should not be used that we discussed in our previous conversation, the with keyword or with statement is one of the really few things in JavaScript that I can think of that's been effectively removed out of the language. There are very few such examples that I can think of.

 

Yep.

 

So

 

So

 

anyway, we want to go

 

yeah,

 

start

 

let's

 

going

 

get to

 

down

 

our list.

 

our list. Yeah, so

 

Yep.

 

this list, I want to say in advance that the previous list we had were the features that I considered more obvious or less controversial. Interestingly, we ended up arguing about some of them anyway, but this list is more, how would I phrase it? which I guess maybe it's a good thing that AJ couldn't make it this time. We could never have dug ourselves

 

Fight, fight, fu- oh, sorry.

 

out of some of the rabbit holes.

 

REEEW! Catfight!

 

Yeah, exactly.

 

Well, some of the rabbit holes are informative, right? It's like, okay, you know, cause it forces us to clarify the trade-offs, right?

 

Oh yeah, for sure. I mean, if we all were in total agreement about everything, this would be a really boring podcast, I think.

 

Yeah,

 

Anyway.

 

we'll just read the manual next time. Anyway.

 

So, the first language feature that is really, you know, kind of ubiquitous in the language and really used a lot and I think is actually fairly poorly designed and should be avoided operator and in particular when it's used in the context of the for loop as in for in That usually does not mean what most JavaScript developers exactly expected to mean It doesn't do exactly what they expected to do and and there are better alternatives in the language to be used instead so

 

Give an example of how they're expecting something, but it's not doing what it's, they think it's doing.

 

Yeah, for

 

You

 

Oh

 

know,

 

example,

 

it's like, it sounds

 

in

 

like, it sounds like a princess bride, you know, I do not think that word means what you think it means.

 

So the in operator basically takes, you know, you apply it to an object and you give a name of a property, the literal string name of a property, and

 

Mm-hmm.

 

it returns true if that property exists in the object and false otherwise. But it turns out that it doesn't just check that object but also traverses up the prototype chain. that particular object instance, but then looks at its proto property, goes up the chain all the way to the root object. So in most cases, for example, if you do an in on toString, for example, you would usually get true because almost all objects in JavaScript derive from the base object and that implements toString. So, everybody effectively has toString. want to check for the existence of a property, they want to do it in that particular object instance, not traverse up the prototype chain. And for that, JavaScript actually has the has-own property method, which does exactly that. rather than the in operator if that's what you want to do. The other thing is that in kind of exists because JavaScript objects are so dynamic in nature. So you kind of, you know, you pass, you have an object and you don't necessarily know what the structure of that object is. what to do accordingly. And it turns out that that's an approach that's kind of problematic. If you're using an object as a dictionary, you probably should be using a map instead. And we discussed that in our previous talk on this subject.

 

Mm-hmm.

 

And if you're doing it because you're kind of doing duct typing, well, these days with everybody that's kind of going out of fashion as well, effectively,

 

Yeah.

 

whether we like it or not. And as I mentioned before, 4IN was in particular problematic. First of all, it used to have this problem where the order was not determinate, and that's always a problem, and that actually got fixed.

 

Oh, I can see that being a problem, yeah.

 

But that actually did get fixed.

 

Oh, okay.

 

version of which ECMAScript version they fixed it in, but they actually did specify the order. So that at least was addressed. But the thing is that in most cases what you are really interested is not the keys. For in basically

 

Right.

 

iterates over the keys. What you're really interested in most cases are the values. And so what

 

Yep.

 

you really generally want is something is for of. also has this association with iterators. So basically what you usually want to do is you want to use something maybe like object keys or object entries and then use for of instead bottom line

 

Mm-hmm.

 

for in is kind of like that black sheep of the family and there are better ways to iterate over collections. Let's put it this way.

 

So are

 

So.

 

you saying you should use four of or? I

 

っ

 

always reach for like four each or something like that.

 

Well, here's the thing. And we also touched on that in the past. So I'm a big fan of iteration methods, like map or filter, because they're very explicit. And they have this

 

Thanks for watching!

 

declarative approach. If you see a filter, well, you know what it does. It filters. If you see a find, you know what it does. It finds something. When you look at a generic loop, like a for-of, reading the code you don't know what it does. For each is actually not such a great example of an iteration method because it works via side effects and it's also not very descriptive really. So out of all the iteration methods for each is kind of like, I don't know, the one I dislike, one I also try effectively not to use. But there's another issue. If you're doing asynchronous stuff, if you're using asynchronous weight, you can get into all sorts of issues or problems if you try to do it in iteration methods, because you don't inherit the asynchronous nature of that iteration into those iteration methods, if I'm trying to say. It's kind of difficult to explain in a podcast, but if let's say I have an async function and inside of it I'm iterating over some collection and I want to, and let's say it's a collection of promises and I want to suspend that entire async function for each or a map for it because

 

Okay.

 

because those inner functions They are distinct from that outer function and don't inherit its it's a sink nature as it were and even if

 

Oh,

 

I

 

using async away with loops like that is an absolute nightmare.

 

Hahaha

 

I remember having to deal with that before. It's, I still can't remember what I did. I just remember having to work around that.

 

Well, you basically just use for-of instead. You know, that's probably the easiest thing to do in most cases.

 

Yep.

 

If yeah, but I agree, it's a problem in the language. You know, if I'm looking at a different programming language like Kotlin, for example, they actually have a much nicer solution for that. So in those cases, it is kind of inherited into those inner functions, but that's not the case in JavaScript. And so yeah, if you wanna do a wait inside your loop, you probably want to use for of instead. Anyway, so but going back again, I would say that in as it for in is not is something that I would generally recommend to avoid even though it's such a basic part of the language. So I actually didn't put it in the list, but I mentioned it during our conversation. So I'll mention it again. is probably something that's usually not a good idea. Again, the whole benefit of those iteration methods is that they're really explicit about what they do. You break the iteration into a sequence of sub-operations. Each one, it's very clear what it does. So you filter something, then you map it, then maybe you filter it again, to sum it up or whatever. And for each, like I said, is, first of all, it's not very descriptive. You don't really know what it's doing. And even worse, it works via side effects because it doesn't really return anything. So, you know, if you're just console logging the entire content of the collection, well, okay, I guess. But otherwise, you know, if you're going to for each, just use a regular for loop. I actually find it cleaner in most cases. So anyway, the next one I think is going to be really controversial and that's the else keyword. I think that else is something that's usually best avoided. Any thoughts on that?

 

Why?

 

Why am I here?

 

Yeah.

 

No, I mean, so I've used guard clauses, I've used, I'm trying to think of what else I've done besides else, but sometimes you need it to do one thing or the other, I mean, a ternary operator's nice if you can get it all on one line and not make

 

Ha!

 

it this

 

Monstrosity.

 

complicated, heinous mess, right? I don't know, I mean, why wouldn't you use else?

 

So first of all, before I dive into that, I do want to mention, and I said it before in our previous episode on this topic, that only Sith deal in absolutes. There are exceptions to every rule, and I'm sure you'll find situations in which else is the best tool for the job. which I'm just saying that in most cases, I find that my code is clearer and cleaner when I don't use it. And what I usually use instead is I try to have simple short functions with early returns. So basically, I do if something, return, if something, return, or if something, do something, and return, if something, do something, and return. And then so you're kind of, every time you're not collectively falling into an health.

 

So I think the correct, the other term for that that I've heard is short circuiting, right?

 

Exactly. Short circuit is also what is done in Boolean expressions in JavaScript, like you know, in other languages like C or C++. You know, when you have the, let's say the logical OR operator, the two lines or the logical AND operator, it also does short-circuiting. So for example, if you've got the logical OR, if the left-hand side is true or true and operator, the two up and percents, then if the left hand side is false or falsy, it never even evaluates the right hand side because there is

 

Right.

 

no point, because it will be false regardless. So you've got short circuit in in Boolean expressions in JavaScript and I also like this approach for conditionals. And is that it allows me to set and forget. I do an if statement, I check a particular condition, I handle that condition, and then I get out of there. I cut out of the function, and I don't need to consider that condition anymore. So for example, I can check that something is, let's say, undefined, I do something and I leave and from that point on I don't need to worry about that thing being undefined anymore and you know really usually by the way typescript is smart enough to to do this for me and When I have an else I Kind of need to think wait a minute What is what if statement is this else associated with and I need to scroll up? Condition and then say ah, okay. So now I'm effectively the reverse of that So I kind of I have to keep all those previous Conditions, you know in in my head and and I can't just you know Ignore them from that point on because every time I see an else I kind of need to match it with the with the appropriate if

 

Well, with a little code formatting, it's pretty easy to do

 

Well,

 

from a readability standpoint.

 

not necessarily.

 

I mean,

 

Um...

 

I mean, tools make it easier. You can collapse and expand and stuff like that. But still, it scrolls out of the screen or whatever. And I just like to set and forget. And I find that short-circuiting is a much cleaner approach for me for achieving that.

 

So in other words,

 

Thanks for watching!

 

you're putting your else in a separative statement in return if that's true.

 

Well, I don't even need the else. I have an if for the if and I have a return at the end of the if.

 

Okay, so then you're writing another function for the else then? I mean,

 

no

 

there are legit cases where you'd

 

let's

 

have

 

say

 

to do either this or this.

 

so so basically let's say i i i test the condition x and i do either a or b so you might write it as if x you know a else b i would write it as if x a return and then just b and i can't get to the b if the x existed because i'll hit that return state

 

So...

 

But what if there's more you need to do?

 

Then

 

What

 

I

 

if

 

put

 

there's

 

it

 

more

 

in,

 

past that?

 

so I put, that's why I said that it goes hand in hand with having small functions. So, usually I'll separate this entire sequence of doing this or that into its own function, and then I would call that from the containing function that would have done the if, you know, I would have had the if else in it. Now obviously, if all you have in the if situation is like one line, and all you have in the and they're really simple lines, then you know it feels like, I don't know, maybe too much effort. And in that case, like I said, you know, there are no absolute rules here. But you know, in most cases, I tend to avoid else.

 

So I- It's funny because usually you and AJ get into stuff and I'm just like, I can see both sides. On this one.

 

I think it depends on

 

A

 

the

 

RIT-

 

case. I think it depends on the size. I think that Dan's approach works when you have small cases, but once you start getting a bigger code, you're having to jump around between functions just to look at how a particular

 

Thanks for watching.

 

case

 

Bye.

 

is handled. I think that's gonna get messy real fast.

 

Actually,

 

Yeah.

 

I find that that's the opposite situation in most cases, because if I name a function appropriately so that the name describes what it does, again, I don't have to jump into the function to figure out what it does because then its name tells me what it does. So basically, having an if-else in the middle of the code is kind of, to me that here I have a bit of complicated logic and it makes sense to break it off into a separate function. Now if I have a problem naming that function because what it does is so trivial that I can't come up with a truly descriptive name, then maybe, you know, maybe it does make sense to keep it in where it was supposed to be and just use an if and an else. But in most cases, you know, I like to keep my functions lean and mean.

 

So what's your

 

Dope.

 

opinion of ternary then?

 

Sorry?

 

What's your opinion of a turn area, a simple turn area, a one line turn area?

 

A one-line ternary I can live with, again, but once it becomes, you know, once you got to start indenting that thing, it's probably...

 

Oh yeah, I mean, you can,

 

Yeah.

 

I've seen examples of, you know, three levels of embedded ternary's within one. And that's, I mean, that's a mess. There's no point in that, but, but I mean, just to simple, if this is true, then do this, or return this, other than that. I do that in computed values all the time in view or any number of cases. So I think you can't get much leaner and meaner than a one line ternary for an FLS,

 

Oh yeah, and

 

you know, if it's

 

Yeah.

 

very simple.

 

also

 

Yeah.

 

I agree with that. And also ternaries work really well with the const because you kind of, when you have an if else and you're trying to use that to set some value, you need to declare it using let or var out before the if, and then, you know, sign the value in the various clauses. And with a ternary, you can just make it const. So, and again, that's kind of, you know, necessarily such a nice aspect of the language but you know there we are and like you say if it's a simpler ternary expression then I'll keep it and if it becomes complex then I'll probably break it off into its own function again and give it a name

 

So the thing that I'm reacting to with this is that I have this visceral reaction to using return as control logic,

 

Thanks for watching!

 

or as a control function. So you're effectively saying return because I'm not going to execute the rest of this function. I think what you're controlling for is actually, yeah, when you get the long procedure inside of an if and then another one inside of an else. problem, that's a code smell, right? You should be able to extract

 

you

 

those out into their own functions and then keep it simple to where you can either do a ternary operator or an if, do this, do this, do this, else, do this, do this, do this, and it's just these simple calls to other functions. The idea of just saying, hey, return, because

 

you

 

the conditions met, I only use that for like I'm expecting a string return if I didn't get a string in my arguments, right?

 

But

 

Otherwise,

 

I,

 

I'm just down to...

 

yeah,

 

But

 

I

 

even

 

get

 

then,

 

what

 

it's

 

you're saying.

 

throw an error, right?

 

Yeah, I get what you're saying, but I just basically consider all logic like that to be kind of guard clauses. Like, what's the big difference, really? And now I get why some people, especially, to an extent, old timers maybe, are kind of reluctant about

 

Hey

 

return.

 

hey hey hey hey. Ha ha ha.

 

you know,

 

I know. Ha ha

 

because

 

ha.

 

it kind of smells like a go-to, you know, and

 

little bit.

 

we've experienced languages, programming languages that actually used go-to, and then we were told and banged on the head with a hammer that go-tos are evil, you know, that famous Dijkstra article, go-tos are harmful So,

 

Boy, that brings back memories of basic on a Commodore 64

 

Yeah,

 

in the mid

 

for

 

80s.

 

Hehehehe

 

sure.

 

But you could do it easily. You could easily do a loop with GoTo and fill up your screen real fast, which is fun when you're a teenager first messing with programming.

 

Yeah...

 

Yeah, the interesting point that I once heard in this context is that the problem is not the go-to, it's the come from. That you don't know how you got to a particular point. So that's kind of the problem with a go-to. But anyway, so those of us who experience languages where go-tos were prevalent, like basic, kind of carry the scars and then a return kind of smells like a go-to. But once you get over that, and you You know,

 

Thanks for watching!

 

most developers these days, I don't think, experience languages that make use of go-tos. And then again, if you keep your function small, there's no come-from-problem here. You know exactly where this return is going to send you to because it's all, let's say, the function fits on your screen and the return just sends you to that bottom of that function and that's it.

 

Yeah, see for me, return means you asked me for this, here it is, right? And

 

Okay.

 

if I call return, I like to return some value, something that you asked me for,

 

Exactly.

 

you know?

 

Usually

 

And...

 

it's the result of the computation of that if. The if

 

Right.

 

says, you know, if something, do something, that something that you do generates some sort of a value and then you return it.

 

Yeah. But, but anyway, so to my thinking then, if I'm calling return, it means, you know, you know, here's the thing. Um, whereas if, if I have an if else, it's just part of the procedure. But yeah, you know, it shouldn't get that complicated. If you're nesting ifs and else's, you're going to, you're going to get lost in them. If you have a big long, you know, um, body to your if. and then another big long body to your else statement, you're gonna get lost in it, you

 

you

 

need to break that up. But yeah, I just don't think of return as a control statement to say, hey, done executing. I guess that is what it means. But yeah, for me, it's just, it's not an approach that I would use. I would much rather just use the if else, and then, you know, return whatever it is that they're asking me for at the end of the function.

 

All basically as I'm saying is once If if the if else is really really small Then I'll

 

Hmm

 

probably end up with a ternary expression and if the

 

Yep.

 

if else becomes bigger then I end up splitting it into its own function and Once I split it into its own function rather than using if else I just do if Return and then you know the other condition

 

Right.

 

And like I said, I like to keep my functions really small and concise.

 

Yeah.

 

And that's the way that works best for me.

 

Yep, that is the way of less pain, usually.

 

Yeah, what I tend to see when I see if-else's in code, usually from my experience goes hand in hand with overly complex functions and logic, and it really quickly gets to a point where it's difficult to follow. That's been my experience. But again,

 

Yeah.

 

this is just, you know, this is my opinion. Something for our listeners to try out, consider, try out and see how, you know, whether they like it or not. But I totally accept that some people might have a different opinion on this. I

 

Mm-hmm.

 

actually think that this is something that AJ tends to agree with me about, but we can ask him when he's back on.

 

Yeah, yeah, my approach is just if, if I have to scroll up to see what the if was from the else or the if, then I need to break out a function. I need to pull this stuff off and do it somewhere else so that it's clear that this is what's happening.

 

Usually needing to scroll is an indication to me

 

Yeah.

 

that the function is too long. I

 

Yep.

 

like my functions

 

Yep.

 

to fit in the screen.

 

That's effectively what I'm saying here too. And once you have that body of the if and body of the else in different functions, you can usually abstract it into a ternary operator unless your conditional clause is long or

 

you

 

complicated, in which case you can move that off into its own function too.

 

Yeah.

 

That's why I like to have a 32-inch vertical screen. I can fit a lot of function on there.

 

You're the one that one of the people that turns their screen on the side, you know, so you can have longer functions

 

Exactly, just for that reason alone.

 

I remember the days where...

 

You should see all the comments he puts in those functions too.

 

Code comments, that's one that I didn't bring up. You know, that's an episode on its own, whether or not we like code comments.

 

Yes,

 

Ugh.

 

Steve's Functions. It's a novel and functionality.

 

Well, I actually throw some dad jokes in there too to keep people on their toes. And so that tends to make things longer, but that's another discussion.

 

Yeah.

 

Anyway, what were you saying, Dan?

 

No, so, oh yeah, one more thing. When I mentioned else as something that I like to avoid using in that Twitter thread, somebody asked me, well, what about else if? And the thing is that JavaScript doesn't really have an else if. It has an else

 

I hate elsif.

 

and it has an if. When you write else if in JavaScript, effectively what you've done is simply not put in the brackets. So, yeah, you might as well have written else, open curly brackets, and then in the if. And yeah, so given the fact that there is no, you know, I recall some programming languages that actually have an lf keyword, but, you know, that's not JavaScript. And consequently, if I dislike else, then I obviously dislike else if because it makes the logic with breaking it up into that short circuit approach, I can have a sequence of really simple if statements, one after the other, which are effectively like an else if, but without that thing of having to go back up and figure out, yeah, wait a minute, what is this an else for? And did I put the if in the correct place? So maybe it should have been, you know, the indentation can get really tricky really quickly with these sort of things.

 

Yeah, for me, the LSIF isn't the indentation and it's not that it's branching logic where you can have now more than two branches. The issue for me is that you're effectively breaking up the conditional for every other condition that you can have because it's not the first case and this case. It's not the first case or the second case and this case. And that, you know, then I have to cross my eyes and go,

 

Hahaha

 

okay, so it's, you know, string and it's it happened in 2022 and right

 

Exactly.

 

you know it that's my problem is that it breaks up that conditional clause and it just makes it really tricky to figure out and

 

Well, you

 

so

 

know the solution for that is code comments. Anyway.

 

Yeah, because our

 

You

 

compiler

 

know, sometimes

 

is valid.

 

you have to.

 

Yeah, compilers

 

But,

 

validate code

 

yeah.

 

comments, right?

 

Exactly. Hey,

 

So

 

I think

 

in that

 

we've...

 

case, I would rather have the if else and then if else because you're still breaking up the conditional, but you know you're doing a binary switch every time. I don't know.

 

Anyway, I think we've flogged else looking at the rest of our list that we have left to go

 

Yeah, so

 

and time

 

let's

 

left.

 

move to the next one. One thing, so the next one is also gonna be kind of controversial, I guess, or maybe not, let's see. I really wish that JavaScript did not have null. Or, yeah, or put it differently, the fact that it has both null and undefined is a shame. It should have only had one. And

 

Mm-hmm.

 

consequently, I tried to avoid using null as much as I possibly can and just use undefined. Now, you might ask, well, why not the other way around, especially given that null is fewer characters to type and probably also more familiar to people coming from other programming languages. And the answer is that in JavaScript, you really can't get away from undefined. If you get the value of a property that doesn't exist or a property that hasn't been initialized variable that hasn't been initialized, what you'll get back is undefined, not null. So null is something that you need to explicitly set into something. So undefined is kind of built into the language, you can't get away from it, whereas null is something that you kind of explicitly use. And given that, I tried to avoid using null. Now, if we did not have the undefined as a word in the language that you can use, it actually also has the undefined value, it would have been more problematic, but it does exist. So really, there's hardly any reason to actually use null that I can think of. There are a few cases, unfortunately, in the language where you kind of have to use null, and I'll touch on one of them in a bit. But generally speaking, you know, if I can, I really try to avoid it. Now, per originally into JavaScript, it was kind of influenced by databases where there's a difference between not having a field versus having a field that doesn't have a value. But it turns out that most people don't really care about this distinction so much.

 

Mm-mm.

 

And at the end of the day, it kind of just created noise into the language. the recently added nullish operator, and because we can't just check for undefined because

 

you

 

it might be null, or we can't just check for null because

 

Mm-hmm.

 

it might be undefined. So we need an operator to deal with it, the two question marks, or the optional chaining where it needs to handle both null and undefined again, because life. And also, the fact that type of a null object rather than whereas type of undefined is undefined is yet another advantage for undefined.

 

So most of the programming that I've done, and I've done a handful of languages, they all have a null, nil, whatever, right? And effectively what it means is we don't know. And some people try to use it as falsy

 

Thanks for watching!

 

or use it as hasn't been set up yet or use it as, right? And so it has all these definitions. I think I'm defined as just more honest.

 

Thanks for watching!

 

We haven't done anything with this yet,

 

Yeah,

 

right? We

 

exactly.

 

don't know what this is.

 

You know,

 

And that's what it is anyway.

 

maybe in an ideal world, what is undefined in JavaScript would have been called null and we wouldn't have had both, but it is what it

 

Yeah.

 

is. We have both of them. And so consequently, I really try to avoid using null. Another interesting issue with null, by the way, is if you have, let's say, an optional argument in a function, if you pass in undefined, value that you specify in the function declaration but if you pass in null then you won't you'll get null and and that's another example of where undefined probably has a closer behavior to what you know is actually intended in that situation

 

So can you ever run into a situation where null is undefined?

 

Par null.

 

Yeah. The one thing

 

Hey cool

 

that

 

son.

 

I, yeah, there are, like I said, there are a few

 

Hahaha.

 

cases, yeah, there are a few cases in the language where unfortunately null was chosen. For example, if you use match, the regular expression match and it doesn't match, then it returns null rather than undefined. And I'll give another example where null is a requirement. to the next item on my list. But bottom line is, why have to use null because I have no choice? Well, obviously I have no choice. But otherwise, I just try to avoid it and use undefined wherever I can.

 

Yep.

 

Anybody disagrees?

 

Nope, not here.

 

I actually use NO quite a bit more than undefined. The only time I've ever really used undefined is when something's returning it. I have to check with typeof to see if something's returning undefined and then handle this case from there. But I usually don't

 

And why,

 

assign values as undefined.

 

and why do you use not because it's fewer characters to type, or do you have any like intent there or just because you're used to it?

 

just because I'm used to it. I mean, partially because I'm saving finger stress,

 

Ha

 

having

 

ha!

 

to type four characters instead of eight. That's, think about it, that's double the work. So I'm just being efficient.

 

Yeah, it's like, you know, there are a couple of things that the choices that the bed and I make in the language like, you know, Function you having to type the entire word function rather than just fun or funk or something like that um, but um Yeah, so

 

Maybe Funky, yeah,

 

Yeah

 

I should've used Funky.

 

so

 

Well, when you're writing a script language in 10 days, I mean, you gotta make some quick choices.

 

Yeah.

 

Yep.

 

And again, undoubtedly undefined is kind of, you know, kind of long. How many characters is that? Eight? But no, nine. But and that's kind of unfortunate. But yeah, but still, you know, they kind of mean the same thing. There's no extra value in using And like I said, I can't get away from undefined, but I can't decide to avoid using null. And so I try to steer clear of null. Anyway, moving on to the next one. This one has an interesting story about it, and that's the object.create. Are you familiar with it?

 

Not really.

 

Yeah, this is one of those cases.

 

I used object as I think object assign is what I use most of the time. Like when you want to do a deep copy, but no, not object create.

 

So this is an example of something where I'm saying you shouldn't use this and people are going like, whoa, I didn't even know this existed. But so I'm telling people not to use something that they probably didn't know about. But anyway, if they somehow do know about it, then they shouldn't use it. And if they see it in the code, well, now they know about it and know why they shouldn't use it. create is yet another way for JavaScript code to create an object instance. The simplest use is you do object.create and hand over a reference to another object, which would be used as a prototype. And it will return an empty object that has what you pass in as a prototype as its prototype. So it's another way to create an empty object. So if you think about, if you do like curly braces and then immediately close curly braces, that's an empty object that has the simple object, big O, as its prototype. That's why it has methods

 

Thanks for

 

like

 

watching!

 

toString, for example, which we mentioned before. But when you create an object with object.create, you need to explicitly specify what the prototype is. as in null, in which case it won't have a prototype. So you can literally create an object that has

 

Thanks for watching!

 

no prototype. And that was kind of useful back in the day when you were using, let's say, object as dictionaries, and you wanted it to work with in operator. So here you see all these things that I recommended not using all coming together. Now, the funny thing about this one originally proposed by Crockford Douglas Crockford, I even found a link to the article where he proposed it and where he gave like simple Implementation how to actually polyfill it into the language when it doesn't exist

 

Thanks for watching!

 

But I but it turned out to be an actually not such a great idea and and where he even admitted it, that at the end of the day, he doesn't really use it anymore. And it's a shame that it was added. So you could use it in two ways. Like I said, you could either just pass in the prototype reference, and it would create an empty object. And that's kind of a bad idea, because that means that you now use imperative logic or imperative statements to add properties into that object you constructed. something with no properties on in it and then, you know, using statements just add stuff into it and that's like a bad idea in most cases.

 

Frankenobject.

 

Yeah, exactly. It's a bad idea for constructing objects generally. You want to declaratively construct objects and especially in a language it has such great support for object literals. I mean, why go there? The is actually to pass in a properties object, kind of like the defined property or defined properties. And that's a very verbose and unreadable way to construct objects. I'm not even going to try to describe it in a podcast. If you're interested, just, you know, check the MDN for object.create and you'll see examples. But it's very verbose, to TypeScript and stuff like that and, you know, like why? So it just turned out that it was a bad idea. That's it. You know, if you want to create objects, just use object literals. And by the way, these days you can even explicitly specify the prototype in an object literal using the underscore underscore proto underscore underscore property, unless you really know what you're about.

 

Yes, I think we need to be very objective about that.

 

Yeah, where's the drum roll? Okay, here we go.

 

Sorry, sorry for those who think drumroll should only be for dad jokes at the end.

 

No, they should be for other stuff as well.

 

As I was told on Twitter.

 

You know, they should be for other stuff as well. It's just that we had an episode that for some reason,

 

Hehehe

 

like every other sentence, we had the drum

 

Hehehe

 

roll.

 

Yeah.

 

It kind of was stuck on loop or something. Anyway, so

 

This had an itchy trigger finger that

 

yeah,

 

day.

 

exactly. So object.create is basically something that you probably didn't know and if you didn't know then it's a good thing. but you also know to avoid it and you know, let's move on but I

 

the more you know.

 

Yeah, I will put the link to the art to crock first article that I did find in the show notes So if you're interested in in his original reasoning back from 2008 I believe into why it should be added to the language then you can read it there Another thing that oh, this is something that I'm seeing more and more in code and I really hate it now are like drawn to it. There are even like one or two advantages to it, but that doesn't change the fact that I really hate it and I don't use it. And that's creating named function using the arrow operator. So writing something like a const foo equals open parentheses something close parentheses arrow and then you know the open curly braces and then whatever. really don't like it. If you want to declare a function, we have the perfectly expressive and informative function keyword to do just that. Why use the arrow for it? I just don't, I really don't get it. It's like some people felt like arrow is the new thing, arrow everywhere, like function is deprecated, well, it totally isn't. And I just, you know, I like to say what I mean and what, and when I create a named function, I like to create it using the function keyword. That's it.

 

so you don't get the point of arrows.

 

No, I totally get the point of arrows. I use arrows a lot.

 

I was trying to make a dad joke, sorry.

 

Ah,

 

I got it.

 

okay,

 

I got it.

 

okay.

 

Anyway,

 

Yeah,

 

so

 

I'm slow.

 

I do have a question on this though, because sometimes I see it, I agree with you on the point of const function name equals arrow function, but I also see it semi-frequently on things that have a callback in them, right? So it's something and then you pass it a callback function and I see those callback functions defined with an arrow.

 

Oh, I'm-

 

Or

 

No,

 

does

 

no,

 

that not

 

no,

 

bother you?

 

no, no. For those I do use arrows. When it's anonymous,

 

Okay.

 

I like to use an arrow. I like to use arrows when they are effectively part of an expression. It also generally means that they need to be kind of short.

 

Mm-hmm.

 

They need to be, the code needs to be, it's almost a one-liner by definition, you know, sometimes it might be two or three, but really short and the code must be obvious. Like you can look at that code at a glance and immediately figure out what it does. isn't, then you need to give it a name. And if you need to give it a name, a descriptive name, then I like to use the function keyword. Now, there is one advantage to using const, which is that it makes that name const. If you try to reassign to that name, you'll get an exception, which is probably what you want. Like you generally don't

 

Mm-hmm.

 

want to reassign to functions, but it does potentially introduce a whole can of worms on hoisting because when you create functions like that using const or let or var or whatever and assigning an arrow function to that, you don't hoist that function definition to the top of the scope.

 

Great.

 

And that's really potentially problematic. That function doesn't really exist until you get to that line of code. And especially given that I like to put the higher level functions at the top and the really specific functions at the bottom, that kind of is problematic or potentially even dangerous when you're using const with an arrow. You will run into situations where you think a function is defined and because the execution path was slightly different, well, all of a sudden it isn't. So you kind of are then forced to put these at the top and I really don't like to put them at the top because it means that I'm reading the functions when I don't yet have sufficient context to even understand why they're needed.

 

You know, it's interesting that you say that because I've written code where it took that approach with the const and I just realized that that was my issue with trying to order everything in the right order so that it would run. And if I just use the function keyword, it would have hoisted everything and figured it out.

 

Exactly. And I don't, and again, I don't even, I don't really know why people do it. It's like, it's like, sometimes when I ask, you know, people, why, why did you do

 

const

 

it?

 

is cool.

 

They say, because that's the modern way. That's, that's how JavaScript is supposed to look these days. This is what the exam, code examples that I'm seeing look like, you know? So basically it's a for very specific things. I mean, look, in an ideal world, if instead of function, if Brandon Icke had named it Fun, let's say, F-U-N, then maybe it would have been so short enough that we wouldn't even have needed arrows. But I get why using the function keyword is too long for anonymous functions. And also, I do like the fact that if you don't put in the curly braces, then you also get the implicit return. It makes the use of such arrow functions really nice as function expressions and stuff like filter or find makes it even more readable. At least in my opinion, AJ might disagree. But again, I just don't get it in the context of named functions. Even one liner named functions, I prefer to use the function keywords. I like to be explicit. ordering issue that's the result of you know avoiding hoisting.

 

I'm lazy so the ordering issue sells me on this. Right, cause I don't think about it.

 

Yeah, okay. Now that I've convinced you, let's move to the next one. The next one is one that I'm personally, I'm kind of, you know, I'm kind of unsure about. Some, some, it's one that I've kind of debated with myself whether or not to add it to the list, because on the one hand, I dislike it. And often when I use it, I end up refactoring the code and it kind of goes away. But On the other hand, it's kind of needed. So I don't know. It's the switch keyword. It's useful in certain cases like reducers, but generally I find that, I don't know, maybe it's just the syntax that JavaScript got from Java and from C, you know, maybe if we had proper, the match that you have in certain programming languages, maybe I wouldn't have disliked it so much, but I just find that I dislike the switch statement. Yeah, that.

 

I agree, switch statements never work the way that I expect them to ever in any language. Like I always wind up having to debug them over and over and over again.

 

Yeah, the fact that the case clauses aren't a scope is an issue. The

 

Yeah. Yep.

 

fact that you have a fault through and you have to use the break keyword,

 

Mm-hmm.

 

the fact that if you don't specify a condition, it kind of skips the entire switch, which kind of brings up the question of why do I even need a default, and why is it called default and not else?

 

Right.

 

and stuff like that. Ordering is never trivial. And you know, it's kind of not such a nice, it just has this annoying syntax. And also it seems to kind of create this kind of coupling because in like in strictly Thai programming languages, especially the more modern ones, by the compiler to match all the possible conditions. And if you don't have this ability to fall through, you have to be really explicit about, you know, you can have like an else or a default, which is a catch-all, but if you neglect that, the compiler will actually scream at you that you

 

Mm-hmm.

 

need to cover all your bases. And that certainly does not exist with switch. easy to forget something, which means that you've created a tight coupling between all the various values that can be assigned to a variable anywhere in the code and all the switch statements that are associated with that variable. And it's just not nice. That's what I think. So I try to use dynamic dispatching instead a lot of times, which is basically on as some sort of a key into some sort of a map or an object or something and then having and selecting the method to execute this way, you know, or just even using ifs. I just don't like switch. What can I say?

 

I was already on that train with you, so...

 

Yeah, I guess it's one of those things where there are, you know, as you said earlier, there's exceptions to every rule and there's cases where no pun intended, where switch works well. But I think, yeah, as a primary structure within your code, it's probably not the best.

 

Yeah, it's also, again, it tends to be so verbose. It's always, you know, like I said, I like to keep my functions lean and mean and short. And with Switch, they always end up being, you know, long and complicated. And anyway, by the way, an interesting fact about Switch statement in JavaScript is that some people don't know in other programming languages, like let's say C, Switches are often translated of a lookup table or a jump table. Whereas in JavaScript, it actually is like a sequence of ifs. So you can actually in JavaScript reverse what you put in the switch and what you put in the cases. What I mean is that in, let's say, in C or in Java, what you put in the switch statement, that's the variable. What you put in the case statements. to be constants. In JavaScript, you can actually reverse it. You can actually put expressions or variables in your case. So you can do like switch on true, and then do a case expression, case expression. It will stop at the first expression that is truthy. You know, try it out. It's really funny.

 

Yep.

 

But, again, be that as it may.

 

Ruby does that too, because it evaluates it on a triple equal,

 

Yeah, so

 

which is a fuzzy match.

 

yeah, and again, that's so just goes to show that there really is hardly any benefit even over a sequence of ifs. And again, given that, I just don't like it very much.

 

Yep.

 

The last item that I have on my list, unless you have additional suggestions, is something that again, I'm probably I'm doubtful that many people know even existed. Maybe people who use Svelte might have become familiar with it because Svelte kind of uses it for something really specific. But anyway, it's the fact that JavaScript, despite not having a go-to statement, actually does support labels in the code. So you can an identifier colon, and that would be used in your code, and that would be used as a label. And what you can do with it is that you can label loops, and then you can use that label in a break or a continue to specify which loop, let's say, to break out of. So you can have, let's say, a loop within a loop, and if you want a break in the inner break out of the outer loop,

 

Oh, interesting.

 

you can actually use a label to name, as it were, the outer loop, and then do break space in that label, and you would break out of that outer loop. Now this is way too close to go to for my liking. If I have this type of a scenario, I would usually put these loops inside a function and then return out of it or

 

Mm-hmm.

 

something like that.

 

Yeah.

 

Like I said, it's way too close to a go to for my liking. What do you think?

 

I agree. I do functions. If I have to nest loops at all, I'm reaching for, you know, do this function and that function has the other loop in it. And then if I need it to bubble out to break, then it'll be break if false or have it throw an error or something like that.

 

I chalked this up under things I learned

 

Yeah,

 

Yep.

 

so interestingly, like I said, people who use Svelte might have encountered it because Svelte has this concept of using a dollar as a special label. So it kind of adopted, so Rich Harris encountered this label syntax, which apparently he wasn't familiar with, and then say, hey, this is useful for a very particular case that I have in svelte a dollar as a label on a statement, you're actually indicating to the svelte compiler that this is a reactive expression. This is an expression that needs to be computed when one of the things that it depends upon changes or something along these lines, as I recall.

 

Cool.

 

which is, you know, Svelte tends to do that sort of thing. It uses JavaScript statements and keywords for things that are somewhat different than, you know, similar to, but different from what JavaScript, like, you know, the language itself uses them for. So it's interesting. You know,

 

Yep.

 

it's a discussion worth having as well, like what we think about the fact that Svelte

 

Cool.

 

Anyway, that essentially covers my list.

 

Good deal. Well, I've got to take off in five

 

Ah!

 

minutes. So I'm going to push us to picks. But yeah, it's been an interesting conversation. And yeah, I mean, some of these I just, I've never used and some of them, you know, I think the else is probably going to be one that I think a lot of people are going to have to think over. But yeah.

 

Well, if we've got people thinking, we've done our job.

 

Yep. All right, well, let's go ahead and do some picks. I see that Steve signed in as a host, so I'm gonna go first and then I'm gonna jump off. We played this game, and I'm trying to remember what it's called. Well, I'll come back to it if I can remember what it is. But in fact, I'll just pick a different game. So I usually pick a game. I'm gonna pick a game called Orbis. I think I might have picked it on the show before. I'm almost certain I have. So Orbis is you're building a universe. And effectively what it is is you're stacking these tiles. You kind of lay them on the table. They're hexagon shaped and they kind of stack up into a pyramid shape. tiles on tiles of the same color as the one below it. So if you have a green and a yellow next to it, the one that goes kind of in that little V shape at the top of two hexagons together has to be green or yellow. And as you build and you pull these tiles, you get worshipers, and they're just little cubes, and you put the cubes on, to pick a god for your universe who gives you bonuses at the end of the game and effectively you're trying to score the highest score. It's a pretty fun game. It's what 45 minutes I think. And I'm

 

Was

 

trying

 

that a

 

to...

 

board game or like a video

 

It is

 

game

 

a board

 

or?

 

game. It is a

 

Okay.

 

board game. It... Uh, it has a weight of 2.09. So it's kind of right at that ideal game night casual gamer level. Um, I've played it with some friends. It's pretty fun.

 

I wanted to ask you about that. I hope you have a minute or two to answer it.

 

Yeah.

 

You're mentioning all these games that are appropriate for game nights, but if you're bringing in people and it's a new game, don't you spend the entire game night just teaching that new game?

 

Uh, sometimes if it's a really complicated game, sometimes what I found is that what you wind up doing is you wind up kind of a, you set it up and you kind of walk people through the basic mechanics and then you play it. And so usually, um, the setup takes a few minutes longer than normal. You spend five to 10 minutes explaining the fundamentals of the game and then you play through it. are strategizing in a way that makes sense. And most of the game nights I go to or hold, we're there for like three or four hours. So anyway, so the answer is kind of, but yeah. Anyway, other picks. I've been playing a game on my phone lately. It's called Diablo Immortal. If you've played the Diablo video game series from Blizzard, it's pretty fun. You know, I'll pick it up and I'll play a quest and then I'll put it down. And you can kind of do that. And so yeah, I've been enjoying that. I've also started listening to the Michael Vey book series again by Richard Paul Evans. It's not the most sophisticated book I've read. I've had some people actually complain when I've recommended the books to them. They're like, they're a little juvenile. They're well written. I really enjoy them. There's a new book coming out at the end of September. I'm listening to all those books on Audible. I'm going to pick that. I'm just going to encourage people to go check out JS Remote Conf. In addition to that, I'm looking at pulling together a JavaScript meetup sometime in September. It'll be online. We're going to have a social hour afterward. Feel free to keep an eye out for that. TopEndDevs.com slash meetups. Yeah, that's pretty much what I got.

 

Cool.

 

I'll let you guys do your picks and take it from here. I gotta jump onto this other call and Steve can end the call, so.

 

Bye Chuck. And Chuck is gone.

 

Alright, you want to go next to

 

Okay,

 

pics?

 

I'll go next then. So my first pick is the pick that I already mentioned at the beginning of our show. It's that interview with John Carmack. So he was a guest on a podcast, I guess, hosted by Lex Friedman. And it's a really long interview. It's like a five hour interview or John Carmack is like that legendary 10x or maybe 100x programmer. He's co-founder of ID Software. They're the ones who created Castle Wolfe Stein and Doom and Quake and whatnot. He's credited with inventing a lot of these 3D game engines that actually made all this thing possible. He's kind of legendary in our industry. And like I said, it's a five-hour interview. I'm only like 30 minutes into it, but it's really interesting. He has a really interesting perspective on our industry as a whole, having been in it for such a long time, having been involved in so much development and innovation, and he's also a really hands-on tech guy. So I recommend listening to that, in the show notes. So that's my first pick. Another pick that I have, so we've had Steve from Builder.io, the CEO of Builder.io on our show talking about Builder.io and we'll have other people from that company joining us in the upcoming weeks and I've just encountered is a framework benchmark that kind of trying to compare the performance of the various frameworks that are out there, you know, React, Vue, Svelte and whatnot. And the way that they're going about it is interesting. They have this tool that they developed, which Steve mentioned, which is called Mitosis, which kind of takes a generic representation in the framework of choice. So you can create a generic description of a component and then compile it into a React component or compile it into a view component and so forth. So they wrote their framework using that kind of component programming language, I guess. It looks kind of like React that uses JSX. And then they compiled it into those various frameworks results. So assuming they generate properly efficient code in all the frameworks that they support, it's an interesting way to compare the performance of those various frameworks if that's what you're interested in. So if building performant applications is an important consideration for you and you're thinking of, hey, which framework should I choose? Then at and again I'll put a link to that. And my final pick is that same pick that I pick each and every time because unfortunately it just keeps on going and that's the war in Ukraine. You know, it's, it's, it's, I'm afraid it's really becoming normalized. It's no longer the top of the news and we just tend to forget that hundreds of people are We need to continue to see what we can do to end this conflict and support the people of Ukraine in their struggle to be free and not be oppressed and not be killed. So, yeah, that would be my final pick for today.

 

All righty, so I guess I'm up. All right, so first off, before I get to the high point of every podcast, is an article I found on Hacker News. So if anybody's followed astronomy or NASA over the past couple months, you've noticed that the James Webb Space Telescope has finally been put in place and is sending back data pictures and some of the pictures are just unreal with the amount of clarity and how close up they are much much better than the Hubble and you know if you think about how good the Hubble was when it first came out so this is that much more and so it's really it's quite fascinating look at some of these these images and in particular how far back in in time

 

Thanks for watching!

 

they go because of the speed of all that. I have

 

Thanks

 

been,

 

for watching!

 

you know, I dabble and read about astronomy and cosmology and various science of that nature. And in particular, you know, up until the Webb was, telescope was deployed, you know, the Big Bang theory, the hot Big Bang has sort of been the dominant theory, not a fact, a theory in cosmology describing how the universe started and was formed and so on. And there's an interesting article that I saw in Hacker News from a website called mindmatters.ai, how the clarity of the photos that are coming from James Webber are causing people to question that theory because of what they're seeing in terms of the smoothness or the clumpness Back farther in time, not at all what was expected to get predicted by Einstein's theory. So I guess part of me is interesting thinking, oh wow, that's interesting that you have data to challenge a pretty entrenched theory. But the bigger issue that I see with this article is that's how science should

 

Exactly,

 

work.

 

I totally agree.

 

There is never, anytime you ever hear somebody say, quote unquote, the science is settled, they don't know what science does. You know, you always. being challenged. Even the most deeply entrenched theories can be challenged when new data comes along to provide new points of view or something that you hadn't thought of

 

Totally

 

before.

 

agree.

 

Unfortunately, I see how when it comes to pandemics and things and people say, the science is settled, this works and this doesn't is complete BS, but that's what gets me thinking about this. So this is just a works and things are challenged.

 

That's a great thing about science, that, you know, when something is shown to be, when entrenched theory is shown to be potentially incorrect, scientists become excited. That's the opportunity to win Nobel prizes. It's the being able to, the ability to be able to challenge the, you know, the dominant view is when breakthroughs are made. And that's the beauty of science.

 

Yep.

 

Totally agree with that.

 

Yep, that's how it should be practiced. As an always, but

 

Well, you

 

in

 

know,

 

this one

 

people

 

case, this

 

are people,

 

is how it should.

 

you know, people tend to be set in their ways. People don't like changing their point of views. You know, and the universe is under no constraints to make sense to us. Let's put it this way.

 

Yeah, yeah, for sure. For sure. So finally, we'll come to the dad jokes of the week. Most of you, if they have listened regularly, you know I have an affinity for cow jokes in particular. So I came across this one to add to my list of cow jokes. So where do anybody know where milkshakes come from?

 

Where do milkshakes come from?

 

Nervous cows.

 

Ha, okay, that's nice.

 

I so need a cow sound effect, I really do. Although a friend of mine pointed out that they also come from cows on trampolines.

 

Pfft

 

I suggested nervous cows on trampolines as a compromise, but they both work.

 

Okay. Okay. That's, that's kind of getting silly, but okay. I guess that's the point.

 

So last Halloween, you know, everybody has costume parties. And so I, I turned up, I crashed a costume party and I dressed as a football, but I was kicked out immediately.

 

Okay.

 

Right. And then finally, what is worse than raining cats and dogs?

 

What is worse?

 

Hailing taxis.

 

Okay...

 

Yes,

 

That's

 

yes,

 

nice.

 

yes. Uh-uh. Thank you, thank you. So that is all we have for this episode of JavaScript Jabber, learning about more things that you shouldn't do or should not use in JavaScript. Hopefully it's been useful to you. Chuck had to leave early, as he said, so

 

Yeah,

 

we will

 

if

 

say goodbye

 

I can

 

to now.

 

just throw a quick comment. If people have ideas for additional things in JavaScript that should be avoided, or alternatively, if they think that I was full of it and made incorrect assertions,

 

Ha ha.

 

then by all means, do engage with me. Show me the error of my ways, or alternatively, tell me that you totally agree with me, whatever. Either way works. I'm on Twitter, Dan Shapir. So feel free.

 

And there's also the JS Jabber handle on

 

Yeah,

 

Twitter

 

for

 

for

 

sure.

 

the podcast as a whole. And we will all get that. Alrighty, thanks for listening and we will talk at you next time.

 

Bye!