DEV Community: Rajat Verma

The Scope Chain in JavaScript

Rajat Verma — Sat, 10 Jul 2021 07:07:37 +0000

Chapter 3: The Scope Chain

These are the notes of third chapter of the book "You Don't Know JS: Scope and Closures".
The connections between scopes that are nested in the other scopes are called the scope chain.
The scope chain is directed, meaning the lookup moves upward only.

"Lookup" Is (Mostly) Conceptual

We described runtime access to a variable as a lookup in the last chapter, in which the JavaScript Engine first checks if the variable is present in the current scope before moving upward up the chain of nested scopes (towards the global scope) until the variable is found, if at all.
The lookup stops as soon as the first matching named declaration in scope is found.
The scope of a variable is usually decided during the initial compilation process. It will not change based on anything that can happen later during runtime.
Since the scope is known from compilation, this information would likely be stored with each variable's entry in the AST, which means that the Engine doesn't need to lookup up a bunch of scopes to figure out which scope a variable comes from.
Avoiding the need for lookup is a key optimization benefit of lexical scope.

Note: Consider the following scenario: we have numerous files and we are unable to locate the declaration of a specific variable in one of them. It's not always an error if no declaration is found. That variable could be declared in the shared global scope by another file (program) in the runtime.

So the ultimate determination of whether the variable was declared in some scope may need to be deferred to the runtime.
Let's understand this with the Marble and Buckets analogy that we discussed in the last chapter:

Any reference to a variable that's initially undeclared is left as an uncolored marble during that file's compilation; this color cannot be determined until other relevant files have been compiled and the application runtime commences. That deferred lookup will eventually resolve the color to whichever scope the variable is found in (likely the global scope).

Shadowing

If all variables have different names it wouldn't matter if all of them were just declared in the global scope.
Having different lexical scopes starts to matter more when you have two or more variables, each in different scopes, with the same lexical names.
Let's consider an example:

var studentName = "Suzy";

function printStudent(studentName) {
  studentName = studentName.toUpperCase();
  console.log(studentName);
}

printStudent("Frank");
// FRANK
printStudent(studentName);
// SUZY
console.log(studentName);
// Suzy

The studentName declaration on line 1, creates a new variable in the global scope.
All the three studentName references in the printStudent function refer to a different local scoped variable and not the global scoped studentName variable. This behavior is called Shadowing.
So, we can say that in the above example, the local scoped variable shadows the globally scoped variable.

Note: It's lexically impossible to reference the global studentName anywhere inside of the printStudent(..) function (or from any nested scopes).

Global Unshadowing Trick

It is possible to access a global variable from a scope where that variable has been shadowed, but not through a typical lexical identifier reference.
In the global scope, var and function declarations also expose themselves as properties (of the same name as the identifier) on the global object—essentially an object representation of the global scope. Consider the program:

var studentName = "Suzy";

function printStudent(studentName) {
  console.log(studentName);
  console.log(window.studentName);
}

printStudent("Frank");
// "Frank"
// "Suzy"

So, as we can notice using window.variableName we can still access the globally scoped shadowed variable in a function.

Note:

The window.studentName is a mirror of the global studentName variable, not a separate snapshot copy. Changes to one are still seen from the other, in either direction.
This trick only works for accessing a global scope variable and not a shadowed variable from a nested scope, and even then, only one that was declared with var or function.

Warning: Just because you can doesn't mean you should. Don't shadow a global variable that you need to access, and conversely, avoid using this trick to access a global variable that you've shadowed.

Copying Is Not Accessing

Consider the example:

var special = 42;

function lookingFor(special) {
  var another = {
    special: special,
  };

  function keepLooking() {
    var special = 3.141592;
    console.log(special);
    console.log(another.special); // Ooo, tricky!
    console.log(window.special);
  }
  keepLooking();
}

lookingFor(112358132134);
// 3.141592
// 112358132134
// 42

So, we noticed that we were able to get the value of special variable passed as a parameter to the lookingFor function in the keepLooking function. Does that mean we accessed a shadowed variable?
No! special: special is copying the value of the special parameter variable into another container (a property of the same name). This doesn't mean that we are accessing the parameter special. It means we are accessing the copy of the value it had at that moment, by way of another container. We cannot reassign the special parameter to a different value from the inside keepLooking function.
What if I'd used objects or arrays as the values instead of the numbers ( 112358132134, etc.)? Would us having references to objects instead of copies of primitive values "fix" the inaccessibility? No. Mutating the contents of the object value via a reference copy is not the same thing as lexically accessing the variable itself. We still can't reassign the special parameter.

Illegal Shadowing

Not all combinations of declaration shadowing are allowed. let can shadow var, but var can't shadow let. Consider the example:

function something() {
  var special = "JavaScript";
  {
    let special = 42; // totally fine shadowing
    // ..
  }
}

function another() {
  // ..
  {
    let special = "JavaScript";
    {
      var special = 42;
      // ^^^ Syntax Error
      // ..
    }
  }
}

Notice in the another() function, the inner var special declaration is attempting to declare a function-wide special, which in and of itself is fine (as shown by the something() function).
The syntax error description, in this case, indicates that special has already been defined.
The real reason it's raised as a SyntaxError is because the var is basically trying to "cross the boundary" of (or hop over) the let declaration of the same name, which is not allowed.
That boundary-crossing prohibition effectively stops at each function boundary, so this variant raises no exception:

function another() {
  // ..
  {
    let special = "JavaScript";
    ajax("https://some.url", function callback() {
      // totally fine shadowing
      var special = "JavaScript";
      // ..
    });
  }
}

Function Name Scope

A function declaration looks like:

function askQuestion() {
  // ..
}

While function expression looks like:

var askQuestion = function(){
  //..
};

A function expression, takes in a function as a value, due to this, the function itself will not "hoist".
Now let's consider a named function expression:

var askQuestion = function ofTheTeacher() {
  // ..
};

We know askQuestion can be accessed in the outer scope, but what about ofTheTeacher identifier? ofTheTeacher is declared as an identifier inside the function itself:

var askQuestion = function ofTheTeacher() {
  console.log(ofTheTeacher);
};

askQuestion();
// function ofTheTeacher()...
console.log(ofTheTeacher);
// ReferenceError: ofTheTeacher is not defined

Arrow Functions

Here is how an arrow function is declared:

var askQuestion = () => {
  // ..
};

The arrow function doesn't need the word function to define it.

Backing Out

When a function (declaration or expression) is defined, a new scope is created. The positioning of scopes nested inside one another creates a natural scope hierarchy throughout the program, called the scope chain.
Each new scope offers a clean slate, a space to hold its own set of variables. When a variable name is repeated at different levels of the scope chain, shadowing occurs, which prevents access to the outer variable from that point inward.

That concludes this chapter. I'll be back with the notes for the next chapter soon.

Till then, Happy Coding :)

If you enjoyed reading the notes or have any suggestions or doubts, then feel free to share your views in the comments.
In case you want to connect with me, follow the links below:

LinkedIn | GitHub | Twitter | Medium

Illustrating Lexical Scope in JavaScript

Rajat Verma — Fri, 02 Jul 2021 06:00:58 +0000

Chapter 2: Illustrating Lexical Scope

These are the notes of second chapter of the book "You Don't Know JS: Scope and Closures".
In this chapter, we will discuss how our program is handled by the JS Engine and how the JS Engine works.

Marbles, and Buckets, and Bubbles... Oh My!

Let's say we have marbles of three different colors Red, Blue, and Green. To sort all the marbles we will drop the red marbles into a red bucket, blue into a blue bucket, and green into a green bucket.
Now if we need a red marble we know the red bucket is where to get it from.
Now apply this analogy to scope and variables, the marbles are the variables and the buckets are the scopes.
Let's understand this with the help of an example:

// outer/global scope: RED

var students = [
  { id: 14, name: "Kyle" },
  { id: 73, name: "Suzy" },
  { id: 112, name: "Frank" },
  { id: 6, name: "Sarah" },
];

function getStudentName(studentID) {
  // function scope: BLUE
  for (let student of students) {
    // loop scope: GREEN
    if (student.id == studentID) {
      return student.name;
    }
  }
}

var nextStudent = getStudentName(73);
console.log(nextStudent); // Suzy

As you can see that we have designated three scope colors with code comments: RED (outermost global scope), BLUE (scope of function), and GREEN (scope inside the for loop).
Now let's see the boundaries of these scope buckets by drawing colored bubbles:

Bubble 1 (RED): surround global scope, holds three identifiers: students, getStudentName and nextStudent.
Bubble 2 (BLUE): surround scope of function getStudentName(..), holds one identifier: studentID.
Bubble 3 (GREEN): surround the scope of the for-loop, holds one identifier: student.

NOTE: Scope bubbles are determined during compilation. Each marble is colored based on which bucket it's declared in, not the color of the scope it may be accessed from.

Scopes can nest inside each other, to any depth of nesting as your program needs.
References (non-declarations) to variables/identifiers are allowed if there's a matching declaration either in the current scope, or any scope above/outside the current scope, but not with declarations from lower/nested scopes.
An expression in the RED(1) bucket only has access to RED(1) marbles, not BLUE(2) or GREEN(3). An expression in the BLUE(2) bucket can reference either BLUE(2) or RED(1) marbles, not GREEN(3). And an expression in the GREEN(3) bucket has access to RED(1), BLUE(2), and GREEN(3) marbles.

Nested Scope

Scopes are lexically nested to any arbitrary depth as the program defines.
In the above example, the function scope for getStudentName(..) is nested inside the global scope. The block scope of the for loop is similarly nested inside that function scope.
Any time an identifier reference cannot be found in the current scope, the next outer scope in the nesting is consulted; that process is repeated until an answer is found or there are no more scopes to consult.

Undefined Mess

If the variable is a source, an unresolved identifier lookup is considered an undeclared (unknown, missing) variable, which always results in a ReferenceError being thrown.
If the variable is a target, and the code at that moment is running in strict-mode, the variable is considered undeclared and similarly throws a ReferenceError.
The error message for an undeclared variable condition, in most JS environments, will look like, "Reference Error: XYZ is not defined."
"Not defined" means "not declared" or "undeclared".
"Undefined" means that the variable was found, but it has no other value at the moment. So it defaults to the undefined value.
To perpetuate the confusion even further, JS's typeof operator returns the string "undefined" for variable references in either state:

var studentName;

typeof studentName; // "undefined"
typeof doesntExist; // "undefined"

So, we as developers have to pay close attention to not mix up which kind of "undefined" we're dealing with.

Global... What!?

If the variable is a target and the program is not in strict-mode, the engine creates an accidental global variable to fulfill that target assignment. For Example:

function getStudentName() {
  // assignment to an undeclared variable :(
  nextStudent = "Suzy";
}

getStudentName();
console.log(nextStudent);
// "Suzy" -- oops, an accidental-global variable!

This is another reason why we should use strict-mode. It prevents us from such incidents by throwing a ReferenceError.

That concludes this chapter. I'll be back with the notes for the next chapter soon.

Till then, Happy Coding :)

If you enjoyed reading the notes or have any suggestions or doubts, then feel free to share your views in the comments.
In case you want to connect with me, follow the links below:

LinkedIn | GitHub | Twitter | Medium

You Don't Know JS: Scope & Closures: Chapter 1 (What's the Scope?) Notes

Rajat Verma — Fri, 29 Jan 2021 10:21:25 +0000

Chapter 1: What's the Scope?

While working with JS, have you ever thought, How does it know which variables are accessible by any given statement, and how does it handle two variables of the same name?
The answers to questions like these take the form of well-defined rules called scope. In this book, we will dig deeper into all the aspects of scope.
Let's first uncover how the JS engine processes our programs:
As we studied in the last book that JS is a compiled language and it is first parsed before the execution begins.
The code author's decisions on where to place variables, functions, and blocks with respect to each other are analyzed according to the rules of scope, during the initial parsing/compilation phase.

Compiled vs. Interpreted

Code compilation is a set of steps that process the text of your code and turn it into a list of instructions the computer can understand. Typically, the whole source code is transformed at once, and those resulting instructions are saved as output that can later be executed.
In case of interpretation, the source code is transformed line by line; each line or statement is executed before immediately proceeding to process the next line of the source code.
Here is an image showing the difference between the two:

Let's now learn about the compilation of a program:

Compiling Code

Scope is primarily determined during compilation, so understanding how compilation and execution relate is key in mastering scope.
There are mainly three stages of compilation:
1. Tokenizing/Lexing
2. Parsing
3. Code Generation

Tokenizing/Lexing

Breaking up a string of characters into meaningful (to the language) chunks, called tokens. For eg:

  var a = 2;

This program would likely be broken up into the following tokens: var , a , = , 2 , and ;. Whitespace may or may not be persisted as a token, depending on whether it's meaningful or not.

Parsing

Parsing is the process of taking a stream of tokens and turning it into a tree of nested elements, called the Abstract Syntax Tree or AST.

For example, the tree for var a = 2; might start with a top-level node called VariableDeclaration , with a child node called Identifier (whose value is a ), and another child called AssignmentExpression which itself has a child called NumericLiteral (whose value is 2 ).

Code Generation

Code generation involves taking an AST and turning it into executable code. This part varies greatly depending on the language, the platform it's targeting, and other factors.

NOTE: The implementation details of a JS engine (utilizing system memory resources, etc.) are much deeper than we will dig here. We'll keep our focus on the observable behavior of our programs and let the JS engine manage those deeper system-level abstractions.

Required: Two Phases

The most important observation we can make about the processing of JS programs is that it occurs in (at least) two phases: parsing/compilation first, then execution.
The separation of a parsing/compilation phase from the subsequent execution phase is an observable fact, There are three program characteristics you can observe to prove this to yourself: syntax errors, early errors, and hoisting.

Syntax Errors from the Start

Consider the program:

var greeting = "Hello";
console.log(greeting);
greeting = ."Hi";
// SyntaxError: unexpected token .

When we try to execute this program it shows no output, but instead throws a SyntaxError about the unexpected . token right before the "Hi" string.
Since, JS is a compiled language and not interpreted (line by line), the string was not printed, and the program was executed as a whole.

Early Errors

Now, consider:

console.log("Howdy");
saySomething("Hello", "Hi");
// Uncaught SyntaxError: Duplicate parameter name not
// allowed in this context
function saySomething(greeting, greeting) {
  "use strict";
  console.log(greeting);
}

The "Howdy" message is not printed, despite being a well-formed statement. Instead, just like the snippet in the previous section, the SyntaxError here is thrown before the program is executed.
In this case, it's because strict-mode (opted in for only the saySomething(..) function here) forbids, among many other things, functions to have duplicate parameter names; this has always been allowed in non-strict-mode.
Here also, we can observe that the code was first fully parsed and then only the execution began. Otherwise, the string "Howdy" would be printed.

Hoisting

Finally, consider:

function saySomething() {
  var greeting = "Hello";
  {
    greeting = "Howdy"; // error comes from here
    let greeting = "Hi";
    console.log(greeting);
  }
}
saySomething();
// ReferenceError: Cannot access 'greeting' before initialization

The noted ReferenceError occurs from the line with the statement greeting = "Howdy".
What's happening is that the greeting variable for that statement belongs to the declaration on the next line, let greeting = "Hi", rather than to the previous var greeting = "Hello" statement.
Here also, we can notice that the JS engine could only know, at the line that error is thrown, that the next statement would declare a block-scoped variable of the same name ( greeting ) is if the JS engine had already processed this code in an earlier pass, and already set up all the scopes and their variable associations.

Compiler Speak

Let's now learn how the JS engine identifies the variables and determines their scopes as the program is compiled.
Let's first see an example:

var students = [
  { id: 14, name: "Kyle" },
  { id: 73, name: "Suzy" },
  { id: 112, name: "Frank" },
  { id: 6, name: "Sarah" },
];

function getStudentName(studentID) {
  for (let student of students) {
    if (student.id == studentID) {
      return student.name;
    }
  }
}

var nextStudent = getStudentName(73);

console.log(nextStudent);
// Suzy

All occurrences of variables/identifiers in a program serve in one of two "roles": either they're the target of an assignment or they're the source of a value.
If a variable is being assigned a value, then it is a target otherwise a source of value.

Targets

In the above code, since the students and nextStudent variables are assigned a value so they are both targets.
There are three other target assignment operations in the code that are perhaps less obvious. One of them:

for (let student of students) {

This statement assigns a value to student for each element of the array students.

Another target reference:

getStudentName(73);

Here, the argument 73 is assigned to the parameter studentID.

The last target reference in the program is:

function getStudentName(studentID) {

A function declaration is a special case of a target reference. Here the identifier getStudentName is assigned a function as a value.

So, we have identified all the targets in the program, let's now identify the sources!

Sources

The sources are as follows:

for (let student of students)

Here the student is a target but the array students is a source reference.

if (student.id == studentID)

In this statement, both the student and studentID are source references.

return student.name;

student is also a source reference in the return statement.

In getStudentName(73), getStudentName is a source reference (which we hope resolves to a function reference value). In console.log(nextStudent), console is a source reference, as is nextStudent.

NOTE: In case you were wondering, id, name, and log are all properties, not variable references.

Cheating: Runtime Scope Modifications

Scope is determined as the program is compiled, and should not generally be affected by runtime conditions.
However, in non-strict-mode, there are technically still two ways to cheat this rule, modifying a program's scopes during runtime.
The first way is to use the eval(..) function that receives a string of code to compile and execute on the fly during the program runtime. If that string of code has a var or function declaration in it, those declarations will modify the current scope that the eval(..) is currently executing in:

function badIdea() {
eval("var oops = 'Ugh!';");
console.log(oops);
}

badIdea(); // Ugh!

If the eval(..) function was not present, the program would throw an error that the variable oops was not defined. But eval(..) modifies the scope of the badIdea() function at runtime.
The second way to cheat is the with keyword, which essentially dynamically turns an object into a local scope — its properties are treated as identifiers in that new scope's block:

var badIdea = { oops: "Ugh!" };

with (badIdea) {
  console.log(oops); // Ugh!
}

The global scope was not modified here, but badIdea was turned into scope at runtime rather than compile-time, and its property oops becomes a variable in that scope.

NOTE: At all costs, avoid eval(..) (at least, eval(..) creating declarations) and with. Again, neither of these cheats is available in strict-mode, so if you just use strict-mode (you should!) then the temptation goes away!

Lexical Scope

JS's scope is determined at compile-time, the term for this kind of scope is lexical scope.
"Lexical" is associated with the "lexing" stage of compilation, as discussed earlier in this chapter.

NOTE: It's important to note that compilation doesn't do anything in terms of reserving memory for scopes and variables.

That's it for this chapter. I will be back with the notes of the next chapter.

Till then, Happy Coding!

If you enjoyed reading these notes or have any suggestions or doubts, then do let me know your views in the comments.
In case you want to connect with me, follow the links below:

LinkedIn | GitHub | Twitter

You Don't Know JS: Get Started: Appendix A (Exploring Further) Notes

Rajat Verma — Tue, 12 Jan 2021 19:36:26 +0000

Appendix A: Exploring Further

Values vs. References

In Chapter 2: Surveying JS, we discussed the different kinds of values: primitives and objects.

Reference

References are the idea that two or more variables are pointing at the same value, such that modifying this shared value would be reflected by access via any of those references.

In many languages, the developer can choose between assigning/passing a value as the value itself, or as a reference to the value.
In JS, however, this decision is entirely determined by the kind of value.

Note: Primitive values are always assigned/passed as value copies. For eg:

var myName = "Kyle";
var yourName = myName;

myName = "Frank";

console.log(myName);
// Frank
console.log(yourName);
// Kyle

As you can notice, yourName wasn’t affected by the re-assignment of myName to "Frank", as they both hold different copies.

Note: Object values (arrays, objects, functions, etc.) are treated as references. For eg:

var myAddress = {
  street: "123 JS Blvd",
  city: "Austin",
  state: "TX",
};

var yourAddress = myAddress;
// I've got to move to a new house!

myAddress.street = "456 TS Ave";

console.log(yourAddress.street);
// 456 TS Ave

Because the value assigned to myAddress is an object, it’s held/assigned by reference, and thus the assignment to the yourAddress variable is a copy of the reference, not the object value itself. That’s why the updated value assigned to the myAddress.street is reflected when we access yourAddress.street.

So Many Function Forms

Recall this snippet from Chapter 2: Surveying JS:

var awesomeFunction = function (coolThings) {
  // ..
  return amazingStuff;
};

This function expression is referred to as an anonymous function expression, since it has no name identifier between the function keyword and the (..) parameter list.
But when we perform name inference on an anonymous function it gives:

awesomeFunction.name;
// "awesomeFunction"

name inference only happens in limited cases such as when the function expression is assigned (with = ).
If you pass a function expression as an argument to a function call, for example, no name inference occurs; the name property will be an empty string, and the developer console will usually report “(anonymous function)”.
Even if a name is inferred, it’s still an anonymous function. because the inferred name is metadata and can't be used to refer to that function.

Note: An anonymous function doesn’t have an identifier to use to refer to itself from inside itself — for recursion, event unbinding, etc.

Tip: It is a good practice to use named functions as they improve the readability of the program.

Here are some more declaration forms:

// generator function declaration
function *two() { .. }

// async function declaration
async function three() { .. }

// async generator function declaration
async function *four() { .. }

// named function export declaration (ES6 modules)
export function five() { .. }

// IIFE
(function(){ .. })();
(function namedIIFE(){ .. })();

// asynchronous IIFE
(async function(){ .. })();
(async function namedAIIFE(){ .. })();

// arrow function expressions
var f;
f = async (x) => {
  var y = await doSomethingAsync(x);
  return y * 2;
};

Note: Keep in mind that arrow function expressions are syntactically anonymous, meaning the syntax doesn’t provide a way to provide a direct name identifier for the function.

Tip: Since, arrow functions are anonymous functions, they should be used everywhere. They have a specific purpose (i.e., handling the this keyword lexically).

Coercive Conditional Comparison

Here we will talk about, conditional expressions needing to perform coercion-oriented comparisons to make their decisions.

var x = "hello";
if (x) {
  // will run!
}

if (x == true) {
  // won't run
}

if (Boolean(x) == true) {
  // will run, as both have the same type
}

// which is the same as:
if (Boolean(x) === true) {
  // will run
}

Since the Boolean(..) function always returns a value of type boolean, the == vs === in this snippet is irrelevant; they’ll both do the same thing. But the important part is to see that before the comparison, coercion occurs, from whatever type x currently is, to boolean.

Prototypal “Classes”

In Chapter 3: Digging to the Roots of JS, we learned how different objects are linked together using a prototype chain.
Here, we will talk about Prototypa; Classes:

function Classroom() {
  // ..
}

Classroom.prototype.welcome = function hello() {
  console.log("Welcome, students!");
};

var mathClass = new Classroom();
mathClass.welcome();
// Welcome, students!

All functions by default reference an empty object at a property named prototype.
This is not the function’s prototype (where the function is prototype linked to), but rather the prototype object to link to when other objects are created by calling the function with the new keyword.
This “prototypal class” pattern is now strongly discouraged, in favor of using ES6’s class mechanism:

class Classroom {
  constructor() {
    // ..
  }
  welcome() {
    console.log("Welcome, students!");
  }
}

var mathClass = new Classroom();
mathClass.welcome();
// Welcome, students!

Under the covers, the same prototype linkage is wired up, but this class syntax fits the class-oriented design pattern much more cleanly than “prototypal classes”.

That's it for this chapter. I will be back with the notes of the next chapter.

Till then, Happy Coding!

If you enjoyed reading these notes or have any suggestions or doubts, then do let me know your views in the comments.
In case you want to connect with me, follow the links below:

LinkedIn | GitHub | Twitter

You Don't Know JS: Get Started: Chapter 4 (The Bigger Picture) Notes

Rajat Verma — Tue, 12 Jan 2021 09:27:17 +0000

Chapter 4: The Bigger Picture

This chapter divides the organization of JS into three main pillars:
- Pillar 1: Scope and Closure
- Pillar 2: Prototypes
- Pillar 3: Types and Coercion

Pillar 1: Scope and Closure

The organization of variables into units of scope (functions, blocks) is one of the most foundational characteristics of any language. Scopes are like buckets while variables are like the marbles that are put into the buckets.
The scope model of a language is like the rules that help you determine which color marbles go in which matching-color buckets.

Lexical Scope:

It is a type of convention used in many programming languages that sets the scope of a variable so that it can only be called from within the block of code in which it is defined.

JS is lexically scoped.
Many people claim that JS is not lexically scoped because of its two characteristics that are not present in other languages:
- Hoisting: All variables declared anywhere in scope are treated as if they’re declared at the beginning of the scope.
- var-declared variables: var-declared variables are function scoped, even if they appear inside a block.
Neither hoisting nor function-scoped var are sufficient to back the claim that JS is not lexically scoped.

Closures

Closure is a natural result of lexical scope when the language has functioned as first-class values, as JS does.
When a function makes reference to variables from an outer scope, and that function is passed around as a value and executed in other scopes, it maintains access to its original scope variables; this is closure.
We will dive deeper into Scope and Closure in the Book 2 of this series.

Pillar 2: Prototypes

We covered Prototypes in detail in the last chapter.
JavaScript is one of the very few languages where we have the option to create objects directly and explicitly, without first defining their structure in a class.
We will cover more about Prototypes, objects, and classes in Book 3 of this series.

Pillar 3: Types and Coercion

JS developers should learn more about types and should learn more about how JS manages type conversions.
No JS program will do anything useful if it doesn’t properly leverage JS’s value types, as well as the conversion (coercion) of values between types.
We will learn more about Types and Coercion in Book 4 of this series.

That's it for this chapter. With that, we have covered the first Book of the series "You Don't Know JS Yet".

Now you’ve got a broader perspective on what’s left to explore in JS, and the right attitude to approach the rest of your journey.

I will be back with the notes of the first chapter of Book 2.

Till then, Happy Coding!

If you enjoyed reading these notes or have any suggestions or doubts, then do let me know your views in the comments.
In case you want to connect with me, follow the links below:

LinkedIn | GitHub | Twitter

You Don't Know JS: Get Started: Chapter 3 (Digging to the Roots of JS) Notes

Rajat Verma — Sat, 02 Jan 2021 11:10:03 +0000

Chapter 3: Digging to the Roots of JS

Programs are essentially built to process data and make decisions on that data.
The patterns used to step through the data have a big impact on the program’s readability.

Iteration

The Iterator pattern suggests a standardized approach to consuming data from a source one chunk at a time.
The iterator pattern defines a data structure called an iterator that has a reference to an underlying data source (like the query result rows), which exposes a method like next(). Calling next() returns the next piece of data (i.e., a “record” or “row” from a database query).
ES6 standardized a specific protocol for the iterator pattern directly in the language. The protocol defines a next() method whose return is an object called an iterator result; the object has value and done properties, where done is a boolean that is false until the iteration over the underlying data source is complete.
The next() approach is manual, so ES6 also included several APIs for standard consumption of the iterators.

Consuming Iterators

for..of loop:

// given an iterator of some data source:
var it = /* .. */;

// loop over its results one at a time
for (let val of it) {
  console.log(`Iterator value: ${val}`);
}
// Iterator value: ..
// Iterator value: ..
// ..

So, as you can notice the above code prints all the iterator values one by one.

The ... or spread operator can also be used to consume the iterators. For eg:

// An Array spread: spread an iterator into an array, 
// with each iterated value occupying an array element position.
var vals = [ ...it ];

// OR

// A function call spread: spread an iterator into a function, 
// call with each iterated value occupying an argument position.
doSomethingUseful( ...it );

Iterables

The iterator-consumption protocol is technically defined for consuming iterables; an iterable is a value that can be iterated over.
ES6 defined the basic data structure/collection types in JS as iterables. This includes strings, arrays, maps, sets, and others.

// an array is an iterable
var arr = [10, 20, 30];
for (let val of arr) {
  console.log(`Array value: ${val}`);
}
// Array value: 10
// Array value: 20
// Array value: 30

Since, arrays are iterables we can shallow-copy them using the ... operator. For eg:

var arrCopy = [ ...arr ];

We can also iterate strings as:

var greeting = "Hello world!";
var chars = [...greeting];
chars;
// [ "H", "e", "l", "l", "o", " ", "w", "o", "r", "l", "d", "!" ]

Map

A Map data structure uses objects as keys, associating a value (of any type) with that object.

// given two DOM elements, `btn1` and `btn2`
var buttonNames = new Map();
buttonNames.set(btn1, "Button 1");
buttonNames.set(btn2, "Button 2");

for (let [btn, btnName] of buttonNames) {
  btn.addEventListener("click", function onClick() {
    console.log(`Clicked ${btnName}`);
  });
}

In the for..of loop over syntax (called the default map iteration, we use the [btn,btnName] ("array destructuring") to break down each consumed tuple into the respective key/value pairs ( btn1 / "Button 1" and btn2 / "Button 2" ).
We can call values() to get a values-only iterator:

for (let btnName of buttonNames.values()) {
  console.log(btnName);
}
// Button 1
// Button 2

Or if we want the index and value in an array iteration, we can make an entries iterator with the entries() method:

var arr = [10, 20, 30];
for (let [idx, val] of arr.entries()) {
  console.log(`[${idx}]: ${val}`);
}
// [0]: 10
// [1]: 20
// [2]: 30

For the most part, All built-in iterables in JS have three iterator forms available: keys-only ( keys() ), values-only ( values() ), and entries ( entries() ).

Closure

Closure is when a function remembers and continues to access variables from outside its scope, even when the function is executed in a different scope.
Closure is part of the nature of a function. Objects don’t get closures, functions do.
To observe a closure, you must execute a function in a different scope than where that function was originally defined.

function greeting(msg) {
  return function who(name) {
    console.log(`${msg}, ${name}!`);
  };
}

var hello = greeting("Hello");
var howdy = greeting("Howdy");

hello("Kyle");
// Hello, Kyle!
hello("Sarah");
// Hello, Sarah!
howdy("Grant");
// Howdy, Grant!

First the greeting(..) outer function is executed, creating an instance of the inner function who(..), that function closes over the variable msg. The instance of the inner function is assigned to the variables named hello and howdy respectively.
Since the inner function instances are still alive (assigned to hello and howdy, respectively), their closures are still preserving the msg variables.
These closures are not snapshots but actual variables. Hence, we can make changes to it using the inner function.

function counter(step = 1) {
  var count = 0;
  return function increaseCount() {
    count = count + step;
    return count;
  };
}

var incBy1 = counter(1);

incBy1(); // 1
incBy1(); // 2

Note: It’s not necessary that the outer scope be a function—it usually is, but not always—just that there be at least one variable in an outer scope accessed from an inner function:

for (let [idx, btn] of buttons.entries()) {
  btn.addEventListener("click", function onClick() {
    console.log(`Clicked on button (${idx})!`);
  });
}

this Keyword

Scope is static and contains a fixed set of variables available at the moment and location you define a function.
Execution Context is dynamic, entirely dependent on how it is called (regardless of where it is defined or even called from).
this is not a static/fixed characteristic of function, it is defined each time the function is called.

function classroom(teacher) {
  return function study() {
    console.log(`${teacher} says to study ${this.topic}`);
  };
}
var assignment = classroom("Kyle");

The outer classroom(..) function makes no reference to a this keyword, so it’s just like any other function we’ve seen so far. But the inner study() function does reference this , which makes it a this-aware function. In other words, it’s a function that is dependent on its execution context.

Since no topic was defined in the global object, calling assignment() prints:

assignment()
// Kyle says to study undefined

Now consider:

var homework = {
  topic: "JS",
  assignment: assignment,
};
homework.assignment();
// Kyle says to study JS

Here, the this for that function call will be the homework object. Hence, this.topic resolves to "JS" in this case.

Note: The benefit of this-aware functions and their dynamic context is the ability to more flexibly re-use a single function with data from different objects.

Prototypes

A prototype is a characteristic of an object.
The prototype can be thought of as a linkage between two objects and this linkage occurs when an object is created.
A series of objects linked together via prototypes is called the prototype chain.
The purpose of this prototype linkage (i.e., from an object B to another object A) is so that accesses against B for properties/methods that B does not have, are delegated to A to handle.

var homework = {
  topic: "JS",
};

The homework object has only a single property, however its default prototype linkage connects to the Object.prototype object, which has common built-in methods on it like toString(), valueOf(), etc. For eg:

homework.toString();
// [object Object]

Object Linkage

To define Object prototype linkage, create the object using the Object.create(..):

var homework = {
  topic: "JS",
};

var otherHomework = Object.create(homework);
otherHomework.topic;
// "JS"

The figure shows how the objects are linked in a prototype chain:

Tip: Object.create(null) creates an object that is not prototype linked anywhere, so it’s purely just a standalone object; in some circumstances, that may be preferable.

Note:

homework.topic;
// "JS"
otherHomework.topic;
// "JS"

otherHomework.topic = "Math";
otherHomework.topic; // "Math"

homework.topic;
// "JS" -- not "Math"

The assignment to topic creates a property of that name directly on otherHomework; there’s no effect on the topic property on homework.

this Revisited

The the true importance of this shines when considering how it powers prototype-delegated function calls:

var homework = {
  study() {
    console.log(`Please study ${this.topic}`);
  },
};

var jsHomework = Object.create(homework);
jsHomework.topic = "JS";
jsHomework.study();
// Please study JS

var mathHomework = Object.create(homework);
mathHomework.topic = "Math";
mathHomework.study();
// Please study Math

Both the objects have different topic and so different results on calling the study() function. For a better understanding:

That's it for this chapter. I will be back with the notes of the next chapter.

Till then, Happy Coding!

If you enjoyed reading these notes or have any suggestions or doubts, then do let me know your views in the comments.
In case you want to connect with me, follow the links below:

LinkedIn | GitHub | Twitter

You Don't Know JS: Get Started: Chapter 2 (Surveying JS) Notes

Rajat Verma — Mon, 23 Nov 2020 18:50:28 +0000

Chapter 2: Surveying JS

Best way to learn JS is to practice it!

Each File is a Program

Almost every Web Application has a bunch of JS files.
In JS, every single file is its own separate program. So, if somehow one file fails, it won't affect the execution of the other files.
The only way multiple JS files act as a single program is by sharing their state via the "global scope".
Since ES6, JS started supporting Modules format.

Values

Fundamental unit of information in a program is Value.
Values come in two forms in JS: Primitive and Objects.

Strings

Strings are ordered collection of characters.

console.log("Hello World");

In this code, Hello World is the string.
Strings can be defined using both Single-Quotes or Double-Quotes. The choice of which to use is yours. Just make sure to choose one and use it consistently in your program.
We can also use the backtick-character to define a string. However, this choice is not merely stylistic; there’s a behavioral difference as well. For example:

console.log("My name is ${ firstName }.");
// My name is ${ firstName }.

console.log('My name is ${ firstName }.');
// My name is ${ firstName }.

console.log(`My name is ${ firstName }.`);
// My name is Rajat.

In the above code snippet, we assumed that we have already declared a variable named firstName with the value Rajat.
The use of backtick declaration to place the value of a variable in a string is known as Interpolation.

Other primitive datatypes

Booleans and numbers are also used in a JS program.

while (false) {
  console.log(3.141592);
}

The code inside of the while loop is never executed as the condition always remains false.
Math.PI should be used for getting the value of mathematical PI.
Bigint is a primitive type that is used to store large whole numbers (larger than (2^53) - 1).
In addition to strings, numbers, and booleans, two other primitive values in JS programs are null and undefined. While there are many differences between them, for most parts both serve the purpose of the emptiness of a value. However, it’s safest and best to use only undefined as the single empty value.
Another primitive data-type is Symbol. You won’t encounter direct usage of symbols very often in typical JS programs. They’re mostly used in low-level code such as in libraries and frameworks.

Arrays And Objects

Besides primitives, the other value type in JS is an object value.
Arrays are a special type of object that’s comprised of an ordered and numerically indexed list of data. For eg:

names = [ "One", "Two", "Three", "Four" ];
names.length;
// 4
names[0];
// One
names[1];
// Two

JS arrays can hold any data type, either primitive or object. Even functions are values that can be held in arrays or objects.
Objects are more general: an unordered, keyed collection of any various values. For eg:

name = {
  first: "Kyle",
  last: "Simpson",
  age: 39,
  specialties: ["JS", "Table Tennis"],
};
console.log(`My name is ${name.first}.`);

Here, name is an object with keys like first, last, age, and specialties.
We can also use the following syntax to access the value of an object:

name["first"]

Value Type Determination

The typeof operator tells the built-in type of value (i.e, primitive or object).

typeof 42; // number
typeof "abc"; // string
typeof true; // boolean
typeof undefined; // undefined
typeof null; // object
typeof { a: 1 }; // object
typeof [1, 2, 3]; // object
typeof function hello() {}; // function

Note that typeof returns the type of null, array as an object, and function as function.

Declaring and Using Variables

Variables are like containers for values. There are many types of variable declaration in JS, and each one of them has its own different meanings. For eg:

var name = "Kyle";
var age;

The var keyword declares a variable to be used in the program, and optionally allows initial value assignment.
Similarly, the let keyword can be used to declare variables as:

let name = "Kyle";
let age;

let allows more limited access to the variable than var. This is called block scoping as opposed to regular or function scope.
Another type of declaration is using the const keyword. A variable declared using this keyword is similar to let, with the addition that it must be given a value at the moment it’s declared, and cannot be re-assigned a different value later.

const myBirthday = true;
let age = 39;
if (myBirthday) {
  age = age + 1;
  // OK!
  myBirthday = false; // Error!
}

Tip: If you stick to using const only with primitive values, you avoid any confusion of re-assignment (not allowed) vs. mutation (allowed)! That’s the safest and best way to use const .

Functions

In JS, the term function takes the broader meaning of a Procedure. A procedure is a collection of statements that can be invoked one or more times, maybe provided some inputs, and may give back one or more outputs. A function declaration in JS looks like this:

function greetHello(name) {
  const msg = `Hello ${name}`;
  return msg;
}

This function is a statement and not an expression. The association between the identifier greetHello and the function value happens during the compile phase of the code before that code is executed.
A function expression can be defined as:

// let awesomeFunction = ..
// const awesomeFunction = ..
var awesomeFunction = function (coolThings) {
  // ..
  return amazingStuff;
};

This function is an expression that is assigned to the variable awesomeFunction. Contrary to a function statement, a function expression is not associated with its identifier until that statement during runtime.
In JS, functions are a special type of object. They are treated as Values.
A function may or may not have a parameter.
Functions can also return values. You can only return a single value, but if you want to return multiple values, then you can wrap up them into a single object/array.
Since functions are values, they can be assigned as properties on objects:

var whatToSay = {
  greeting() {
    console.log("Hello!");
  },
  question() {
    console.log("What's your name?");
  },
  answer() {
    console.log("My name is Kyle.");
  },
};
whatToSay.greeting();
// Hello!

Comparisions

== is generally referred to as the loose-equality operator.
=== equality comparison is often described as, “checking both the value and the type”. For eg:

3 === 3.0 // true
null === null // true
3 === "3" // false

=== disallows any sort of type conversion (aka, “coercion”) in its comparison, where other JS comparisons do allow coercion.
The === operator is designed to lie in two cases of special values: NaN and -0. Consider:

NaN === NaN; // false
0 === -0; // true

In the first case, it says that an occurrence of NaN is not equal to any other occurrences of NaN. In the case of -0, the === operator lies and says it’s equal to the regular 0 value.
So, for such comparisions involving NaN use the Number.isNaN(..) utility, and For -0 comparison, use the Object.is(..) utility.
The Object.is(..) utility can also be used for NaN comparisons. It is a really-really-strict comparison!
Object values comparision is even more complicated:

[ 1, 2, 3 ] === [ 1, 2, 3 ];  // false
{ a: 42 } === { a: 42 }       // false
(x => x * 2) === (x => x * 2) // false

The === operator uses identity equality for object values.
In JS, all object values are held by reference, are assigned and passed by reference-copy, and are compared by reference (identity) equality.

var x = [ 1, 2, 3 ];
// assignment is by reference-copy, so
// y references the *same* array as x,
// not another copy of it.
var y = x;
y === x;            // true
y === [ 1, 2, 3 ];  // false
x === [ 1, 2, 3 ];  // false

JS doesn’t provide structural equality comparison because it’s almost intractable to handle all the corner cases!

Coercive Comparisons

Coercion means a value of one type being converted to its respective representation in another type.
The == operator performs an equality comparison similarly to how the === performs it. In fact, both operators consider the type of values being compared. And if the comparison is between the same value type, both == and === do exactly the same thing, no difference whatsoever. If the value types being compared are different, the == differs from === in that it allows coercion before the comparison.
Instead of “loose equality,” the == operator should be described as “coercive equality”. Consider the following examples:

42 == "42";
1 == true;

In both cases, the value types are different so coercion is applied and once they are of the same type then only the values are compared.
The relational comparison operators (>, <, >=, <=) also work like == operator. For eg:

var arr = ["1", "10", "100", "1000"];
for (let i = 0; i < arr.length && arr[i] < 500; i++) {
  // will run 3 times
}

These relational operators typically use numeric comparisons, except in the case where both values being compared are already strings; in this case, they use the alphabetical (dictionary-like) comparison of the strings:

var x = "10";
var y = "9";
x < y;      // true, watch out!

How We Organize in JS

Two of the most used patterns are classes and modules.

Classes

A class in a program is a definition of a type of custom data structure that includes both data and behaviors that operate on that data.

class Page {
  constructor(text) {
    this.text = text;
  }
  print() {
    console.log(this.text);
  }
}

class Notebook {
  constructor() {
    this.pages = [];
  }
  addPage(text) {
    var page = new Page(text);
    this.pages.push(page);
  }
  print() {
    for (let page of this.pages) {
      page.print();
    }
  }
}

var mathNotes = new Notebook();
mathNotes.addPage("Arithmetic: + - * / ...");
mathNotes.addPage("Trigonometry: sin cos tan ...");
mathNotes.print();

// Arithmetic: + - * / ...
// Trigonometry: sin cos tan ...

In Page class, the data text is stored in property this.text and the behavior is print().
In Notebook class, the data pages is an array of Page instances and the behaviours are print() and addPage(..).

Class Inheritance

class Publication {
  constructor(title, author, pubDate) {
    this.title = title;
    this.author = author;
    this.pubDate = pubDate;
  }
  print() {
    console.log(`
Title: ${this.title}
By: ${this.author}
${this.pubDate}
`);
  }
}

This Publication class defines a set of common behavior that any publication might need.

class Book extends Publication {
  constructor(bookDetails) {
    super(bookDetails.title, bookDetails.author, bookDetails.publishedOn);
    this.publisher = bookDetails.publisher;
    this.ISBN = bookDetails.ISBN;
  }
  print() {
    super.print();
    console.log(`
Publisher: ${this.publisher}
ISBN: ${this.ISBN}
`);
  }
}

The Book class uses the extends clause to extend the general definition of Publication to include additional behavior. This behavior is called Inheritance.

Modules

The Modules pattern have the same goal i.e. to group data and behavior, but it has certain differences from classes. An example of classic-modules is:

function Publication(title, author, pubDate) {
  var publicAPI = {
    print() {
      console.log(`
Title: ${title}
By: ${author}
${pubDate}
`);
    },
  };
  return publicAPI;
}

function Book(bookDetails) {
  var pub = Publication(
    bookDetails.title,
    bookDetails.author,
    bookDetails.publishedOn
  );
  var publicAPI = {
    print() {
      pub.print();
      console.log(`
Publisher: ${bookDetails.publisher}
ISBN: ${bookDetails.ISBN}
`);
    },
  };
  return publicAPI;
}

The class form stores methods and data on an object instance, which must be accessed with the this. prefix. With modules, the methods and data are accessed as identifier variables in scope, without any this. prefix.

ES Modules

ESMs are always file-based; one file, one module.
They have to be exported from one file to be used in another.

That's it for this chapter. I will be back with the notes of the next chapter.

Till then, Happy Coding!

If you enjoyed reading these notes or have any suggestions or doubts, then do let me know your views in the comments.
In case you want to connect with me, follow the links below:

LinkedIn | GitHub | Twitter

You Don't Know JS: Get Started: Chapter 1 (What is JavaScript?) Notes

Rajat Verma — Wed, 18 Nov 2020 14:16:13 +0000

Chapter 1: What Is JavaScript?

JavaScript is not the script part of Java.
The official name of the language specified by TC39 and formalized by the ECMA standards body is ECMAScript.
TC39 - the technical steering committee that manages JS, comprises around 50-100 people from different companies like Mozilla, Google, Apple, and Samsung.
ECMA - the standards organization.
All tc39 proposals can be found here: https://github.com/tc39/proposals
v8 engine - Chrome's JS Engine
SpiderMonkey engine - Mozilla’s JS engine

The Web Rules Everything About (JS)

The array of environments that runs JS are constantly expanding.
But, the one environment that rules JS is the web.

Not All (Web) JS...

Various JS environments (like browser JS engines, Node.js, etc.) add APIs into the global scope of your JS programs that give you environment-specific capabilities, like being able to pop an alert-style box in the user’s browser.
These are not mentioned in the actual JS specifications.
Some exmaples of such APIs are: fetch(..), getCurrentLocation(..), getUserMedia(..) and fs.write(..).
Even console.log() and all other console methods are not specified in the JS specifications but are used in almost every JS environment.
Most of the cross-browser differences people complain about with JS is so inconsistent! claims are actually due to differences in how those environment behaviors work, not in how the JS itself works.

It’s Not Always JS

console/REPL (Read-Evaluate-Print-Loop) are not JS enviornments, they are developer tools.
Their primary purpose is to make life easier for developers.
We shouldn’t expect such tools to always adhere strictly to the way JS programs are handled, because that’s not the purpose of these tools.

Many Faces

Typical paradigm-level code categories includes:
- Procedural - follows a top-down, linear approach thorugh a pre-determined set of operations.
- Object Oriented - collects logic and data into units called classes.
- Functional - organizes code into functions.

Paradigms are orientations that guide the programmers to approach the solutions to their problems.

C is procedural, Java and C++ are Object-oriented while Haskell is FP.
Some languages support code that comes from a mix and match of more than one paradigm, these languages are called "multi-paradigm languages".
JavaScript is most definitely a multi-paradigm language.

Backwards & Forwards

JavaScript practice the Preservation of backward compatibility.
Backwards Compatibility: It means that once something is accepted as valid JS, there will not be any future change to the language that causes that code to become Invalid JS.
TC39 members often proclaim that: “we don’t break the web!”.
Forwards Compatibility: Being forwards-compatible means that including a new addition to the language in a program would not cause that program to break if it were run in an older JS engine.
JS is not forwards-compatible.
HTML and CSS are forwards-compatible, for instance, if you take out a code from 2020 and try to run it in an older browser, it will just skip the unrecognized HTML/CSS but it will not break the page (though the page may not look the same). They are not backward-compatible.

Jumping the Gaps

Since JS is not forward-compatible, there will always be some code that is valid JS, but is not working in an older browser or environment.
Due to this, JS developers need to take special care to address this gap. For new and incompatible syntax, the solution is transpiling.
Transpiling: to convert the newer JS syntax version to an equivalent older syntax that the old browsers and environments support.
The most common transpiler is Babel.
It’s strongly recommended that developers use the latest version of JS so that their code is clean and communicates its ideas most effectively.

Filling the Gaps

If the forwards-compatibility issue is not because of a new-syntax but because of an API method that was recently added, the solution is to define the recently added API that acts as if the older environment had already had it natively defined.
This pattern is called a polyfill.
Example:

// getSomeRecords() returns us a promise for some
// data it will fetch
var pr = getSomeRecords();
// show the UI spinner while we get the data
startSpinner();
pr.then(renderRecords).catch(showError).finally(hideSpinner);
// render if successful
// show an error if not
// always hide the spinner

This code uses an ES2019 feature and so it would not work in a pre-ES2019 environment, as, the finally(..) method would not exist, and an error would occur.

To make it work, we can define the finally(..) method, as:

if (!Promise.prototype.finally) {
  Promise.prototype.finally = function f(fn) {
    return this.then(
      function t(v) {
        return Promise.resolve(fn()).then(function t() {
          return v;
        });
      },
      function c(e) {
        return Promise.resolve(fn()).then(function t() {
          throw e;
        });
      }
    );
  };
}

Warning: This is only a simple illustration of a basic (not entirely spec-compliant) polyfill for finally(..). Don’t use this polyfill in your code; always use a robust, official polyfill wherever possible, such as the collection of polyfills/shims in ES-Shim.

What’s in an Interpretation?

Code wriiten in JS: is it an interpreted script or compiled program?
The real reason that matters to have a clear picture of whether JS is interpreted or compiled relates to the nature of how errors are handled in it.
Historically, Interpreted or Scripting languages were executed in generally a top-down and line-by-line fashion.

Some languages go through a processing step (typically Parsing) before their execution. This parsing creates an Abstract Syntax Tree (AST) of the whole program.

In JS, source code is parsed before it is executed.
So JS is a parsed language, but is it compiled? The Answer is very close to YES than NO.
The parsed JS is converted into binary form and that binary form is executed.
Hence, JS is a compiled language. So, due to this fact, we are informed about the errors in our code even before it gets executed.

Web Assembly (WASM)

In 2013, ASM.js was introduced as one way of addressing the pressures on the runtime performance of JS.
ASM.js intended to provide a path for non-JS programs (C, etc.) to be converted to a form that could run in the JS engine.
After several years, another set of engineers released Web Assembly.
WASM is a representation format more akin to Assembly that can be processed by a JS engine by skipping the parsing/compilation that the JS engine normally does.
The parsing/compilation of a WASM-targeted program happens ahead of time (AOT); what’s distributed is a binary-packed program ready for the JS engine to execute with very minimal processing.

Strictly Speaking

With the release of ES5(2009), JS added "strict mode" as an opt-in mechanism for encouraging better JS programs.
It should be thought of as a guide to the best way to do things so that the JS engine has the best chance of optimizing and efficiently running the code.

Strict mode is switched on per file with a special pragma (nothing allowed before it except comments/whitespace):

// only whitespace and comments are allowed
// before the use-strict pragma
"use strict";
// the rest of the file runs in strict mode

Strict mode can alternatively be turned on the per-function scope
Interestingly, if a file has strict mode turned on, the function-level strict mode pragmas are disallowed. So you have to pick one or the other.

That's it for this chapter. I will be back with the notes of the next chapter.

Till then, Happy Coding!

If you enjoyed reading these notes or have any suggestions or doubts, then do let me know your views in the comments.
In case you want to connect with me, follow the links below:

LinkedIn | GitHub | Twitter

How to use NPM (and import/export modules) in JavaScript

Rajat Verma — Sun, 14 Jun 2020 04:42:46 +0000

If you are familiar with JavaScript or Web Development then you must have heard about npm. NPM helps us to manage packages and dependencies in our projects. So, while learning a JavaScript framework the knowledge of npm would be really useful to learn it in an easier manner.

In this series of articles, we aimed to cover the following topics:

Important ES6 Features
Objects and Array methods
Asynchronous JavaScript and Fetch API
NPM and import/export modules in JavaScript (this article)

Let’s first start with NPM:

NPM

What is NPM?

NPM is the default package manager for node. It is used to install, share, and manage javascript packages in a project.
NPM has three components:

The website (Using the website we can find, share, and view packages)
The Command Line Interface (CLI) (The CLI is the component that helps us in managing our packages)
The registry (The npm registry is the database where all the packages exist, we can download packages published by other developers and can also publish our own packages to the registry)

Note:

NPM can also be used to publish and manage private packages.
A package is simply a program that performs one or more operations.

How to Install npm?

NPM comes pre-installed with node.js. So, you don’t need to worry about installing it manually, you just have to install node.js on your system.

To install node.js, visit https://nodejs.org/en/download, and install its LTS (Long Term Support) version.
After installation, use the commands shown below to check if they are installed:

// to check nodejs's version
node -v or node --version  
// to check npm's version
npm -v or npm --version

This will result in something like this:

package.json

The package.json file is like the manifest of your project. It makes it easier to install and manage packages. It consists of all the metadata of the project that will be useful while sharing the project with other developers.
According to the official docs:

A package.json file:

lists the packages your project depends on
specifies versions of a package that your project can use using semantic versioning rules
makes your build reproducible, and therefore easier to share with other developers

Asynchronous JavaScript to learn before JavaScript Frameworks

Rajat Verma — Fri, 05 Jun 2020 19:09:02 +0000

In this series of articles, we aimed to cover the following topics:

Important ES6 Features
Objects and Array methods
Asynchronous JavaScript and Fetch API (this article)
NPM and import/export modules in JavaScript In the last two articles, we have already covered the first two topics so, in this article, we will talk about Asynchronous JavaScript and Fetch API. So, without wasting any time let’s get started with the topic:

Before jumping into the details of Asynchronous JavaScript, let us first talk about the execution of Synchronous Code in JavaScript. We will consider a simple example to understand this:

function sayHi() {
  console.log('Hi!');
}

console.log('Program starts'); // prints: Program starts
sayHi();                      // prints: Hi!
console.log('Program ends'); // prints: Program ends

As you can notice, it follows a sequential order, that is all the tasks are executed in the order in which they were coded. Internally the JavaScript engine executes these tasks with the help of Call Stack.
Let’s see how the Call Stack helps in executing our code:

As you can notice, The task that is currently in execution gets added to the Call Stack and is popped from it once it completes its execution.
So, Now, you have an idea about the execution of synchronous code and the Call Stack, let’s get started with asynchronous javascript.

Looking to work on a ReactJS Design-System

Rajat Verma — Wed, 29 Apr 2020 15:38:02 +0000

Hello Everyone,
I am looking to work on a ReactJS Design System so that I can contribute to an open-source project and work the components directly to websites. So, if anyone of you is currently working on or are interested in working then please let me know so that we can make a great Open-source project out of it.

Video-Chat-Using-React

Rajat Verma — Mon, 27 Apr 2020 09:56:22 +0000

What I built

Built an application that helps to communicate in this condition of pandemic crisis.

Category Submission:

COVID-19 Communications

Link to Code

https://github.com/rajat2502/Video-Chat-React-Twilio

How I built it (what's the stack? did I run into issues or discover something new along the way?)

It is built using ReactJS and Express in the backend. I have used Twilio's Video APIs to make it.