Variables — Named Containers

In Module 2, we said JavaScript has memory — it can hold onto information. A variable is how it holds onto that information. But what does that actually mean? Where does the information go? And what does it look like?

A variable is a named container with a value inside. It has two parts: a name (what this piece of information is about) and a value (the actual information).

In JavaScript, creating a variable looks like this:

let guestCount = guestInput.value
let selectedRestaurant = dropdown.value
let kitchenBackedUp = true

Each line creates a named container. let is a built-in JavaScript keyword that means "create a variable." The name comes next. Then = puts a value inside it.

Notice the first two variables get their values from somewhere dynamic — from what a user typed or selected. The third one (kitchenBackedUp) is set to true directly. Both are valid. Some values come from users and databases. Some are set by the developer. The variable doesn't care where the value came from — it just holds it.

let vs const — variables vs constants

There are two keywords for creating named containers. They look almost identical but have one important difference.

let creates a variable — a container whose value can be updated later. Use this for anything that might change.

let guestCount = guestInput.value
// User changes their selection
guestCount = updatedInput.value

The value inside guestCount changed, but the container kept its name. The code didn't change — the file looks the same. What changed is what's stored in your computer's RAM. The old value was erased and the new value took its place.

const creates a constant — a container whose value is set once and cannot be updated. Use this for settings, configuration, or anything that shouldn't change while the app is running.

const taxRate = 0.08
const maxGuests = 50
const appName = "PetKarma"

These are values the developer decided when writing the code. The tax rate is always 8%. The max guest limit is always 50. The app name is always PetKarma. They don't come from a user or a database — they're decisions baked into the code. If you try to reassign a const, JavaScript throws an error and stops.

let guestName = nameInput.value
let guestCount = guestDropdown.value
let selectedRestaurant = restaurantDropdown.value

const maxGuests = 50
const taxRate = 0.08
const appName = "PetKarma"

Where do variables actually live?

This is where it gets physical. When JavaScript creates a variable, the value gets stored in your computer's RAM — a physical chip inside your device. RAM is a massive grid of tiny cells, and each cell holds an electrical charge: on or off, 1 or 0. Billions of these cells.

Here's what actually happens when JavaScript runs let firstName = "Ruthnie":

1. The browser's JavaScript engine says "I need to store the text 'Ruthnie' somewhere."
2. It asks the operating system for a chunk of RAM.
3. The OS says "here, use cells 4,847,201 through 4,847,207."
4. The JavaScript engine converts R-u-t-h-n-i-e into binary — ones and zeros — and writes them into those cells as electrical charges.
5. It keeps a lookup table: "the name firstName points to memory address 4,847,201."

If you could freeze time and look at RAM, you'd see something like a massive spreadsheet:

Address      | Value
-------------|------------------
4,847,201    | 01010010 (R)
4,847,202    | 01110101 (u)
4,847,203    | 01110100 (t)
4,847,204    | 01101000 (h)
4,847,205    | 01101110 (n)
4,847,206    | 01101001 (i)
4,847,207    | 01100101 (e)

And somewhere else in RAM, the JavaScript engine keeps its lookup table — connecting variable names to memory addresses:

Variable name   | Points to address
----------------|------------------
firstName       | 4,847,201
email           | 4,851,300
caseType        | 4,855,400

When your code later says console.log(firstName), the engine checks the lookup table, finds the address, reads the binary values there, decodes them back into letters, and displays "Ruthnie."

Code vs RAM — two different places

This is worth being very explicit about because it's a common source of confusion.

let guestCount = guestInput.value

guestCount: 14

The code says "go get the value from guestInput and put it in a container called guestCount." The code never says 14. The number 14 only exists in RAM because that's what the user happened to type. If a different user types 6, RAM holds 6. Same code, different result.

Close the tab and the RAM is released. The electrical charges dissipate. The data is physically gone — not archived, not saved somewhere. Gone. That's why variables are temporary.

Three tiers of memory

Variables in RAM aren't the only kind of memory in the browser world. There are three tiers, and knowing the difference matters.

1. RAM (variables) — fastest, most temporary. Dies when the tab closes. Every let and const lives here. You don't choose to use RAM — it's automatic. Every variable you create goes to RAM by default. There is no other option.
2. Local storage — slower, but survives tab closing and browser restarting. Still on the user's device only. Limited to about 5-10MB. The developer has to explicitly write code to use it.
3. Database — lives on a server somewhere else entirely. Permanent. Accessible from any device. The developer has to explicitly write code to send data there.

Variables in action — when do they matter?

Here's the timeline of where variables fit in the life of a page:

1. Page loads — JavaScript might fetch data from a database and put it into variables
2. User interacts — JavaScript updates variables as the user types, clicks, selects
3. User triggers a save — JavaScript takes what's in its variables and sends it to the database
4. User leaves the page — variables are destroyed. Only what was saved to the database survives.

Three real scenarios

To make the boundary between variables and databases concrete, here are three scenarios where they interact differently.

Scenario A: A calculator (no database at all)

A calculator website has no database. No backend. The whole thing runs in the browser. Every piece of information — your inputs, the result, the history — lives in variables. All temporary. Close the tab, it's gone. And that's fine because nothing needed to be permanent.

Scenario B: An intake form (accumulating before saving)

The user is filling out a form across multiple steps. JavaScript holds all of that in variables as they go. The user hasn't hit submit yet, so the database doesn't know anything. Variables are acting as a temporary holding area, accumulating information until the user is ready to commit it. On submit, it all goes to the database at once.

Scenario C: Loading an existing record

The user opens a client record. JavaScript sends a request to the backend: "give me client #247." The backend pulls data from the database and sends it back. JavaScript puts it into variables so the page can display it. The data came from the database, but now it's living in a variable so the page can work with it. If the user edits a field, the variable updates — but the database doesn't know yet. Not until the user clicks Save.