DEV Community: Parth

How does a string have methods if it's not an object?

Parth — Fri, 23 Oct 2026 17:44:15 +0000

This is the fifth post in a series I'm writing as I learn JavaScript.

By now this series has a running theme: I learn a rule, then I find something that seems to break it, and chasing down why teaches me more than the rule did.

Here's this one.

I'd just learned that strings are primitives. Not objects — primitives. A string is a single value, like a number or a boolean. Fine.

Then, on the same day, I wrote this:

let name = "parth";
console.log(name.toUpperCase()); // "PARTH"
console.log(name.length);        // 5

And stopped.

.toUpperCase() is a method. .length is a property. Those belong to objects. But I was just told a string is a primitive, not an object. So how does a primitive have methods hanging off it?

Either strings are secretly objects, or something sneaky is happening. It turns out to be the second one, and it has a name: autoboxing.

First, strings really are primitives

Just to be sure I hadn't misunderstood:

console.log(typeof "parth"); // "string", not "object"

A normal string is a primitive. It's not an object. That part was true.

So the methods aren't on the string. The string is borrowing them.

What actually happens: autoboxing

When you write name.toUpperCase(), JavaScript does something behind your back, in this order:

It sees you trying to use a method on a primitive.
It temporarily wraps the primitive in its matching object — here, a String object. (Numbers get a Number object, booleans a Boolean, and so on.)
The object does have all the methods, so .toUpperCase() runs.
You get your result back.
The temporary wrapper object is thrown away. That wrap-use-discard move is autoboxing. The primitive stays a primitive. For a split second, JavaScript loans it an object body so it can use the methods, then takes the body back the instant it's done.

You never see the wrapper. It's created and destroyed inside that one expression.

So the string didn't have methods. JavaScript briefly lent it some.

The object version actually exists

The wrapper JavaScript creates temporarily is a real thing you can make yourself, on purpose, with new String():

let a = "parth";              // primitive string
let b = new String("parth");  // String OBJECT

console.log(typeof a); // "string"
console.log(typeof b); // "object"  ← different!

b is the object version — the same kind of object autoboxing creates for a moment, except this one sticks around because you asked for it.

You can confirm it's a real object instance with instanceof:

console.log(b instanceof String); // true  — b was built from the String constructor
console.log(a instanceof String); // false — a is a primitive, not an instance of anything

(An instance is just an object created from a constructor or class — new String("parth") creates an instance of String, the same way new Date() creates an instance of Date.)

You almost never want the object version

Here's the catch, and the reason I'm glad I learned this rather than just using new String():

let a = "parth";
let b = new String("parth");

console.log(a === b); // false!

They look identical, but one's a primitive and one's an object, so strict equality says no. Object wrappers also behave strangely in conditionals and comparisons. The rule that falls out of this:

Always write string primitives — "parth", not new String("parth"). Let autoboxing hand you the methods when you need them. You get all the convenience of the object with none of the weirdness.

The object wrapper isn't something you're meant to create. It's machinery JavaScript uses internally, and it just happens to be reachable.

What I actually took away

For a while I thought JavaScript was being contradictory: strings are primitives, but also they have methods like objects do. Both can't be true.

They are both true — because of timing. The string is a primitive at rest. It only becomes object-shaped for the instant you call a method, then snaps back. Autoboxing is the bridge between "simple value" and "has useful methods," and it's invisible precisely because it cleans up after itself.

It's the same lesson as the rest of this series, really: the weird behavior isn't JavaScript being careless. It's a mechanism doing something deliberate, just quietly. Once you can see it, it stops being a contradiction and starts being a feature.

That's where this little series lands for now — five "wait, what?" moments from my first notebook of JavaScript, each one explained instead of memorized. If you've hit one I haven't covered, drop it in the comments. It might be the next post.

Copy or reference? Stack, heap, and why changing one thing changed two

Parth — Tue, 20 Oct 2026 10:15:37 +0000

Here's the moment JavaScript stopped making sense to me for an afternoon.

let a = 10;
let b = a;
b = 20;

console.log(a); // 10 — fine, a didn't change

Makes sense. b got its own copy of 10, I changed b, and a stayed put. Exactly what you'd expect.

Then I did what looked like the same thing with an object:

let person1 = { name: "Parth" };
let person2 = person1;
person2.name = "Vatsal";

console.log(person1.name); // "Vatsal" — wait, WHAT?

I changed person2. But person1 changed too. I never touched person1.

Same pattern, completely different result. Figuring out why taught me one of the most important ideas in the language: some values are copied, and some are shared. Which one you get depends on the type — and it comes down to where JavaScript stores things.

Two kinds of data, two kinds of storage

From an earlier post in this series: JavaScript has two families of types.

Primitives — string, number, boolean, null, undefined, bigint, symbol. A single value.
Non-primitives — objects, arrays, functions. Collections of values. What I didn't know is that JavaScript keeps them in two different places in memory.

The stack is for primitives. It's small, fast, and orderly, and it holds the value directly. When a variable holds a number, the number itself is sitting right there in the stack.

The heap is for objects. Objects can be big and grow over time, so they live in a larger, more flexible space. But the variable doesn't hold the object itself — it holds a reference: an address that points to where the object lives in the heap.

That difference — value vs address — is the whole explanation.

Why the number behaved

let a = 10;
let b = a;

a holds 10 directly in the stack. When you write let b = a, JavaScript copies the value. Now b has its own 10, completely separate.

Change b, and a has no idea. They were never connected — just two boxes that happened to hold the same number.

This is called copy by value.

Why the object didn't

let person1 = { name: "Parth" };
let person2 = person1;

person1 doesn't hold the object. It holds a reference — an address pointing to the object in the heap.

When you write let person2 = person1, JavaScript copies the reference, not the object. So now person1 and person2 hold the same address. Two variables, one object, pointing at the exact same thing in the heap.

So when you do person2.name = "Vatsal", you follow the address to the one object and change it. And since person1 points to that same object, it sees the change too.

You didn't have two objects. You had two signposts pointing at one.

This is copy by reference.

The mental picture that made it click

A primitive is like writing a phone number on two separate sticky notes. Change one note, the other is untouched — they were only ever copies.

An object is like two sticky notes that both say "the contact is in drawer 3." Go to drawer 3 and change the contact, and both notes now point to the changed thing. You didn't copy the contact. You copied the location.

STACK (primitives, held directly)      HEAP (objects, held by reference)

 a  →  10                               person1 ──┐
 b  →  10   (its own copy)                         ├──→  { name: "Vatsal" }
                                        person2 ──┘    (one object, two pointers)

This connects back to const

In the var/let/const post, I mentioned a const quirk that now makes complete sense:

const person = { name: "Parth" };

person.name = "Vatsal";     // works fine
person = { name: "Aryan" }; // TypeError

const locks the reference — the address the variable holds. You can't point it at a different object. But you can absolutely follow the existing address and change what's inside. The box is glued in place; its contents aren't.

Stack-vs-heap is why. const protects what's in the variable (the address), not what's across the heap at the other end of it.

The practical catch

This bites people in real code constantly. The classic version:

let original = { count: 0 };
let backup = original;   // you THINK you saved a copy

original.count = 99;
console.log(backup.count); // 99 — your "backup" changed too

backup was never a copy. It's the same object. If you actually want a separate one, you have to make a real copy — for a shallow one:

let backup = { ...original }; // spread into a brand new object

Now backup points to its own object in the heap, and the two move independently.

What I actually took away

I used to think "copy" meant one thing. It doesn't. In JavaScript, copying a primitive copies the value, and copying an object copies the address — and those two behave in opposite ways the moment you change something.

Once I pictured the stack holding values and the heap holding objects behind pointers, every one of these "wait, what?" moments turned into "oh, of course." The number stays independent because it was copied. The object moves together because it was shared.

Same word, two behaviors. The type tells you which one you're getting.

Did this one get you too? The backup that wasn't actually a backup got me early on. I'd love to hear your version in the comments.

Why "1" + 2 + 2 is "122" but 1 + 2 + "2" is "32"

Parth — Sun, 11 Oct 2026 18:16:37 +0000

This is the third post in a series I'm writing as I learn JavaScript.

Here are two lines that look almost identical:

console.log("1" + 2 + 2); // "122"
console.log(1 + 2 + "2"); // "32"

Same numbers. Same +. The only difference is where the string sits. And yet the answers aren't just different — they're different kinds of thing. One is a hundred and twenty-two-ish. The other is thirty-two-ish. Both are actually text.

When I first saw this I assumed it was a trick question. It isn't. Once you know the two rules behind it, it's completely predictable — and it stops being a source of bugs.

Here are the rules.

Rule 1: JavaScript reads left to right

JavaScript doesn't look at the whole line and plan ahead. It works through it one step at a time, left to right, and each + is evaluated before moving to the next.

So the line isn't judged all at once. It's a chain.

Rule 2: `+` has two completely different jobs

The + operator does one of two things depending on what it's touching:

Two numbers → addition. 2 + 2 is 4.
Anything involving a string → joining (concatenation). "a" + "b" is "ab".

And here's the key part: the moment + touches a string, it converts the other side into a string too, then glues them together. This automatic conversion has a name — type coercion. JavaScript coerces one value into another type to make the operation work.

Now let's walk through both lines with those two rules.

`"1" + 2 + 2`

Left to right:

"1" + 2     → "1" touches a string operation → 2 becomes "2" → "12"
"12" + 2    → still a string → 2 becomes "2" → "122"

Result: "122". The string at the front poisons the whole chain. Once step one produces a string, every step after it is also a string.

`1 + 2 + "2"`

Left to right:

1 + 2       → two numbers → real addition → 3
3 + "2"     → now a string appears → 3 becomes "3" → "32"

Result: "32". Here the numbers get to add up first, because the string doesn't show up until the end. 1 + 2 becomes 3, and only then does the "2" turn it into text.

That's the whole mystery. Same pieces, different order, and left-to-right evaluation does the rest. The string acts like a switch: everything after it becomes text.

The other operators aren't so confused

+ is the troublemaker because it has two jobs. Every other math operator has only one — math — so they don't get tempted to join strings. Instead, they convert strings into numbers:

console.log("5" - 2);  // 3   ("5" becomes 5)
console.log("10" - "4"); // 6  (both become numbers)

- can't join anything, so when it meets a string it does the only thing it knows: turn it into a number and subtract. Same for * and /.

So there's a rough rule of thumb:

+ leans toward strings — if it sees one, it joins.
-, *, / lean toward numbers — they always convert to number and do math.

When conversion fails: NaN

If you ask JavaScript to turn something into a number and it can't, you don't get an error. You get NaN — "Not a Number."

console.log(Number("Parth")); // NaN
console.log("Parth" - 2);     // NaN

"Parth" isn't a valid number, so the conversion fails, and NaN is the result. The strange part: NaN's type is still number.

console.log(typeof NaN); // "number"

It's a number-typed value that represents "this was supposed to be a number, but the math didn't work out." And you can't test for it with ===, because — famously — NaN isn't even equal to itself. You check for it like this:

console.log(Number.isNaN(NaN)); // true

Two kinds of conversion

Everything above is JavaScript converting types on its own, mid-operation. That's called implicit conversion (or type coercion) — the engine does it for you, whether you asked or not.

You can also convert explicitly — on purpose, in your own code:

let age = "25";           // a string
let realAge = Number(age); // you convert it yourself

console.log(realAge);        // 25
console.log(typeof realAge); // "number"

Implicit is JavaScript deciding for you. Explicit is you deciding for JavaScript. Bugs tend to come from the first kind — the conversions you didn't realize were happening.

The one that bites everyone: == vs ===

This is the most important practical takeaway, and it comes straight out of coercion.

== compares values after coercing them to the same type:

console.log(2 == "2"); // true — "2" is coerced to 2 first

=== compares values without any coercion. Different type means not equal, full stop:

console.log(2 === "2"); // false — number vs string, done

== is doing the same silent conversion that produced "122" — and that's exactly why it causes bugs. It says two things are equal when they only look equal after JavaScript quietly reshapes one of them.

Use === by default. It compares what's actually there, instead of what things turn into.

What I actually took away

For a while I thought JavaScript was just being weird on purpose. It isn't. Every one of these results comes from two simple rules — left to right, and + prefers strings — plus the fact that the language would rather convert a type than throw an error.

That last habit is the real theme. JavaScript almost never refuses. Give it a string where it wanted a number and it'll convert, join, or hand back NaN — anything but stop. That's convenient right up until it produces "122" when you wanted 5.

You can't turn the behavior off. But once you can see it coming, it stops being magic and starts being rules. And === quietly shuts down a whole category of it.

What's the coercion result that surprised you most? Mine was typeof NaN being "number". I'd love to hear yours in the comments.

var, let, const — and why JavaScript changed its mind

Parth — Sat, 01 Aug 2026 19:16:19 +0000

When I started learning JavaScript, I kept seeing the same advice: use let and const, don't use var.

Usually it came as a rule, not a reason. And a rule you don't understand is a rule you forget — so I went looking for the why.

It turns out var isn't just old-fashioned. It's broken in three specific ways, and let and const exist to fix exactly those three things.

Here they are.

Problem 1: var lets you redeclare the same variable

Watch this:

var name = "Parth";
var name = "Saini";

console.log(name); // "Saini"

No error. No warning. JavaScript just quietly lets you declare the same variable twice.

That sounds harmless in a five-line example. Now imagine a 500-line file where you declare var count at the top, and 300 lines later — having forgotten — you declare var count again. Your original value is gone, and nothing tells you.

let refuses:

let name = "Parth";
let name = "Saini"; // SyntaxError: Identifier 'name' has already been declared

The error is the feature. It catches the mistake at the moment you make it.

Problem 2: var ignores blocks

A block is anything inside curly braces — an if, a for, a bare { }.

You'd expect a variable declared inside a block to stay inside it. var doesn't care:

if (true) {
  var age = 21;
}

console.log(age); // 21 — it escaped!

That variable leaked out of the if and into the surrounding code. var is function-scoped, not block-scoped: it only respects the boundaries of a function, and treats if and for blocks as if the braces weren't there.

let and const are block-scoped. They stay where you put them:

if (true) {
  let city = "Delhi";
  console.log(city); // "Delhi" — fine
}

console.log(city); // ReferenceError: city is not defined

That error is the whole point. The variable did its job inside the block and then stopped existing, which is exactly what you wanted.

Problem 3: var gets quietly moved to the top

This one broke my brain for a while:

console.log(a); // undefined — not an error!
var a = 10;

I used a variable before I declared it, and JavaScript didn't complain. It printed undefined.

The reason is hoisting. Before running your code, JavaScript scans it and moves all var declarations to the top of their scope. So what actually runs is closer to this:

var a;           // moved up, no value yet
console.log(a);  // undefined
a = 10;          // the assignment stays put

The declaration moves. The value doesn't. So you get a variable that exists but is empty — and undefined instead of a helpful error.

let and const are hoisted too, but they refuse to be touched before their declaration line:

console.log(b); // ReferenceError: Cannot access 'b' before initialization
let b = 10;

Again: the error is the improvement. "Cannot access before initialization" tells you exactly what you did wrong. undefined tells you nothing, and lets a broken program keep running.

So what's the difference between let and const?

Simple version:

let — the value can be changed later.
const — the value cannot be reassigned after you create it.

let score = 10;
score = 20;       // fine

const name = "Parth";
name = "Vatsal";  // TypeError: Assignment to constant variable

But here's the part that trips people up. const locks the variable, not the contents:

const person = { name: "Parth" };

person.name = "Vatsal";  // this works!
console.log(person);     // { name: "Vatsal" }

person = { name: "Aryan" }; // this doesn't — TypeError

You can change what's inside the object. You just can't point the variable at a different object.

Think of const as gluing a label to a box. You can't move the label to another box — but you can still open the box and rearrange what's inside.

The bonus problem: variables you never meant to create

There's a fourth way to make a variable, and it's an accident:

name = "Parth";  // no let, no const, no var

This works. JavaScript silently creates a global variable — one that's visible everywhere in your program. Misspell a variable name during an assignment and you don't get an error; you get a brand new global you didn't ask for, while the one you meant to update sits there unchanged.

This is exactly what "use strict" was made for:

"use strict";

name = "Parth"; // ReferenceError: name is not defined

Do you still need to write it? Usually not — you're probably already in strict mode without knowing it. ES modules (anything with import/export) run in strict mode automatically, and so does most code in React, Next.js, Angular, and modern Node projects.

What I actually took away

I came in expecting "var is old, let is new." That's not the story.

The real story is that var fails silently, and let and const fail loudly. Redeclaring a variable, leaking one out of a block, using one before it exists — var allows all three without a word. let and const throw an error at every one.

That felt backwards to me at first. More errors sounds like a worse language.

But an error at the moment you make a mistake is a gift. The alternative is undefined quietly flowing through your program until it finally breaks somewhere far away — with no clue where it came from.

Use const by default. Use let when the value genuinely needs to change. Reach for var basically never.

And now you know why — not just that.

What tripped you up most when you were learning scope? For me it was hoisting. I'd love to hear about it in the comments.

typeof null is "object" — a bug from 1995 nobody can fix

Parth — Sun, 12 Jul 2026 19:28:22 +0000

I'm learning JavaScript. A few weeks in, I ran this line:

console.log(typeof null); // "object"

And I stared at it for a while.

null is not an object. It's the value you use to say there is deliberately nothing here. It's a primitive — same family as string, number, boolean. So why does JavaScript insist on calling it an object?

I assumed I'd misunderstood something. I hadn't. It's a bug. It's been in the language since 1995, everybody knows about it, and it is never getting fixed.

Here's the story, because it turned out to be the most interesting thing I've learned so far.

Where it came from

JavaScript was created by Brendan Eich in about 10 days in 1995. That's not a joke — Netscape wanted a scripting language for their browser and they wanted it immediately.

When you build a language that fast, you take shortcuts. One of them was how values got stored in memory. Every value carried a small type tag — a few bits at the front saying "this is a number," "this is a string," and so on. To find out a value's type, the engine just looked at the tag.

The tag for an object was all zeros.

And null? In that original implementation, null was represented as a null pointer — which, on the machine, is also all zeros.

So when typeof looked at null, it saw all zeros, checked its table, and confidently reported: object.

That's it. That's the whole bug. Two different things happened to look identical to the one piece of code that was supposed to tell them apart.

Why it was never fixed

This is the part I find genuinely interesting.

Everyone figured this out pretty quickly. It's not a mystery, and it's not hard to fix — you'd just special-case null in typeof and be done in an afternoon.

But by the time anyone got around to it, the web already existed. Thousands of sites had shipped code that ran typeof x === "object" and depended on getting true back for null. Some of that code was checking whether a value was "object-ish." Some of it was doing something weirder. Nobody knew exactly how much of it was out there, and nobody could go and edit it.

So fixing the bug would mean breaking working websites. Real ones. Pages that people were using.

There was actually a proposal, years later, to make typeof null return "null". It was rejected. The reasoning was blunt: it would break too much.

The bug stayed. Not because it was hard to fix, but because the cost of fixing it was higher than the cost of living with it.

What I actually took away from this

I started out thinking this was a piece of JavaScript trivia — the kind of thing that shows up in interview questions and nowhere else.

But it taught me something bigger, and it's not really about JavaScript:

Once people depend on your mistake, it stops being a mistake and becomes a feature you have to support.

That's a slightly uncomfortable thought when you're a beginner writing code nobody else will ever run. But it reframed how I read old, weird, "why is it like this" corners of a language. Usually the answer isn't that the designers were careless. It's that they were fast, or early, or working with constraints that no longer exist — and then the world built on top of them before anyone could go back.

Ten days in 1995. One shortcut. And typeof null === "object" ever since.

The practical bit

If you actually need to check for null, don't use typeof. Just compare directly:

if (value === null) {
  // definitely null
}

And if you want to know whether something is a real object, you have to rule null out yourself:

if (typeof value === "object" && value !== null) {
  // an actual object
}

That extra value !== null is in a lot of real codebases. Now you know why it's there.

Have you ever come across a JavaScript behavior that made you stop and think, "Why does it work like that?" I'd love to hear about it in the comments.

DEV Community: Parth

How does a string have methods if it's not an object?

First, strings really are primitives

What actually happens: autoboxing

The object version actually exists

You almost never want the object version

What I actually took away

Copy or reference? Stack, heap, and why changing one thing changed two

Two kinds of data, two kinds of storage

Why the number behaved

Why the object didn't

The mental picture that made it click

This connects back to const

The practical catch

What I actually took away

Why "1" + 2 + 2 is "122" but 1 + 2 + "2" is "32"

Rule 1: JavaScript reads left to right

Rule 2: + has two completely different jobs

"1" + 2 + 2

1 + 2 + "2"

The other operators aren't so confused

When conversion fails: NaN

Two kinds of conversion

The one that bites everyone: == vs ===

What I actually took away

var, let, const — and why JavaScript changed its mind

Problem 1: var lets you redeclare the same variable

Problem 2: var ignores blocks

Problem 3: var gets quietly moved to the top

So what's the difference between let and const?

The bonus problem: variables you never meant to create

What I actually took away

typeof null is "object" — a bug from 1995 nobody can fix

Where it came from

Why it was never fixed

What I actually took away from this

The practical bit

Rule 2: `+` has two completely different jobs

`"1" + 2 + 2`

`1 + 2 + "2"`