You Don't Know JS: ES6 & Beyond

Hey everyone, and welcome to another deep dive with us.

It's great to be here.

Today. We're taking a look at a book by Kyle Simpson called You Don't Know JSES six and Beyond. Yeah, specifically, we'll be focusing on the syntax and organization chapters to see how they can help us write cleaner and more modern JavaScript code.

Absolutely, two chapters packed with insights that can really level up your JavaScript game.

Okay, So to kick things off, I think it's worth highlighting the fact that JavaScript evolves so rapidly these days.

Right, oh yeah, definitely gone are the days of waiting years for a new version.

Right.

ES six was a big shift, and the language is constantly changing now, so it's really important for us the developers to stay on top of things, always be learning, right exactly, embrace the evolution.

Yeah, okay, So let's dive into some of these evolutionary changes, starting with block scope declarations using let and constant sounds good. Now, Before EES six we only had var, and I think we've all run into some of those head scratching moments, right.

Well, for sure, var was function scoped, yeah, which you know sometimes led to some confusing bugs.

Yeah, definitely especially in.

Larger projects where you might have variables with the same name in different parts of the code.

Exactly. So how do let and constant address this?

Well, Let in constant introduced block level scoping mm hmmm, which means they're only accessible within the block of code where they're defined.

Okay, So it's all about creating these clear boundaries precisely.

Think of it as creating a more contained environment for your variables, preventing those accidental collisions and unexpected behaviors.

Got it now? I noticed that Kyle Simpson is a big advocate for declaring let at the top of the scope. Why is that?

Yeah, he's got a strong point there. Declaring let at the top makes it very clear what variables are in play within that scope, and it helps avoid what's called the temporal dead zone.

What's that?

It's an error you can run into if you try to use a variable before it's been declared.

Ah. Okay, So it's like setting the ground rules up front exactly.

It makes you code more predictable and less prone to errors.

Awesome. And what about const When should we use that?

Const is for values that you know won't change throughout your code, like say the mathematical constant pi, right, or maybe some configuration settings. Yeah, it makes it super clear that those values are meant to be constant.

Makes sense. It's like a promise to yourself and your fellow developers that this value is set in stone exactly.

Yeah. And there's a chance it might even help the JavaScript engine optimize things behind the scenes.

Dot it so let for variables that might change cost for rock solid values. Perfect, all right, Moving on to something a bit more flexible now, the spread rest operator.

Ah, yes, the versatile operation.

It's like a Swiss army knife, right exactly.

It can do double duty, either spreading out the elements of an iterable like an array, or gathering values into an array.

It's like a transformer that can adapt to different situations.

I like that analogy. So, for example, imagine you have an array of numbers and you want to pass them as individual arguments to a function.

Right, which was a bit of a pain before sixty.

Exactly, you'd have to resort to tricks like using apply. But with a spread operator, you can just use those three dots boom, and it unpacks those array elements into individual arguments, so much cleaner.

What about the rest operator, how does that work.

It's like the flip side of the coin. Instead of spreading out, it gathers things together. Okay, let's say you have a function that needs to handle an unknown number of arguments. The rest operator lets you scoop them all up into a nice need array.

So no more messing around with that clinky argument's objects.

Nope, the rest operator is much more elegant.

I'm sold now onto something that feels like a breath of fresh air. Default parameter values, Oh yeah, those are great.

They might seem simple, but they really improve code clarity.

I know, right, I've written so much code over the years checking for undefined values.

I feel you well. With default parameters, you can set a default value right in the function definition.

It's like having a backup plan built in exactly.

If the caller doesn't provide a value, the default just slides right in.

Love it. Now, what happens if someone passes in a falsey value like zero or an empty string?

That's the beauty of it. Yeah, default parameters handle those cases gracefully. They only kick in if the argument is actually missing.

Ah, so it's not just a blind.

Replacement, right, It's smarter than that.

I like it, and we can even use more complex expressions for default values.

Right, absolutely, any valid expression will do awesome.

Okay, I'm really starting to see how these seemingly small changes really add up to make JavaScript more robust and expressive.

It's all about giving you more control and flexibility totally.

Now, let's talk about a feature that I find particularly elegant, destructuring.

Destructuring is all about taking complex data structures like arrays and objects and extracting the values you need in a very concise way.

It always looks so clean when I see it encode it is.

Imagine you have an array representing a person's details like their name, age, and occupation. With destructuring, you can pull those values out into separate variables in a single line.

So instead of writing multiple lines to access each element, it's all done in one go.

Exactly. Yeah, and it's even more interesting with object destructuring. Oh. Also, you can extract properties from an object and assign them to variables using a similar syntax. Okay, but what's cool is that the target source pattern is reversed compared to object literals.

Can you explain that a bit more sure?

In an object literal, you'd write property value, but with destructuring its value variable. You're essentially specifying which property you want and where you want to put it.

I see, it's like mirroring the structure of the object exactly.

And just like with default parameters, you can provide default values in case a property is missing.

So it's a robust way to handle data.

Extraction absolutely, and we can even use destructuring and function parameters. Right.

It's a fantastic way to unpack arguments.

It makes your function definitions much more readable.

Love it all, right, onto some enhancements for our good friend, the object literal.

Object Literal's got some cool upgrades in ES six, like what Well. For one, we have concise methods, which provide a shorter way to define functions within objects.

So less typing, more concise code exactly.

And then there are computed property names.

Ah, yes, I've seen those us.

They allow you to use expressions to determine the names of properties dynamically.

Okay, that's pretty handy when you don't know the property name in advance.

It is. It avoids that awkward bracket notation we used to.

Have to use much cleaner. And speaking of cleaner, let's talk about string interpolation. I love how ES six made working with strings so much easier.

Template literals are a game changer totally.

Using backticks, we can embed expressions directly into strings.

It's so much easier to read than concatenating strings.

Right, no more plus signs everywhere. But there's a catch, right, something about them being plain strings.

Yeah, it's important to remember that template literals are immediately evaluated into plan strings. There's no intermediate template object or anything like that.

Got it, So it's more like an inline evaluation, kind of like an ia.

That's a good way to think about it.

And multiline strings are a breeze with template literals too.

Right, absolutely, they preserve white space and line breaks as you type them.

So much better than the old days of backslashes and awkward line breaks.

No more string concatenation headaches.

Now onto a feature that sounds even more powerful, tagged template literals.

Tag template literals takes string interpolation to the next level.

How sound.

You can attach a function a tag to a template literal, and that tag function gets the string parts and values as separate arguments. Okay, give you total control over how the string is put together.

Wow, So you could write a tag function that say, uppercases all the values or even does something more complex like internationalization.

Exactly, the possibilities are pretty much endless.

That's awesome. Okay, Now onto a topic that's always a bit of a hot potato. Erow functions.

Erofunctions are a concise way to write functions, but their main claim to fame is how they handle.

This right, the dreaded this keyword.

They solve a lot of the headaches we used to have with this binding.

Yeah, I've spent countless hours trying to wrangle this into submission.

I know the feeling. So with erofunctions, this is lexically bound. It means that this always refers to the context where the erowfunction was defined, not where it's called.

Oh I see, so no more var self.

This hacks exactly. Erofunctions make it much more predictable.

Awesome. But I've also heard that they're not always the silver bullet. What are some of the caveats?

Well, they don't have their own arguments object okay, and the way super works inside them is a bit.

Different too, So it's important to use them intentionally, mainly for this binding behavior.

Yeah, they're a powerful tool, but like any tool, it's good to know when and how to use it totally.

All right, let's move on to a feature that simplifies looping.

The four Ah yes, the four dot of loop is a much cleaner way to iterate over iterable.

Objects compared to the old four loop with an index.

Yeah, or even the four dot N loop, which iterates over object keys not values.

Right right, So it's like taking a scenic route through an array, stopping at each value along the way.

I like that. It's a much more intuitive way to work with iterables.

And speaking of iterables, can you remind me what those are? Exactly?

An interable is basically anything you can loop over arrays, strings, generators, even some custom objects.

Okay.

The key is that they have a special method called symbol dot iterator that defines how they should be iterated.

So for prew dot love works its magic by tapping into that method.

Exactly. It's a very elegant solution.

I'm liking it.

Now.

What about those regular expression improvements?

Ah yes. ES six introduced two new flags for regular expressions, the Unicode flag and the sticky flag.

Okay, Unicode, I get that. Yeah, we need to handle emojis and other non asty characters these days, precisely.

The Unicode flag ensures that your regular expressions work correctly with Unicode.

And what about the sticky flag. What does that do?

Sticky flag changes how the regular expression engine searches for matches. Okay, it makes the engine stick to the current position in the string, which is really helpful for certain parsing tasks.

Ah, I see, So it's like giving the rejects engine a bit more context.

Exactly. It's a powerful tool for certain situations.

Awesome. Now onto some new editions that make working with numbers and strings even more convenient.

EES six brought a bunch of new methods and features for both number and string Okay, Like what for numbers, we got new literal formats for binary, aucal and hexadecimal.

Numbers, so we can finally write binary numbers directly in our code exactly.

And for strings, there's a whole suite of new methods for handling Unicode characters, normalizing strings, and more.

It's like EES six is making JavaScript a first class citizen in the world of Unicode.

It definitely is.

I'm all for it. Now, let's talk about something a bit more mind bending. Symbols.

Symbols are a new primitive type in JavaScript. They're unique and immutable. Okay, I'm falling so far, which makes them perfect for creating hidden properties on objects.

Hidden properties. That sounds intriguing.

Imagine you're building a library and you need to store some internal data on an object, but you don't want to clash with any properties the user might be using. I see, symbols allow you to create these properties that are essentially invisible to the outside world.

So it's like having a secret compartment in your objects exactly.

It's a great way to improve encapsulation and prevent naming collisions.

And because symbols are unique, there's no chance of accidentally using the same symbol twice.

Precisely, they offer a level of safety and control that we didn't have before.

That's really neat. Okay, Now let's dive into the world of iterators and generators.

Iterators and generators are all about controlling the flow of data. Okay. An iterator is an object that defines a sequence of values, right, and generator is a special kind of function that can be paused and resumed producing a sequence of values.

Oh, I think I need an analogy here. This sounds a bit abstract.

Imagine you're reading a book, and you want to be able to pause at any point and come back later without losing your place. Okay, generators are kind of like bookmarks for your code.

I like that. So using the yield keyword in a generator is like placing a bookmark exactly, and.

The generator function can pick up right where it left off.

That's really cool. And how are generators related to iterators?

The generator function actually creates an iterator. When you call a generator function, it doesn't run the code right away. Oh, Instead, it returns an iterator object, and each time you call the next method on that iterator, it runs the generator function until it hits a yield statement.

So it's like stepping through the generator function one bookmark at.

A time, precisely.

I see how this could be really useful for things like asynchronous operations.

You're right, generators provide a very elegant way to handle a secretous code, especially when combined with promises.

Okay, my mind is officially blown. All right, let's shift gears and talk about one of the most anticipated features of ES six. Modules.

Ah. Yes, modules finally a standardized way to organize our code.

It's like JavaScript finally grew up.

I know, right before EES six we had to rely on all sorts of ad hoc solutions for modularity, right, all.

Those different module loaders and bundlers exactly.

But now we have a built in way to define modules in important export code.

No more global scope pollution exactly.

Modules make it so much easier to write well structured and maintainable code.

It's a beautiful thing. Now let's talk about a feature that might be familiar to developers coming from other languages.

Classes.

Classes in ES six provide a more familiar syntax for working with objects and inheritance.

So under the hood, it's still prototypes.

That's right. Classes are basically syntactic sugar on top of prototypes, so.

They're not a completely new inheritance model.

Nope. They just offer a cleaner way to express what we were already doing.

Okay, So it's all about making the code more readable and easier to understand.

Exactly, especially for those coming from class based languages.

Right, and classes come with all the usual bells and whistles, constructors, methods, the extends, keyword.

You got it. They just make things a bit smoother.

I'm all for smoother, all right, Onto some new additions for handling data, maps, sets, and weak references.

Maps and sets provide more efficient ways to work with key value pairs and unique values.

Okay, can you give me an example.

Imagine you're building a shopping cart. You could use a map to store the items in the cart, right, where the key is the product ID and the value is the quantity I see.

And if you need to keep track of unique visitors to your website, you could use a set to store their user IDs.

Ah, makes sense? And what about weak references.

Weak references are a way to hold a reference to an object without preventing it from being garbage collected.

Interesting, So it's like having a loose grip on an object exactly.

It's useful for situations where you want to associate data with an object without affecting its lifespan.

Got it. Okay, so we've covered a lot of ground here in this first part.

We have.

We've seen how ES six introduced block scope declarations, the spreadurist operator, default parameter values, and destructuring.

And we've also looked at object literal enhancements, tablet literals, aerofunctions, and the four dot of loop.

Plus those handy new methods for numbers and strings the power symbols, and the control offered by iterators and generators.

We've even touched on modules, classes, and the data handling capabilities of maps, sets and weak references.

It's a lot to take in before we move on to what lies beyond YES six. I encourage everyone to think about which of these features you're most excited to try out in your own projects.

There's so much to explore and experiment with in the world of modern JavaScript, and stay tuned for Part two, where we'll venture beyond ES six and into even more exciting territory.

It's going to be a wild ride, all right. So we've explored a lot of the core features of ES six.

Yeah, we've covered a good chunk of it.

Now I'm really curious to see what lies beyond ES six.

Buckle up, there's a whole lot more to discover.

Okay, so where do we start.

Well, one of the most anticipated features beyond ES six is asyncowate. It's all about making asynchronous code look and feel more like synchronous code.

Oh that sounds like a dream come true. I've spent countless hours wrestling with callbacks and promises.

I know, right, asyncowight really simplifies things.

Okay, so how does it actually work.

Imagine you're fetching data from an API with promises, you typically have these chains of than handlers. Yeah, but with a syncowate you can write code that reads more like a traditional synchronous flow.

So no more pyramid of doom exactly.

You use the awake keyword to pause execution until a promise is resolved.

And that makes the code much easier to read and understand.

Absolutely, asynchronous code becomes much less daunting.

I'm sold. Now what about object dot observe. I heard that was supposed to be a game changer for change detection. Ah.

Yes, Object dot observe was a promising feature. It allowed you to observe changes to JavaScript objects and get notified when properties were added, deleted, or modified.

Sounds incredibly useful for things like data binding.

It did. Yeah, Unfortunately it was eventually deprecated due to performance concerns and some complexities. Oh that's a shame, it is. But the good news is that proxies can be used to achieve similar functionality with more control and flexibility.

Right, we talked about proxies earlier. Okay, so they kind of stepped in to fill.

The gap yep proxies are super powerful.

Now let's talk about some simpler additions that make life easier, like the exponentiation operator.

Oh yeah, that's a handy one. No more math dot pal for simple exponentiation.

Much more concise. And what about spread syntax for objects? I loved using it with a raise.

Well you're in luck. Spread syntax can now be used to copy properties from one object to another.

Awesome, so we can finally say goodbye to manually copying properties.

It's a huge time saver.

And while we're on the topic of handy additions, let's not forget about array dot includes.

Array dot includes makes it super easy to check if an array contains a certain value.

No more writing custom loops or helper functions for that.

It's the little things that make life easier totally.

Now let's talk about something that sounds a bit more advanced. CMD.

CMD stands for single instruction, multiple data. It's a way to perform parallel processing.

Okay, so instead of processing data one element at a time, we can process multiple elements simultaneously exactly.

It can lead to some serious performance games, especially for tasks that involve a lot of number crunching.

Like image or audio processing exactly.

CMD is a game changer for those kinds of applications.

It's like having a team of processors working together instead of just one.

It really is. It opens up a whole new level of performance for JavaScript.

I'm impressed JavaScript keeps getting more and more.

Powerful, and it's doing it without sacrificing its accessibility and developer friendliness.

That's the beauty of it. It's evolving but staying true to its roots.

Well said.

Okay, before we move on to the final part of our deep dep I want to shift gears and talk about something a bit different. Type to Raise.

Ah. Yes, Type to Raise. They're like stepping into the engine room of JavaScript in what sense they allow you to work with raw binary data in a very structured and efficient way.

Okay, now this is starting to sound a bit intimidating. I usually think of JavaScript as dealing with strings, numbers, and objects.

It is a bit of a shift. Yeah, but think about scenarios where you need to process large files, manipulate images, or work with audio data.

Those are definitely more specialized use cases.

They are, but they're becoming more and more common in web development.

I see and type to rays provide a way to handle those kinds of tasks more efficiently.

Exactly. They act as a bridge between JavaScript's high level world and the low level world of binary data.

So it's like giving JavaScript access to the materials.

Precisely. It opens up a whole new level of control and performance.

Okay, So I'm guessing there's more to type arrays than just arrays of ones and zeros. What makes them special?

Type arrays offer a way to view that binary data as different types, like integers, floats, or even custom data structures.

So we can interpret that raw binary data in different ways.

Exactly. It's like looking at the same data through different lenses.

And that gives us more control over how we process it exactly.

Now, the actual binary data is stored in an array buffer. What's bad, it's basically a raw block of memory.

Okay.

Type rays don't actually store the data themselves. They just provide a way to access and interpret that data within the array buffer.

So the array buffer is like the container, and the type array is like the map that tells us what's inside.

That's a good way to think about it, And.

We can have multiple type derays viewing the same array buffer.

Absolutely each type array provides a different view of the same underlying data.

That's pretty powerful. Now, working with binary data can be tricky. Are there any gotchas we should be aware of?

Definitely. One thing to be mindful of is indianness.

Indian Ness I've heard the term, but never really understood what it means.

It refers to the order in which bytes are stored in memory. Oka Some systems store the most significant bite first, big Indian, while others store the least significant bite first, little Indian.

So it's like writing a number from left to right or right to left exactly.

It can affect how we interpret.

The data, and JavaScript provides ways to handle that.

Yes, we can detect and handle indian ness to make sure we're reading the data correctly.

Okay, good to know. Now I'm curious about practical applications. Can you give me some real world examples of how type rays are used?

Sure, Image processing is a common use case. Image data is basically a grid of pixels, each represented by color values. Type arrays can be used to manipulate those pixel values directly, allowing for things like brightness adjustments, color transformations, and even image compression.

Wow, can do some serious image manipulation with JavaScript now.

Absolutely, and because type derays offer efficient access to the data, they're great for performance critical tasks.

What other examples can you think of?

Audio processing is another big one. Audio data is represented as a series of samples. Type derays can be used to analyze and manipulate those samples, enabling things like filtering, equalization, and even audio synthesis.

That's amazing. So we can create our own audio effects using JavaScript.

You got it. And because tuch derays are so efficient, we can even do real time audio manipulation.

This is starting to sound a bit like the realm of low level languages like C or C plus plus our type derays really meant for the average JavaScript developer.

They are a more specialized feature, but understanding the basics can be beneficial even if you don't use them directly.

So it's good to have them in our mental toolkit exactly.

It broadens our understanding of how JavaScript works under the hood.

Okay, so we've talked about type derays providing different views of binary data, but how do we actually create those views.

It's a two step process. First, you create an array buffer, which is that raw memory buffer, right, and then you create a type array view on top of that buffer, specifying the type and size of the view.

So the array buffer is like the canvas and the type deray is like the paintbrush.

I like that analogy. The type ray doesn't copy the data, it just provides a way to access it.

So if we change the data through one view, those changes will be reflected in other views that share the same array buffer.

Exactly, it's all connected.

What are some of the different types of views we can create?

There are a bunch of type ray constructors, each representing a different way to view the data.

Okay, like what you've got.

Any array for signed eight bit integers, u inate array for unsigned eight bit integers, in sixteen array for signed sixteen bit integers, and so on. Okay, And they're also float thirty two array and float sixty four array for floating point numbers.

So we have a lot of options depending on the kind of data we're working with.

Exactly, choose the right tool for.

The job, and don't forget typed arrays are also iterable, that's right.

We can use them with four to sea of loops and other iteration techniques.

It's all coming together. Well. I think we've covered a lot of ground. In this second part, we've gone from a sincawight to object dot observe to typed rays.

We've really explored some of the cutting edge features of JavaScript.

What I find really amazing is how JavaScript is managing to evolve and become more powerful without sacrificing its core values of accessibility and developer friendliness.

I agree, it's a testament to the careful design and evolution of the language.

Now, before we jump into the final part of our deep dive, I want to leave everyone with a thought provoking question. What does this rapid evolution of JavaScript mean for the future of web development? How will these advancements shape the way we build websites and web applications in the years to come? All right, welcome back to the final stretch of our deep dive into ES six and beyond. We've covered a lot of ground.

We have, from the foundational features of ESA to some of the more specialized areas exactly.

Now, for this last part, I'm kind of curious to see how some of these pieces fit together. We've talked about typed arrays for efficient binary data handling, and maps and sets for managing collections. How do these powerful tools work together because they seem kind of like they're in different worlds.

Yeah, yeah, that's a great point. It might seem that way, but they can actually complement each other really well. Okay, So well, let's imagine you're building a game and you need to represent the game world as a grid, right, okay, yeah, yeah, each cell and that grid could be represented by a thirty two bit integer, which you could store in a

So instead of using like nested arrays or objects, which can get kind of messy, we have this more struct shirt approach using type arrays in.

A map exactly. You get the efficiency of type arrays for the grid data itself and the flexibility of a map for associating additional information.

And I imagine this would scale really well for large game worlds.

Absolutely. It's a great way to manage large data sets efficiently.

That's cool. Any other applications come to mind? Where you might combine type arrays with maps or sets.

Hmm, let's see what about scientific computing, Like if you're working with matrices or vectors, Okay, yeah, you could use type arrays to represent those mathematical structures and then use sets to efficiently perform set operations like union, intersection and difference.

So we're leveraging the numerical power of type arrays and the set operations of sets to do some pretty complex calculation.

Precisely, it's all about choosing the right tool for the job and combining them in clever ways.

I'm really seeing the power and flexibility of JavaScript here.

It's a versatile language for sure.

Now, before we wrap things up, I think it's where noting that while type dearrays are awesome, yeah, they're not always the right choice, right. They do add a level of complexity, definitely.

Yeah. If you're working with smaller data sets or your application doesn't have strict performance requirements, then traditional arrays and objects might be a simpler and more suitable option.

It's all about choosing the right tool for the job. As always.

Couldn'tgree more.

Well, I think we've done a pretty good job of exploring the world of ES six and beyond. We've covered the core features, delved into some specialized areas like type derays.

Yeah, we've seen how JavaScript is constantly evolving to meet the demands of modern web development.

What I find really fascinating is how it's embracing new paradigms while still staying true to its roots of accessibility and developer friendliness.

It's an exciting time to be a JavaScript developer. There's always something new to learn, something new to try.

It's a language that keeps pushing the boundaries of what's possible on the web.

Absolutely, so keep.

Experimenting, keep learning, and most importantly, have fun coding. That's what it's all.

About out couldn't to said it better myself.

Well, that's all the time we have for today. Thanks for joining us on this deep dive into the world of ES six and beyond.