Here's a fun fact that surprises a lot of people: JavaScript and Java are basically unrelated. The name was a marketing decision back in the 90s, not a technical one, and it has been causing mild confusion ever since. JavaScript is its own language, and it happens to be the only one that runs natively inside every web browser on the planet.

What that actually means

Open any website, right click, and look at "view page source" — the visible page is HTML, the styling is CSS, and anything that actually does something, anything that responds to a click, validates a form, or updates content without reloading the page, that's JavaScript. If a webpage feels alive rather than static, JavaScript is almost certainly involved.

A tiny taste

document.querySelector("button").addEventListener("click", function () {
  alert("You clicked me!");
});

Don't worry about understanding every piece of that yet — a whole tutorial later in this series is dedicated to exactly this pattern. For now, just notice the shape: find something on the page, and tell it what to do when a particular thing happens.

It isn't just for browsers anymore

For a long time, JavaScript only ran inside a browser. That changed with Node.js, a runtime that lets JavaScript run directly on a server or your own computer, completely outside any browser. This is a big part of why JavaScript ended up everywhere — the same language you use to make a button interactive can also power the server that button talks to.

Why it can feel a little weird at first

JavaScript has some quirks that trip up newcomers, and honestly, some of them trip up experienced developers too. Comparing values with == instead of === can silently do type conversion in surprising ways. Variables declared with var behave differently than let or const, in ways that genuinely matter (the next tutorial covers this properly). None of this makes JavaScript a bad language, it just means a few of its rules are worth learning deliberately rather than guessing at.

Is it worth learning?

If you want to build anything that runs in a browser, there really isn't an alternative — JavaScript isn't one option among many there, it's the only one, at least directly. Combined with how widely it's used on the server side too, it's one of the most practically useful languages you can spend time on, regardless of what kind of software you eventually want to build.

If you look at old JavaScript code, you'll see var everywhere. Look at anything written in the last several years, and you'll barely see it at all. There's a real reason for that shift, and it's worth understanding rather than just memorising "use let and const."

The modern default: let and const

let age = 25;
age = 26;             // fine, let can be reassigned

const name = "Sam";
name = "Alex";         // error! const can't be reassigned

const means the variable can't be reassigned after it's set. Reach for it by default, always. Only switch to let when you genuinely know the value will need to change later, like a counter going up in a loop. This habit alone catches a surprising number of bugs, because you get an error the moment you accidentally try to overwrite something that shouldn't change.

So what is wrong with var?

var has a scoping rule that trips people up constantly: it doesn't respect block boundaries the way let and const do. Take a look:

if (true) {
  var x = 10;
}
console.log(x); // 10 — leaked out of the if block!

if (true) {
  let y = 10;
}
console.log(y); // error — y doesn't exist out here

With var, x escapes the if block entirely and is still visible outside it, which is almost never what you actually want, and it gets genuinely confusing in bigger programs with nested blocks everywhere. let and const fix this by respecting the curly braces you can actually see on screen, which lines up with how most people naturally read code.

const doesn't mean "frozen," by the way

const person = { name: "Sam" };
person.name = "Alex";   // this is totally fine
person = {};             // this isn't — reassigning the variable itself

This one genuinely surprises people the first time. const only locks the variable name to a particular object or array — it says nothing about whether the contents of that object can change. If you truly need an unchangeable object, that's a separate topic (Object.freeze), but don't assume const gives you that for free.

The rule of thumb

Use const unless you've a specific reason to reassign the variable, in which case use let. There's essentially no good reason to reach for var in code you're writing today — it mostly exists now for compatibility with old code that hasn't been updated yet.

JavaScript gives you more than one way to write a function, which is either flexible or annoying depending on your mood that day. Understanding the differences, especially around arrow functions, will save you real confusion down the line.

The classic function

function greet(name) {
  return "Hello, " + name;
}
console.log(greet("Sam"));

The arrow function

const greet = (name) => {
  return "Hello, " + name;
};

Same behaviour, different syntax. For a one-line function that just returns a value, arrow functions get even shorter, dropping the braces and the return keyword entirely:

const greet = name => "Hello, " + name;
const add = (a, b) => a + b;

Once you get used to reading this shorthand it's genuinely nice — but if it looks like magic right now, that's completely normal, everyone finds it a little dense at first.

The real difference: how "this" behaves

This is the part that actually matters, not just the shorter syntax. Inside a regular function, the value of this can change depending on how the function gets called, which causes no end of confusion. Arrow functions don't have their own this at all — they simply borrow it from whatever code surrounds them. This makes arrow functions genuinely more predictable inside things like event handlers and callbacks, which is a big part of why they took off so fast once JavaScript added them.

Scope: what a function can and can't see

function outer() {
  let secret = "hidden";

  function inner() {
    console.log(secret); // works — inner can see outer's variables
  }

  inner();
}

console.log(secret); // error — secret doesn't exist out here

A variable declared inside a function only exists inside that function, and anything nested within it. Try to use it outside, and JavaScript has no idea what you're talking about. This is scope, and it's one of those ideas that feels abstract until suddenly, usually while debugging something, it clicks completely.

Parameters with default values

function greet(name = "friend") {
  return "Hello, " + name;
}
greet();          // Hello, friend
greet("Sam");     // Hello, Sam

Which style should you use?

Honestly, for most everyday code, arrow functions have become the default choice, especially for short callbacks. Regular functions still earn their keep for methods on objects, and for anywhere you specifically need the traditional, changeable behaviour of this. You'll end up using both — knowing why each exists matters more than picking a side.

Almost every piece of data you touch in JavaScript ends up in one of two shapes: an array, or an object. Get comfortable with both and a surprising amount of everyday JavaScript starts to feel familiar.

Arrays: ordered lists of things

const fruits = ["apple", "banana", "cherry"];
console.log(fruits[0]);       // apple
console.log(fruits.length);   // 3

fruits.push("date");          // add to the end
fruits.pop();                 // remove from the end

Looping over an array

fruits.forEach(fruit => {
  console.log(fruit);
});

The array methods everyone eventually loves

const numbers = [1, 2, 3, 4, 5];

const doubled = numbers.map(n => n * 2);
const evens = numbers.filter(n => n % 2 === 0);
const total = numbers.reduce((sum, n) => sum + n, 0);

console.log(doubled); // [2, 4, 6, 8, 10]
console.log(evens);   // [2, 4]
console.log(total);   // 15

map, filter and reduce look intimidating the first time you see them, but they are worth pushing through. map transforms every item, filter keeps only the ones matching some condition, and reduce collapses the whole array down to a single value. Once these three click, a lot of loops you would have written by hand suddenly become one clean line.

Objects: named properties instead of positions

const person = {
  name: "Ann",
  age: 30,
};

console.log(person.name);      // Ann
console.log(person["age"]);    // 30 — also works
person.age = 31;                // update a value
person.city = "London";         // add a brand new property

Both the dot syntax and the square bracket syntax reach the same value. Dot notation is what you'll use almost all the time; the square bracket version becomes useful when the property name is stored in a variable rather than typed out directly.

Objects inside arrays, arrays inside objects

const users = [
  { name: "Ann", age: 30 },
  { name: "Bob", age: 25 },
];

console.log(users[0].name); // Ann

This combination, an array of objects, is genuinely everywhere in real JavaScript. Data coming back from an API almost always looks exactly like this, so getting comfortable reaching into it, whether that's users[0].name or looping with users.forEach, pays off constantly.

A quick way to tell them apart

If order matters and you're mainly thinking "the first one, the second one, the last one," reach for an array. If you're thinking "the name field, the age field," reach for an object. Most real data ends up being some combination of both, nested inside each other.

HTML describes what a page looks like when it first loads. But the moment you click a button and something changes without the page reloading, that's JavaScript reaching into the page and altering it directly, live, through something called the DOM.

What the DOM actually is

DOM stands for Document Object Model, which sounds more intimidating than it's. When a browser loads your HTML, it builds a tree of objects representing every element on the page — every div, every button, every paragraph becomes an object JavaScript can read and change. Change the object, and the browser immediately updates what you see on screen.

Finding an element

const heading = document.querySelector("h1");
console.log(heading.textContent);

querySelector takes a CSS-style selector, the exact same kind you would write in a stylesheet, and returns the first matching element it finds. Prefer querySelectorAll when you want every match instead of just the first.

Changing what is on the page

heading.textContent = "Welcome!";
heading.style.color = "blue";
heading.classList.add("highlight");

textContent swaps the visible text. style lets you tweak CSS directly from JavaScript, though for anything more than a quick one-off change, toggling a CSS class with classList is usually the cleaner habit, since your styling stays organised in a stylesheet rather than scattered through your JavaScript.

Reacting to a click

const button = document.querySelector("button");
button.addEventListener("click", function () {
  alert("Button clicked!");
});

addEventListener is the workhorse of interactive pages. You're telling the browser: "when this specific thing happens to this specific element, run this specific function." The function itself doesn't run right away — it just sits there, waiting, until the click actually happens.

Creating brand new elements

const item = document.createElement("li");
item.textContent = "New item";
document.querySelector("ul").appendChild(item);

This pattern, create an element, fill it with content, then attach it somewhere in the page, is how JavaScript builds things like a new row in a to-do list without ever reloading the page.

A word of caution

Directly manipulating the DOM by hand, piece by piece, works perfectly well for small pages, but it gets messy fast once a page has a lot of moving parts. This is exactly the problem frameworks like React were built to solve, by letting you describe what the page should look like and handling the actual DOM updates for you behind the scenes. That said, understanding plain DOM manipulation first makes those frameworks make a lot more sense later, rather than feeling like unexplained magic.

Some things in JavaScript don't finish instantly — fetching data from a server, reading a file, waiting on a timer. JavaScript handles this kind of "finish later" work with something called a Promise, and honestly, this is one of the topics that takes a while to feel comfortable with, so don't worry if it feels a bit abstract at first.

What a Promise represents

A Promise is an object representing a value that doesn't exist yet, but will eventually — either successfully, or with an error. Think of it as a receipt: you don't have your food yet, but you've something that guarantees you'll get either the food or an explanation of what went wrong.

Using .then()

fetch("https://api.example.com/users")
  .then(response => response.json())
  .then(data => console.log(data))
  .catch(error => console.log("Something went wrong:", error));

Each .then() runs once the previous step finishes successfully, and .catch() runs if anything along the chain fails. This works, and you'll see it in plenty of real code, but chaining a lot of .then() calls together can get hard to read once there are more than two or three steps.

async/await: the same thing, easier to read

async function getUsers() {
  try {
    const response = await fetch("https://api.example.com/users");
    const data = await response.json();
    console.log(data);
  } catch (error) {
    console.log("Something went wrong:", error);
  }
}

This does exactly the same thing as the .then() version above, but it reads almost like ordinary, top-to-bottom code, which is a genuinely big deal once your logic gets more complicated than two chained steps. The await keyword essentially pauses the function right there until the Promise finishes, without freezing the rest of the page while it waits.

Two important rules

• await only works inside a function marked async — you can't just sprinkle it anywhere.
• Wrap awaited code in try/catch to handle failures, the same way you would with any other error-prone code.

Why does any of this matter?

JavaScript runs on a single thread, meaning it can only do one thing at a time. If fetching data from a server just froze everything until it finished, every website would feel completely unresponsive while anything loaded. Promises, and async/await on top of them, let JavaScript start a slow operation, immediately move on to other work, and come back to handle the result the moment it actually arrives.

Don't overthink it early on

If this still feels a little fuzzy, that's completely normal. Write a few small examples that fetch something and log it to the console, break them on purpose, and see what the error messages look like. This concept genuinely clicks with practice more than with reading about it.

Clicking a button is the example everyone reaches for first, but JavaScript can react to a huge range of things happening on a page, and understanding events properly opens up a lot more than just "do something on click."

The pattern, one more time

element.addEventListener("eventType", function () {
  // what should happen
});

Events beyond click

• "input" — fires as the user types into a text field, letter by letter.
• "submit" — fires when a form is submitted, letting you intercept it before the page reloads.
• "keydown" — fires when any key is pressed, useful for keyboard shortcuts.
• "mouseover" and "mouseout" — fire when the mouse enters or leaves an element.
• "load" — fires once the page has fully finished loading.

Stopping a form from reloading the page

const form = document.querySelector("form");
form.addEventListener("submit", function (event) {
  event.preventDefault();
  console.log("Form submitted, but the page didn't reload");
});

event.preventDefault() is one of those small lines that unlocks a lot. Without it, submitting a form does what forms have always done — sends the browser to a new page, which isn't what you want in most modern, JavaScript-driven forms.

The event object itself

button.addEventListener("click", function (event) {
  console.log(event.target);       // the exact element that was clicked
  console.log(event.type);         // "click"
});

Every event handler receives an event object describing what actually happened, which becomes essential once one function needs to handle clicks from several different buttons and figure out which one triggered it.

Event bubbling: events travel upward

Click a button inside a div, and technically the click event fires on the button first, then "bubbles" upward through every parent element containing it, all the way up to the whole document. This is why you can sometimes attach one listener to a parent element and catch clicks happening on any of its children, rather than attaching a separate listener to every single child individually — a pattern called event delegation, which is worth looking into once basic listeners feel comfortable.

Removing a listener

function handleClick() {
  console.log("clicked");
}
button.addEventListener("click", handleClick);
button.removeEventListener("click", handleClick);

Note this only works with a named function, not an anonymous one written directly inline — you need something to actually point back to when you want to remove it later.

The takeaway

Events are how a static page becomes an application that responds to a real person using it. Once addEventListener feels natural, most of what makes a website feel "interactive" rather than just "readable" starts to make a lot more sense.

Modern websites constantly pull in data without reloading the page — a social feed refreshing, search results appearing as you type, a weather app updating. Under almost all of that sits the same tool: fetch.

A basic GET request

fetch("https://api.example.com/users")
  .then(response => response.json())
  .then(data => console.log(data));

fetch sends a request and gives you back a Promise, which is why this pairs naturally with everything from the promises tutorial. The first .then() converts the raw response into usable JSON; the second one actually does something with that data.

The same thing with async/await

async function getUsers() {
  const response = await fetch("https://api.example.com/users");
  const data = await response.json();
  console.log(data);
}

Sending data, not just requesting it

fetch("https://api.example.com/users", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({ name: "Ann", age: 30 }),
})
  .then(response => response.json())
  .then(data => console.log("Created:", data));

By default fetch sends a GET request. To send data, you switch the method to POST, tell the server what kind of data is coming with the Content-Type header, and hand over the actual data as a JSON string, using JSON.stringify to convert your JavaScript object into text the server can understand.

Checking whether the request actually succeeded

Here's something that catches a lot of people off guard: fetch doesn't treat a 404 or 500 error as a failure the way you might expect. The Promise still resolves successfully; you've to check response.ok yourself:

const response = await fetch("https://api.example.com/users/999");
if (!response.ok) {
  throw new Error(`Request failed with status ${response.status}`);
}

Handling network failures

try {
  const response = await fetch("https://api.example.com/users");
  const data = await response.json();
  console.log(data);
} catch (error) {
  console.log("Network error:", error);
}

A genuine network failure, like no internet connection at all, does reject the Promise and land in catch. Combine that with the response.ok check above and you're covering both the "request never even reached the server" case and the "server responded, but with an error" case.

Putting it together

fetch, combined with async/await and a bit of error checking, is the backbone of essentially every modern web app that talks to a backend. Once this pattern feels natural, connecting a front end you've built to a real API, including one built with the Spring Boot tutorials elsewhere on this site, stops feeling like a separate skill and starts feeling like the same handful of ideas applied again.