When a Value Isn’t Just a Value

There’s a subtle shift that happens when you move from JavaScript to TypeScript.

At first, it feels like you’re just adding types.

But slowly, you start realizing you’re not just working with data anymore.

You’re working with meaning.

And enums are one of the clearest examples of that shift.

The Problem With “Just a String”

In JavaScript, it’s very common to represent states like this:

let status = "success"

It works. It’s simple.

But it comes with a quiet problem.

Nothing stops you from doing this:

status = "succes" // typo
status = "done"   // unexpected value

The issue isn’t just correctness.

It’s that the value "success" has no protection, no structure, and no shared agreement.

It’s just… a string.

When Values Start Carrying Meaning

At some point, you realize:

Not all values are equal.

Some values represent states, roles, or decisions.

They’re not just data — they carry meaning inside your system.

And once something carries meaning, you don’t want it to be loosely defined anymore.

Introducing a Named Set

This is where enums come in.

enum Status {
  Success = "success",
  Error = "error"
}

At first glance, it looks like a simple mapping.

But something important just happened.

You moved from:

"success"

to:

Status.Success

And that’s not just a different syntax.

It’s a different way of thinking.

From Raw Values to Named Concepts

Before enums, you think in raw values:

"success"
"error"

After enums, you think in named concepts:

Status.Success
Status.Error

That small change creates a boundary.

You’re no longer passing around arbitrary strings.

You’re passing around meaningful states.

Why This Matters More Than It Seems

Consider this:

function handle(status: Status) {
  if (status === "success") {
    console.log("ok")
  }
}

This works.

But something feels off.

You defined an enum, but you’re still comparing with a raw string.

Which means:

You stepped outside the abstraction you just created.

The enum was supposed to define a controlled set of meanings.

But by comparing with "success", you’re back to treating it as plain data.

Staying Inside the Abstraction

The intended way is:

if (status === Status.Success) {
  console.log("ok")
}

Now everything stays consistent.

You’re no longer relying on raw values.

You’re relying on the contract of the enum.

What You Gain From This

This shift gives you a few important things:

• consistency → one source of truth
• safety → no typos or unexpected values
• refactoring → change once, update everywhere
• readability → code expresses intent, not just data

But the real gain is deeper.

A Layer of Meaning

Enums introduce a layer between:

Raw data ↔ System logic

Instead of your system depending on:

"success"

It depends on:

Status.Success

Which means:

Your logic is now tied to meaning, not representation.

The Hidden Trade-off

But enums are not always the perfect solution.

They generate runtime code.

They are slightly heavier than simple type unions.

And sometimes, a simpler approach works just as well:

type Status = "success" | "error"

So the question becomes:

Do I need a runtime object, or just a compile-time constraint?

A Small Shift in Thinking

Enums are not about replacing strings.

They’re about changing how you relate to them.

Instead of asking:

“What value is this?”

You start asking:

“What does this represent?”

And once you see that difference, enums stop being just another feature.

They become a way to make your code speak more clearly — not just to the compiler, but to yourself.