DEV Community: Sheikh Mubashir

Demystifying JavaScript: Understanding Execution Contexts, Hoisting, and Type Conversion

Sheikh Mubashir — Fri, 11 Oct 2024 12:48:59 +0000

JavaScript may seem simple on the surface, but under the hood, there’s a lot happening. Today, we’ll explore some essential concepts like execution contexts, hoisting, primitive vs. non-primitive data types, and type conversion. These are crucial to understand if you want to write better, bug-free code.

Global Execution Context and Lexical Environment
When you run a JavaScript file in the browser, the code gets executed line by line in the call stack. However, before any of your code runs, a global execution context is created. This context sets up the this and window objects. In Node.js, the equivalent of window is global, and if you compare the two, you'll find that window === global returns true.

Whenever you call a function, a new lexical environment is created. The global execution context is the first to be created, and all functions defined inside it can access its variables. This is how JavaScript’s scope chain works — you can access variables in the outer (global) scope from inside a function.

Hoisting: Variables and Functions
JavaScript has a mechanism called hoisting, where variables and functions are “moved” to the top of their scope during compilation. Here’s how it works:

Variables: Variables declared with var are partially hoisted, meaning you can reference them before they are initialized, but their value will be undefined until the line where they are initialized is reached.
Functions: Functions declared with the function declaration syntax are fully hoisted, meaning you can call the function even before its declaration in the code.
Example:

console.log(a); // undefined
var a = 5;

console.log(b); // Error: b is not defined
let b = 10;

hoistedFunction(); // Works!
function hoistedFunction() {
  console.log('This function is hoisted!');
}

notHoistedFunction(); // Error: notHoistedFunction is not a function
var notHoistedFunction = function() {
  console.log('This function is not hoisted!');
}

As you can see, let and const are not hoisted like var, and function expressions (like notHoistedFunction) are only defined at runtime.

Primitive vs. Non-Primitive Types
JavaScript has two types of data: primitive and non-primitive.

Primitive types include string, number, boolean, undefined, null, symbol, and bigint. These are immutable, meaning their values cannot be changed. For example:

let x = 'hello';
x[0] = 'H'; // This won’t change the string, it stays 'hello'

Non-primitive types are objects, arrays, and functions. These are mutable, and their values can be changed because they are passed by reference. For instance:

let obj1 = { name: 'John' };
let obj2 = obj1; // Both obj1 and obj2 now reference the same object
obj2.name = 'Doe';
console.log(obj1.name); // Outputs: Doe

To avoid modifying the original object, you can create a shallow copy using Object.assign() or the spread operator (...). For deep copies, which copy nested objects, use JSON.parse() and JSON.stringify().

Example Code Snippet: Shallow Copy vs Deep Copy

// Shallow copy example
let obj1 = { name: 'John', details: { age: 30 } };
let obj2 = { ...obj1 }; // Shallow copy
obj2.details.age = 40;
console.log(obj1.details.age); // Output: 40 (Shallow copy affects the original)

// Deep copy example
let obj3 = JSON.parse(JSON.stringify(obj1)); // Deep copy
obj3.details.age = 50;
console.log(obj1.details.age); // Output: 40 (Deep copy doesn’t affect the original)

Type Conversion and Comparison
JavaScript is a dynamically typed language, meaning you don’t have to specify variable types explicitly. However, this can sometimes lead to unexpected behavior, especially when using comparison operators.

Always prefer using triple equals (===) over double equals (==) to avoid type coercion. For example:

console.log(0 == '0'); // true (type coercion happens)
console.log(0 === '0'); // false (no type coercion)

For special cases, like comparing NaN, use Object.is() because NaN === NaN returns false.

console.log(NaN === NaN); // false
console.log(Object.is(NaN, NaN)); // true

JavaScript’s Runtime and Node.js
JavaScript runs on a single-threaded, synchronous runtime, which means it can only execute one task at a time. This might seem limiting, but JavaScript handles asynchronous tasks efficiently by using the Web API and callback queue. Here’s how it works:

When JavaScript encounters an async task (like setTimeout or an HTTP request), it sends the task to the Web API.
The call stack continues to execute the remaining code.
Once the async task is complete, it is added to the callback queue and will execute when the call stack is empty.
Node.js extends this runtime to the server-side, using the V8 engine and a non-blocking I/O system powered by libuv. Node.js introduced the idea of a single-threaded event loop that can handle multiple requests without blocking other operations.

By understanding how JavaScript handles execution contexts, hoisting, type conversion, and asynchronous tasks, you’ll be able to write cleaner and more efficient code. With JavaScript’s dynamic nature, tools like TypeScript can help you avoid common pitfalls by providing static type checks that make your code production-ready.

Mastering JavaScript: Avoiding Pitfalls with Memory Management and Asynchronous Execution

Sheikh Mubashir — Wed, 09 Oct 2024 09:03:39 +0000

As JavaScript developers, understanding how the language handles tasks like memory management and asynchronous code execution is crucial for writing efficient code. Today, we’ll dive into how JavaScript’s engine optimizes code and manages memory, while also exploring its single-threaded, asynchronous nature.

Inline Caching and Code Optimization

When it comes to optimization, compilers use techniques like inline caching to make code faster. For this to work efficiently, your code needs to be predictable — not just for humans but also for the machine. To help the compiler optimize code, it’s best to avoid certain built-in keywords like eval(), arguments, for in, delete, and with. These keywords can introduce hidden classes, which slow down the compiler’s ability to optimize your code.

Call Stack and Memory Heap

JavaScript runs code using two main components: the call stack and the memory heap.

The memory heap is where all the values and objects are stored in random order.
The call stack keeps track of the functions currently being executed, following a First In, Last Out (FILO) pattern.
One common issue developers face is stack overflow, which happens when a function calls itself recursively or repeatedly without breaking the loop. The browser eventually runs out of memory and crashes.

Example Code Snippet: Stack Overflow Example

function recursiveFunction() {
  return recursiveFunction(); // This will cause a stack overflow
}

recursiveFunction();

In this example, the function keeps calling itself with no end, causing the call stack to fill up and resulting in a stack overflow.

Garbage Collection and Memory Leaks

JavaScript is a garbage-collected language, which means it automatically removes unused variables and objects from the memory heap. This process is handled by the mark-and-sweep algorithm, and unlike in languages like C, you can’t manually control memory management in JavaScript. While this automatic process makes things easier, there are common mistakes that can lead to memory leaks.

Common Causes of Memory Leaks:

Global variables: If you declare global variables that are never cleaned up, they stay in memory.
Event listeners: Failing to remove event listeners after they’re no longer needed can cause memory to fill up.
setTimeout functions: Similar to event listeners, if setTimeout is not cleared after use, it can lead to a memory leak.
Single-Threaded and Asynchronous Execution
JavaScript is a single-threaded and synchronous language, meaning it can handle one task at a time. This might seem limiting, but JavaScript is also powerful when it comes to handling asynchronous tasks.

Here’s how it works:

When JavaScript encounters an async task, such as a network request, it sends it to the Web APIs (in the browser).
While the async task is handled in the background, the synchronous code continues to execute.
Once the async task is complete, the result is pushed into the callback queue.
If the call stack is empty, JavaScript takes the result from the callback queue and pushes it onto the call stack to execute.
This is how JavaScript can handle tasks like HTTP requests without freezing the page, even though it runs on a single thread.

Example Code Snippet: Asynchronous Code Execution

console.log('Start');

setTimeout(() => {
  console.log('Async Task Complete');
}, 3000); // This runs after 3 seconds, but JS doesn't block the next line

console.log('End');

In this example, the message “Async Task Complete” appears after 3 seconds, but “End” prints immediately because the async task runs in the background.

Node.js and JavaScript Runtime

Before Node.js came along in 2009, JavaScript could only run inside browsers. Node.js, created by Ryan Dahl, allows JavaScript to run outside the browser. Node.js is built using C++ and uses the V8 engine (the same engine that runs JavaScript in Chrome) to handle tasks. It is known for its non-blocking I/O and single-threaded nature, meaning it handles multiple tasks simultaneously without using multiple threads.

Node.js introduced the concept of single-threaded, non-blocking architecture, allowing it to handle I/O operations (like file reading) efficiently without blocking other operations.

Why JavaScript is Not Just an Interpreted Language: Understanding JIT Compilation

Sheikh Mubashir — Tue, 01 Oct 2024 08:54:26 +0000

When it comes to translating code into machine code, there are two main approaches: interpreters and compilers. JavaScript is often referred to as an interpreted language, but that’s not entirely accurate, and I’ll explain why.

Interpreters vs. Compilers
An interpreter translates code line by line, which makes it great for quickly running code. It’s a fast way to start execution, but there’s a downside — it doesn’t optimize repetitive tasks. For example, if your code has a loop that repeats the same result, the interpreter will process it each time without any optimization, slowing things down.

On the other hand, a compiler takes the entire code in one go and translates it into machine code. This process takes longer at first, but after the initial compilation, it runs much faster. That’s because compilers can optimize repetitive tasks, like loops, making the code more efficient.

Enter JIT (Just-In-Time) Compiler
In the late 2000s, engineers saw the strengths of both interpreters and compilers and decided to create something better — a JIT (Just-In-Time) compiler. This hybrid approach combines the best of both worlds.

Here’s how it works:

When you give a JavaScript file to the browser, the code goes through a parser, which converts it into an Abstract Syntax Tree (AST).
At this point, there’s a decision to make:
If the code doesn’t need optimization, it goes directly to the interpreter, which translates the code to machine-readable instructions (binary).
If the code has repetitive or complex tasks, a profiler detects the need for optimization and forwards it to the compiler, which optimizes the code and translates it.

here is the best diagram for a better understanding

So, when someone asks, “Is JavaScript an interpreted language?” you can say “technically yes”, but it depends on the implementation. JavaScript uses both an interpreter and a compiler, thanks to JIT compilation.

Here’s an example to demonstrate the efficiency difference between an interpreter and a compiler.

function calculateSum() {
  let sum = 0;
  for (let i = 0; i < 1000000; i++) {
    sum += i;
  }
  return sum;
}

console.log(calculateSum());

In this example, an interpreter would go through each iteration of the loop one by one. A JIT compiler, on the other hand, would notice that the loop can be optimized, speeding up execution after the first run.

Conclusion
Understanding how JavaScript works under the hood helps you appreciate its flexibility and efficiency. The combination of interpreters and compilers (thanks to JIT) allows JavaScript to run quickly and efficiently in modern browsers.

Next time someone calls JavaScript an interpreted language, you can explain that while it starts out that way, it can also behave like a compiled language when optimization is needed.