DEV Community: Mateusz Janusz

Hoisting in JavaScript

Mateusz Janusz — Sat, 16 Jul 2022 11:49:17 +0000

Have you ever wondered why you were able to call functions before you wrote them in your code? This is possible thanks to hoisting.

Hoisting is a process of moving the declaration of variables and functions to the top by the interpreter. This happens during compilation, before code execution.

So no matter where variables and functions are declared, they are moved to top of their scope. It allows functions to be used in code before they are declared in the code.

printName("John"); // Output: 'My name is John'

function printName(name) {
  console.log("My name is " + name);
}

variables are partially hoisted

It's important to remember that functions are fully hoisted but variables are only partially hoisted.
This is because JavaScript only hoists declarations, not initializations.

In other words, JS engine is allocating variables in memory but without their value. Their values get assigned (initialization) during code execution. Before execution, the variable has its default initialization: it's undefined for variables declared using var, otherwise uninitialized.

console.log(name); // returns 'undefined' (JavaScript has hoisted the variable declaration only)

var name = 'John'; // initialization and declaration 

console.log(name); // after the line is executed, it returns 'John'

Because of this, we can use variables before we declare them. However, we have to be careful because the hoisted variable can be initialized with undefined.

`let` and `const` hoisting

With const and let, just as with var, the variable is hoisted to the top of the block, but it is not initialized with a default value. So an exception (Reference error) will be thrown if a variable declared with let or const is used before it is initialized.

console.log(name); // Output: ReferenceError: name is not defined
const name = 'John';

using 'strict mode'

We can also use strict mode that was introduced in the es5 version of JavaScript. In a restricted mode, the compiler won't tolerate the usage of variables before they are declared.

'use strict';

console.log(name); // Output: ReferenceError: name is not defined
name = 'John';

Function expressions vs declarations

Function declarations are hoisted completely to the top, but we should not forget that function expressions (similar to variables) are not fully hoisted. Function expressions are hoisted to the top of the block, but they are not initialized until code is executed.

declaration(); // This function has been hoisted

// Function declaration
function declaration() {
  console.log('I am hoisted');
};

expression(); // Output: "TypeError: expression is not a function

// Function expression
var expression = function() {
  console.log('I am declared during execution');
};

The Javascript Engine

Mateusz Janusz — Mon, 11 Jul 2022 07:53:19 +0000

A computer cannot understand Javascript, so we need another computer program that can execute JS code and translate it into a language that is understandable by machines. This computer program is called Javascript Engine.

The very first JavaScript engine was created by Brendan Eich in 1995 for the Netscape web browser.

ECMAScript is the standardized specification of JavaScript, therefore a Javascript engine is also called ECMAScript engine. There is many of them and most of them are developed by web browser vendors.

Nowadays, the most popular (the most used) engine is called V8. It was created by Google for its Chrome browser. It is written in C++ and it was developed with a big focus on performance. It was crucial for Google to develop an engine that can handle heavy applications such as Google Maps. They achieved it thanks to just-in-time compilation which significantly improved execution times. V8 can run standalone, or can be embedded into any C++ application. Apart from Google Chrome, Chromium project, Electron.js, also server-side JavaScript runtime Node.js is using the V8 engine.

There are other popular JavaScript engines used by different browsers:

Safari is using Apple's own engine JavaScriptCore
Firefox has SpiderMonkey
Edge was initially using Chakra but has been rebuilt using Chromium and the V8 engine.

See the list of all ECMAScript engines.

How engine works

Let's focus on how Javascript engine works step by step.

Firstly, raw JS code goes into a Parser. Parser does a lexical analysis, it breaks code into a series of tokens (sequence of characters), so later they can get converted into Abstract Syntax Tree.
AST is a hierarchical tree like structure of program representation. It breaks things down for system to understand what code does.
Interpreter takes AST and splits out Bytecode. This process in V8 engine is known as Ignition.
In the meantime, Profiler watches for optimizing the code. When it finds a code that is repeated, it will move this code into a compiler.
Compiler modifies the code to optimize it, so it runs faster. It updates Bytecode with optimized parts of code. In V8 Engine, this compiler is called TurboFan

Interpreter vs Compiler

Interpreters and compilers translates one language into another language which is understandable by a machine.

Interpreters are quick to pick up and running. An interpreter allows us to run code right away, it translates and reads a file, line by line on the fly. The problem with it is that it eventually gets slow, that's why we need compilers.

A compiler doesn't translate code on the fly. Instead, it tries to understand what code does, it takes our code and it changes it to something else to optimize it. So for instance, it won't run the loop all times when it sees a code which has the same input or output, it will translate it into single run code.

What if we combine an interpreter and a compiler into one? We get JIT (just-in-time) Compiler!

How to do human-friendly code reviews

Mateusz Janusz — Sun, 20 Dec 2020 16:56:46 +0000

Doing code reviews is not an easy task. Doing a good code review is even more difficult and responsible job. It is not only a technical process but also a social one. In this article, I discuss a few techniques that may improve your code reviews and make them more human friendly to keep positive relationships with your colleagues.

Explain

You don't always need to do it, but sometimes it's appropriate to give a bit more explanation about your suggestions. It's a good practice to explain both your suggested change and the reason for the change. This helps the developer understand why you are making your comment and there is a chance that the author of the pull request may learn something new.

If you can, provide a link to a section in your company's style guide, to language or library documentation, or to the best practice you’re following. Make sure that the developer really understands how your suggestion improves code health.

Code can sometimes be just messy or written in an unintuitive way. Instead of formulating judgments like "This is bad" or "This line of code is unnecessary", try to explain why this code should be refactored. You could write your comment in a nicer way, for instance, "I found this code hard to understand, what about splitting this complex function?". Referring to the issue in this way helps the developer understand why you are making your comment.

By the way, try to encourage developers to simplify code or add code comments instead of just explaining the complexity to you, so those changes can be helpful also to future code readers.

Give guidance

It's not easy to find a good balance between pointing out problems and providing direct guidance. Code review is an opportunity for developers to learn and protect themselves from mistakes. But giving a ready solution to a problem is just taking away that opportunity.

Instead, let developers explore, research, and make a decision. This helps them to learn. On the other hand, if you leave comments like this one "Can we simplify this complex function?", you're not actually helping much. So instead of only pointing out problems, you should also share some suggestions, instructions, or maybe even a code example.

Remember that a hidden goal of code reviews is also to improve developers' skills so they require less and less guidance over time.

Do not judge

Code review comments should be written in a neutral language. You should never critique the author, instead focus on the code and possible improvements.

If you find something difficult to understand, ask for clarification rather than assuming ignorance or making judgments in comments, like "this can never work". If you want to critique the code of a colleague, make sure to do so in a respectful way and always include some possible ways for improvement.

To make sure you're not critiquing the author, avoid using the word "you" in your message. When the author sees "you" in a comment, they may take the criticism personally. Consider this sentence:

"You made this code hard to understand."

A comment like this brings the focus away from the code, and the author can interpret it as a personal attack.

Writing comments without the word "you" shouldn't be hard, you have at least two options.

Replace "you" with "we"

"This function you wrote is hard to read. Can you simplify it?"
"I find this function difficult to understand. Can we simplify it?"

Which comment would you prefer to receive as an author?

I bet that you would prefer the second one. That's because the second example brings focus to the code and the comment is not judging anybody.

Replace commands with requests

Another option is to omit the subject from the sentence. Look at these two examples:

"You should split this function into smaller ones."
"What about splitting this function so the code is easier to read and debug in the future?"

The second example is not only formulated in a friendly way but it also brings reasoning to your comment.

Point out good work

Don't limit your code review to only finding errors. Pointing out also good work definitely improves the team spirit and is a good motivator. Don't forget to do it especially if you have learned something from this code or if you noticed a solution you wouldn’t have come up with yourself.

Everyone makes mistakes

Remember that we're all humans and it doesn't matter if it's a beginner or experienced developer's code, the truth is that everyone makes mistakes. It may be caused by a bad day, bad mood, lack of domain knowledge, or overload with duties.

I hope that my tips will encourage you to strive for a stress-free and developer-friendly code review. Let's remember that good code reviews not only improve the merged code but they bring benefits to all team members. We can also inspire others and contribute to their self-development.

This article was originally published on my personal site mateuszjanusz.dev.

JS Concepts: Value vs. Reference

Mateusz Janusz — Sat, 19 Dec 2020 10:29:42 +0000

This article is a part of a series covering fundamentals of the JavaScript language. The intention of this series is to help developers advance their knowledge and really understand how the JavaScript language works. And to help myself get better at writing 😉

In the previous article, we talked about call stack. Today, we're going to discuss the difference between value and reference in JavaScript. At the end of this article, you will be able to tell why primitives and objects behave differently and how to avoid mistakes while manipulating them. 💪

Types in JavaScript

In JavaScript we have two categories of types.

Value types (primitives)

Types that are passed by value:

String
Number
BigInt
Boolean
Symbol
undefined
null

Reference types

Types that are passed by reference:

Object
Array
Function

Let's have a closer look at both of them.

Value vs. Reference

When you assign a variable, the JavaScript engine decides whether the value is a primitive or a reference value.

Primitive

When we assign a value as primitive, the value is actually stored in the variable. This means that when you manipulate the variable, you are working on the actual value stored in the variable. If you assign primitive variables to other variables using =, their values are copied to new variables. We say that they are copied by value.

Reference

When we assign non-primitive value to the variable, we copy them by reference. In other words, variables are given a reference to that value, so they don’t actually contain the value.

When you assign a non-primitive variable to other variable using =, its reference is copied to the new variable and so they now both point to the same object’s location in memory. Consequently, if you decide to manipulate only one of them, you are actually working on the reference, which means you manipulate both variables!

This is crucial to understand as it’s often the reason behind bugs.

Examples

Primitive values

const a = 5
let b = a

console.log(a) // 5
console.log(b) // 5

b = 10

console.log(a) // 5
console.log(b) // 10

As you can see in the example above, the value stored in the variable b has been changed, but the value of variable a remains intact. This is because variables a and b have no relationship. By copying value from variable a to b, we created a new independent value.

let index = 0

function increaseIndex(index) {
    index++
}

increaseIndex(index)
console.log(index) // 0

The index value stays 0 even after executing increaseIndex function. This is because primitive values are copied by value. We're dealing with two independent values here, so changing the copied value has no effects on the original value.

Non-primitive values

const person_one = {
    name: 'Adam',
    age: 20
}
const person_two = person_one

console.log(person_one.name) // 'Adam'
console.log(person_two.name) // 'Adam'

person_two.name = 'George'

console.log(person_one.name) // 'George'
console.log(person_two.name) // 'George'

By changing the name of person_two, we're also modifying value in person_one because both person_one and person_two are pointing to the same object. When the variable person_two is created and assigned to person_one, we're creating an alias to the original object, not a new object.

const person = {
    name: 'Adam',
    age: 20
}
function changeName(person) {
    person.name = 'George'
}

changeName(person)
console.log(person.name) // 'George'

In this case, the person name was changed after executing changeName function. This is because when we pass an object into the function, we're passing a reference to that object. When we change a property of that object within the function, the change will be reflected in the outer scope.

Summary

Primitives are copied by their value
Objects are copied by their reference
When you manipulate variable that stores a primitive value, you are working on the value stored in the variable
When you manipulate an object, you are working on the reference to that object, not on the actual object

This article was originally published on my personal blog mateuszjanusz.dev.

JS Concepts: Call Stack

Mateusz Janusz — Sat, 02 Mar 2019 11:38:33 +0000

This article is a part of a series covering fundamentals of the JavaScript language. The intention of this series is to help developers advance their knowledge and really understand how the JavaScript language works. And to help myself get better at writing 😉

Today, we're going to find out what is a call stack and how does it work in JavaScript. Let's begin! 👏

What is a call stack

We can say that the call stack is a kind of a to-do list of function invocations. It is a structure that stores a list of functions to be called.

The reason why we call it a call stack is because it stores data in a stack. Stack is an abstract data type where elements are inserted and removed according to the Last-In First-Out (LIFO) principle.

It's like a stack of pancakes; you always add to the top of the stack and remove from the top of the stack

Because JavaScript is mainly single threaded, it can only execute one line of code at any given time. Basically, it can only do one thing at a time.

If in a JavaScript application, you call a function, that function may resolve in any other function calls. Those functions may be waiting on results of other calls before the main function finishes. So the application needs to keep track of things that were invoked and things that are waiting to be returned. It needs to keep a history of functions that were invoked but are not done yet.

How does it work

Whenever you call a function, the details of the call are saved on top of the stack. Whenever a function returns, the information is taken off the top of the stack.

The code execution is synchronous. Whenever JavaScript engine finds a function invocation, it creates a new execution context for that function and pushes it to the top of the stack. The call stack knows the next function to be executed and will remove it after execution. It reaches to the context below it in the current stack until the memory is clear.

Let's look at the example:

function foo() {
    console.log('Hello')
}

function bar() {
    foo()
    console.log('World')
}

bar()

This is what happens if you run this code:

function bar() is called; empty stack frame (execution context) is created;

Call Stack:
bar()

function bar() calls function foo() which is added to the top of the stack

Call Stack:
foo()
bar()

function foo() returns and prints 'Hello' to the console
function foo() is removed from top of the stack

Call Stack:
~~foo()~~
bar()

now, function bar() is executed and it returns, 'World' is printed to the console
function bar() is popped off the stack

Call Stack:
~~bar()~~

we ended up with an empty stack, the memory is cleared

Call Stack:
EMPTY

You can also observe this if your browser throws an error stack trace in the console. It indicates where in the function it failed. Executed functions are presented from top to bottom, like in the stack. See the example below.

Stack overflow

We've all been there... This happens when we run an infinite loop.

A function invocated recursively (a function calls itself) can hit a limit on the size of the stack in a browser. That's what we call stack overflow. If this happens, a browser will stop all calls and throw 'Maximum call stack size exceeded' error.

Summary

Call stack is an ordered set of stack frames where:

most recently executed function is at the top of the stack
the first invoked function is at the bottom of the stack
the stack is processed from top to bottom

Other takeaways are:

JavaScript is single threaded, it can only do one thing at a time
Stack is a data structure where you always add to the top of the stack and remove from the top of the stack (LIFO)
Function execution is synchronous

This article was originally published on my personal blog.

DEV Community: Mateusz Janusz

Hoisting in JavaScript

variables are partially hoisted

let and const hoisting

using 'strict mode'

Function expressions vs declarations

The Javascript Engine

How engine works

Interpreter vs Compiler

How to do human-friendly code reviews

Explain

Give guidance

Do not judge

Replace "you" with "we"

Replace commands with requests

Point out good work

Everyone makes mistakes

JS Concepts: Value vs. Reference

Types in JavaScript

Value types (primitives)

Reference types

Value vs. Reference

Primitive

Reference

Examples

Primitive values

Non-primitive values

Summary

JS Concepts: Call Stack

What is a call stack

How does it work

Stack overflow

Summary

`let` and `const` hoisting