You Don't Know JS: Types & Grammar

All right, get ready to dive deep into the sometimes confusing, often surprising world of JavaScript types and grammar. Absolutely with us as always is expert, and today we were taking on Kyle Simpson's You Don't Know JS Types and Grammar, one of best, one of the best books out there, you know, with the fundamentals absolutely, like what are the building blocks of JavaScript?

Yeah, so Simpson lays out these seven fundamental types in JavaScript. They've got null and undefined, boolean, number, string, object, and symbol.

I remember when I first started with JavaScript, undefined and undeclared. Yoh yeah, really got me tripped up.

It's a common one, for sure. Yeah, a lot of folks stumble over that. And you know the tricky thing is, yeah, it's not the variable itself that has the type in JavaScript, it's the value. Oh okay, So you can have a variable that exists but hasn't been given a value yet, so it's undefined.

Okay.

But then you could also have a variable that you're trying to use that doesn't even exist. It's undeclared. And the funny or maybe not so funny thing is type of returns undefined for both.

So it's like JavaScript is saying I don't know what you're talking about.

Right, exactly, Like I've never even heard of that undefined Yeah exactly.

So but is that I mean, that seems like a problem.

It might seem like it, but it's actually a really clever safety net. Oh, it's JavaScript trying to protect you from yourself by preventing these reference errors that would normally just crash your program if you try to use a variable that doesn't exist.

So is this like a featured detection kind.

Of that's a great way to think about it. Yeah, okay, especially you know back in the day we had to worry about different browsers supporting different things. Yeah, this was a lifesaver.

So it's like a like a compatibility checker built in exactly. Okay. Cool, So we've got these seven types. Let's start maybe with a RAYS. You know, I used to think of a RAYS as just like a list of things, but but I ran into some really weird behavior. Oh with the length property? Yeah, and delete?

What's with that length and delete? Those are those are tricky ones. So you can use delete okay to remove an element from an array. But the weird thing is it doesn't actually change the length. What it just leaves this like this gap there. So you end up with this thing called a sparse array, a sparse array which behaves differently than like a dense array.

So it's like I delete a word from a sentence, but I leave the space there.

Yeah, exactly exactly. It looks weird and it can mess things up if you're not careful. If you need to actually remove an element and shift everything over, you'd use something like splice.

Okay.

But yeah, delete and length those are those are different? Got it?

Okay, So that's on my my weird JavaScript quirks checklist.

It's a growing list, right, it is.

A growing list, it is. Okay. String Okay, I for the longest time thought that strings were just a raise of characters.

Yeah, that's a common one.

Is that wrong?

It is? Yeah, so they might seem like that, okay, But strings are immutable, which means you can't just like change them in place. Oh okay, So if you use a string method like the uppercase, it's not actually changing the original string, it's creating a whole new string really with the uppercase letters.

Huh. Yeah, that's why my debugger is always so cluttered, right.

It can be hard to track it is. Yeah, but it's it's actually really good for like, yeah, predictability and thread safety things like that.

So every time I'm manipulating a string and creating a whole new string.

You got it.

Okay, that's yeah, I did not know that.

It's one of those things that's often kind of hidden, Yeah, under the hood.

Cool. Well, let's move on to another one that can lead to some unexpected behavior. Oh yeah, numbers.

Numbers.

I vividly remember pulling an all nighter in college. Oh no, because point one plus point two wasn't point three. I thought my code was broken.

Ah, the classic JavaScript math problem. Yeah, this is uh, this is where the IE seven fifty four standard it comes in. It's uh, it governs how JavaScript handles floating point numbers, Okay, and certain decimal numbers like point one to point two. They just can't be precisely represented in binary So it's like trying to fit a square peg in a round hole.

So wait, so it's not that JavaScript is wrong, it's it's that's not JavaScript bug. No, it's that computers can't represent these numbers correctly.

It's a limitation of how computers represent numbers.

Got it?

And it affects a lot of programming languages, not just JavaScript.

So what you're saying is, don't trust JavaScript with my bank account.

Probably a good rule with them.

Okay, all right, well let's move on then to maybe two of JavaScript's greatest hits when it comes to confusing terminology. Oh yeah, Nan and negative zero.

The dynamic duo.

I mean, come on, nan is it's not a number.

Right, But here's the thing. It is a number type.

Wait, wait, hold on, It's not a number, but it's a number.

It's one of those.

That's like saying a squares in a shape, but it's also a type of shape.

Yeah, it's It definitely takes a bit of mental gymnastics to wrap your head around, but think of it as a signal that's something has gone wrong in a calculation. Okay. JavaScript uses NAN to basically say, hey, this operation resulted in an invalid numeric value, and you can't just directly compare something to NAN with like an equality operation. Yes, that's why we have number to specifically test for NAN.

Gotcha, Okay? And negative zero, like, why does that even exist? I've seen it pop up in the console.

I just I know, right, it seems unnecessary at first glance, but it actually does have implications for certain mathematical operations, like what like if you divide by negative zero, you get negative infinity. Oh okay, so it's not just completely useless.

It has meaning.

It does.

Yeah, it's like a secret code. Yeah, kind of.

JavaScript's using to like preserve information.

Exactly about like which direction the value was approaching zero from.

Okay, yeah, that's that's really cool. All right. Well, speaking of things that can be a little bit misleading, let's talk about primitive values versus references.

Oh yeah, that's a big one. And this is where I think, you know, folks coming from other languages especially like really get thrown for a loop, right, because.

In some languages everything is an object. So in JavaScript we have this difference between like primitive values like numbers and strings, yeah, and then objects like a raise and well objects objects. Yeah.

And the key difference is in how they're stored and assigned. So primitives, those are immutable, right, so they can't be changed, okay, and they're always copied by value by value, So when you assign a primitive value to a variable.

You're creating a whole separate copy of that value. Objects on the other hand, are different. When you assign an object to a variable, you're not creating a copy, you're creating a reference to it.

So it's like two different names for the same house.

That's a great way to think about it. Okay, So both of those variables are pointing to the same place in memory, the same object, got it. So if you modify the object using one reference, the changes are going to be reflected everywhere.

Right, Yeah, that makes sense. But I can see how it could go wrong if you're not paying attention.

Yeah, absolutely, you got to really keep that all right. Well, we're talking about objects. Let's talk about some of those built in functions that Simpson calls natives men natives like string, number, array, object. I use these all the time, but I have to.

Admit I've never really understood what's happening behind the scenes. Like when I use the new keyword.

Oh, the new keyword. Yeah, that's where things get a little funky. So that's where this concept of boxing comes in. When you use a native function like string with a new keyword, you're not actually creating a new string. Oh, You're creating this thing called an object wrapper, an object wrapper around the primitive value. So it's like, you know, you're taking a simple value and you're putting it in this like fancy box.

It's a decorated string.

Yeah, yeah, exactly. That comes with like extra methods and properties, so.

It's not just a string anymore. It's an object that contains the string.

That's exactly right. Okay, Yeah, and that object wrapper gives you extra function Okay. But the really wild thing is that this boxing happens automatically really when you try to use methods on primitive values.

Behind the scenes.

Yeah, behind the scenes. So it's like JavaScript is saying, oh, worry about it.

I got you.

You want to use an object method on a primitive no problem, I'll just box it for you real quick.

It's like it's like JavaScript magic.

It's a little bit magical. And then there's unboxing.

Oh there's unboxing too.

Yeah, which is just the reverse. Ok So, if you use an object wrapper in a context where you need the primitive value, JavaScript will just automatically unbox it.

So take it out of the fancy box exactly. Yeah, Okay, I never knew about boxing and unboxing.

Yeah, it's it's one of those things that that's cool. It often happens behind the scenes, all right.

Well, and then there's the array constructor. Yeah, and this this myth of precizing arrays, Oh.

The precizing myth. Yeah. So I've seen a lot of developers, yeah, right, to create an array with a specific length, thinking that they're like being a face reserving memory, pre allocating memory. But that's not actually what happens when you do that. You're creating a sparse array with that length. Okay, but all the slots are.

Empty, so I'm not actually reserving memory.

No, You're not reserving memory, You're just creating.

I'm just I'm just making a list of empty.

Slots exactly like a bunch of placeholders.

Placeholders, Okay, I got it. Yeah, And those can those can behave strangely, so generally best to avoid that, avoid pre sizing unless you really know okay, what you're.

Doing, got it, all right, Well, speaking of things that can be a little bit strange, let's talk about coersion.

Oh, coersion. Yeah, that's a that's a big one.

And I have a love hate it's a love hate relationship with coercion. It can be really elegant, yeah, and and and clean, but it can also but by lead to some tricky buzzs.

Oh yeah, so many bugs. So uh, Coersion, at its heart is simply jovscript's way of converting a value from one type to another. Okay, and we've got two flavors of coercion, right we do, Yeah, explicit and implicit.

Explicit where you're basically, like, you know, explicitly saying JavaScript, I want you to convert this value. You use you know, functions like string or number or bullion, and then you have implicit coercion, which is where it happens like yeah, as a side effect of operations.

Okay, So give me an example, like what happens if I add a string and a number together.

Oh yeah, So the plus operator in JavaScript, right, it could be used for addition or for string concatenation. Oh right, right, So if one of the operatings is a string, JavaScript's gonna say, okay, I'm going to coerce the other one to a string and do string concatenation.

So four plus two.

Would be forty two would be would.

Be a string, forty two a string, not the number.

Six exactly, got it. But if you use an operator that's strictly for numbers, like say subtraction, JavaScript will try to coerce any non number operats into numbers.

So forty two, the string and.

Zero would give you the number forty two. I'll give you the number forty two exactly.

Okay, Yeah, right.

That makes sense. Okay. What about boolean coersion Bullian coersion?

Yeah, this is another big one, right, Yeah, this is where those truthy and falsey values come in.

I think a lot of people even experience JavaScript developers. I think this is where oh yeah, things can get can get weird.

It's easy to trip up on this one, okay for sure. So JavaScript has this specific set okay of values that are considered falsey.

Okay, So like false itself, falls itself, null, undefined.

Yep, those are all falsey nan nan yeah.

Zero negative zero, negative zero, and d string empty string, that's right, okay. And everything else is truth So.

Even an empty object is truthy.

Even an empty object is truthy, which can be a little counterintuitive. Right.

So if I if I use an empty object and if statement.

Ye, the code in the if block will execute?

It will it will? Yeah, It's one of those things you just got to kind of, you know, got to remember, burn into your.

Brain, burn it in now. Simpson talks about these ye falsey objects, which yeah, I mean that just sounds like a paradox to me.

Yeah, that's it's a little bit of a head scratcher for sure. He's referring to, Okay, some quirks and how older browsers used to handle certain objects. Like one of the infamous examples is document in Internet Explorer. So in older versions of IE, document all was an object that represented all the elements on the page. But for compatibility reasons, in later versions of IE, they made it behave like a falsey value what in boolean context.

So it's like it's an object, but it's not an object. It's like a.

Quantum object, the JavaScript quantum object.

A JavaScript quantum object.

It's one of those things that you might you might run into if you're.

Dealing with like really old legacy code.

Okay, so another one for my weird JavaScript quirks checklist, the long list. Okay, let's talk about explicit okay, bullian coercion.

Explicit bullying coercion.

Now, I know there's the boolean function, but I don't think I've ever used that.

Yeah, you probably won't see that in a while. Very often, the more idiomatic way to do explicit bullying coercion is to use the double negation.

Operator double negation, So I'm saying like not not true, yeah, which is true, or or not not false which is false exactly.

Yeah. It's a it's a way to force that boolean context. Yeah, and it's it's useful when you're dealing with values that might be either truth or falsey. Yeah, and you just need to like make sure sure, yeah that you're getting a bullyan Okay, I got it.

Now, what about implicit bullian coercion implicity especially with the logical operator and a d.

Oh yeah and the end of the yeah, this is yeah.

Because now these operators it's like they're not just about logic anymore.

Right, They're not just about logic.

It's like they're yeah, selecting operad yeah, operand selectors.

Yeah, that's a great way to think about it. So in JavaScript, the and an Indians they evaluate their operands as booleans, right, right, and then they return one of the operands okay, based on the results okay, And that's where that concept of short circuiting comes in.

Right, So with O R, if the first operand is truth y, yeah, it just it just stops.

It doesn't even look doesn't even look at the second one.

At the second one, I'm done. I found true.

It's like, I'm done here, I got what I need.

That's that's really efficient and with a D.

Yeah, if the first operand is falsey, it's done. It just stops right.

There and doesn't even look at the second one.

That's right. And that's really important to keep in mind. Yeah, when you're dealing with expressions that have like side effects, side effects.

Well, and speaking of side effects, let's talk about the increment and decrement.

Operator, the plus plus and flip.

These can be tricky. Yeah, those are I know, they can be tricky. It's like, yeah, it depends whether they use them before or after.

Yeah, it all comes down to the timing of the side effect. Okay, So when you use plus plus or before an operator, that's called pre increment or pre decrement, and the operator is applied before the value is used in the expression.

Okay. So so if I have like AA equals five, and I do plus plus aa becomes six and the value of the expression is also six, that's right. Okay, But when I use them after after, that's the that's post increment.

As post increment or post decrement. Okay, And in that case, the original value is used in the expression and then the increment or decrement happens.

So with with A plus plus, the value of the expression is five, and then A becomes six exactly.

Yeah. So it's, uh, it's subtle, yeah, but it's it's really important.

It's super important to keep.

Track of yees, especially when you're like in loops or something like that. The loops a ray manipulation.

Okay, So pre increment modifies before, post increment modifies after. Got it, I'm writing that down, good idea, Okay.

Now. Simpson also mentions this kind of obscure operator, Oh yeah, that can be used to like control the order of these side effects, the comma operator.

A comma operator. I don't think I've ever used that.

Yeah, it's it's one of JavaScript's lesser known features. Okay, but it can be handy in certain cases. So the comma operator lets you like string together a bunch of expressions and it evaluates them from left to right. Okay, And the important thing is that the completion value of the whole expression is the value of the last expression.

Okay, So give me an example.

Okay, so let's say you have a plus plus a comma bay. That comma operator will make sure that A gets incremented or B is evaluated, and then the value of the whole expression would be the value of B.

So it's like a way too.

Yeah, it's like a way to control source, yeah, for that order of execution.

Okay, that's that's interesting.

It's a little comma operator. Yeah. Not something you'll use every day, right, but good to know about.

Good to know about. Okay, all right, well, let's ship gears a little bit and talk about building blocks of JavaScript code. Statements and expressions.

Statements and expressions, Yeah, those are those are important.

Yeah, I have to admit I get them mixed up sometimes it's easy to do.

So think of statements as like the actions or instructions, right right, that tell JavaScript what to do. So they perform tasks like you know, declaring variables, assigning values, controlling the flow of execution.

Okay.

Expressions, on the other hand, are like values themselves.

So a statement is like a command.

Yeah, a command.

An expression is like a calculation.

That's a great way to think about it. Yeah. So like, for example, yeah, let a ten that's a statement. Right, that's an instruction to JavaScript saying, hey, create a variable called a and assign it the value ten. The expression ten plus five, on the other hand, that evaluates to fifteen.

Okay, that makes sense. But then Simpson throws in this idea of statement completion values.

Yeah, the completion value you thought about that. Yeah, this is a bit of a hidden gem in JavaScript. So every statement actually has a completion value, really, even if it's just undefined.

So even like a simple statement like let a ten has a.

Value, it does. It does. Yeah.

But but if I type that into the console, I just see undefined.

Yeah, and that's because the console is showing me the completion value of the statement. So in the case of let a ten, the completion value is undefined, not ten, not ten. No, oh, okay, it's it's kind.

Of a it's a behind the scenes yeah, behind the scenes.

Now, Simpson mentions, you can capture these completion values using evil.

Oh evil. Now I've always been told to stay away from evil.

Yeah, you probably should.

It's a little shady.

It's a little shady. It lets you execute like arbitrary code from a string.

That sounds dangerous.

It can be. Yeah, So unless you really really know what you're doing, and you've like really sanitized that string.

Just stay away, avoid at all costs.

Yeah, pretty much. Now there's there's this proposed feature do expression to do expression. Yeah, that's a that's being considered for like future versions of JavaScript, and that would give you cleaner way to capture those completion values.

It's like it's like a supercharged code block, like.

A code block that can return a value, returns of value. Yeah, okay, that's I'll put that on my things to things to watch list.

It's still in the proposal state, but something to keep an eye on, definitely, definitely. Now let's talk about operator precedence.

Operator precedence. Now, I know there's a specific order that JavaScript evaluates. It follows a hierarchy operators, but I don't always remember what it is.

It can be, it can be tricky. So it's uh, it's similar to you know what you might have learned in math class peendus or.

Bottom parentheses, exponents.

Identification division, editions of traction.

That's the basic idea. Yeah, but JavaScript has a lot more operators right than just those, So there's like logical operators, bitwise operators.

So am I going to have to like memorize this giant Well, luckily.

You don't have to memorize a giant table. The key is to just like understand the general principles.

Okay, like what.

So for example, like you know, arithmetic operators like multiplication and division, they have higher precedents okay than like comparison operators like less then or greater than.

Got it.

Logical operators like A and D and O R they usually have lower precedents than the arithmetic word.

This is like a pyramid. It is kind of like a pyramid of precedence.

Yeah, with the with the most important ones at the top. And if you're ever in doubt, just use parentheses parenthesy it just be sure purposes. They make it explicit. Got it all right?

Speaking of things that can be a little tricky, let's talk about automatic semicolon insertion.

ASI, the great semicolon debate.

Great debate.

Yeah, this is one of those.

It's like a religious war almost.

It can get it can get heated, yeah for sure.

So remind me again, as I what is that?

So a SI is It's basically a mechanism in the JavaScript engine that tries to fix by inserting semi colons where they're missing but implied.

So JavaScript is trying to be helpful.

It's trying to be helpful, but sometimes you know, yeah, it's a little too helpful.

Well, because it's it's making assumptions, right.

It is, yeah about what I meant. Yeah, And those assumptions don't always line up with reality.

And this is where people start getting getting into fights.

This is where the debate comes in. Right. So some folks say, look, ASI makes semi colons optional, right, you know, and it makes your code cleaner, more concise.

Less visual clutter, less visual clutter.

Yeah. Okay, But then you have the folks who have been bitten by ASI bugs and they say, no, no, no, always use semi colons, right, you know, to avoid any ambiguity, explicity, be explicit. Yeah, exactly.

So it's a matter of style versus versus safety.

Style versus safety. Yeah, and you know there are valid points on both sides.

So what's the verdict semi colons? Are they in or are they out?

You know, I think the real takeaway is, regardless of how you feel about semi colons, Okay, you need to understand how ASI works. Okay, because if you understand how it works. You can write code, got it that is both readable and reliable, right, whether you semi Collins or not.

So just know the rules of the game, exactly.

Know the rules of the game, and then you could play however.

You want, all right, so informed decisions. I like it, Okay. Well. Simpson also goes into some of the more advanced, potentially confusing areas of JavaScript grammar, absolutely, starting with the temporal dead zone the TDZ. Yeah gz gaes.

It sounds like, yeah, like a sci fi movie or something.

Right, but it's it's actually not that complicated, Okay. It's basically a restriction on when you can access variables that.

Are declared with let and constant.

Right, those those keywords that were introduced in e.

S six for blockscope variables for blockscope.

So unlike var which was functions, gope or global exactly.

Let in constant there, they're only accessible within the block they're declared in.

Okay.

So the TDZ is basically the period between the start of the block and the point where the let or constant variable is actually declared, okay, and during that time you can't access it. It's like it's in limbo.

So it's like a no fly zone for for variables. If I try to if I try to access a variable on the TDZ, my code will crash.

You'll get a reference error. Uh, not quite a crash, but yeah, it's is JavaScript saying hey, not yet, this doesn't exist yet.

Okay, respect the PDC.

Got respect the TDC.

And you know it is it actually, I mean it sounds like a it sounds like a restriction.

It sounds like a restriction, but it's a it's actually really helpful because it prevents like all sorts of unexpected behavior and it encourages you to structure your code better.

So it's so it's actually it's another one of these JavaScript quirks that is actually a lot.

Of those quarks are helpful. Actually, yeah, for our benefit.

Now are there any are there any like Gotcha's. We should always Gotcha's look out for what the TDZ.

Especially when it comes to like function arguments.

Okay, function argument.

Yeah, so you know in E S six we've got default parameter values, right, right.

So if you don't pass a value.

If you omit an argument or pass undefined, it gets that default value.

It's a fallback.

Yeah, it's a fallback. Yeah, Okay, but The catch is if you try to use that parameter within the default value, you're going to hit the TDZ.

Wait, so I can't do something like A equals A plus one.

Yeah, like function foo a equals a plus one. You can't do that because A is still in the TDZ.

Okay, so no, no self referential the.

Self referential deault values. Yeah, exactly, I got it.

Yeah, Okay, that's that's good to know. All right, Well we're talking about function arguments. Let's talk about the arguments array.

Oh, the argument's array.

This is an other one that there's another one yet.

Yeah, so the argument's array.

I mean it holds all the argument.

It holds all the arguments yet were.

Passed to a function, even if they.

Weren't even if they weren't.

Like explicitly defined.

Its eplicitely name.

But I've also heard it's it's kind of it's a legacy thing. Yeah. It has a bit of a mixed reputation.

Yeah for sure.

So first of all, it's not a true array. Oh really, it's an array like object.

So so they call it the argument's array. Yeah, I know, but it's not actually an array.

It's not a true array. It's got some array like properties, like a length property. Okay, but it doesn't have all the methods of a real array. And here's the real kicker. In non strict mode, there's this weird.

Linkage between the arguments array, right, and the named parameters of a function.

So wait, so they're like secretly connected.

Yeah, kind of. So if you modify named parameter inside a function, corresponding element in arguments gets modified to vice versa. Weird. Yeah, it's uh, that's one of those things that can lead to some like really unexpected.

Okay, So arguments are ray use with caution, use with extreme caution.

If it all, yeah, if it all? There are there are better ways to handle, you know, variable numbers of arguments these days, like what like rest parameters which are part of e S six.

Okay, rest parameters, I'm going to check those out. Put that on my my to learn list. It seems like the long list, right, the Java script to learn list is never ending.

There's always something new.

Well, let's let's talk about another area of JavaScript grammar. Sure that that can be tricky. The try dot finally statement.

Try finally yes. So this is used for exception.

Handling, right, exception handling right, so try some code, if something.

Goes wrong, if something blows.

Up, and then finally always execute, always executes.

It's like your cleanup.

Crew, the clean up crew. Okay, So, so finally always executes, whether there's an exception or not. But what happens if if there's a return statement.

Oh yeah, this is where things the triblock. Yeah, this is where things get interesting.

Okay.

So if you have a return statement in your triblock, right, and you also have a return statement in the finally in the finally blocked okay, the one in the finally block wins.

Seriously, even if the triblock return to value already, even if a return to value, yeah, the finally block gets the final. Say so we have a return in finally, Yeah, it's going to override everything else.

It's going to override anything that came before. Okay, so uh, you.

Know, be careful what you put in your finally block.

Be very careful what you put in finally.

Especially if there's returns, especially returns. Okay, what about what about other control.

Flow statements like continue or break?

Yeah, like continue or break?

Yeah? Do they they do have interactions with finally, So if you have a continue or break inside your tri block, and you know that triblock is inside say a loop, right switch statement. Yeah, that finally block is going to execute before the loop continues or the switch breaks.

So it's like the like the finally interrupts the flow it.

Does of the of the loop it does. Yeah, the finally block is very persistent. Okay, once it gets code.

Executed, finally always happens, and.

They always happens it. Yeah. Right, Well, Simpson gives this crazy example of combining finally with.

Label block, label blocks and break statements, and he says.

Is it crazy?

It's crazy. Yeah, maybe we should just uh alone, let sleeping dogs lie. Okay, let's talk about switch.

Statements, which statements.

Another another control flow statement that I think a lot of people use but maybe don't don't appreciate.

Yeah, they have their quirks all the all the little they do. So switch statements are basically a classic way to like, you know, compare a value. It's a bunch of different cases.

So it's like a more concise way of like a yeah, doing a bunch of IFL statement.

More organized way okay to do a bunch of ifls.

All right, but they have some quirks. What do I need to watch out for.

Okay. So the first thing is the matching that happens between the switch expression right and the cases uses strict equality. Oh so the types have to match, so no coercion, no coercion shenanigans.

Allowed, and switch statements.

Not by default no.

Okay, strict matching. God, what else?

Okay? So another interesting quirk is that case clauses. Yeah, they kind of fall through to the next one unless you explicitly use a brake right statement.

Oh I've been bitten by that one, forgotten to break.

Yeah, it's a classic.

And then like weird things have.

Yeah, it can lead to some really unexpected behavior.

Okay. So so strict matching.

Strict matching all through, because all through yep.

Okay, what else?

Okay, here's one that might surprise you. Okay, the default clause doesn't have to be the last one.

What.

Yeah, it can.

I always thought default had to go at the end.

A lot of people think that, Yeah, but it can actually appear anywhere.

JavaScript always keep me on my toes full of surprises. Okay, Well, we've we've talked a lot about like the the internals of JavaScript, like how the engine sees things, but we can't forget about the environment.

Oh yeah, the environment is key.

That are code's actually running in.

This is where things get really interesting.

Right, It's like we've been practicing in a nice, safe environment and now we're going out into the real world where anything can happen.

That's right.

So where do we even begin with that?

Well, you mentioned ANNEXB earlier ANNXB. Yeah, that's a that's a good place to start.

I know it's got something to do with how JavaScript works in browsers, but honestly, it's always been a little mysterious to me, like what is ANNXB.

So NXB is this uh, really fascinating part of the ekmascript specification, which is, you know, the official document that defines the javasup language, And ANXB is basically a collection of rules describe how JavaScript should behave, specifically in web browsers. Okay, because you know, over the years, browsers implemented all sorts of like features and behaviors that weren't actually part of the standards.

So it's it's JavaScript's collection of like unofficial rules.

That's a good way to put it. Yeah, okay, And eventually those unofficial rules they became so widespread that they had to be like officially recognized.

So ANXB is like the rule book for its.

It's like the official acknowledgement all those quirks.

Okay, I like that. Give me some examples. What what kind of rules are we talking about?

Okay? So one example is regular expressions. Okay, So browsers have for a long time supported these extensions to the regular expression syntax that weren't part of the original EKMA script standard, and but they became so common that they were eventually like incorporated into ANXP.

So that's like the the reg XP dot one dollar thing.

That's that's ANNXB in action.

I've seen in people's code. That's right, that's that's ANNXB.

Okay. Another example is the extensions to function dot prototype like arguments and color wait arguments. I know, I know, I thought that was like it was deprecated. It is generally discouraged these days, but it's still part of anx B because it was so widely used, you know, legacy code, bolder code basis. Yeah, so it's like a it's a historical artific.

Historical artifact that's still hanging around.

Still hanging around.

So annex B is, yeah, it's like this Museum of JavaScript quirks.

It's a it's a testament to how JavaScript has evolved, Yeah, evolved over time.

Okay. I like that analogy a lot.

Yeah.

So ANNEXB that's that's. That's all about how JavaScript works specifically inm browsers, in browsers, okay, what about subjects? Host objects?

Yeah?

So host objects are another key part of how JavaScript interacts with its environment. Okay.

And they're objects that are provided, okay, by the host environment itself. It's not the JavaScript.

Engine in a browser. We're talking about things like the document.

Object, document object, the window object.

The window object, yeah.

All the dom elements, right right, yeah, all that stuff Okay, that's that's provided by the browser. Okay, and those give JavaScript the power to manipulate the browser, interact with web pages, right, respond to events, respond to events, all good stuff.

Okay, but I have a feeling. But here this is where things get tricky.

Here's the tricky part. Host objects don't always play by the same rules.

Right, of course not. It wouldn't be JavaScript.

If it was that simple, right, got to have those okay, So they might have properties that you can't change, even though they look like regular JavaScript properties and their methods might behave differently did you'd expect based on the standard JavaScript object model.

So we have to learn like a whole separate set of rules.

It's definitely a learning curve, and it's really important to like consult the browser's documentation.

So when in doubt, check the docs.

Yeah, when in doubt, our TFM R TFM, got it all right. Now, there's one other topic that I think we should touch on, which is extending native prototypes.

Extending native prototypes, Yeah, this is this is one where I feel like there's a lot of a lot of strong opinions. Oh yeah, So we're talking about.

Adding adding methods to like to like a ray dot prototype or ray dot prototype, a string dot prototype.

String dot prototype. Yeah, it's tempting, right, right, it seems so convenient. Just I'll just add.

This, right, just add my add my one method, add this one little method, right, and then all a rays can use it.

It'll be available everywhere.

It's so clean, so elegant. Yeah, but then I've heard it's a bad idea. Yeah, it's it's generally frowned upon, and for good reason, because the main issue is it can lead to conflicts and unexpected.

Behavior, especially as the language is.

The language evolves changes. Yeah, because JavaScript is not standing still right, right, there's always new features coming out and sometimes like the behavior of existing features changes. So imagine you add a custom method called I don't know fubar fubar to a ray dot prototype. Right, and it's great, your coate is cleaner, you're happy. Everything's good. But then you know, a new version of JavaScript comes out. Oh

That sounds like a nightmare to debug.

It can be a nightmare, yeah, because your custom method might override the new one or vice versa.

And then yeah, my code's broken and I don't know why exactly.

Yeah, it can be really hard to track down. So it's uh, it's best to.

Those treat those native prototypes as sacred.

Yeah, don't mess with them, don't touch. Yeah you can look, but don't touch.

Got it? Yeah, all right, So no more extending native prototypes for me. But what if what if I need to like add some functionality that's missing in older browsers, Like how do I do that?

Yeah, that's where polyphils and shims come in.

Okay, poly fills and shims. I've heard of these.

Yeah, they're they're really useful, but.

I don't I'm not really sure what they are.

Okay. So a polyphyll is basically a piece of code that provides a modern JavaScript feature in older environments that don't support it. Yeah, so I'm raising like filling in the gaps, hence the name polyphill.

So I'm making my code work consistently across all these different browsers.

That's exactly right, yeah, okay. And a shim is a little more specialized.

Okay.

It's a piece of code that modifies existing behavior to work around like a bug or incompatibility.

So polyphills, polyphils fill in the missing features.

Yeah, fill in the missing stuff.

Shims like smooth over.

Smooth over rough edges.

Yeah, that's a great way to put it.

Okay. And both of those are good, right.

Like those are good.

Yeah, it's good practice to use those.

It's the best practice because they don't, you know, pollute the global name space potentially conflict with other code.

Okay. Yeah, So polyphills and shims, they are your friends.

There are my friends, okay, a yeah, I'm going to keep them close.

I'm going to make friends with those.

Yeah.

All right. Well there's there's one other thing that Simpson mentions about JavaScript in browsers. Yeah, that I think is worth worth bringing up.

Okay, yeah, so he points out that when we're writing JavaScript for browsers.

We're actually dealing with multiple, okay, separate JavaScript programs.

Wait, wait, multiple programs. I thought it was just one big JavaScript program.

It seems that way. Yeah, but it's actually there are subtleties. Okay, so each script tagh in your HTML represents a separate JavaScript program.

Oh so it's like each script tag is its own.

Is its own little universe universe. Yeah, and this has implications for things like, okay, variable scoping, error handling.

Okay, give me an example.

Okay, so, for example, variable hoisting. Oh right, that thing where variable declarations get kind of conceptually moved to the top of their scope. That only happens within each individual's script program.

Oh so it's not across, not across, not across multiple script tags.

So if I declare a variable in one script tag, I can't use it in another one, not.

Unless you're using global variables, which is generally a bad idea. Yeah, globals are bad.

Yeah, keep your scripts nice and self contained.

Okay, so keep it, keep it contained. What about error handling?

Air handling? Yeah, so errors were actually isolated to the script program.

Or they occur. So if one of my script tags has an error.

Yeah, it's not necessarily going.

To it won't crash everything.

Yeah, it won't bring down the whole page, It won't prevent other scripts.

So javascripts got like built in.

Yeah, it's it's designed to be fault tolerance. Fault tolerance. Yeah, Okay, keep the web running smoothly.

Well, the WIB is a chaotic place, it is. JavaScript has to be able to handle all of it.

Resilience is key.

Resilience is key. Right, Well, I think we've we've reached the end of our deep dive here into JavaScript types and grammar. We did, Yeah, we've really got We've gone deep dive into into how the language works, uncovered.

Some quirks, some quirks, some gotcha and yeah.

And really seeing how JavaScript has to deal with right these different Yeah, what are the key takeaways?

I think you know. The main takeaway is JavaScript is a language that's very.

H deeply connect.

Yeah, intertwined with its environment and understanding that. Okay, it crucial.

It's not just about the rules of the language.

It's not just the language.

Itsel how the language fits into the bigger picture.

The whole ecosystem.

Yeah all right, well, listeners, that's it for our deep dive into JavaScript types and grammar. Absolutely, we really appreciate you coming along with us on this.

Yeah.

Sometimes confusing, Yeah, hope, hopefully enlightening enlightened journey. Remember, the learning never stops. JavaScript is always changing, so stay curious, keep exploring, and don't be afraid to really dive deep into the documentation. Until next time, happy coding, everybody,