Hoisting

What is hoisting really?

The beginner explanation usually says that JavaScript "moves declarations to the top". That is a useful first approximation, but technically it is too vague.
A better model is that JavaScript creates the execution environment before executing the code and registers declarations in their appropriate scope.
Different declarations are initialised differently.

console.log(hoistedVar);

var hoistedVar = 'value';
// undefined

The var binding exists and is initialised to undefined before the assignment executes.
With let and const, the binding exists but is not initialised until execution reaches the declaration.

console.log(hoistedLet);

let hoistedLet = 'value';
// ReferenceError

The period between entering the scope and reaching the declaration is called the Temporal Dead Zone, or TDZ.
Function declarations behave differently again.

hoistedFn();

function hoistedFn() {
  console.log('works!');
}

The function declaration is fully initialised before execution reaches the call.
A function expression does not work the same way.

hoistedExpr();

var hoistedExpr = function () {
};

The variable itself is initially undefined, so attempting to call it produces a TypeError.
Classes are also affected by the TDZ.

new MyClass();

class MyClass {
}

Closures

What is a closure?

A closure is a function together with the lexical environment in which that function was created.
That definition sounds academic, but the behaviour is easier to see in code.

function makeCounter() {
  let count = 0;

  return {
    increment() {
      return ++count;
    },

    decrement() {
      return --count;
    },

    get value() {
      return count;
    },
  };
}

const counter = makeCounter();

counter.increment();
// 1

counter.increment();
// 2

counter.value;
// 2

counter.count;
// undefined

How does debounce work?

Debouncing means delaying an operation until activity has stopped for a specified amount of time.
This is extremely common in search inputs. If a user types hello, you usually do not want to send a network request for h, then he, then hel, then hell, and finally hello.

function debounce(fn, delay = 300) {
  let timeoutId;

  return function (...args) {
    clearTimeout(timeoutId);

    timeoutId = setTimeout(
      () => fn.apply(this, args),
      delay
    );
  };
}

const search = debounce(
  query => fetchResults(query),
  400
);

input.addEventListener(
  'input',
  e => search(e.target.value)
);

Why does debounce use fn.apply(this, args)?

apply() invokes a function with a specified this value and an array of arguments.

function introduce(greeting, punctuation) {
  return `${greeting}, I am ${this.name}${punctuation}`;
}

const person = {
  name: 'Rohit'
};

introduce.apply(person, ['Hello', '!']);
// 'Hello, I am Rohit!'

In the debounce implementation, the wrapper function is deliberately a regular function.

return function (...args) {
  clearTimeout(timeoutId);

  timeoutId = setTimeout(
    () => fn.apply(this, args),
    delay
  );
};

What is throttling?

Debouncing waits until activity stops. Throttling limits how frequently something can run.
A throttled function can be called many times, but the actual operation is restricted to a particular interval.

function throttle(fn, limit = 300) {
  let inThrottle = false;
  let lastArgs = null;

  return function (...args) {
    if (inThrottle) {
      lastArgs = args;
      return;
    }

    fn.apply(this, args);
    inThrottle = true;

    setTimeout(() => {
      inThrottle = false;

      if (lastArgs) {
        fn.apply(this, lastArgs);
        lastArgs = null;
      }
    }, limit);
  };
}

How does memoisation use closures?

Memoisation means caching the result of a function so that repeated calls with the same inputs can reuse previously calculated results.

function memoize(fn) {
  const cache = new Map();

  return function (...args) {
    const key = JSON.stringify(args);

    if (cache.has(key)) {
      return cache.get(key);
    }

    const result = fn.apply(this, args);

    cache.set(key, result);

    return result;
  };
}

What does once() do?

once() creates a function that allows another function to execute only once.

function once(fn) {
  let called = false;
  let result;

  return function (...args) {
    if (called) {
      return result;
    }

    called = true;
    result = fn.apply(this, args);

    return result;
  };
}

const initialize = once(() => {
  console.log('init');
  return { ready: true };
});

initialize();
// logs and returns { ready: true }

initialize();
// no log, returns the cached object

Module Pattern

Can closures create private data?

Yes. The classic module pattern is essentially a closure used to expose a controlled public API while keeping internal state private.

const UserStore = (function () {
  const users = new Map();
  let nextId = 1;

  function validate(user) {
    if (!user.email?.includes('@')) {
      throw new Error('Invalid email');
    }
  }

  return {
    add(user) {
      validate(user);

      const id = nextId++;

      users.set(id, {
        ...user,
        id
      });

      return id;
    },

    get(id) {
      return users.get(id);
    },

    get size() {
      return users.size;
    },
  };
})();

UserStore.add({
  email: 'a@b.com'
});

UserStore.users;
// undefined

UserStore.validate;
// undefined

What are the five main this rules?

1. new binding When a function is called with new, this refers to the newly created object.

function Person(name) {
  this.name = name;
}

const person = new Person('Rohit');

console.log(person.name);
// 'Rohit'

1. Explicit binding call(), apply(), and bind() allow you to explicitly control this.

function greet() {
  return `Hi, ${this.name}`;
}

greet.call({
  name: 'Rohit'
});
// 'Hi, Rohit'

greet.apply(
  { name: 'Rohit' },
  []
);
// 'Hi, Rohit'

const bound = greet.bind({
  name: 'Rohit'
});

bound();
// 'Hi, Rohit'

call() and apply() execute immediately. bind() creates a new function that remembers the chosen this.

3. Implicit binding When a function is called as an object method, the object before the dot becomes this.

const obj = {
  name: 'Rohit',

  greet() {
    return `Hi, ${this.name}`;
  }
};

obj.greet();
// 'Hi, Rohit'

The call site is what matters here. The function is being called as obj.greet(), so this is obj.

4. Default binding A plain function call does not provide an object for implicit binding.

function standalone() {
  return this;
}

standalone();

In strict mode and modules, this is undefined. In non-strict code, the default can be globalThis.

5. Arrow functions Arrow functions do not create their own this.

const arrow = () => this;

arrow.call({
  name: 'X'
});

Why does this disappear when I store a method in another variable?

Consider this.

const user = {
  name: 'Rohit',

  greet() {
    return `Hi, ${this.name}`;
  },
};

user.greet();
// 'Hi, Rohit'

const fn = user.greet;

fn();
// 'Hi, undefined'

Why does setTimeout(user.greet, 100) lose this?

Because you are passing the function itself to another piece of code.

setTimeout(user.greet, 100);

This effectively says, "Here is the function. Call it later."
The timer does not remember that you originally obtained the function from user.greet. The relationship between the function and the object is not stored inside the function.
Compare that with this.

setTimeout(() => user.greet(), 100);

How can we preserve this?

One option is bind().

setTimeout(
  user.greet.bind(user),
  100
);

Another option is to use a wrapper arrow function.

setTimeout(
  () => user.greet(),
  100
);

For class instances, a class-field arrow function is another option when you specifically need a method that survives detachment.

class User {
  name = 'Rohit';

  greet = () => `Hi, ${this.name}`;
}

The class-field arrow gets its lexical this from the instance initialization context. The trade-off is that each instance gets its own function rather than sharing one function on the prototype.

What is the difference between call(), apply(), and bind()?

All three are related to controlling this, but they differ in when the function executes and how arguments are supplied.

function introduce(greeting, punctuation) {
  return `${greeting}, I am ${this.name}${punctuation}`;
}

const person = {
  name: 'Rohit'
};

introduce.call(
  person,
  'Hello',
  '!'
);
// 'Hello, I am Rohit!'

introduce.apply(
  person,
  ['Hello', '!']
);
// 'Hello, I am Rohit!'

const bound = introduce.bind(
  person,
  'Hello'
);

bound('!');
// 'Hello, I am Rohit!'

Method Borrowing

What is method borrowing?

JavaScript methods are functions, so sometimes you can borrow a method from one object or prototype and call it with another object as its this.
For example, an array method can operate on an array-like object.

const arrayLike = {
  0: 'a',
  1: 'b',
  length: 2
};

Array.prototype.join.call(
  arrayLike,
  '-'
);
// 'a-b'

The object is not actually an Array, but it has the indexed properties and length that join() needs.
Modern JavaScript often provides cleaner alternatives.

Array.from(arrayLike);
// ['a', 'b']

Still, understanding method borrowing helps explain why call() and apply() are more than just interview trivia.

Putting It All Together

Why are closures, higher-order functions, this, scope, and reduce() all appearing in the same chapter?

What should I actually remember from this entire section?

Build the mental model first.
Functions in JavaScript are values, which is why they can be stored, passed around, and returned. Higher-order functions take advantage of that ability to build reusable behaviour around other functions.
Regular functions and arrow functions are not interchangeable. Regular functions have dynamic this, their own arguments, and can be constructors. Arrow functions use lexical this, do not have their own arguments, and cannot be used with new.
Scope is lexical. JavaScript resolves variables by walking outward through the scope chain from where the code was written.
Hoisting is better understood as environment creation and declaration initialisation than as variables physically moving upward. var is initialised to undefined, while let, const, and classes remain uninitialised in the TDZ until execution reaches their declarations. Function declarations are fully initialised.
Closures happen when a function retains access to its lexical environment. That single mechanism powers private state, callbacks that remember context, debouncing, throttling, memoisation, currying, and the classic module pattern.
reduce() is not just a fancy way to add numbers. It is a general accumulation mechanism, and it becomes particularly interesting when the accumulated value is passed through a sequence of functions.
Composition combines functions from right to left, while pipe() usually expresses the same idea from left to right.
Finally, this for regular functions is determined by how the function is called. When you detach an object method, you detach the implicit receiver too. Arrow functions behave differently because their this is lexical.
Once these ideas click, a lot of JavaScript stops looking like a random collection of language quirks and starts looking like several features built on top of a few consistent mechanisms.
And yes, there will still be moments where JavaScript makes you stare at the screen for five minutes.
That part is apparently included in the runtime.

Answer to the question from Part 2

We can finally answer the question we left hanging at the beginning.

const user = {
  name: 'Rohit',
  greet() {
    return `Hi, ${this.name}`;
  },
};

const fn = user.greet;

fn();
// 'Hi, undefined'

setTimeout(user.greet, 100);
// same problem

setTimeout(() => user.greet(), 100);
// works

The first call works differently from what you might expect because this is not permanently attached to the function when the function is defined. For a regular function, this is determined by the call site.

When we write user.greet(), the function is being called as a method of user, so the implicit binding rule gives greet() a this value of user. That is why this.name gives us 'Rohit'.

But then we do this:

const fn = user.greet;

We have taken the function out of the object and stored it in another variable. The function itself is still the same function, but the call site has changed.

fn();

This is now a plain function call. There is no user before the dot, so there is no implicit binding to user. In strict mode, this is undefined. The important point is that the function did not forget user; it was never permanently bound to user in the first place.

The same thing happens here:

setTimeout(user.greet, 100);

We are passing the function itself to setTimeout. The timer receives a reference to the function, not an instruction saying "call this function as user.greet()". When the timer eventually invokes it, the original object relationship is gone.

Now look at the final example:

setTimeout(() => user.greet(), 100);

This time we are not passing user.greet directly. We are passing an arrow function that contains the expression user.greet().

When the timer executes the arrow function, that expression is evaluated exactly as written. The call site once again contains user, so greet() receives user as its implicit this.

So the three cases are really three different call sites.

user.greet();
// `this` is user

const fn = user.greet;
fn();
// no implicit receiver

setTimeout(user.greet, 100);
// the function is passed around and called later

setTimeout(() => user.greet(), 100);
// the wrapper later performs `user.greet()`

And that is the answer we were looking for.

The function did not lose some magical connection to the object. JavaScript never stored that connection in the regular function in the first place. The value of this is determined when the function is called, and changing the way the function is called changes what this refers to.

So if you remember only one thing from this entire detour, remember this:

For regular functions, this comes from the call site, not from where the function was defined.

That one rule is responsible for a ridiculous amount of JavaScript confusion.

And finally, after all that, we can officially close the tab that Part 2 left open.

Let's take an example.

const user = {
  name: 'Rohit',
  greet() {
    return `Hi, ${this.name}`;
  },
};

const fn = user.greet;

fn();
// 'Hi, undefined'

setTimeout(user.greet, 100);
// same problem

setTimeout(() => user.greet(), 100);
// works

Can you answer why the first two calls fail while the last one works? If you can, probably this blog is not for you.

But if you can't, then it's completely up to you whether you want to read this article or continue staring at this until it starts staring back.

The interesting part is that all three examples involve the same function.

Functions are everywhere in JavaScript. They can be stored in variables, passed to other functions, returned from functions, attached to objects, blah blah blah. Once you understand that functions are values and that JavaScript keeps track of the environment around those functions, a lot of features that initially look unrelated start fitting together.

This part follows that idea from the ground up. We will move through function forms, parameters, first class functions, higher order functions, reduce(), currying, composition, pipe(), scope, hoisting, closures, practical closure patterns, and finally the infamous this .

What exactly is a function in JavaScript?

A function is a value that represents executable behaviour. That sounds simple, but the important part is the word value.

Because functions are values, you can assign them to variables, store them in objects or arrays, pass them as arguments, and return them from other functions. This is the foundation for higher-order functions, callbacks, composition, currying, and a huge amount of modern JavaScript.

A function can be written in several forms, and the form you choose can change things such as hoisting, this, constructor behaviour, and whether the function has its own arguments object.

// Function expression
const subtract = function (a, b) {
  return a - b;
};

// Arrow function
const multiply = (a, b) => a * b;

const square = x => x * x;

// Function declaration
function add(a, b) {
  return a + b;
}

// Named function expression
const factorial = function fact(n) {
  return n <= 1 ? 1 : n * fact(n - 1);
};

The important distinction is that a function declaration is fully hoisted, while a function expression is created as part of the assignment. Arrow functions are also function expressions and have different behaviour around this, arguments, constructors, and prototypes.

JavaScript also has specialised forms such as async functions, generator functions, and async generators.

async function fetchData() {
}

function* idGenerator() {
  let i = 0;

  while (true) {
    yield i++;
  }
}

async function* streamPages() {
}

So when someone says "a function is a function" screw them up , they don't know.

Why does the distinction between regular functions and arrow functions matter?

Because an arrow function is not simply a shorter way of writing a regular function.

The biggest difference is this. A regular function gets its this value from the way it is called. An arrow function does not create its own this; it takes this from the surrounding lexical scope.

Regular functions also have their own arguments object and can be used with new. Arrow functions cannot be constructors and do not have their own arguments.

const counter = {
  count: 0,

  // Wrong if you expect `this` to mean counter
  incrementBad: () => {
    this.count++;
  },

  // Correct
  increment() {
    this.count++;
  },

  startBad() {
    setInterval(function () {
      this.count++;
    }, 1000);
  },

  start() {
    setInterval(() => {
      this.count++;
    }, 1000);
  },
};

The usual rule is simple enough to remember. If a function is an object or class method and needs the object's this, use a regular function. If you are writing a callback inside that method and want to keep the surrounding this, an arrow function is often exactly what you want.

What are default parameters?

Default parameters allow a function to use a fallback value when the corresponding argument is undefined.

The default is evaluated when the function is called, not when the function is defined, and parameter defaults are evaluated from left to right.

function greet(name = 'Guest', greeting = `Hello, ${name}`) {
  return greeting;
}

greet();
// 'Hello, Guest'

greet('Rohit');
// 'Hello, Rohit'

One detail that catches people is that the default only applies to undefined, not to every falsy value and not to null.

function f(x = 5) {
  return x;
}

f(undefined);
// 5

f(null);
// null

So null basically says, "I intentionally gave you null." JavaScript respects that decision.

What are rest parameters?

Rest parameters collect the remaining arguments into a real array.

function sum(...numbers) {
  return numbers.reduce((total, n) => total + n, 0);
}

sum(1, 2, 3, 4);
// 10

This is different from the older arguments object because rest parameters give you an actual array, so array methods can be used directly.

You can also combine a normal parameter with rest parameters.

function log(level, ...messages) {
  console[level](...messages);
}

Here level receives the first argument and messages collects everything after it.

Why do we sometimes write = {} in a destructured parameter?

This pattern is common when a function accepts an options object.

function createServer({
  port = 3000,
  host = 'localhost',
  secure = false
} = {}) {
  return `${secure ? 'https' : 'http'}://${host}:${port}`;
}

createServer();
// 'http://localhost:3000'

createServer({ port: 8080 });
// 'http://localhost:8080'

The final = {} is important because without it, calling createServer() would try to destructure undefined, which is not possible.

The inner defaults handle missing properties. The outer default handles the case where the entire argument is missing.

That tiny = {} is doing more work than it looks like.

First-Class Functions

What does it mean when people say "functions are first-class citizens"?

It means functions can be treated like ordinary values.

You can assign a function to a variable, pass it to another function, return it from a function, or store it inside a data structure.

function add(a, b) {
  return a + b;
}

const operation = add;

operation(2, 3);
// 5

You can also pass a function into another function.

function execute(fn, value) {
  return fn(value);
}

execute(x => x * 2, 5);
// 10

And you can return a function.

function createMultiplier(multiplier) {
  return value => value * multiplier;
}

const double = createMultiplier(2);

double(5);
// 10

This ability to move functions around as values is one of the central ideas behind functional programming in JavaScript.

What is a higher order function?

A higher-order function is a function that takes another function as an argument, returns a function, or does both.

For example, we can create a wrapper that adds logging around another function.

const withLogging = fn => (...args) => {
  console.log(`calling ${fn.name} with`, args);

  const result = fn(...args);

  console.log(`${fn.name} returned`, result);

  return result;
};

const loggedAdd = withLogging(add);

loggedAdd(2, 3);

withLogging is higher-order because it receives a function and returns another function.

This pattern is extremely useful because you can add behaviour without modifying the original function. Logging, authentication checks, caching, timing, retry logic, debouncing, throttling, and many other patterns can be built this way.A higher order function is a function that takes another function as an argument, returns a function, or does both.

Why does reduce() matter so much?

reduce() takes a collection and repeatedly combines its elements into one accumulated result.

The accumulator is the key idea. On each iteration, the callback receives the result produced so far and the current element.

const numbers = [1, 2, 3, 4];

const total = numbers.reduce(
  (accumulator, number) => accumulator + number,
  0
);

console.log(total);
// 10

The first accumulator value is 0. JavaScript then processes the array one element at a time, carrying the previous result into the next iteration.

More importantly for functional programming, reduce() can be used to build a result by repeatedly applying functions. That idea leads directly to composition and pipe().

What is currying?

Currying transforms a function that normally accepts several arguments into a sequence of functions that each accept arguments progressively.

nstead of this:

add3(1, 2, 3);

you can have:

add3(1)(2)(3);

A simple curry implementation can be written like this.

const curry = fn =>
  function curried(...args) {
    return args.length >= fn.length
      ? fn(...args)
      : (...more) => curried(...args, ...more);
  };

const add3 = curry((a, b, c) => a + b + c);

add3(1)(2)(3);
// 6

add3(1, 2)(3);
// 6

The returned function remembers the arguments collected so far and waits until enough arguments have been provided.

This implementation depends on fn.length, which is the number of declared parameters before the first default or rest parameter.

function add(a, b, c) {
}

console.log(add.length);
// 3

function another(a, b = 10, c) {
}

console.log(another.length);
// 1

function many(a, ...numbers) {
}

console.log(many.length);
// 1

That is why this simple curry implementation is useful for learning but should not be treated as a universal currying library.

Composition

What is function composition?

Composition means combining small functions so that the output of one function becomes the input of another.

Suppose we have three transformations.

const trim = value => value.trim();

const lower = value => value.toLowerCase();

const removeSpaces = value =>
  value.replace(/\s+/g, '-');

Instead of manually calling them one by one, we can create a new function that represents the entire operation.

const compose = (...fns) => x =>
  fns.reduceRight(
    (acc, fn) => fn(acc),
    x
  );

compose() applies functions from right to left.

const transform = compose(
  removeSpaces,
  lower,
  trim
);

transform('  Hello World  ');
// 'hello-world'

The value enters trim, then moves into lower, and finally reaches removeSpaces.

This style works particularly well when each function performs one small, predictable transformation.

Then what is pipe() ?

pipe() is essentially the left-to-right version of composition.

Instead of reading the functions from the right side backwards, you read them in the same order the data flows through them.

const pipe = (...fns) => x =>
  fns.reduce(
    (acc, fn) => fn(acc),
    x
  );

Now we can build something that reads almost like a sequence of instructions.

const slugify = pipe(
  s => s.trim(),
  s => s.toLowerCase(),
  s => s.replace(/[^a-z0-9]+/g, '-'),
  s => s.replace(/^-|-$/g, '')
);

slugify('  Hello, World!  ');
// 'hello-world'

This is one of the places where reduce() becomes much more interesting. The accumulator is not necessarily a number. It can be the value moving through a chain of transformations.

What is scope?

Scope determines where a variable can be accessed.

const globalVar = 'global';

function outer() {
  const functionVar = 'function';

  if (true) {
    let blockVar = 'block';
    console.log(blockVar);
  }

  var functionScoped = 'also function';

  console.log(functionScoped);

  function inner() {
    console.log(globalVar, functionVar);
  }

  inner();
}

The important difference is that var is function scoped, while let and const are block scoped.

function example() {
  if (true) {
    var a = 1;
    let b = 2;
  }

  console.log(a);
  // 1

  console.log(b);
  // ReferenceError
}

The braces create a block scope for let and const, but var ignores that block and belongs to the surrounding function scope.

What is the scope chain?

When JavaScript encounters a variable reference, it looks for that variable in the current lexical environment. If it is not there, it moves outward through the enclosing scopes until it reaches the global scope.

const a = 'global a';

function level1() {
  const b = 'level1 b';

  function level2() {
    const c = 'level2 c';

    function level3() {
      console.log(a, b, c);
    }

    level3();
  }

  level2();
}

level1();

When level3() looks for a, it does not find it locally, so JavaScript walks outward. It finds a in the global scope. The same process finds b in level1 and c in level2.

This is called the scope chain.

The critical point is that scope is lexical. It is determined by where the code is written, not by where the function happens to be called from.

That rule is one of the reasons closures work.

OHH !! I totally forgot to answer the question I asked at the very beginning of this discussion! 😭

But to get to that answer, we still have a long way to go and I think this is enough for this part.

To see the answer, you’ll have to wait for the next one.

See you in the next part!

Try answering these all? [] == false // true 0.1 + 0.2 === 0.3 // false typeof null // "object" NaN === NaN // false 9007199254740992 === 9007199254740993 // true

Did not get at least one right? Happens man! You, me, we both haven't spent enough time with JavaScript. Let's change that!

JavaScript has some wonderfully weird corners. Some of them are genuinely useful. Some are historical baggage. And some look completely ridiculous until you understand the rules underneath them.

But here's the interesting part: most of these behaviors are consequences of specific design decisions, type coercion rules, floating point representation, backward compatibility, and a language that has been evolving for decades while trying very hard not to break the web.

[] == false is true. Why does JavaScript arrive at that answer? That's what this article is about.

This is Part 1 of my attempt to understand JavaScript beyond the syntax. We will start with numbers, then move into type coercion and operators, and try to understand why JavaScript behaves the way it does instead of simply memorizing a list of weird facts.

Before We Start, JavaScript Has History

One of the easiest mistakes when learning JavaScript is assuming that it was designed as one perfectly planned language. It wasn't. Although JavaScript has evolved a lot, it also has a lot of history packed into it.

It started as a relatively small scripting language and eventually became the language running enormous parts of the web, including browsers, servers, build tools, applications, frameworks, extensions, tests, and much more.

And once millions of websites depend on a behavior, you can't simply just say:

"Yeah, that was a terrible idea. Let's f*king remove it."

Because somewhere out there is probably a website that depends on it.

This explains a lot of JavaScript's personality. Older ideas coexist with newer ones: • var, let, const • Old equality == vs Modern strict equality === • Prototype based objects Object.create(...) and later, class syntax class User {} • Callbacks setTimeout(...) and much later async / await

JavaScript is less like a freshly designed building and more like a city. There are beautiful new buildings, ancient roads, strange shortcuts, and at least one intersection nobody knows how to remove because apparently somebody's production system depends on it.

And that's actually a useful way to learn JavaScript. Don't just ask what the syntax does. Ask why the language behaves that way.

1. Numbers Are Not Quite What You Think

Let's start with something that looks completely innocent: 0.1 + 0.2. You might expect 0.3. JavaScript says 0.30000000000000004. And 0.1 + 0.2 === 0.3 // false.

Let's understand what is happening. JavaScript's ordinary Number uses IEEE 754 double precision floating point representation. Computers don't store decimal numbers exactly the way humans write them.

We write 0.1, 0.2, 0.3, but floating point numbers are represented using binary. And just like 1 / 3 cannot be represented exactly using a finite number of decimal digits (0.333333333333...), some decimal fractions cannot be represented exactly in binary.

So JavaScript stores the closest representable value. That means the values involved in 0.1 + 0.2 are already approximations. The result is therefore approximately 0.30000000000000004.

This isn't uniquely a JavaScript problem. It's a consequence of floating point representation.

Comparing Floating Point Numbers Because of this, directly comparing floating point values can be dangerous. Instead of blindly doing a === b, you can compare whether they're sufficiently close: const nearlyEqual = (a, b, eps = Number.EPSILON) => Math.abs(a - b) < eps; nearlyEqual(0.1 + 0.2, 0.3); // true

The exact comparison strategy should depend on the scale and requirements of your calculation, but the important idea is simple: floating point arithmetic is approximate.

2. The Number Safe Integer Limit

JavaScript numbers have another interesting limitation: Number.MAX_SAFE_INTEGER gives 9007199254740991, which is 2^53 - 1.

Why can't JavaScript safely represent every integer beyond this? Because Number is a floating point format, and it has limited precision. Eventually, two different integers can round to the same representable floating point value.

For example: 9007199254740992 === 9007199254740993 // true.

That looks completely absurd. But the important word is precision here. The number isn't necessarily too large to exist. JavaScript simply can't represent every integer in that range distinctly using Number.

You can check whether an integer is safe: Number.isSafeInteger(2 ** 53); // false

For integers requiring arbitrary precision, JavaScript provides BigInt: const huge = 9007199254740993n; Notice the n. It indicates that this is an integer value represented using BigInt rather than Number.

3. NaN Is... Special

Now we reach one of JavaScript's favorite ways to confuse beginners like me: NaN === NaN // false. Wait whaaaaat! How can something not equal itself?

NaN represents a special numerical value that indicates an invalid or undefined numerical result. For example: 0 / 0 // NaN Number("hello") // NaN

NaN has special comparison semantics. So NaN === NaN // false. If you want to check whether something is actually NaN, use: Number.isNaN(NaN) // true

And notice the difference from the older global function: isNaN("hello") // true The global isNaN() performs coercion first. What the hell is coercion? We will come to that soon. Number.isNaN() does not: Number.isNaN("hello") // false It is generally much safer when you specifically want to know whether the value is the NaN value.

4. Infinity Exists Too

JavaScript's number system also includes Infinity, -Infinity, and NaN. So: 1 / 0 // Infinity -1 / 0 // -Infinity 0 / 0 // NaN

Again, these behaviors come from the floating point number model JavaScript uses.

5. Never Blindly Use Floating Point for Money

A weird JavaScript behavior becomes a real engineering problem when money gets involved. Imagine calculating 0.1 + 0.2 once. Not a big deal. Now imagine doing floating point calculations across thousands of financial transactions. Suddenly tiny representation errors can become actual financial defects.

A common solution is to represent money using integer minor units. Instead of ₹19.99, store 1999 paise. Then arithmetic remains integer arithmetic and you divide by 100 only for display.

For calculations requiring decimal arithmetic, use an appropriate decimal representation or library and a suitable database type rather than blindly relying on binary floating point. A tiny floating point quirk can become a very non tiny production bug.

6. Type Coercion, "I'll Figure It Out" Philosophy (lol)

Now let's talk about one of JavaScript's most famous features: type coercion. Here we go.

JavaScript can automatically convert values from one type to another depending on the operation being performed. For example: 1 == "1" // true 1 === "1" // false

What's happening? This is where JavaScript starts doing something that feels strange at first. The language can look at two values with different types and, depending on the operator, convert one or both values before comparing them. That automatic conversion is called type coercion.

7. == vs ===

The easiest way to think about them is: • == → allows type coercion • === → does not perform that coercion

So 1 == "1" // true can involve converting the string "1" → 1 and then comparing 1 == 1. But 1 === "1" // false because one value is a number and the other is a string.

This is why modern JavaScript code generally prefers === and !==. It makes the comparison more explicit and avoids many surprising conversions.

8. The Famous null and undefined Case

Here's one of the few places where == can actually be useful: null == undefined // true But: null === undefined // false

They're different values, but loose equality has a special rule treating them as equivalent. So this: value == null can intentionally mean: "Is this either null or undefined?" Equivalent to: value === null || value === undefined

This is one of the rare cases where using == can be intentional and readable. Everywhere else? I'd generally reach for ===.

9. And Then JavaScript Does This

[] == false // true. At this point, JavaScript appears to have completely lost the plot. But let's slow down.

This isn't because an empty array is secretly false. In fact: Boolean([]) // true. An empty array is truthy.

So why does [] == false produce true? Because == uses its own coercion rules. The object is converted toward a primitive value. Conceptually, the empty array can become: [] ↓ "" ↓ 0 And false ↓ 0. So the comparison eventually becomes 0 == 0, which is true.

This is an important distinction. Equality coercion and boolean coercion are not the same thing. When JavaScript evaluates if ([]), it asks whether the value is truthy. Since an array is an object: Boolean([]) // true.

But when evaluating [] == false, JavaScript follows the abstract equality algorithm, which involves different conversion rules. Same value. Different operation. Different rules. And that is a recurring theme in JavaScript.

10. Truthy and Falsy

There are exactly eight falsy values: • false, 0, -0, 0n, "", null, undefined, NaN

Everything else is truthy. That means these are all truthy: • [], {}, "0", "false", function () {}

Yes. Even Boolean([]) // true and Boolean({}) // true. Objects are truthy regardless of whether they're "empty." This is why: if ([]) { // runs }

Understanding truthy and falsy values is important because JavaScript uses boolean conversion in many places, including if, while, logical operators, and conditional expressions.

11. Explicit Conversion Is Usually Better

JavaScript can automatically convert values, but you can also explicitly convert them. And explicit conversion is usually easier to understand: String(42) // "42" Number("42") // 42 Boolean(0) // false

Some interesting examples: Number("") // 0 Number(" 12 ") // 12 Number("12px") // NaN

For parsing: parseInt("12px", 10) // 12 Notice the radix: parseInt("12", 10). It's good practice to explicitly provide it. And parseFloat("3.14em") // 3.14.

JavaScript is willing to parse the numeric prefix here. That can be useful, but it can also be surprising if you expected strict validation.

The bigger lesson is that explicit conversion makes your intention visible. Instead of making the reader figure out what JavaScript might convert automatically, you can tell JavaScript exactly what type you want.

12. Operators Have Their Own Personality

JavaScript operators don't always simply return booleans. Consider: const name = input || "Anonymous"; The || operator returns one of its operands. It isn't simply true or false.

Similarly: const port = process.env.PORT ?? 3000; uses the nullish coalescing operator.

The difference between || and ?? is extremely important. Consider: const count = 0; count || 10 // 10 (because 0 is falsy) count ?? 10 // 0 (because ?? only falls back for null and undefined)

So: • || → fallback if falsy • ?? → fallback if null or undefined

If 0 is a legitimate value, ?? is often what you actually want.

Logical Assignment JavaScript extends these ideas with logical assignment: a ||= b; a &&= b; a ??= b;

Conceptually: • a ||= b; means roughly a = a || b; (Assign b if a is falsy) • a &&= b; means roughly a = a && b; (Assign b if a is truthy) • a ??= b; means roughly a = a ?? b; (Assign b only if a is null or undefined)

These operators are small, but they become extremely useful once you understand the underlying behavior.

Where We Stop for Part 1

So far, we've looked at the part of JavaScript that makes many people wonder whether the language was designed during a very long coffee break.

We've seen floating point precision, safe integers, NaN, Infinity, type coercion, loose and strict equality, truthy and falsy values, explicit conversion, nullish coalescing, and logical assignment.

But there is a much more interesting part of JavaScript waiting ahead: functions. Not just how to declare them, but why JavaScript treating functions as values changes almost everything.

In the next part, we'll get into first class functions, higher order functions, reduce(), closures, currying, function composition, pipe(), arrow functions, this, destructured parameters, and more.

And that's where JavaScript starts becoming less about syntax and more about how the language actually thinks.

See you in Part 2.