Types — The Categorization of Data

Every variable is a named container. But what's inside the container matters. A number, some text, a true/false answer — these are different categories of data. Those categories are called types.

A type is the categorization of what a variable holds. Not the variable itself — the kind of value inside it.

The built-in types

JavaScript has a handful of built-in type categories:

String — text. Always wrapped in quotes. Called "string" because it's a string of characters, like beads on a necklace.

"Ruthnie"
"Personal Injury"
"hello"

Number — any number. No quotes. The moment you put quotes around a number, it becomes a string: "14" is text, 14 is a number. They look the same to a human. They are completely different to JavaScript.

14
29.99
-3
0

Boolean — true or false. Only two possible values. No quotes. Named after George Boole, a mathematician. Used whenever something is yes or no, on or off, present or absent.

true
false

Object — a container that holds multiple pieces of related data grouped together under one name. You access the pieces inside with dot notation.

let client = {
  firstName: "Ruthnie",
  email: "ruthnie@example.com",
  caseType: "Personal Injury",
  isActive: true
}

client.firstName   // "Ruthnie"
client.isActive    // true

Array — an ordered list of things. Square brackets. Comma-separated. Arrays are technically a special kind of object.

let caseTypes = ["Personal Injury", "Family Law", "Immigration", "Criminal Defense"]

caseTypes[0]   // "Personal Injury" (counting starts at zero)

Undefined — a variable exists but nothing was put in it yet.

Null — a variable was intentionally set to "nothing." The difference: undefined means nobody filled this in yet. null means someone deliberately said this has no value.

Every variable has three properties

A variable has a name, a value, and a type categorization of that value. These are three separate things describing one piece of data.

Variable name       | What it holds                      | Type categorization
--------------------|------------------------------------|-----------------------
formData            | { firstName: "Ruthnie", ... }      | object
formData.firstName  | "Ruthnie"                          | string
formData.phone      | "555-1234"                         | string
result              | { success: true, leadId: 247 }     | object
result.success      | true                               | boolean
result.leadId       | 247                                | number

The variable is the container. The type categorization is the category of what's inside. They aren't the same thing — they're two different properties of the same piece of data.

Why types matter — JavaScript is dangerously loose

Here's the problem. JavaScript doesn't force you to say what type a value is. And it tries to guess what you meant instead of stopping you when things don't match.

"29.99" * 3   // Result: 89.97

The * operator only works with numbers. JavaScript sees a string on the left, tries to convert it to a number, succeeds, and does the math. It guessed right this time.

"29.99" + "5.00"   // Result: "29.995.00"

The + operator works with numbers AND strings. JavaScript's rule: if either side is a string, treat + as concatenation (sticking text together). It doesn't look inside the strings to see if they contain digits. It sees string + string and immediately concatenates. No second-guessing.

You'd expect 34.99. You get "29.995.00". That's a real bug. And it doesn't crash your app. It doesn't throw an error. It silently gives you the wrong answer.

Checking a type — typeof

If you're ever debugging and something isn't working the way you expect, you can ask JavaScript what type a value is:

typeof "Ruthnie"     // "string"
typeof 14            // "number"
typeof true          // "boolean"
typeof undefined     // "undefined"

typeof is a built-in keyword. You'd use it by adding temporary lines in your code to check what type something actually is:

console.log(typeof price)
console.log(price)

Open the browser, press F12 to open DevTools, look in the Console tab. You'd see both lines printed — the type and the value. If you expected to see number and 29.99 but instead you see string and 29.99, you've found your bug.

Three different meanings of "types"

The word "type" shows up in three different contexts in development. They overlap but they're enforced by different systems at different times.

JavaScript types — the categories we just covered. String, number, boolean, object, array. These exist in RAM while your app is running. JavaScript doesn't enforce them — it lets mismatches happen silently.

Database types — the categories your database uses. Text, integer, boolean, enum, timestamp. These are enforced when data is saved or read. Try to put text in an integer column and PostgreSQL rejects it.

TypeScript type definitions — rules you write that describe the specific shape of your data. TypeScript enforces them while you're writing code, before it even runs. Your editor shows red squiggly lines. The build fails. The app never starts if the types don't match.

Why everything isn't uniform

If you're wondering why JavaScript types, database types, and TypeScript type definitions don't just match — it's because they were invented by different people, at different times, with no coordination.

• SQL was created in the 1970s by IBM researchers
• JavaScript was created in 1995 by Brendan Eich — in 10 days
• PostgreSQL evolved from a 1986 university project
• TypeScript was created in 2012 by a Microsoft team

None of these people were in the same room. SQL calls text TEXT. JavaScript calls it string. They're describing the same concept with different words and different rules. A huge part of what modern development tooling does is bridge the gaps between systems that were never designed to work together. That generated Supabase types file? That's a bridge. An API? That's a bridge. The key insight: a lot of what feels like unnecessary complexity is actually bridge-building.

Why JavaScript is loose — the history

JavaScript was created in 1995 for Netscape, the browser company at the time. Brendan Eich built it in 10 days. The looseness with types wasn't an accident — it was deliberate. The thinking was: people making simple web pages shouldn't have to worry about declaring types.

In 1995, that was fine. Websites were simple. But the internet grew massively and people started building complex apps with JavaScript — apps it was never designed for. By the time everyone realized loose types were causing real bugs at scale, billions of websites already ran on JavaScript. You can't change how the language works when the entire internet depends on the current behavior.

So Microsoft created TypeScript in 2012 as a layer on top. TypeScript checks your code before it runs, catches type mismatches in your editor, then strips all the type information out and produces plain JavaScript for the browser. The browser never sees TypeScript. It only runs JavaScript. Every .ts and .tsx file gets compiled down to .js before the browser touches it. That's what happens during your npm run build step.