Forem: Code Crumb

The Case of the Misidentified null

Code Crumb — Sun, 24 May 2026 15:06:27 +0000

Most developers eventually encounter this line of code:

typeof null // "object"

And the reaction is usually immediate:

“Wait… what?”

Because null is not an object.

It represents the intentional absence of a value.

So why does JavaScript identify it as one?

The Investigation Begins

Back in the 1990s, JavaScript engines were designed for speed and memory efficiency.

Values were stored inside tiny 32-bit memory containers.

To quickly identify what kind of value was being stored, the engine used hidden binary markers called type tags.

Think of them like internal evidence labels.

Something similar to:

Type	Conceptual Tag
Object	`000`
Integer	`001`
String	`010`
Boolean	`011`

(Simplified conceptual representation)

The Critical Mistake

Objects were associated with a zero-based type pattern internally.

But null had a problem.

Its internal representation was essentially all zeroes:

00000000000000000000000000000000

So when JavaScript checked the value’s type…

it accidentally matched the object tag.

The engine effectively interpreted:

“all zeroes”

as:

“object”

And just like that…

null was misidentified.

Why Wasn’t the Bug Fixed?

Because the mistake spread everywhere.

By the time developers realized the issue, websites and applications across the internet already depended on this behavior.

Changing it would break massive amounts of existing code.

So the bug became permanent.

The Developer Workaround

Instead of writing:

typeof value === "object"

Developers learned to safely check:

value !== null && typeof value === "object"

That extra condition prevents null from slipping through.

Closing the Case

What makes this bug fascinating isn’t just the incorrect output.

It’s the fact that a tiny implementation detail from the early days of JavaScript…

still survives in modern applications decades later.

One small mistake.

One massive legacy.

One very strange crime scene.

📹 Surveillance Footage

The full investigation is available on TikTok:

View the Evidence

What’s the weirdest JavaScript behavior you’ve encountered?

JS Crime Scene: The Misleading Array

Code Crumb — Thu, 21 May 2026 14:20:29 +0000

🕵️ JS Crime Scene: The Case of the Misleading Array

📹 Surveillance Footage

The full investigation is available on TikTok:

View the Evidence

The call came in early.

An application was completely misbehaving, data was leaking out of order, and the logs were a mess.

The victim?

Developer Sanity

Someone tried to sort a simple array of integers, and JavaScript decided to play by its own rules.

Let's inspect the evidence, identify the culprit, and deploy the one-line fix before production collapses entirely.

🔍 The Crime Scene Report

We found a collection of numerical values at the center of the incident.

No complex objects.

No deeply nested structures.

Just raw numbers.

Here is the exact code executed at the scene:

// The Lineup (Original Array)
const numbers = [1, 10, 2, 25, 5];

// The Attempted Sort
numbers.sort();

console.log(numbers);

// Output:
// [1, 10, 2, 25, 5]

📋 The Expected vs. Actual Output

Intended Behavior (Math)	Actual Reality (JavaScript)	Status
`[1, 2, 5, 10, 25]`	`[1, 10, 2, 25, 5]`	❌ Maliciously Broken

Look closely at that result.

10 comes before 2?

25 comes before 5?

Did mathematics quietly stop working overnight?

Not exactly.

🕵️‍♂️ The Culprit: UTF-16 String Sorting

When you call .sort() without providing a comparator function, JavaScript does not sort numbers mathematically.

Instead, it secretly performs a type coercion operation and converts every element into a string first.

Our innocent integers suddenly became:

1 → "1"
10 → "10"
2 → "2"
25 → "25"
5 → "5"

Once converted to strings, JavaScript compares them character-by-character using UTF-16 code unit values.

Essentially, the engine starts sorting your numbers like dictionary words.

📖 Think of It Like a Dictionary

In a dictionary:

"Apple" comes before "Banana"
because "A" comes before "B"

JavaScript applies that exact same logic here.

For example:

"10" starts with "1"
"2" starts with "2"

Since the character "1" has a lower UTF-16 value than "2", JavaScript places "10" first.

The engine isn't malfunctioning.

It's simply following text-based sorting rules.

🛠️ The Fix: Deploying a Comparator Function

To force JavaScript to sort numerically, you must explicitly tell the engine how two values should be compared.

Here’s the proper fix:

const numbers = [1, 10, 2, 25, 5];

// Numeric Sort Fix
numbers.sort((a, b) => a - b);

console.log(numbers);

// Output:
// ✅ [1, 2, 5, 10, 25]

One tiny comparator function.

Massive difference.

⚙️ How the Comparator Actually Works

This line:

(a, b) => a - b

subtracts the second value from the first.

JavaScript then interprets the result.

Negative Result

If the result is negative:

2 - 5 = -3

JavaScript understands that 2 should come before 5.

Positive Result

If the result is positive:

10 - 2 = 8

JavaScript knows 2 should move ahead of 10.

Zero

If the result is 0, both values are considered equal, and their order remains unchanged.

💡 Pro Tip: Reverse Sorting

Need descending order instead?

Just flip the subtraction:

numbers.sort((a, b) => b - a);

Output:

[25, 10, 5, 2, 1]

🚨 Case Closed

Another JavaScript mystery solved.

The golden rule?

Never trust the default behavior of .sort() when working with numbers.

Always provide a comparator function if you want predictable numeric sorting behavior.

Otherwise, JavaScript will happily treat your integers like alphabetized grocery items.

And that’s how 10 ends up beating 2 in a fight it should never win.

Have you ever been burned by JavaScript's default .sort() behavior in production?

Drop your horror stories below 👇

The Weird Beauty of JavaScript: One Language, Infinite Personalities

Code Crumb — Mon, 18 May 2026 18:30:50 +0000

There’s a moment every developer hits where JavaScript stops feeling like “just another language” and starts feeling like an entire ecosystem.

That realization hit me hard recently while working on a simple experiment.

At first, I was writing tiny frontend interactions — toggling classes, handling clicks, animating interfaces. The usual.

Then suddenly I was:

building backend APIs
handling async operations
interacting with databases
debugging terminal processes
managing environment variables
writing logic that never even touches the browser

And the strange part?

It was still JavaScript.

That’s the thing about JS that catches a lot of developers off guard:

The language itself doesn’t dramatically change.

The environment does.

JavaScript Has Multiple Personalities

Most beginners meet JavaScript inside the browser.

That’s where we learn things like:

button.addEventListener('click', () => {
  console.log('clicked');
});

Everything feels visual.

You click something.
Something happens.
The browser reacts.

Simple.

But then Node.js enters the picture.

Now JavaScript can suddenly:

const fs = require('fs');

fs.readFile('data.txt', 'utf8', (err, data) => {
  console.log(data);
});

Wait…

JavaScript can read files now?

That’s usually the first mental shift.

Because once JS escapes the browser, you start realizing:

This language isn’t tied to buttons and animations anymore.

It can run servers.
It can power APIs.
It can manage authentication.
It can stream data.
It can run entire applications.

Same Syntax. Different Powers.

One of the most confusing parts about learning full-stack development is thinking you need to “learn another language” for backend work.

But often, especially in the JavaScript ecosystem, you’re not actually learning a new language.

You’re learning a new runtime.

In the Browser

JavaScript gets access to:

the DOM
window
document
browser storage
user interactions

But it cannot directly:

access your computer’s file system
connect directly to production databases
manage backend processes

In Node.js

JavaScript gains access to:

the file system
environment variables
servers
backend APIs
databases
operating system processes

But now there’s no:

document
window
DOM rendering

Same language.

Completely different world.

Why This Matters for Beginners

A lot of developers quit too early because the ecosystem feels overwhelming.

Frontend.
Backend.
Frameworks.
Tooling.
Bundlers.
Runtimes.
Databases.
Deployment.

It starts looking like a mountain of disconnected technologies.

But once you understand that JavaScript is acting differently depending on where it runs, things start clicking into place.

The browser and Node.js aren’t enemies.

They’re teammates.

One handles the experience.
The other handles the logic.

The Chaos Is Kind of Beautiful

JavaScript has a reputation for being chaotic.

And honestly?

Sometimes it deserves that reputation.

This is a language where things like this exist:

[] + [] // ""
[] + {} // "[object Object]"

Completely normal.
Totally reasonable.
Absolutely terrifying.

But underneath all the weirdness is something incredibly powerful:

JavaScript adapts.

It evolved from a simple browser scripting language into one of the most dominant development ecosystems on the planet.

That flexibility is exactly why it keeps showing up everywhere.

Why I Started Code Crumb

One thing I noticed while learning is that most tutorials teach what to type… but not why things work.

That’s what inspired Code Crumb.

I wanted to create content that:

simplifies JavaScript concepts
explains the reasoning behind the code
helps beginners connect frontend and backend ideas together
makes the ecosystem feel less intimidating

The short-form videos are the quick “aha” moments.

These blog posts are where we slow things down and explore the deeper concepts behind them.

Final Thought

If JavaScript feels overwhelming right now, that’s normal.

You’re not learning a single tool.

You’re learning an entire ecosystem.

And once you start recognizing how the same language changes depending on its environment, the whole full-stack journey starts making a lot more sense.

So whether you’re currently debugging browser code or staring at a terminal window full of Node errors:

Keep building.
Keep experimenting.
Keep breaking things.

That’s where the real learning happens.