The little HTML element that never matched the design

I’ve lost count of how many times I’ve styled a form, felt happy with the result, and then reached the dropdown.

The input fields looked clean. The buttons matched the design system. The spacing was consistent.

And then there was <select>.

It looked like it belonged to a completely different website.

The problem with native dropdowns

A native dropdown is one of the simplest things to build in HTML.

<label for="country">Choose a country</label>
<select id="country" name="country">
  <option value="us">United States</option>
  <option value="ca">Canada</option>
  <option value="in">India</option>
</select>

No JavaScript. No dependencies. Just HTML.

But when the design calls for rounded corners, custom colors, a different arrow, styled options, and a highlighted selected item, things get complicated.

You can style parts of a native <select>, but the opened dropdown menu has traditionally been controlled largely by the browser and operating system.

That is where the familiar workaround begins.

So, we rebuild it in JavaScript

We hide the original dropdown and create a custom one using buttons, divs, event handlers, and CSS.

Then we handle opening and closing, track the selected option, support keyboard navigation, manage focus, and make the component work with forms.

Suddenly, a tiny dropdown has become a component of its own.

Libraries such as Select2 and Choices.js can help, especially when you need advanced functionality.

But sometimes, all you wanted was a dropdown that matched your design.

What if CSS could handle more of that work without throwing away the native <select>?

It now can, in browsers that support customizable select elements.

Meet appearance: base-select

The modern approach starts with a CSS property:

select,
select::picker(select) {
  appearance: base-select;
}

That second selector is the interesting part.

appearance: base-select opts the control into a customizable rendering model. The ::picker(select) pseudo-element targets the dropdown menu itself.

Instead of styling only the closed control, you can customize both the button and the list of options using CSS.

No JavaScript is required just to change the dropdown’s appearance.

Let’s style a real dropdown

First, give the select a cleaner button style.

select {
  width: 100%;
  padding: 12px 16px;
  border: 1px solid #d1d5db;
  border-radius: 10px;
  background: #ffffff;
  color: #172554;
  font: inherit;
  cursor: pointer;
}

Now enable the customizable rendering model and style the dropdown menu.

select,
select::picker(select) {
  appearance: base-select;
}
select::picker(select) {
  padding: 6px;
  border: 1px solid #e5e7eb;
  border-radius: 12px;
  background: #ffffff;
  box-shadow: 0 12px 30px rgb(0 0 0 / 10%);
}

The menu can now have its own border, spacing, background, and shadow.

That is a meaningful difference from the traditional approach, where the opened menu often resisted the styling you wanted.

And yes, you can style individual options

The options do not have to look like a plain list anymore.

select option {
  padding: 10px 12px;
  border-radius: 8px;
}
select option:checked {
  background: #ccfbf1;
  color: #115e59;
}

The :checked pseudo-class targets the selected option, allowing you to give it a distinct visual treatment.

You can also customize the dropdown arrow with ::picker-icon and use :open to change the select's appearance while its menu is open.

These are CSS features designed specifically for customizable selects, not JavaScript tricks.

What are these CSS selectors actually called?

If the syntax looks unfamiliar, you are not alone.

Consider these examples:

select::picker(select) { }
select::picker-icon { }
select:open { }
select option:checked { }
select option::checkmark { }

They might look similar, but each selector targets something different.

1. select — Type selector

Targets the HTML <select> element itself: the dropdown control you see on the page.

2. ::picker(select) — Pseudo-element

Targets the dropdown picker that opens when you interact with the select. Think of it as the popup menu containing the options.

3. ::picker-icon — Pseudo-element

Targets the dropdown arrow inside the select button. You can customize its appearance instead of relying entirely on the default icon.

4. :open — Pseudo-class

Targets the select while its picker is open. This is useful for changing the border, background, or other styles to indicate that the control is active.

5. :checked — Pseudo-class

Targets the selected option, making it possible to distinguish the current choice from the other options.

6. ::checkmark — Pseudo-element

Targets the checkmark displayed alongside the selected option, allowing you to customize that indicator.

Here is how the selectors work together:

/* The dropdown control */
select {
  border-radius: 10px;
}

/* The popup menu */
select::picker(select) {
  border-radius: 12px;
  padding: 6px;
}

/* The dropdown arrow */
select::picker-icon {
  color: teal;
}

/* When the dropdown is open */
select:open {
  border-color: teal;
}

/* The selected option */
select option:checked {
  background: #ccfbf1;
  color: #115e59;
}

/* The selected option's checkmark */
select option::checkmark {
  color: teal;
}

The key distinction is simple: pseudo-classes describe a state, while pseudo-elements target a specific part of an element or its rendered content.

Once you understand that difference, these selectors become much easier to read and remember.

What about the JavaScript we used to write?

Here is the part I like most about this change.

We have not replaced HTML with a clever new framework. We have not created another abstraction to maintain.

We have made an existing HTML element more customizable.

The native <select> still represents a form control. You can continue using its name, value, and normal form behavior.

In supporting browsers, you get much more control over its appearance without implementing the entire interaction model yourself.

That does not mean every custom dropdown library is unnecessary. Searchable selects, asynchronous options, tagging, and complex multi-select interactions can still justify a dedicated component.

The important difference is that visual customization no longer automatically means rebuilding the interaction in JavaScript.

Browser compatibility: What should you know?

This is the part you should not skip.

Customizable select elements are a major improvement, but support depends on the browser and version. The appearance: base-select approach and its related selectors are not universally available in every browser.

Support for the main property does not necessarily guarantee support for every related pseudo-element or HTML enhancement.

Before using these features in production, check the current compatibility information for the exact features you intend to use.

You can start with MDN’s customizable select guide and its CSS appearance reference.

Use progressive enhancement

The safest approach is to keep a functional native select as your foundation, then enable the advanced styling in browsers that support it.

/* A useful baseline */
select {
  width: 100%;
  padding: 12px;
  border: 1px solid #d1d5db;
  border-radius: 10px;
}
/* Enhanced appearance in supporting browsers */
@supports (appearance: base-select) {
  select,
  select::picker(select) {
    appearance: base-select;
  }
  select::picker(select) {
    padding: 6px;
    border: 1px solid #e5e7eb;
    border-radius: 12px;
  }
}

Browsers that do not support base-select can ignore the enhanced declarations and continue using the native control.

One important detail: @supports checks whether a declaration is recognized. It does not guarantee that every related pseudo-element or behavior works identically.

Test your actual target browsers, including mobile devices, and provide a sensible fallback wherever necessary.

The bigger lesson

Frontend development has a habit of turning small styling frustrations into large JavaScript components.

Sometimes that is necessary. Sometimes we are working around limitations that the platform is gradually removing.

Customizable <select> elements are a good reminder to revisit those old assumptions.

Before adding another dependency, ask yourself whether the browser can now do the job directly.

Because sometimes the best frontend abstraction is the one you no longer need to build.

And sometimes, all you wanted was a dropdown that matched your design.

You write a variable, assign it a value, and use it somewhere in your code.

Simple enough.

But what happens when you assign an object to another variable? Why can changing one variable unexpectedly change the other? And why does an object sometimes remain in memory even after the function that created it has finished running?

These aren’t just JavaScript trivia questions. They explain some of the most confusing bugs you’ll encounter in real projects.

The interesting part is that a variable’s name, its value, and the memory holding that value are not necessarily the same thing.

Let’s unpack that.

A variable isn’t a little box you can always point to

Consider this example:

let age = 25;
let name = "Alex";
let isDeveloper = true;

It’s tempting to imagine three boxes sitting somewhere in memory, each containing one value.

That’s a useful beginner’s mental model. But JavaScript’s actual memory behavior is more complicated.

JavaScript creates bindings for these variables and associates them with values. The engine manages how those values are represented and stored internally.

For primitive values such as numbers, strings, and booleans, the details are often invisible to you.

Things become more interesting when objects enter the picture.

const user = {
  name: "Alex",
  age: 25
};

Where does the object live? What does user actually hold?

To answer that, we need to understand two familiar terms: the stack and the heap.

Stack vs. heap: The mental model that helps

You have probably heard that JavaScript stores primitive values on the stack and objects on the heap.

This is a common teaching model, but there’s an important detail: JavaScript doesn’t require every engine to store values in exactly this way.

The ECMAScript specification defines language behavior, not a universal physical memory layout. JavaScript engines can optimize storage and execution as they see fit.

Still, the stack-and-heap model is useful for understanding what’s happening.

Think of it this way:

• Stack: Often associated with function calls, execution contexts, and short-lived local state.
• Heap: Commonly associated with dynamically allocated objects and other data that may outlive a particular function call.

Imagine a function that creates an object.

function createUser() {
  const name = "Alex";
  const user = {
    name: name,
    active: true
  };
  return user;
}

const result = createUser();

When createUser() executes, JavaScript establishes the function's execution context.

The function creates local bindings for name and user, and evaluates an object literal to create an object.

In a simplified stack-and-heap diagram, the local bindings belong to the function’s execution context, while the object is represented as an allocation in the heap.

When the function returns, its execution context can be discarded. But the returned object remains accessible through result.

That’s the first important insight: a function finishing doesn’t automatically mean everything it created must disappear.

Whether data can be reclaimed depends on whether it remains reachable.

The real surprise: Two variables, one object

Now let’s look at a bug that appears in ordinary application code.

const user = {
  name: "Alex"
};

const anotherUser = user;

anotherUser.name = "Sam";

console.log(user.name);

What do you expect the output to be?

It’s tempting to think that anotherUser received a copy of user. If that were true, changing one object wouldn't affect the other.

But the output is:

"Sam"

Why?

Because assigning an object to another variable doesn’t clone that object.

Both variables now provide access to the same underlying object.

Here’s a simplified representation:

user ──────────┐
               ├────> { name: "Sam" }
anotherUser ───┘

The arrows represent the relationship between the variable bindings and the object. They aren’t literal pointers you can inspect in ordinary JavaScript.

When you run anotherUser.name = "Sam", you modify that shared object. Reading user.name then returns the updated value because user still accesses the same object.

This is why copying objects requires more thought than assigning a variable.

How to create a separate object

If you want a shallow copy of this object, you can use the spread syntax:

const user = {
  name: "Alex"
};

const anotherUser = { ...user };

anotherUser.name = "Sam";

console.log(user.name);        // "Alex"
console.log(anotherUser.name); // "Sam"

Now the two variables access different objects.

However, spread syntax creates only a shallow copy. If the object contains nested objects, those nested objects are still shared unless you copy them separately.

This distinction matters when managing form state, updating React state, editing configuration objects, and working with cached API responses.

A variable assignment can look harmless while creating shared mutable state across different parts of your application.

Primitive values behave differently

Compare object assignment with this example:

let first = 10;
let second = first;

second = 20;

console.log(first);  // 10
console.log(second); // 20

Here, changing second doesn't change first.

The difference isn’t simply that one value is stored on the stack and the other on the heap. The important language-level distinction is how assignment behaves.

For a primitive value, the receiving variable gets that value. Reassigning one binding doesn’t reassign the other.

For an object, the receiving variable gets the same object reference value. Mutating the object through either variable affects the same object.

JavaScript passes arguments by value, too. When the value is an object reference, the function receives a copy of that reference — not an independent copy of the object.

Consider this example:

function updateUser(user) {
  user.name = "Sam";
}

const person = {
  name: "Alex"
};

updateUser(person);

console.log(person.name); // "Sam"

The function parameter receives a reference value that points to the same object. Mutating that object is visible to the caller.

But reassigning the parameter is different:

function replaceUser(user) {
  user = { name: "Sam" };
}

const person = {
  name: "Alex"
};

replaceUser(person);

console.log(person.name); // "Alex"

Reassigning user changes only the local parameter binding. It doesn't replace the caller's person binding.

Once you understand this distinction, many mysterious-looking JavaScript bugs become predictable.

Why some variables survive after a function returns

So far, we’ve seen that objects can remain accessible after the function that created them has finished.

Closures reveal an even more interesting version of this behavior.

Look at this function:

function createCounter() {
  let count = 0;
  return function increment() {
    count++;
    return count;
  };
}

const counter = createCounter();
console.log(counter()); // 1
console.log(counter()); // 2
console.log(counter()); // 3

The createCounter() function has already returned.

So why hasn’t count disappeared?

The returned increment function still has access to the lexical environment in which it was created. That environment includes the count binding.

As long as the returned function remains reachable, the engine must preserve the information needed for its behavior.

The engine may optimize how it represents that environment. It doesn’t have to keep an entire function execution context frozen on the stack.

But the observable behavior must remain the same: each call can access and update the same count binding.

This is a closure.

A closure allows a function to retain access to variables from its surrounding lexical scope, even after that outer function has finished executing.

Closures are useful for counters, private state, event handlers, callbacks, and functions that remember configuration.

They’re also a reminder that the lifetime of data isn’t always the lifetime of the function that created it.

If memory can stay around, how does JavaScript clean it up?

Imagine creating thousands of objects while using your application.

Eventually, some objects are no longer needed. If JavaScript kept all of them forever, applications would consume increasing amounts of memory.

This is where garbage collection comes in.

JavaScript engines use garbage collectors to reclaim memory occupied by data that is no longer needed. Modern engines commonly use reachability as a key part of deciding what can be collected.

Consider this example:

let user = {
  name: "Alex"
};

user = null;

Initially, user provides access to the object.

After user = null, that binding no longer provides access to it. If nothing else can reach the object, it becomes eligible for garbage collection.

Notice the wording: eligible for garbage collection.

Setting a variable to null doesn't immediately free the object's memory. The object might still be referenced elsewhere, and garbage collection timing is controlled by the engine.

For example:

let first = {
  name: "Alex"
};

const second = first;

first = null;

console.log(second.name); // "Alex"

The object remains accessible through second. Removing one reference doesn't make an object collectible when another reference still reaches it.

This is also why certain memory leaks happen.

An object may no longer be useful to your application but remain reachable through a long-lived reference, such as an event listener, timer, cache, or closure.

The garbage collector cannot safely discard an object that the program can still access.

What this means for your real projects

You don’t need to manually manage memory in everyday JavaScript. But understanding these relationships can help you write more predictable applications.

Keep these three situations in mind.

1. When updating React state

Avoid mutating an existing object when your intention is to create a new state value.

// Avoid mutating the existing object
user.name = "Sam";
setUser(user);
// Prefer creating a new object
setUser(previous => ({
  ...previous,
  name: "Sam"
}));

The second approach creates a new object with the updated property. This works better with React’s state-update and identity-based comparison behavior.

2. When managing event listeners

A component that repeatedly registers listeners without removing obsolete ones can keep unnecessary work and references alive.

Clean up listeners when they’re no longer needed, particularly when attaching them to long-lived objects such as window or document.

3. When caching data

A cache can improve performance, but an unbounded cache can retain objects long after they’re useful.

Think about how entries are removed, whether the cache needs a size limit, and how long the cached data should remain available.

In all three situations, the useful question is the same: What still has access to this data, and how long does that access need to last?

The mental model worth remembering

JavaScript memory becomes easier to understand when you stop imagining every variable as an isolated box.

Instead, think about three things:

• Bindings: The names your code uses to access values.
• Objects and values: The data those bindings refer to or represent.
• Reachability: Whether the program can still access that data.

The stack-and-heap model helps visualize how engines commonly manage execution and dynamically allocated data, but it isn’t a universal map of where every JavaScript value physically lives.

You don’t need to know the exact memory address of an object to understand why it survives, why two variables can modify the same data, or why a closure remembers a value.

The next time a JavaScript variable behaves unexpectedly, ask yourself one question:

Did I change the variable, change the object it references, or change whether that object is still reachable?

That question can lead you to the answer faster than staring at the assignment alone.

#programming #webdevelopment #JavaScript #Software Development

There’s a particular kind of frustration every frontend developer knows.

You open an API response to find one value.

The JSON looks manageable at first. A few objects, some arrays, and a couple of nested properties.

Then you scroll.

And scroll.

And scroll some more.

The property you need is buried inside an object, which sits inside an array, which lives inside another object. You try searching for the key, but now you have multiple matches and no easy way to understand which one you actually need.

You could write a quick script. You could use an online formatter. Or you could keep digging through the response.

But I kept thinking: Why should finding one value inside JSON be this much work?

That question became the starting point for a project I built called JSON Explore.

The problem wasn’t JSON. It was working with JSON.

JSON is everywhere in frontend development.

API responses, configuration files, mock data, application state, logs, and test fixtures all use it in one form or another.

Working with small JSON objects is easy.

The experience changes when the data gets larger.

Imagine an API response containing hundreds of users. Each user has an address, preferences, roles, and activity history. Some properties appear in several places, and some objects are nested multiple levels deep.

You want to find every occurrence of id.

A basic text search might find the word, but it doesn’t necessarily tell you where each value belongs in the data structure.

You need context.

You want to know the exact path, inspect the surrounding object, and understand whether you’re looking at the right value.

That’s where I saw an opportunity to build something more useful than another JSON formatter.

I wanted one workspace, not another collection of tools

I started building JSON Explore around a simple idea:

Bring your JSON into one workspace and keep it there while you work with it.

Instead of treating formatting, searching, querying, and inspecting as separate jobs, I wanted them to work with the same document.

Here’s what that looks like in practice.

Consider this JSON:

{
  "users": [
    {
      "id": 101,
      "name": "Alice"
    },
    {
      "id": 102,
      "name": "Bob"
    }
  ],
  "admin": {
    "id": 101,
    "name": "Admin"
  }
}

Suppose I want to find every occurrence of id.

Searching for the word alone isn’t enough. I want to know which objects contain it and how to reach each one.

JSON Explore can show matching paths such as:

$.users[0].id
$.users[1].id
$.admin.id

Now I can see the structure behind the matches rather than treating the response as a wall of text.

That small difference makes a tool much more useful during everyday debugging.

Four problems I wanted to solve

1. Stop digging through nested objects

The Explore tool presents JSON as an interactive tree.

Instead of reading every line, you can navigate the structure, inspect nodes, and search for keys or values.

The goal is simple: spend less time finding the data and more time understanding it.

2. Find values by their paths

Sometimes you already know where the value should be.

For example, you might want to inspect:

users[].profile.email

Or find every id property, regardless of how deeply it is nested:

$..id

JSON Explore supports simple path expressions and a subset of JSONPath syntax.

You don’t need to manually expand every object to locate the data you’re interested in.

3. Understand the structure, not just the values

Sometimes the problem isn’t finding a specific property.

You want to understand the entire document.

How many nodes does it contain? Which data types appear most often? What are the common keys? How deeply nested does the structure get?

The Statistics tool helps answer those questions.

This becomes particularly useful when inspecting unfamiliar API responses or trying to understand a dataset before working with it.

4. Make large documents less painful

A tool can feel great with a small example and become frustrating with a real-world payload.

Large JSON documents can make interfaces sluggish if parsing and searching block the browser’s main thread or if the UI tries to render every node at once.

I wanted JSON Explore to handle this more thoughtfully.

For large documents, it uses a Web Worker to move expensive processing away from the main thread. The tree is virtualized so the interface doesn’t need to render every node simultaneously.

These techniques don’t make every operation instant, but they help keep the interface responsive as the document grows.

The decision I cared about most: keeping JSON in the browser

There was another consideration beyond convenience.

JSON can contain sensitive information.

A developer might be inspecting an internal API response, customer records, application configuration, or data copied from a debugging session.

Pasting that information into an online tool introduces a reasonable question:

Where does my data go after I paste it?

For JSON Explore’s core workflow, I designed processing to happen locally in the browser.

Parsing, searching, querying, formatting, and statistics don’t require uploading the document to a backend.

That means the tool can help inspect JSON without sending its contents to a server.

Of course, this doesn’t make every JSON document safe to handle carelessly. Your browser environment and any extensions or scripts you run still matter. But avoiding unnecessary uploads is an important design choice.

For a developer utility, privacy shouldn’t have to be an afterthought.

Building a developer tool taught me to think beyond features

It’s easy to approach a project by listing features.

Add a search box. Add a formatter. Add a query panel. Add a statistics view.

But a collection of features doesn’t automatically create a good developer experience.

The more important questions are:

• Can someone find what they need without understanding the entire interface?
• Can they switch between tasks without losing their current document?
• Does the tool remain usable with larger inputs?
• Can they inspect a result in context instead of receiving only a matching value?
• Can they work with potentially sensitive data without unnecessary uploads?

These questions changed how I thought about the project.

Performance isn’t just about making code execute faster. It’s also about keeping the interface usable.

Privacy isn’t just a statement on a landing page. It affects where processing happens.

And usability isn’t simply about having fewer clicks. It’s about helping developers understand their data with less effort.

Those principles are useful far beyond a JSON tool.

Try it with your own JSON

I built JSON Explore for a familiar problem, but I wanted it to be useful in real development work — not just in a demo.

You can paste JSON, upload a document, explore nested structures, search keys and values, run supported path queries, inspect statistics, and format valid JSON in the browser.

There’s no account to create before getting started.

If you regularly work with API responses or large JSON files, give it a try:

Open JSON Explore

I’d especially like to know where your current JSON workflow becomes frustrating.

Is it finding a deeply nested value? Comparing structures? Working with large responses? Or something else entirely?

I’m building this to solve practical developer problems, and that feedback can help determine what deserves attention next.

Because sometimes the most useful developer tools don’t come from inventing a completely new workflow.

They come from taking a familiar, frustrating task and asking a simple question:

Can this be easier?

You need to fetch some data from an API.

You write a few lines of JavaScript, wait for the response, and update the UI. Everything works.

Then you encounter another developer using .then(), while you're using async/await.

Suddenly, a simple question appears: Which approach is better?

If you’ve searched for this comparison, you’ve probably seen examples showing how async/await replaces Promise chains with cleaner-looking code.

But there’s something important those comparisons often miss.

async/await and Promises aren't competing solutions. They work together.

Understanding that difference makes it much easier to choose the right approach.

First, let’s understand what a Promise actually does

Imagine you’re building a product page.

The browser needs to request product details from an API. That request takes time, so JavaScript can’t immediately provide the final response.

This is where a Promise comes in.

A Promise represents the eventual result of an asynchronous operation. It can be pending, fulfilled, or rejected.

Here’s a simple example:

fetch("/api/products")
  .then((response) => response.json())
  .then((products) => {
    console.log(products);
  })
  .catch((error) => {
    console.error("Something went wrong:", error);
  });

Each .then() handles a successful step in the chain, while .catch() handles a rejection that reaches it.

The browser doesn’t need to stop everything while the request is in progress. Other JavaScript work can continue.

That’s the real value of Promises: they give us a way to work with results that aren’t available immediately.

But as the number of dependent steps grows, Promise chains can become harder to follow.

Why async/await feels easier to read

Now imagine you need to fetch a user, read their permissions, and then load their dashboard.

With Promise chains, you might write:

fetchUser()
  .then((user) => fetchPermissions(user.id))
  .then((permissions) => fetchDashboard(permissions))
  .then((dashboard) => console.log(dashboard))
  .catch((error) => console.error(error));

This is perfectly valid JavaScript.

However, when several steps depend on previous results, some developers find it harder to follow the flow.

Here’s the same sequence using async/await:

async function loadDashboard() {
  try {
    const user = await fetchUser();
    const permissions = await fetchPermissions(user.id);
    const dashboard = await fetchDashboard(permissions);
    console.log(dashboard);
  } catch (error) {
    console.error(error);
  }
}

Notice what changed.

The code reads more like a sequence of instructions. Each await makes the next step wait for the previous Promise to settle successfully.

You can see the dependency between operations without mentally tracing multiple .then() callbacks.

That’s the main advantage of async/await: it makes many asynchronous workflows easier to read and maintain.

But it doesn’t replace the underlying Promise mechanism.

Here’s the difference most developers miss

Look at this function:

async function getMessage() {
  return "Hello, JavaScript!";
}

It looks like the function returns a string.

It doesn’t. An async function always returns a Promise.

You can observe that behavior here:

getMessage().then((message) => {
  console.log(message);
});

The Promise fulfills with "Hello, JavaScript!".

Even if you return an ordinary value, JavaScript wraps that value in a fulfilled Promise. If the function throws an error, its returned Promise rejects.

Now consider await:

async function showMessage() {
  const message = await getMessage();
  console.log(message);
}

await lets you work with the fulfilled value rather than explicitly attaching a .then() callback.

It doesn’t eliminate Promises. It changes how you write code that consumes them.

This distinction matters when you pass asynchronous functions to other functions, return values from them, or combine multiple requests.

When should you use async/await?

For most everyday asynchronous workflows, async/await is an excellent default.

Consider a form submission that needs to save a user’s profile.

async function saveProfile(profile) {
  try {
    const response = await fetch("/api/profile", {
      method: "POST",
      headers: {
        "Content-Type": "application/json",
      },
      body: JSON.stringify(profile),
    });
  if (!response.ok) {
      throw new Error("Failed to save profile");
    }
    const result = await response.json();
    console.log("Profile saved:", result);
  } catch (error) {
    console.error("Could not save profile:", error);
  }
}

The flow is straightforward:

1. Send the request.
2. Check whether the HTTP response indicates success.
3. Read the response body.
4. Handle errors.

There’s another detail worth noticing: fetch() doesn't reject just because the server returns an HTTP error such as 404 or 500.

That’s why the example checks response.ok explicitly.

This approach is useful for API requests, form submissions, authentication flows, and other operations where one step depends on another.

It also works naturally with try/catch, which many developers find easier to understand than rejection handlers spread across a long chain.

But async/await can accidentally make your code slower

Here’s where the comparison gets interesting.

Suppose a dashboard needs to load the user’s profile and their notifications.

These two requests don’t depend on each other.

You might write:

const profile = await fetchProfile();
const notifications = await fetchNotifications();

This starts the second request only after the first one finishes.

If both requests could run independently, you’ve introduced unnecessary waiting.

The better approach is to start both operations before waiting for their results:

const [profile, notifications] = await Promise.all([
  fetchProfile(),
  fetchNotifications(),
]);

Now both operations can be in progress at the same time.

Promise.all() fulfills when all its input Promises fulfill. If any input Promise rejects, the combined Promise rejects.

This is one of the most useful patterns to remember when building frontend applications.

The problem wasn’t async/await. The problem was how the Promises were being coordinated.

There’s an important caveat: Promise.all() doesn't cancel the other operations automatically when one rejects. Those operations may continue running.

Use it when you need all results and the operations can safely run independently.

When Promises are the better tool

So, should you stop using .then()?

Not at all.

Promises are especially useful when you’re coordinating asynchronous operations or composing results without needing a full sequential workflow.

For example, imagine you need to load three independent sections of a page:

const requests = [
  fetchProfile(),
  fetchProducts(),
  fetchNotifications(),
];
Promise.all(requests)
  .then(([profile, products, notifications]) => {
    renderDashboard(profile, products, notifications);
  })
  .catch((error) => {
    console.error("Dashboard loading failed:", error);
  });

You could write this using async/await too. Neither syntax has exclusive access to Promise.all().

The point is that Promises provide the coordination tools, while async/await provides another way to express the flow.

There are also cases where .then() is a natural fit, such as transforming a result in a short expression or working with an API that already returns a Promise chain.

Choose the form that makes the intent easiest to understand.

One more mistake: assuming await handles every error

Consider this example:

async function loadProducts() {
  const response = await fetch("/api/products");
  return response.json();
}

What happens if the request fails because of a network problem?

The function’s returned Promise rejects.

What happens if the server responds with HTTP 500?

The fetch() Promise can still fulfill with a Response object. Without checking response.ok, your code might try to process an error response as if it were successful data.

And what if the response body contains invalid JSON?

Reading it with response.json() can reject too.

Using await doesn't automatically make these errors disappear.

You still need to decide how your application should respond: show an error message, retry a request, use cached data, or let a higher-level error handler deal with it.

Good asynchronous code isn’t just about choosing readable syntax. It’s about making failure behavior explicit.

My rule of thumb for real projects

When deciding between the two, I use a simple mental model:

• Use async/await when you're describing a sequence of dependent operations.
• Use Promise.all() when independent operations can run concurrently and you need all their results.
• Use Promise.allSettled() when you want to inspect every operation's outcome, even if some fail.
• Use .then() and .catch() when a short Promise chain expresses the intent clearly.

These aren’t strict rules. You can combine all these techniques in the same function.

For example, you can use async/await for the main workflow and Promise.all() for parallel requests inside it.

The goal isn’t to follow one syntax everywhere. It’s to make the relationships between asynchronous operations obvious.

The takeaway

The next time you compare async/await with Promises, don't ask which one is universally better.

Ask two more useful questions:

How should these operations be coordinated? And which syntax makes that intention easiest to understand?

Promises give JavaScript a way to represent and coordinate future results. async/await makes those results easier to work with in many situations.

Once you understand that relationship, choosing between them becomes much less confusing.

And your asynchronous code becomes easier to reason about — not because you picked the trendier syntax, but because you understood what your code actually needs to do.

If you’ve worked with JavaScript for a while, you’ve probably seen something like this:

const user = {
  name: "Aditya",
  sayName() {
    console.log(this.name);
  }
};
user.sayName();

Easy enough.

It prints:

Aditya

Then you make one small change:

const sayName = user.sayName;

sayName();

And suddenly:

undefined

Same function.

Same this.name.

Same JavaScript.

So what changed?

The way the function was called.

And this is the part of this that causes most of the confusion.

this Doesn't Mean "The Object Where the Function Lives"

A common assumption is:

“this refers to the object that contains the function."

That works in some situations, but it’s not the actual rule.

Consider:

const user = {
  name: "Aditya",
  greet() {
    console.log(this.name);
  }
};
user.greet();

Here, this refers to user.

Why?

Because the function is called like this:

user.greet();

The object before the dot becomes the receiver of the method call.

So:

user.greet();

means the function is called with user as its this.

But look at this:

const greet = user.greet;
greet();

Now there is no user. before the function call.

The function has been detached from the object.

And that’s where things start getting interesting.

The Most Useful Rule for this

For regular functions, start with one question:

How was this function called?

Not:

Where was it created?

Not:

Which object contains it?

Not:

What variable name does it have?

Look at the call.

Called as a method

user.greet();

this → user

Called as a standalone function

greet();

this depends on the execution mode and environment.

In strict mode:

function greet() {
  console.log(this);
}
greet();

this is:

undefined

That’s why simply memorizing “this means the current object" eventually breaks down.

But Then Why Does This Work?

Let’s make the example slightly more realistic.

const counter = {
  count: 0,
  increment() {
    this.count++;
  }
};
counter.increment();
console.log(counter.count);

The result is:

1

When JavaScript evaluates:

counter.increment();

the call is associated with counter.

So inside increment():

this === counter

And therefore:

this.count++;

is effectively modifying:

counter.count++;

This is why object methods using this feel natural.

Now Detach the Function

Here’s the bug that often surprises developers:

const counter = {
  count: 0,
  increment() {
    this.count++;
  }
};
const increment = counter.increment;
increment();

It looks like we’re still calling counter.increment().

But we’re not.

We’re calling:

increment();

The relationship with counter is gone.

This is one of the most important things to understand about JavaScript’s this:

Assigning a method to another variable does not preserve its original this.

The function itself didn’t change.

The call changed.

And Then Arrow Functions Change the Rules

Just when regular functions start making sense, arrow functions appear.

Consider:

const user = {
  name: "Aditya",
  greet: () => {
    console.log(this.name);
  }
};
user.greet();

You might expect:

Aditya

But you shouldn’t.

Arrow functions don’t create their own this.

Instead, they capture this from their surrounding lexical scope.

That’s a completely different behavior from regular functions.

Regular Function vs Arrow Function

Compare these:

const user = {
  name: "Aditya",
  regular() {
    console.log(this.name);
  },
  arrow: () => {
    console.log(this.name);
  }
};
user.regular();
user.arrow();

The regular function gets its this from the call:

user.regular();

The arrow function does not.

Its this comes from the surrounding scope where the arrow function was created.

This is why arrow functions are often useful inside callbacks.

The Callback Problem

Imagine:

const user = {
  name: "Aditya",
  greet() {
    setTimeout(function () {
      console.log(this.name);
    }, 1000);
  }
};
user.greet();

You might expect:

Aditya

But the regular function passed to setTimeout doesn't automatically inherit the this from greet().

This is where an arrow function can help:

const user = {
  name: "Aditya",
  greet() {
    setTimeout(() => {
      console.log(this.name);
    }, 1000);
  }
};
user.greet();

Now the arrow function captures the surrounding this.

So the this inside the callback refers to the same this from greet().

This is one of the most practical reasons you’ll see arrow functions everywhere in frontend code.

What About call(), apply(), and bind()?

JavaScript also gives you explicit control over this.

For example:

function greet() {
  console.log(`Hello ${this.name}`);
}
const user = {
  name: "Aditya"
};
greet.call(user);

Now you’re explicitly saying:

Call greet with user as this.

And JavaScript does exactly that.

You can also use bind():

const boundGreet = greet.bind(user);
boundGreet();

bind() creates a new function whose this is bound to user.

This is useful when you need to pass a method around without losing its context.

So Which Rule Should You Remember?

Instead of memorizing a huge list of special cases, start with this mental model:

1. Regular function called as an object method

user.greet();

this → user

2. Regular function called by itself

greet();

this depends on the execution mode.

In strict mode, it’s undefined.

3. Arrow function

const greet = () => {};

Arrow functions don’t create their own this.

They use the surrounding this.

4. Explicit binding

greet.call(user);
greet.apply(user);
greet.bind(user);

You explicitly control the this value.

A Simple Way to Debug this

When you encounter a confusing this, don't immediately search for a complicated explanation.

Instead, ask these questions:

1. Is this a regular function or an arrow function?

If it’s an arrow function, look at its surrounding scope.

2. How is the function being called?

Look at the actual call site.

user.method();

is different from:

const method = user.method;
method();

3. Is call(), apply(), or bind() involved?

These can explicitly control this.

4. Is the function running as a callback?

Callbacks are a common place where this gets misunderstood.

This simple checklist solves a surprising number of this bugs.

The Mistake Developers Often Make

The biggest mistake is trying to understand this by looking only at the function definition.

For example:

function greet() {
  console.log(this);
}

Looking at this function alone doesn’t tell you what this will be.

You need to look at how greet is called.

user.greet();

is one situation.

greet();

is another.

greet.call(user);

is another.

The function can be the same.

The this value can be different.

That’s the key.

The Mental Model That Makes this Easier

If there’s one idea worth remembering from this article, make it this:

For regular functions, this is primarily determined by how the function is called.

And for arrow functions:

this is inherited from the surrounding scope.

Once you understand those two ideas, a lot of JavaScript behavior stops looking random.

You no longer need to ask:

“Why is JavaScript changing this?"

Instead, ask:

“How was this function called?”

That question will usually lead you to the answer.

JavaScript’s this isn't really unpredictable.

It’s contextual.

And once you start looking at the call instead of the function itself, the behavior becomes much easier to reason about.

There’s a JavaScript concept that confuses almost every developer at some point.

“Closures”

The explanations usually make them sound much more complicated than they actually are.

You hear things like lexical environment, execution context, scope chain, and persistent references.

And suddenly a simple JavaScript function sounds like a compiler design lecture.

But here’s the interesting part:

You probably use closures already.

Event handlers.

setTimeout.

Callbacks.

Factory functions.

React hooks.

Even some of the small utility functions you write every day.

So instead of starting with a definition, let’s look at what actually happens.

Start with this tiny example

function createCounter() {
  let count = 0;
  
  return function () {
    count++;
    return count;
  };
}
const counter = createCounter();
console.log(counter()); // 1
console.log(counter()); // 2
console.log(counter()); // 3

At first glance, something strange is happening.

createCounter() has already finished running.

So where is count?

Why doesn’t it disappear?

And how does the returned function still know what count is?

That’s a closure.

The function remembers

When createCounter() runs, it creates the variable:

let count = 0;

Then it returns another function.

That function uses count:

return function () {
  count++;
  return count;
};

Here’s the important part:

The returned function doesn’t just remember the code inside itself.

It also keeps access to the variables that were available in the scope where it was created.

So even after createCounter() finishes, the returned function can still access count.

That’s the key idea behind closures.

“A closure is a function together with access to the variables from the scope where that function was created.”

That’s it.

The concept sounds much scarier than the actual behavior.

But why doesn’t count disappear?

This is where closures become easier to understand.

Normally, you might think:

function test() {
  let message = "Hello";
}

test();

After test() finishes, you can't access message.

console.log(message); // Error

And that’s correct.

message is local to test().

But now look at this:

function test() {
  let message = "Hello";
  return function () {
    console.log(message);
  };
}

const sayHello = test();

sayHello(); // Hello

The outer function finished.

But the inner function still needs message.

JavaScript keeps the necessary variable accessible to that function.

That’s the important difference.

Closures are not just about counters

The counter example is popular because it’s easy to understand.

But closures become much more interesting when you see where they appear in everyday frontend code.

For example:

function greetUser(name) {
  return function () {
    console.log(`Hello, ${name}`);
  };
}

const greetAditya = greetUser("Aditya");

greetAditya();

The returned function remembers name.

You can create multiple independent functions:

const greetAditya = greetUser("Aditya");
const greetRahul = greetUser("Rahul");

greetAditya(); // Hello, Aditya
greetRahul();  // Hello, Rahul

Each function has access to its own surrounding state.

And that’s where closures become genuinely useful.

You probably use closures with event handlers

Consider a button:

function setupButton(buttonId, message) {
  const button = document.getElementById(buttonId);
  button.addEventListener("click", () => {
    console.log(message);
  });
}
setupButton("saveButton", "Saved successfully!");

The click handler uses message.

But message belongs to setupButton().

Once setupButton() finishes, why can the click handler still access it?

Closure.

The event handler was created inside setupButton(), so it retains access to the variables from that surrounding scope.

This pattern appears everywhere in frontend development.

And setTimeout does the same thing

Here’s another example:

function showMessage(message) {
  setTimeout(() => {
    console.log(message);
  }, 1000);
}

showMessage("Hello!");

One second later, the callback still knows what message was.

Again:

Closure.

The callback remembers the surrounding variable.

This is one reason closures are so important in JavaScript.

You don’t usually write:

“I’m going to create a closure now.”

You simply write a callback.

JavaScript creates the closure as part of how that function works.

Here’s where things get really useful

Closures can also help you create private state.

JavaScript doesn’t require you to expose every variable.

For example:

function createUser() {
  let points = 0;
  return {
      addPoint() {
        points++;
      },
      getPoints() {
        return points;
      }
    };
}

const user = createUser();
user.addPoint();
user.addPoint();

console.log(user.getPoints()); // 2

Notice what you cannot do:

console.log(user.points);

There is no public points property.

But the returned methods can still access it because they close over the variable.

This gives you a simple form of encapsulation.

The same idea appears in React

If you’ve worked with React, closures aren’t some strange concept sitting outside your normal code.

They’re already part of it.

For example:

function Counter() {
  const [count, setCount] = useState(0);
  
  function handleClick() {
      console.log(count);
    }
  return (
    <button onClick={handleClick}>
      {count}
    </button>
  );
}

handleClick can access count from the surrounding function.

That’s closure behavior.

React adds its own rendering and state model on top of this, so React’s behavior can involve more details than this simple example suggests.

But the underlying JavaScript concept is still there:

A function can access variables from the scope where it was created.

Understanding this makes a lot of JavaScript and React behavior feel less mysterious.

But closures can also cause bugs

Here’s the part developers sometimes learn the hard way.

Closures keep references to variables that a function still needs.

That can be useful.

But if you accidentally keep functions around longer than necessary, you can also keep related data reachable for longer than you intended.

For example, imagine creating a large object:

function createHandler() {
  const largeData = createLargeObject();

  return function () {
      console.log(largeData);
    };
}
const handler = createHandler();

As long as handler remains reachable and needs largeData, that data can remain reachable too.

This doesn’t mean:

“Closures cause memory leaks.”

That’s an oversimplification.

The real issue is unnecessary references that remain alive longer than needed.

Closures are just one mechanism that can contribute to that situation.

One more closure example you should understand

Look at this:

function createMultiplier(multiplier) {
  return function (number) {
    return number * multiplier;
  };
}

const double = createMultiplier(2);
const triple = createMultiplier(3);
console.log(double(5)); // 10
console.log(triple(5)); // 15

Something interesting happened here.

createMultiplier() created two functions.

But each function remembers a different value.

double remembers:

multiplier = 2

triple remembers:

multiplier = 3

That’s the power of closures.

You can create functions that carry their own surrounding state.

So when should you actually care about closures?

You don’t need to consciously think about closures every time you write a callback.

But understanding them becomes valuable when you’re working with:

• Event handlers
• setTimeout and setInterval
• Callbacks
• Factory functions
• Private state
• Function generators
• Memoization
• Async code
• React components and callbacks
• State that needs to survive beyond a function call

When something behaves like:

“How does this function still know that value?”

Closures are often part of the answer.

The mental model I use

Don’t think about closures as some special JavaScript feature you need to memorise.

Think about them like this:

A function remembers the environment it was created in.

For example:

function outer() {
  const name = "JavaScript";

    return function inner() {
      console.log(name);
    };
}

inner() was born inside outer().

So it can still access the variables that were available around it.

That’s the mental model.

Not:

“Closures are complicated lexical environments.”

But:

“This function can remember where it came from.”

Once you think about closures this way, a lot of JavaScript code becomes easier to reason about.

The important takeaway

Closures aren’t something you occasionally use when studying advanced JavaScript.

They’re already hiding inside the code you write.

That event handler?

Closure.

That timer callback?

Closure.

That factory function?

Closure.

That function that somehow still remembers a variable after the outer function finished?

Definitely closure.

The most useful thing to remember isn’t the textbook definition.

It’s this:

A function can keep access to variables from the scope where it was created, even after that outer function has finished running.

Once that clicks, closures stop feeling like magic.

They become one of the most natural parts of JavaScript.

When you write HTML, you create the initial structure of a webpage. For example, your document might contain a simple heading:

<h1>Hello</h1>

After the browser loads that page, JavaScript can find the heading and change its text:

document.querySelector("h1").textContent = "Hello World";

The page now displays:

<h1>Hello World</h1>

At first, this can make it seem as though JavaScript changed the HTML file itself. But that is not what happened. The original HTML file on the server still contains <h1>Hello</h1>. JavaScript changed the browser's live representation of the page: the Document Object Model, or DOM. Understanding the difference between the HTML source and the DOM makes many JavaScript behaviours much easier to understand.

HTML is a document. The DOM is a live representation.

HTML is the markup you write.

For example:

<body>
  <h1>Hello</h1>
  <button>Click me</button>
</body>

When the browser loads that document, it parses the HTML and creates a structure in memory.

That structure is the Document Object Model, or DOM.

You can think of it roughly like this:

HTML
 │
 │ browser parses
 ▼
DOM
 │
 ├── body
 │    ├── h1
 │    └── button

The important part is that the DOM is not simply a copy of your HTML text.

It is a structured, programmable representation of the document.

That’s what JavaScript interacts with.

So what does JavaScript actually change?

Consider this:

<h1 id="title">Hello</h1>

Then:

const title = document.querySelector("#title");
title.textContent = "Welcome";

The JavaScript finds the DOM element and changes its text.

The DOM now represents:

<h1 id="title">Welcome</h1>

But your original HTML source file hasn’t suddenly been rewritten.

If the HTML came from a server or a static file, that source still contains:

<h1 id="title">Hello</h1>

This distinction is small, but extremely important.

Changing the DOM is not the same thing as rewriting the HTML source.

Here’s an easy way to see the difference

Open a webpage.

Then change something using JavaScript:

document.querySelector("h1").textContent = "Changed!";

The page changes immediately.

Now compare:

DOM

<h1>Changed!</h1>

with the original HTML source:

<h1>Hello</h1>

They can now be different.

That’s because the browser is working with its live DOM representation.

The DOM is more than what you originally wrote

Here’s where things get even more interesting.

Suppose your HTML contains:

<ul id="users">
  <li>John</li>
</ul>

JavaScript can add another element:

const list = document.querySelector("#users");
const item = document.createElement("li");
item.textContent = "Sarah";
list.appendChild(item);

The browser’s DOM now contains:

ul
├── li "John"
└── li "Sarah"

But you never added Sarah to the original HTML file.

The browser doesn’t need you to rewrite the source document.

JavaScript modified the live DOM.

This is one of the fundamental things behind interactive websites.

The DOM is a tree

The word Object Model can sound more complicated than it really is.

At its simplest, think of the DOM as a tree of nodes.

Given:

<main>
  <h1>Hello</h1>
  <p>Welcome!</p>
</main>

The browser creates a structure roughly like:

Document
   │
   └── main
       ├── h1
       │    └── "Hello"
       │
       └── p
            └── "Welcome!"

That’s why JavaScript can navigate relationships such as:

element.parentElement
element.children
element.nextElementSibling

You’re not searching through a plain text file.

You’re working with a structured tree.

And the DOM can change

This is another important difference.

HTML source is generally the document you started with.

The DOM is live.

You can create elements:

const button = document.createElement("button");

Change attributes:

button.setAttribute("disabled", "");

Change content:

button.textContent = "Loading...";

And insert the element:

document.body.append(button);

The DOM changes as your application runs.

This is why we can build interactive interfaces without repeatedly downloading a completely new HTML document.

But there is one more thing developers often confuse

You might inspect a page and see HTML that wasn’t present in the original source.

For example, JavaScript might create:

<div class="notification">
  Saved successfully
</div>

You didn’t write that element in the original HTML.

But browser developer tools can show it in the Elements panel.

That’s the DOM representation you’re looking at.

If you view the original page source, you may not find that element there.

So:

View Source and Inspect Element are not necessarily showing you the same thing.

One important reason is that JavaScript can modify the DOM after the browser loads the original HTML.

Why does this matter for frontend developers?

Because a lot of frontend behaviour becomes easier to understand once you stop thinking:

“JavaScript changes the HTML.”

Instead, think:

“JavaScript changes the DOM.”

That mental model explains code like:

element.classList.add("active");
element.remove();
element.textContent = "Loading...";
element.append(newElement);

All of these operate on the live document structure.

The browser can then use that changed DOM as part of the process of updating what you see on the screen.

What about React?

This distinction becomes even more useful when working with React.

You might write:

return <h1>Hello</h1>;

But React doesn’t mean your JSX is literally the DOM.

JSX is syntax that describes UI.

React manages how that description should be reflected in the actual DOM.

That’s one reason it helps to understand the DOM before learning too much about framework abstractions.

Otherwise, concepts like rendering, reconciliation, refs, and DOM updates can feel unnecessarily mysterious.

You don’t need to know every internal detail.

Just remember:

HTML
  ↓
Browser parses it
  ↓
DOM
  ↓
JavaScript can modify it
  ↓
Browser updates the rendered page

Frameworks add another layer on top of this process, but the browser’s DOM is still there.

One common mistake

Developers sometimes assume that changing the DOM means they’ve changed the original HTML permanently.

They haven’t.

For example:

document.body.innerHTML = "<h1>New page</h1>";

This can replace the current document structure represented by the DOM.

But it doesn’t rewrite the HTML file on your server.

Refresh the page, and the browser loads the document again from its source.

Unless you’ve persisted the change somewhere and generated different HTML, the original document comes back.

That’s an important distinction between runtime state and source content.

The mental model to remember

Don’t think of this:

HTML = DOM

Think of it more like:

HTML
 │
 │ parsed by browser
 ▼
DOM
 │
 │ modified by JavaScript
 ▼
Updated DOM
 │
 │ used during rendering
 ▼
What the user sees

The HTML is the document you provide.

The DOM is the browser’s live, structured representation of that document.

JavaScript interacts with the DOM.

And the browser uses the current document state when rendering the page.

Final takeaway

The DOM isn’t your HTML file.

HTML is markup.

The DOM is the browser’s live object-based representation of the document.

Once you understand that, several things become much clearer:

• Why JavaScript can add and remove elements
• Why querySelector() works
• Why textContent changes what you see
• Why DevTools can show elements you never wrote in the original HTML
• Why the DOM can change while the original source stays the same
• Why frameworks like React still ultimately interact with the DOM

The most useful mental shift is simple:

You write HTML. The browser builds the DOM. JavaScript changes the DOM.

Once that clicks, the DOM stops feeling like some mysterious JavaScript API and starts looking like what it really is:

the browser’s live representation of your page.

When JavaScript has too much work to do, the answer isn’t always more optimization. Sometimes, you need to move the work somewhere else.

Imagine this.

A user clicks a button.

The button changes to “Processing…”

Everything looks correct.

But then the entire page stops responding.

The animation freezes.
Scrolling feels stuck.
Clicks don’t work.

Even though the browser hasn’t crashed.

This usually happens because JavaScript is doing too much work on the main thread.

And this is where Web Workers become interesting.

Instead of making the browser’s main JavaScript thread do everything, you can move certain heavy computations into a separate worker.

The UI gets room to breathe while the work continues.

The problem: JavaScript can still block everything

In the previous article, we looked at an important browser idea:

JavaScript runs on a main thread, but the browser itself does much more than just run JavaScript.

That doesn’t mean the main thread can never become a bottleneck.

It absolutely can.

Consider this:

function calculate() {
  let total = 0;
  for (let i = 0; i < 1_000_000_000; i++) {
      total += i;
    }
    return total;
  }
calculate();

The code is valid.

The browser can execute it.

But while this loop is running, the main JavaScript thread is busy.

And if the main thread is busy with a long-running task, it can’t immediately handle other work that depends on it.

That’s when your UI starts feeling frozen.

Why does the UI freeze?

Here’s the part that is easy to miss.

Your button click, JavaScript execution, user interactions, and many tasks related to updating the page all compete for time on the browser’s main thread.

Now imagine this sequence:

User clicks button
       ↓
JavaScript starts heavy calculation
       ↓
Main thread stays busy
       ↓
UI work has to wait
       ↓
Page feels frozen

The browser isn’t necessarily broken.

Your code is simply occupying the thread for too long.

This is why a function that looks completely harmless can become a serious performance problem when the amount of data or computation grows.

But what if the heavy work didn’t run there?

This is the basic idea behind a Web Worker.

A Worker gives JavaScript another execution context that can run independently of the page’s main JavaScript execution.

Instead of doing this:

MAIN THREAD
     │
     ├── UI
     ├── Events
     ├── JavaScript
     └── Heavy calculation  ← problem

You can do this:

MAIN THREAD                  WORKER
     │                         │
     ├── UI                    ├── Heavy calculation
     ├── User input            ├── Data processing
     └── Page logic            └── Result
             │                  │
             └── messages ─────┘

The important word here is messages.

A Worker doesn’t magically share everything with your page.

You communicate with it.

Your first Web Worker

Let’s move the expensive calculation from the earlier example into a Worker.

Main JavaScript

const worker = new Worker("worker.js");

worker.postMessage(1_000_000_000);

worker.onmessage = (event) => {
  console.log("Result:", event.data);
};

And the Worker:

worker.js

self.onmessage = (event) => {
  let total = 0;
  for (let i = 0; i < event.data; i++) {
    total += i;
  }
  self.postMessage(total);
};

That’s the basic Worker pattern.

The main thread sends data:

worker.postMessage(...)

The Worker receives it:

self.onmessage = (...)

The Worker does the work.

Then it sends the result back:

self.postMessage(...)

And the main thread receives it:

worker.onmessage = (...)

What’s actually happening?

Think of the Worker as a separate JavaScript worker that you give a job to.

The main thread says:

“Here’s the data. You handle this.”

The Worker performs the calculation.

When it’s finished, it sends a message back.

So instead of:

Main thread
     ↓
Heavy calculation
     ↓
UI waits

you get:

Main thread ──→ Worker
     │             │
     │             └── Heavy calculation
     │
     └── continues handling the page

That’s the important difference.

The goal isn’t necessarily to make the calculation itself faster.

The goal is to prevent that calculation from competing with the main thread’s UI work.

Workers communicate through messages

One of the biggest differences between normal JavaScript and Workers is how they communicate.

A Worker doesn’t simply reach into your page and change the DOM.

For example, this won’t work inside a Worker:

document.querySelector("#result");

A Worker doesn’t have direct access to the page’s DOM.

Instead, you communicate using messages.

worker.postMessage(data);

And receive messages with:

worker.onmessage = (event) => {
  console.log(event.data);
};

This separation is actually useful.

It forces you to make the data flow explicit.

Main Thread
     │
     │ postMessage()
     ▼
  Worker
     │
     │ postMessage()
     ▼
Main Thread

For many applications, that’s exactly the boundary you want.

The old approach vs the better approach

❌ The problematic approach

Imagine processing a huge dataset directly inside a button handler:

button.addEventListener("click", () => {
  const result = processHugeDataset(data);
  renderResult(result);
});

If processHugeDataset() takes a long time, the main thread is occupied while it runs.

The UI may become unresponsive.

✅ The better approach

Move the expensive computation into a Worker:

const worker = new Worker("worker.js");

button.addEventListener("click", () => {
  worker.postMessage(data);
});

worker.onmessage = (event) => {
  renderResult(event.data);
};

Now the expensive processing happens in the Worker.

The main thread can continue handling the page while it waits for the result.

So what should actually go into a Worker?

This is where developers sometimes overuse Workers.

You don’t need a Worker for every function.

A Worker becomes interesting when the task is CPU-heavy enough to compete with the main thread.

Good candidates include:

• Processing large datasets
• Complex calculations
• Large JSON transformations
• Parsing large files
• Image processing
• Audio or video processing
• Computational algorithms
• Data compression or transformation
• Some cryptographic or mathematical operations
• Syntax highlighting or other expensive text processing

The common pattern is simple:

A lot of computation + little need for direct DOM access = good Worker candidate.

When you probably don’t need one

Don’t create a Worker just because you can.

For a tiny operation like:

const total = price * quantity;

a Worker would add unnecessary complexity.

There is communication overhead, Worker startup cost, and another piece of code to manage.

For small tasks, normal JavaScript is usually the better choice.

The question shouldn’t be:

“Can I use a Worker?”

It should be:

“Is this work heavy enough that keeping it on the main thread hurts the user experience?”

That’s a much better question.

Workers aren’t just about performance

There’s another benefit that is easy to overlook.

Workers create a boundary.

Your UI code can focus on:

Input
↓
State
↓
Display

while the Worker focuses on:

Input data
↓
Processing
↓
Output data

That separation can make expensive processing easier to isolate and reason about.

But there is a trade-off.

You now have asynchronous communication, Worker lifecycle management, error handling, and data transfer to think about.

So Workers solve one problem while introducing some additional complexity.

That’s normal.

Good engineering isn’t about eliminating complexity.

It’s about putting complexity where it actually helps.

There isn’t just one type of Worker

When developers hear “Web Worker”, they often imagine one single API.

There are several Worker-related APIs, but they serve different purposes.

TypeMain purposeDedicated WorkerRun JavaScript work for a particular page/contextShared WorkerAllow multiple browsing contexts to communicate with a shared WorkerService WorkerHandle capabilities such as network interception, caching, and offline experiences

For heavy CPU-bound work, the Dedicated Worker is usually the concept you want to understand first.

A Service Worker is not simply a replacement for a Dedicated Worker.

They solve different problems.

A few production details matter

The basic example is small, but real applications need a little more care.

Handle errors

worker.onerror = (error) => {
  console.error("Worker error:", error);
};

Stop a Worker when you no longer need it

worker.terminate();

This can be useful when a Worker is temporary rather than something your application keeps around.

Be careful with large data

Messages between the main thread and a Worker involve data transfer.

Many JavaScript values are handled through the browser’s structured cloning mechanism.

For certain large binary datasets, Transferable objects can be used to transfer ownership rather than copying the data.

You don’t need to understand every detail on day one.

Just remember:

Moving computation off the main thread doesn’t mean moving data is free.

What about React?

React doesn’t change the underlying browser behavior.

If a React event handler performs a huge synchronous calculation:

function handleClick() {
  const result = expensiveCalculation();
  setResult(result);
}

that calculation still runs on the JavaScript execution context handling the page.

React can’t magically make CPU-heavy JavaScript disappear.

A Worker can be used as the computation layer instead:

React UI
   │
   │ send data
   ▼
Web Worker
   │
   │ process data
   ▼
React UI

This can be especially useful in applications where users interact with large datasets, editors, visualizations, or other computation-heavy interfaces.

The important part is not React.

It’s understanding which thread is doing the expensive work.

The biggest mistake: using Workers for everything

Workers are useful.

But they aren’t a performance button.

If your application is slow because of unnecessary rendering, excessive network requests, large assets, inefficient React updates, or poorly structured code, adding a Worker may not solve the actual problem.

First identify the bottleneck.

Then decide whether moving computation off the main thread makes sense.

A useful mental checklist is:

1. Is the task CPU-heavy?
2. Does it run long enough to affect responsiveness?
3. Does it need direct DOM access?
4. Can the input and output be passed through messages?
5. Is the added Worker complexity worth it?

If the answers line up, a Worker may be a very good fit.

The mental model I want you to remember

You don’t need to memorize the entire Worker API.

Remember this:

MAIN THREAD
     │
     │ "Here is the work."
     ▼
  WORKER
     │
     │ "Here is the result."
     ▼
MAIN THREAD

The main thread handles the page.

The Worker handles expensive JavaScript that can be isolated from the UI.

That simple separation can make the difference between an interface that feels frozen and one that stays responsive while the work happens.

One important distinction

There are two different performance problems developers often mix together.

Problem 1: JavaScript is doing too much work.

You may need to optimize the algorithm or reduce the amount of work.

Problem 2: The work is legitimately expensive, but it doesn’t need to block the UI.

That’s where a Worker becomes particularly useful.

A Worker doesn’t make bad code good.

It gives expensive code somewhere else to run.

And that’s a much more useful way to think about it.

Final takeaway

The browser gives your JavaScript a main thread that is critical to the responsiveness of your application.

If you occupy it with a huge calculation, the UI can suffer.

Web Workers give you another place to run JavaScript work without requiring that computation to happen on the page’s main execution thread.

The pattern is surprisingly simple:

Send work → Worker processes it → Receive the result.

You don’t need Workers everywhere.

You need them when expensive computation doesn’t belong in the same place as your UI work.

The next time a page feels frozen during a large calculation, don’t only ask:

“How can I make this function faster?”

Also ask:

“Does this function need to run on the main thread at all?”

JavaScript is single-threaded.

You have probably heard that sentence hundreds of times.

But then you open a modern website and somehow all of this happens together:

A network request is running.

An image is loading.

A CSS animation is moving.

The browser is responding to clicks.

The page is rendering.

And your JavaScript is still executing.

So what is actually going on?

If JavaScript has one thread, who is doing all the other work?

The answer is one of the most useful things to understand about how browsers work:

JavaScript is not the browser.

JavaScript has a main thread

When frontend developers say JavaScript is single-threaded, they’re usually talking about the JavaScript execution model.

Your JavaScript code runs on a main JavaScript thread.

For example:

console.log("One");
console.log("Two");
console.log("Three");

These statements execute one after another.

JavaScript doesn’t normally execute these three pieces of code simultaneously on the same thread.

There is one call stack.

One piece of JavaScript runs at a time.

That’s what single-threaded means in this context.

But here’s where things get interesting.

The browser has responsibilities that go far beyond executing JavaScript.

The browser has more jobs than running JavaScript

A browser is a much larger system.

It has to deal with things like:

• Network requests
• Timers
• User input
• Rendering
• Image decoding
• Audio
• Video
• Storage
• Layout
• Painting
• Compositing
• Other browser and operating-system work

Your JavaScript isn’t personally performing all of these operations.

Instead, JavaScript can ask the browser to perform certain work.

For example:

fetch("/api/users");

Your JavaScript starts the request.

But JavaScript isn’t sitting there manually opening a network connection and moving every byte from the server.

The browser and its underlying systems handle that work.

When the result is ready, the browser can arrange for your JavaScript callback or promise continuation to run.

That’s a very different model from:

“JavaScript does everything.”

Think of JavaScript as one worker inside a much bigger system

A useful mental model is to imagine a restaurant.

JavaScript is one worker taking orders.

The browser is the entire restaurant.

There are other workers handling different responsibilities.

JavaScript might say:

“I need this data from the server.”

The browser starts handling the network operation.

JavaScript doesn’t need to sit there doing nothing until every byte arrives.

Instead, it can continue with other JavaScript work.

Later, when the operation is ready to be observed by JavaScript, the relevant task can be scheduled for the JavaScript thread.

This is the basic idea behind asynchronous browser APIs.

So what happens with fetch()?

Consider this:

console.log("Start");
fetch("/api/users")
  .then(() => {
    console.log("Users received");
  });
console.log("End");

Many beginners initially imagine something like this:

Start
   ↓
fetch()
   ↓
wait for server
   ↓
Users received
   ↓
End

But that’s not what happens.

The JavaScript execution doesn’t simply stop at fetch() waiting for the network response.

Conceptually, the flow is closer to:

JavaScript
   │
   ├── Start fetch
   │
   ▼
Browser handles network work
   │
   │
   └───────────────┐
                   │
JavaScript         │
continues          │
                   │
   ▼               │
console.log("End") │
                   │
                   ▼
        Response becomes available
                   │
                   ▼
        Promise continuation
        gets scheduled
                   │
                   ▼
        JavaScript runs it

So the output is generally:

Start
End
Users received

The important part isn’t just that fetch() is asynchronous.

The important part is who is doing the waiting.

JavaScript isn’t blocking its thread waiting for the server response.

The event loop connects the pieces

This is where the event loop becomes important.

You can think of the JavaScript environment as having a place where JavaScript executes and mechanisms that coordinate when asynchronous work can continue.

A simplified model looks like this:

Browser
                │
     ┌──────────┼───────────┐
     │          │           │
 Network     Timers      User Input
     │          │           │
     └──────────┼───────────┘
                │
                ▼
         Scheduling queues
                │
                ▼
           Event Loop
                │
                ▼
          Call Stack
                │
                ▼
           JavaScript

This diagram is simplified.

The real browser architecture is more complicated, and different browser engines implement things differently.

But it gives you the right mental model:

JavaScript execution is only one part of the system.

And this is why timers don’t “run JavaScript in the background”

Consider:

setTimeout(() => {
  console.log("Done");
}, 1000);

A common mental model is:

“JavaScript starts a timer thread that waits one second.”

That’s not a good way to think about it.

The browser provides the timer functionality.

After the timer’s delay has elapsed, the callback becomes eligible to be scheduled.

Then JavaScript executes the callback when the main thread is available.

So this:

setTimeout(() => {
  console.log("Done");
}, 1000);

while (true) {}

is a terrible idea.

Why?

Because the timer can become ready, but the JavaScript thread is still stuck inside the infinite loop.

The callback cannot simply interrupt the currently executing JavaScript.

The browser can know:

“The timer is ready.”

But JavaScript still has to get a chance to run:

Main JavaScript thread

while (true) {
   // never finishes
}
        ↓
Timer becomes ready
        ↓
Callback waits
        ↓
JavaScript never becomes available

This is one of the most important distinctions to understand.

Asynchronous does not mean JavaScript is executing your callback on another thread.

So why doesn’t the UI freeze all the time?

Because the browser is doing much more than executing JavaScript.

But there is an important catch.

The main thread is often responsible for work that directly affects your page’s responsiveness, including JavaScript execution and parts of the rendering process.

That means this can still freeze the page:

const start = performance.now();

while (performance.now() - start < 5000) {
  // expensive work
}

For five seconds, JavaScript keeps the main thread busy.

During that time, interactions and rendering work that need the main thread can be delayed.

And this is where the phrase:

“JavaScript is single-threaded”

starts to matter.

The browser can be multithreaded while your JavaScript isn’t

This is the key distinction.

A browser process can use multiple threads for different kinds of work.

The exact architecture varies between browsers and operating systems, but modern browsers are highly concurrent internally.

You might have work happening around:

Browser
│
├── JavaScript execution
├── Network activity
├── Rendering-related work
├── Image/media processing
├── Browser services
└── Other internal tasks

But that does not mean you can write:

runThisFunctionOnAnotherBrowserThread();

for arbitrary JavaScript.

Your normal JavaScript execution still follows its single-threaded execution model.

If you want JavaScript itself to perform CPU-heavy work away from the main thread, that’s where Web Workers become useful.

Conclusion

JavaScript is single-threaded, but that doesn’t mean the entire browser is limited to one thread.

Your JavaScript runs on a main execution thread, while the browser handles many other responsibilities through its own internal systems.

Network requests, timers, user input, rendering, media processing, and other operations can happen outside the direct execution of your JavaScript code.

When those operations are ready to continue, the browser schedules the relevant callbacks or promise continuations so JavaScript can process them.

The main thread still matters, though.

If your JavaScript performs expensive work for too long, it can delay user interactions, rendering, and other tasks that depend on that thread.

So the browser can be highly concurrent while your JavaScript remains single-threaded.

That distinction explains both the power and the limitations of browser-based JavaScript.

Takeaway

Remember these three ideas:

1. JavaScript is single-threaded.
   Your normal JavaScript code runs one piece at a time on the main execution thread.
2. The browser is a larger, concurrent system.
   It handles networking, timers, rendering, input, media, and other work beyond JavaScript execution.
3. Asynchronous does not mean your callback runs on another thread.
   The browser handles the waiting, then schedules your JavaScript to run when the main thread is available.

A useful mental model is:

Browser
│
├── JavaScript execution
├── Network activity
├── Timers
├── User input
├── Rendering
├── Media processing
└── Other browser systems

JavaScript is one part of that system — not the whole thing.

Once you understand that, the event loop, asynchronous APIs, UI freezing, and browser concurrency become much easier to reason about.

You changed the DOM. Your JavaScript ran. So why did the user see nothing until much later?

There’s a frontend bug that can make you question everything you know about JavaScript.

You click a button.

You change the text on the screen.

You show a loading spinner.

Then you start some expensive JavaScript work.

You expect this:

Click
  ↓
"Loading..."
  ↓
Heavy work
  ↓
"Done!"

But the browser sometimes gives you this:

Click
  ↓
Heavy JavaScript
  ↓
"Done!"

The "Loading..." state never appeared.

Not because your JavaScript failed.

Not because the DOM didn’t change.

The DOM changed.

The browser simply didn’t get a chance to show you the change.

That distinction completely changed the way I think about frontend performance.

The DOM can change before the user sees the change

Consider this simple example:

button.addEventListener("click", () => {
  status.textContent = "Loading...";
  doSomethingExpensive();
  status.textContent = "Done!";
});

At first glance, nothing looks wrong.

The browser executes:

1. Change the text to "Loading..."
2. Run expensive JavaScript
3. Change the text to "Done!"

So you might expect the user to briefly see "Loading...".

But that’s not necessarily what happens.

The browser’s main thread is responsible for running most JavaScript as well as handling events and rendering work such as style, layout, and painting. A long-running JavaScript task can therefore delay the browser’s opportunity to update what the user sees.

That’s the part that feels strange at first.

Changing the DOM is not the same thing as painting pixels to the screen.

And once you understand that, a lot of “weird” frontend behavior suddenly makes sense.

The practical takeaway

When debugging UI responsiveness, don’t ask only:

“Did my state or DOM update?”

Also ask:

“When did the browser actually get a chance to render that update?”

The browser has another job besides running your JavaScript

It’s easy to imagine the browser as something that simply executes our code.

We write:

element.textContent = "Hello";

and imagine the browser immediately drawing "Hello".

But the browser has a lot more to do.

The main thread may need to:

• process user input
• execute JavaScript
• calculate styles
• calculate layout
• paint pixels
• handle other browser work
• respond to the next interaction

And most of that work is competing for the same main-thread time.

The browser’s event loop processes JavaScript tasks and microtasks, then can perform needed rendering before moving on. If your JavaScript keeps the main thread busy, the rendering opportunity can be delayed.

Think of the main thread as one person working at a very busy desk.

You keep handing them jobs:

“Run this function.”

“Handle this click.”

“Calculate this.”

“Process this array.”

“Update the UI.”

“Paint the screen.”

They don’t have infinite hands.

If you give them one enormous JavaScript task, everything else has to wait.

This is where the “16ms” idea becomes interesting

You’ve probably heard frontend developers talk about the 16.67ms frame budget.

It can sound like one of those performance numbers developers memorize because they’re supposed to.

But it’s easier to understand if you think about what the browser has to accomplish between frames.

At 60Hz, a new frame is available roughly every 16.7ms.

That time isn’t reserved exclusively for your JavaScript.

The browser also needs time for things such as scripting, style calculation, layout, and painting.

So imagine you have:

16.67ms
────────────────────────────
JavaScript       ██████████
Style            ██
Layout           ██
Paint            ██
────────────────────────────

Now imagine your JavaScript takes much longer:

16.67ms
────────────────────────────
JavaScript       ███████████████████████████
Style
Layout
Paint
────────────────────────────

The browser doesn’t magically create another 20 milliseconds.

Your frame is late.

And when frames keep arriving late, users experience things like:

• laggy scrolling
• delayed buttons
• frozen loading states
• stuttering animations
• input lag
• interfaces that feel “heavy”

The practical takeaway

Frontend performance isn’t only about making JavaScript execute faster.

It’s also about making sure the browser gets enough opportunities to do everything else.

The sneaky part: splitting functions doesn’t necessarily help

Here’s a mistake that looks like optimisation:

function updateEverything() {
  updateHeader();
  updateSidebar();
  processProducts();
  calculateTotals();
  updateCharts();
}

You might think the work is now divided into smaller pieces because each operation has its own function.

But all of those functions still run synchronously as part of the same task:

button.addEventListener("click", () => {
  status.textContent = "Loading...";
  updateEverything();
  status.textContent = "Done";
});

The browser cannot usually paint the "Loading..." state until the click handler and all of the work inside updateEverything() have finished.

The same thing happens if you write the calls separately:

button.addEventListener("click", () => {
  status.textContent = "Loading...";
  updateHeader();
  updateSidebar();
  processProducts();
  calculateTotals();
  updateCharts();
  status.textContent = "Done";
});

The functions are smaller from a code-organisation perspective.

The browser task is not smaller.

To create separate opportunities for the browser to respond, you need to yield between chunks of work:

async function updateEverything() {
  updateHeader();
  updateSidebar();
  await new Promise(resolve => setTimeout(resolve, 0));
    processProducts();
    calculateTotals();
    await new Promise(resolve => setTimeout(resolve, 0));
    updateCharts();
}


button.addEventListener("click", async () => {
  status.textContent = "Loading...";
  await updateEverything();
  status.textContent = "Done";
});

Now the browser can handle pending work between chunks, including rendering the loading state.

This is an important distinction.

Breaking code into functions is good for organisation. It doesn’t automatically break a long task into multiple browser opportunities.

A long task is generally defined as an uninterrupted main-thread task lasting more than 50ms. During such work, user interactions and visual updates can be delayed.

Give the browser a chance to breathe

Suppose you have a large amount of work that genuinely needs to happen.

Instead of doing everything in one uninterrupted task:

function processEverything(items) {
  for (const item of items) {
    expensiveCalculation(item);
  }
}

you can split the work into smaller chunks.

Conceptually:

async function processItems(items) {
  for (const chunk of chunks(items)) {
    processChunk(chunk);
    await new Promise(resolve => {
      setTimeout(resolve, 0);
    });
  }
}

Now the browser has opportunities between chunks to handle other work, including UI updates.

Modern browsers also expose scheduler.yield() for yielding from long-running work where supported. It is specifically designed to let the browser handle higher-priority work before your JavaScript continues.

The exact scheduling strategy depends on the problem.

The important idea is simpler:

Don’t make the browser wait for your entire workload before giving it another opportunity to respond.

This explains a UI bug I’ve seen over and over

Imagine a search interface.

The user selects a filter.

You immediately want to show:

Filtering...

Then you process 50,000 records.

A naive implementation might look like:

filterButton.addEventListener("click", () => {
  status.textContent = "Filtering...";
  const results = expensiveFilter(allProducts);
  renderResults(results);
  status.textContent = "Done";
});

The code looks completely reasonable.

But if expensiveFilter() takes long enough, the user might never see "Filtering...".

The interface feels broken.

The developer might start investigating:

“Why isn’t React updating?”

“Is my state wrong?”

“Is the browser caching something?”

“Is CSS hiding the element?”

Sometimes the real problem is much simpler:

The main thread was busy.

The browser couldn’t paint the intermediate state when you expected it to.

A better mental model

Think of UI updates as having two stages:

Your JavaScript
      ↓
Changes state / DOM
      ↓
Browser gets an opportunity
      ↓
Style / Layout / Paint
      ↓
User sees pixels

There is a gap between the first and the last step.

That gap matters.

React doesn’t escape this problem

This isn’t a “vanilla JavaScript problem.”

React can make state management easier, but your application still ultimately has to run JavaScript and interact with the browser’s rendering environment.

You can write:

setLoading(true);
doSomethingVeryExpensive();
setLoading(false);

and still have the same fundamental problem.

The important question isn’t:

“Did I call setLoading(true)?"

It’s:

“Did the browser get an opportunity to render that state before the expensive work continued?”

That’s a much more useful way to think about performance in React applications.

The same mental model applies to:

• Next.js applications
• dashboards
• data-heavy tables
• client-side filtering
• large lists
• complex animations
• expensive calculations
• drag-and-drop interfaces

The framework changes.

The browser still has a main thread.

Sometimes the best solution is to stop doing the work there

There are cases where breaking work into smaller chunks isn’t enough.

Maybe you’re processing a huge dataset.

Maybe you’re doing image manipulation.

Maybe you’re calculating something computationally expensive.

In those cases, a Web Worker can move JavaScript computation to another thread, keeping the main thread available for UI work. Workers can’t directly manipulate the DOM, but they can perform computation and communicate results back to the main thread.

The architecture becomes something like:

┌──────────────────┐
                 │   Main Thread    │
                 │                  │
User Input ────→ │ UI + DOM + Paint │
                 └────────┬─────────┘
                          │
                          │ data
                          ↓
                 ┌──────────────────┐
                 │   Web Worker     │
                 │                  │
                 │ Heavy computation│
                 └──────────────────┘

Now your expensive calculation doesn’t have to monopolize the same thread responsible for keeping the interface responsive.

The DevTools trick I wish more frontend developers used

When an interface feels slow, don’t immediately start rewriting code.

Open Chrome DevTools.

Record a Performance trace.

Then look at the Main thread.

You’re looking for something like:

Main
██████████████████████████████
       Long JavaScript task
                             █
                             Paint

Instead of:

Main
████ JavaScript
    ██ Render
       ███ JavaScript
           ██ Render
              █ JavaScript

The second pattern gives the browser more opportunities to respond.

Long tasks are particularly important because they can cause delayed input, sluggish animations, and delayed visual updates.

This is one of those cases where the performance timeline is often more useful than staring at the source code.

The practical takeaway

When a UI “feels slow,” measure what the main thread is doing, not just how many lines of JavaScript you have.

The biggest misconception I had about frontend performance

It’s tempting to think:

Fast JavaScript = fast website.

It’s not that simple.

A better mental model is:

Fast JavaScript is useful. Available main-thread time is even more important.

A function that takes 5ms might be perfectly fine.

A function that takes 200ms might be a serious problem.

But even that isn’t the whole story.

What matters is when the work happens, what it competes with, and whether the browser gets opportunities to respond to the user.

That’s why two applications can perform very differently even when their JavaScript does roughly the same amount of work.

One idea worth remembering

The next time you write:

updateUI();
doSomethingExpensive();

don’t just ask whether updateUI() ran.

Ask:

“Does the browser have a chance to paint this before I start the expensive work?”

That one question can lead you to an entirely different debugging path.

Because the browser doesn’t paint every time you change the DOM.

It paints when it gets an opportunity to render.

And your JavaScript can take that opportunity away.

The browser isn’t ignoring your UI

When your UI doesn’t appear immediately, it can feel like something went wrong.

Sometimes nothing is wrong with the UI code.

The browser is simply busy.

Your JavaScript, event handlers, rendering work, layout calculations, and other tasks are all competing for time on a very busy main thread.

So here’s the mental model I’d keep:

JavaScript changes the UI
          ↓
The browser still has work to do
          ↓
The main thread must become available
          ↓
Rendering gets an opportunity
          ↓
The user finally sees the change

Your code changing the UI and the user seeing the UI are two different events.

Once you really understand that, “the UI didn’t update” stops being a mysterious frontend bug.

It becomes a performance problem you can reason about.

And the next time you build a loading state, animation, search filter, or expensive interaction, don’t just make the JavaScript work.

Leave the browser enough room to show the user that your work is happening.

That small shift in thinking can make a surprisingly big difference.