Every developer should fully understand how they work and be able to discern the subtle differences between them.

So you know, JS functions are first-class citizens.

Which means: they’re all just object values — all instances of the Function class, with methods and properties.

So bind(), apply(), and call() are 3 essential methods every JavaScript function has.

Were you with me in the painful early days of React; when we still did this? 👇

This was just one of the multiple applications of bind() — a seriously underrated JavaScript method.

JavaScriptCopied!

// damn class components are such a chore to write now
import React from 'react';

class MyComponent extends React.Component {
  constructor(props) {
    super(props);
  }

  greet() {
    alert(`Hi, I'm ${this.props.name}!`);
  }

  // remember render()?
  render() {
    return (
      <button onClick={this.greet.bind(this)}>Click me</button>
    );
  }
}

export default MyComponent;

sayName() would be a mess without bind() — the alert() would never work.

Because internally React is doing something fishy with this method that completely screws up what this means inside it.

Before sayName would have had absolutely no problems showing the alert — just like in this other class:

JavaScriptCopied!

class Person {
  props = { name: 'Tari' };

  greet() {
    console.log(`Hi, I'm ${this.props.name}!`);
  }
}

const person = new Person();

person.greet();

But guess what React does to the greet event handler method behind the scenes?

It reassigns it to another variable:

JavaScriptCopied!

class Person {
  props = { name: 'Tari' };

  greet() {
    console.log(`Hi, I'm ${this.props.name}!`);
  }
}

// reassign to another variable:
const greet = Person.prototype.greet;

// ❌ bad idea
greet();

So guess what happens to this — it’s nowhere to be found:

This is where bind comes to the rescue — it changes this to any instance object you choose:

So we’ve binded the function to the object — the bind target.

(I know it’s “bound” but let’s say binded just like how we say “indexes” for “index” instead of “indices”).

It’s immutable — it returns the binded function without changing anything about the original one.

And this lets us use it as many times as possible:

vs call()

There’s only a tiny difference between call and bind

bind creates the binded function for you to use as many times as you like.

But call? It creates a temporary binded function on the fly and calls it immediately:

JavaScriptCopied!

class Person {
  constructor(props) {
    this.props = props;
  }

  greet() {
    console.log(`Hi, I'm ${this.props.name}`);
  }
}

const person = new Person({ name: 'Tari' });

const greet = Person.prototype.greet;

greet.bind(person)();

greet.call(person);

So call() is basically bind() + a call.

But what about when the function has arguments? What do we do then?

No problem at all — just pass them as more arguments to call:

JavaScriptCopied!

class Person {
  constructor(props) {
    this.props = props;
  }

  greet(name, favColor) {
    console.log(
      `Hi ${name}, I'm ${this.props.name} and I love ${favColor}`
    );
  }
}

const person = new Person({ name: 'Tari' });

const greet = Person.prototype.greet;

// bind(): normal argument passing to binded function
greet.bind(person)('Mike', 'blue🔵');

// call(): pass as more arguments
greet.call(person, 'Mike', 'blue🔵');

And you can actually do the same with bind():

JavaScriptCopied!

// the same thing
greet.bind(person)('Mike', 'blue🔵');

greet.bind(person, 'Mike', 'blue🔵')();

vs apply()

At first you may think apply() does the exact same thing as call():

JavaScriptCopied!

class Person {
  constructor(props) {
    this.props = props;
  }

  greet() {
    console.log(`Hi, I'm ${this.props.name}`);
  }
}

const person = new Person({ name: 'Tari' });

const greet = Person.prototype.greet;

greet.call(person); // Hi, I'm Tari

greet.apply(person); // Hi, I'm Tari

But just like bind() vs call() there’s a subtle difference to be aware of:

Arguments passing:

JavaScriptCopied!

class Person {
  constructor(props) {
    this.props = props;
  }

  greet(name, favColor) {
    console.log(
      `Hi ${name}, I'm ${this.props.name} and I love ${favColor}`
    );
  }
}

const person = new Person({ name: 'Tari' });

const greet = Person.prototype.greet;

//💡call() -- pass arguments with comma separated
greet.call(person, 'Mike', 'blue🔵'); // Hi, I'm Tari

//💡apply() -- pass arguments with array
greet.apply(person, ['Mike', 'blue🔵']); // Hi, I'm Tari

One mnemonic trick I use to remember the difference:

• call() is for commas
• apply() is for arrays

Recap

• bind() — bind to this and return a new function, reusable
• call() — bind + call function, pass arguments with commas
• apply() — bind + call function, pass arguments with array

This is a big mistake many developers make that makes code cryptic and unreadable.

Don’t do this:

JavaScriptCopied!

// ❌ Bad: negative name
const isNotVisible = doStuff();
const isDisabled = doStuff();
const isNotActive = doStuff();
const hasNoAccess = doStuff();

// ❌ Double negation
console.log(!isNotVisible);
console.log(!isDisabled);
console.log(!isNotActive);
console.log(!hasNoAccess);

Double negatives like this makes it much harder to think about the logic and conditionals in your code.

It’s much better to name them positively:

JavaScriptCopied!

// ✅ Good: positive name
const isVisible = doStuff();
const isEnabled = doStuff();
const isActive = doStuff();
const hasAccess = doStuff();

// ✅ Clear and readable
console.log(isVisible);
console.log(isEnabled);
console.log(isActive);
console.log(hasAccess);

There is no indirection and your brain takes zero time to parse this.

Just imagine the pain of trying to understand this:

I didn’t not forget about not being unable to use the account.

Lol I couldn’t even understand it myself even though I made it up.

Compare to the far more natural way you’d expect from a sensible human:

I remembered that I could use the account.

Control flow negation

This is a more delicate form of double negation you need to know about:

JavaScriptCopied!

const isAllowed = checkSomething();
// ❌ Bad
if (!isAllowed) {
  handleError();
} else {
  // ❌ double negation!
  handleSuccess();
}

It’s double negation because we’re checking for the negative first.

So the else clause becomes a not of this negative.

Better:

JavaScriptCopied!

const isAllowed = checkSomething();
// ✅ Fix: invert the if
if (isAllowed) {
  handleSuccess()
} else {
  handleError();
}

The same thing for equality checks:

JavaScriptCopied!

// ❌ Double negation
if (value !== 0) {
    doError();
} else {
    doSuccess();
}

// ✅ Better
if (value === 0) {
    doSuccess();
} else {
    doError();
}

Even when there’s no positive condition you can leave it blank — to keep the negative part in the else:

JavaScriptCopied!

const hasAlreadyFetched = false;

if (hasAlreadyFetched) {
  // nothing to do
} else {
  doSomething();
}

This is great for expressions that are awkward to negate, like instanceof:

JavaScriptCopied!

// ❌ Bad
if (!(obj instanceof Person)) {
  doSomething();
}

// ✅
if (obj instanceof Person) {
} else {
  doSomething();
}

Exception: guard clauses

In guard clauses we deliberately deal with all the negatives first before the positive.

So we return early and avoid deeply nested ifs:

❌ Instead of this:

JavaScriptCopied!

function sendMoney(account, amount) {
  if (account.balance > amount) {
    if (amount > 0) {
      if (account.sender === 'user-token') {
        account.balance -= amount;
        console.log('Transfer completed');
      } else {
        console.log('Forbidden user');
      }
    } else {
      console.log('Invalid transfer amount');
    }
  } else {
    console.log('Insufficient funds');
  }
}

✅ We do this:

JavaScriptCopied!

// ✅ Much cleaner
function sendMoney(account, amount) {
  if (account.balance < amount) {
    console.log('Insufficient funds');
    return;
  }

  if (amount <= 0) {
    console.log('Invalid transfer amount');
    return;
  }

  if (account.sender !== 'user-token') {
    console.log('Forbidden user');
    return;
  }

  account.balance -= amount;
  console.log('Transfer completed');
}

See, there’s no hard and fast rule. The end goal is readability: to make code as easy to understand in as little time as possible.

Flags always start out as false

Flags are boolean variables that control program flow.

A classic use case is running an action as long as the flag has a particular value:

JavaScriptCopied!

let val = false;

while (true);
  // do something that changes val
  if (val) {
    break;
  }
}

In cases like this, always initialize the flag to false and wait for true.

Flags should always start out as false.

JavaScriptCopied!

// ❌ waiting for true -> false
let isRunning = true;
while (true) {
  // processing...
  if (!isRunning) {
    break;
  }
}

// ✅ waiting for false -> true
let hasStopped = false;
while (true) {
  // processing...
  if (hasStopped) {
    break;
  }
}

This makes so much sense when you understand flags to be a signal — that something is there.

Compound conditions

Negation also makes complex boolean expressions much harder to understand.

❌ Before:

JavaScriptCopied!

if (!sleepy && !hungry) {
  console.log('time for gym👟');
} else {
  console.log('what to do now...');
  // ❌ hard to understand when this runs
}

This is where De Morgan’s Laws come in:

A powerful rule set for smoothly simplifying complex booleans and removing excessive negation:

JavaScriptCopied!

let a: boolean;
let b: boolean;
 
!(a && b) === !a || !b;
!(a || b) === !a && !b;

✅ So now:

JavaScriptCopied!

if (!(sleepy || hungry)) {
  console.log('time for gym👟');
} else {
  console.log('what to do now...');
}

Now we can easily invert the logic as we did before:

JavaScriptCopied!

if (sleepy || hungry) {
  console.log('what to do now...');
} else {
  console.log('time for gym👟');
}

It’s also structurally similar to the English in this way:

The first version was like:

(!a && !b)

It’s time for gym cause I’m not sleepy and I’m not hungry

After the refactor:

!(a || b):

It’s time for gym cause I’m not sleepy or hungry.

That’s how we’d typically say it.

Key points

• Boolean variable names should be in the positive form. Exception: flags
• Always check the positive case first in if-else statements. Exception: Guard clauses
• Use De Morgan’s Laws to simplify negation in compound conditions.

This is a little-known way to console log without newline that many developers have never used.

Let’s say we need to log in a loop like this:

JavaScriptCopied!

for (let i = 1; i <= 5; i++) {
  // print number without newline
}
// Output: 1 2 3 4 5

❌ Unfortunately the normal way fails us:

So what do we do?

What we do: is process.stdout.write:

JavaScriptCopied!

for (let i = 1; i <= 5; i++) {
  process.stdout.write(`${i} `);
}
// Output: 1 2 3 4 5

How is process.stdout.write different from console.log?

Well first of all, console.log IS process.stdout.write!

stdout is the fundamental way every CLI program logs output to the console.

That’s what it uses at its core:

JavaScriptCopied!

Console.prototype.log = function() {
  this._stdout.write(util.format.apply(this, arguments) + '\n');
};

But this extra processing makes it so much better for formatting:

• I can easily inspect objects with console.log without JSON.stringify:

But process.stdout.write fails miserably — it only accepts strings and Buffers:

But there’s something incredible only process.stdout.write can do:

Data streaming:

process.stdout is actually, a stream.

Streams represent data flow in Node.

• Read streams — data coming from
• Write streams — data going into
• Duplex streams — both

Data’s flowing from the file read stream into the stdout stream.

It’s the same as this:

JavaScriptCopied!

import fs from 'fs';

fs.createReadStream('codingbeautydev.txt').on(
  'data',
  (chunk) => {
    process.stdout.write(chunk);
  }
);

But pipe is much more natural for stream-to-stream data flow:

Letting you create powerful transformation pipelines like this:

JavaScriptCopied!

import fs from 'fs';
import { Transform } from 'stream';

// ✅ duplex stream
const uppercase = new Transform({
  transform(chunk, encoding, callback) {
    callback(null, chunk.toString().toUpperCase());
  },
});

fs.createReadStream('codingbeautydev.txt')
  .pipe(uppercase)
  .pipe(process.stdout);

process.stdin

process.stdin is the process.stdout‘s input counterpart — a readable stream for user input.

So see how with a single line I create a pipeline to reflect all my input to me:

JavaScriptCopied!

process.stdin.pipe(process.stdout);

And when I insert the uppercase transformation into the pipeline:

JavaScriptCopied!

import fs from 'fs';
import { Transform } from 'stream';

// ✅ duplex stream
const uppercase = new Transform({
  transform(chunk, encoding, callback) {
    callback(null, chunk.toString().toUpperCase());
  },
});

process.stdin.pipe(uppercase).pipe(process.stdout);

process.stderr

Here to complete the standard stream trio.

• console.log → process.stdin
• console.error → process.stderr

Probably also defined this way in Node:

JavaScriptCopied!

Console.prototype.error = function() {
  this._stderr.write(util.format.apply(this, arguments) + '\n');
};

JavaScriptCopied!

console.log('A normal log message');

console.error('An error message');

You can see the difference in the browser:

Although not much difference on Node:

These are 3 powerful streams that let you input, process, and output data creatively and intuitively.