ES6: Const & Let

Reggie Peterson — Sat, 14 Sep 2019 21:45:17 +0000

~View the original post here at jayess.lifesandwich.co~

Who uses var? Not you hopefully. ES6 (ES2015) killed it for the better. It's replaced by two new variable assignment keywords; Const & Let — they work a little bit differently than var.

Const: Your go-to 99% of the time.

Let: Use it only when needed.

So what's the difference? Why are they so much better than var?

The answer is that Const & Let are block scoped vs var which is function scoped.

Block Scoped: only exist between a pair of curly braces { //code }

Function scoped: only exists within the current function.

The primary difference here is that naming a variable using const or let in an if statement, or a loop will basically hold that variable within it and will not allow it outside.

so this:

if(true) {
var x = 2;
}
console.log(x)

logs 2,
but this:

if(1 === 1) {
const y = 2;
}
console.log(y)

throws an error.

This is because x, created with var, doesn't care about the if statement { }, but const (and let) does.

This is a good thing, because it means if you accidentally name two variables the same, you won't get unexpected behavior, since a variable inside an if/ function/ loop will be completely different than one (named the exact same thing) outside of those { }. It helps avoid naming collisions.

Const vs Let

let is the same as var, aside from the block scope thing we just talked about.

const, however, is short for constant, and means that you can't reassign it.

so:

let a = 1
a = 2

is cool.
but this:

const b = 1
b = 2

is a no go

You also have to initialize const with a value:

let c;
c = 3

is fine
but:

const d;
d = 4;

is not. (it'll error on that first line)

This is good because it means you can't accidentally reassign a value (although you can mutate arrays and objects via push, pop, and such).

//RECAP

Var isn't great because it's function scoped and reassignable. Which is theoretically fine. but it opens the door for bad juju (namespace collision, unexpected values)

const and let are block scoped, and const is also not reassignable, which is why const should be used all of the time, except when you for sure need to reassign (like when incrementing in a loop).

Ditching var is a simple step to future proof your code and reduce bugs, and your users will thank you for it.

~View the original post here at jayess.lifesandwich.co~

What Is the Event Loop?

Reggie Peterson — Sat, 14 Sep 2019 20:02:50 +0000

check out the original post @ jayess.lifesandwich.co

It's mystical. Maybe you've never heard of it. If you're a developer who deals with browsers / http requests at all, chances are you've utilized it. It's what allows setTimeout to work, allow promises to be made, and how async/await is handled.

But First; JavaScript Engines

1) Browsers work on the web.

2) The web uses JavaScript.

3) Therefore, Browsers have JavaScript engines (to run the javascript)

Chrome's JavaScript engine is called V8. The same V8 Node.js is built on.

V8 is a single threaded execution engine. Single threaded meaning one call stack. Execution engine means, well, it executes the code.

V8

V8 has two main components: a memory heap & a call stack.

Memory Heap

This isn’t relevant enough to get into details, but the memory heap handles how & where the JavaScript gets stored. if you create a function called helloWorld and then want to use it later, the memory heap is what stores it and remembers where it is so when you want to use it, it works. That’s basically it.

Call Stack

A call stack is a data structure that allows functions to be added or removed from the top.

Since JavaScript & V8 are single threaded, there is just one call stack in V8. Whenever we perform an action/function in JavaScript, that thing is pushed onto the call stack, where it will run to completion and then be popped (or removed) off the top.

If the function called contains another function call, that will be pushed onto the call stack on top of the current call. This will continue until all code/calls have been executed and they will be removed one by one from the top.

Back to the Event Loop

Since JavaScript can only do one thing at a time, anything that needs to or should be done asynchronously must rely on functionality provided by the browser itself. Most browsers have browser APIs to handle the actual request, and then use a task queue and event loop to determine when it should be done.

A simple example

1) The browser receives the Javascript source code you wrote & interprets it

2) While the browser is executing the code, if it encounters a browser API such as a http request, it will push it onto the stack, begin a new, separate process of retrieving the response, and pop the call off of the stack

3) The browser will continue executing the code as before

4) Once the separate process is complete (ex. http request) it is sent to a task queue.

5) The response will wait in the queue until the event loop determines the call stack in empty* and will push it to the call stack, where the callback / promise / whatever was waiting is executed

6) After execution, it is popped off the stack and execution continues as normal or repeats these steps as needed.

Now here is the part you came for

So What is the Event Loop?

The event loop is a programming construct that checks the call stack and, when empty* will push the next waiting callback or promise in the queue to the call stack.

That's it.

It's a little program that directs the flow of traffic from asynchronous requests (promises, setTimout, http requests) back into the main flow of the one and only JS call stack.

Asterisk

There are not one, but two queues:

A microtask queue for promises.

A task queue for everything else.

You should also know that the event loop prioritizes microtasks above regular tasks.

This means that a normal task response waiting in the task queue will be pushed onto the call stack after the call stack is empty. As in, no more things to fire.

Here is a tool with a cool visual to show you how this works (sorry, no microtask queue)

However, this isn't the case for microtasks. Microtasks will fire in between code finishing and more code starting.

For example:

If you had three console.logs and a setTimeout set to 0ms with an function call in it, you would get normal synchronous code execution all the way from top to bottom and then after the console.logs were completed, the setTimeout function call would run.

But with microtasks such as promises, assuming your promise is at the top of the file above the console.logs, it would fire as soon as it could. At the end of the file, after the first console.log, after the second console.log, etc. It doesn't care. as soon as something is popped off the stack, and as normal execution is about to continue, all the microtasks in the microtask queue slide into the spot on the call stack and they won't let code continue running until ALL OF THEM are complete.

This is opposed to normal tasks in the task queue running one at a time, one per event loop cycle.

Got it?

Cool. That was easy.