DEV Community: Brendon O'Neill

Asynchronous JavaScript

Brendon O'Neill — Wed, 20 May 2026 13:54:51 +0000

When we write JavaScript or TypeScript, most of our code runs from top to bottom, line by line. This is what we usually think of as synchronous code. One line runs, then the next, then the next.

But when we need to get information from a server, things are different. We cannot just freeze the whole application while we wait for that data to come back. If a website or app did that, most users would probably leave before anything loaded.

So JavaScript needed a way to let certain tasks happen in the background while the rest of the application kept running. That way, we can show loading states, keep the page interactive, and update the UI once the data finally returns.

This is where asynchronous JavaScript comes in. It gives us a way to start a task now and deal with the result later without blocking the rest of our code. Over time, JavaScript introduced different ways to handle this, starting with callbacks and XMLHttpRequest, then moving to promises, the Fetch API, and finally async/await.

In this post, I am going to walk through that progression and show how asynchronous JavaScript evolved into what we use today.

Callbacks and XMLHttpRequest

Before promises and async/await, the main way to deal with asynchronous code was with callback functions.

If you have not come across them before, a callback is just a function passed into another function as an argument. That function gets called later once the task is complete.

Back then, one of the main tools used to communicate with servers in the browser was XMLHttpRequest, usually shortened to XHR. Despite the name, it was not only used for XML. It could also be used to work with JSON, which is what we use most often today. Before fetch() became the normal choice, XHR was the standard way to make HTTP requests in the browser.

Here is a simple example:

function getData(callback) {
  var xhr = new XMLHttpRequest();

  xhr.onreadystatechange = function () {
    if (xhr.readyState === 4) {
      if (xhr.status >= 200 && xhr.status < 300) {
        callback(null, xhr.responseText);
      } else {
        callback("HTTP error: " + xhr.status);
      }
    }
  };

  xhr.open("GET", "/api/data", true);
  xhr.send();
}

function renderContent(data) {
  var container = document.getElementById("content");
  container.innerHTML = "<p>" + data + "</p>";
}

function showError(error) {
  var container = document.getElementById("content");
  container.innerHTML = "<p>" + error + "</p>";
}

getData(function (error, data) {
  if (error) {
    showError(error);
    return;
  }

  renderContent(data);
});

Let’s break down what is happening here.

First, we create a function called getData that accepts a callback. Inside it, we create an XMLHttpRequest object, which handles the request to the server.

Then we use xhr.onreadystatechange, which runs every time the request changes state. We check for xhr.readyState === 4, which means the request has finished. Once it has, we check the HTTP status code. If it is in the 200 range, the request succeeded, so we pass the response into the callback. If it failed, we pass back an error instead.

After that, we call xhr.open() to configure the request and xhr.send() to send it.

At the bottom, we call getData() and pass in another function. That callback decides what to do next. If there is an error, we show it. If not, we render the returned data on the page.

This worked, and for simple requests it was fine. But the problem started when multiple asynchronous tasks depended on each other.

Imagine needing to fetch a user, then fetch their posts, then fetch the comments for one of those posts. Every step depends on the previous one, which means the callbacks start getting nested inside each other. That is what became known as callback hell.

Here is a simple example of that:

function getUser(userId, callback) {
  setTimeout(function () {
    console.log("Fetched user");
    callback(null, { id: userId, name: "Alice" });
  }, 500);
}

function getPosts(userId, callback) {
  setTimeout(function () {
    console.log("Fetched posts");
    callback(null, [
      { id: 1, title: "First Post", userId: userId },
      { id: 2, title: "Second Post", userId: userId },
    ]);
  }, 500);
}

function getComments(postId, callback) {
  setTimeout(function () {
    console.log("Fetched comments");
    callback(null, [
      { id: 1, text: "Nice post", postId: postId },
      { id: 2, text: "Thanks for sharing", postId: postId },
    ]);
  }, 500);
}

getUser(42, function (err, user) {
  if (err) {
    console.error("Error fetching user:", err);
  } else {
    getPosts(user.id, function (err, posts) {
      if (err) {
        console.error("Error fetching posts:", err);
      } else {
        getComments(posts[0].id, function (err, comments) {
          if (err) {
            console.error("Error fetching comments:", err);
          } else {
            console.log("User:", user);
            console.log("Posts:", posts);
            console.log("Comments for first post:", comments);
          }
        });
      }
    });
  }
});

Even in this small example, the code is already getting deeper, more repetitive, and harder to scan. As the number of requests grows, debugging and maintaining it becomes more of a hassle.

Developers needed a cleaner way to deal with async code.

That is where promises came in.

Promises

Promises gave JavaScript a much cleaner way to handle asynchronous work.

A promise is an object that represents a value we do not have yet, but expect to receive later. That future result can either succeed or fail.

A simple way to think about it is lending a pen to someone. They promise they will give it back. You do not know exactly when that will happen, and there is always a chance they come back without it. But instead of standing there waiting, you go and do other things. Then, once the result comes back, you deal with it.

That is basically how promises work in JavaScript.

A promise can end in two main ways:

resolved, meaning the operation succeeded
rejected, meaning something went wrong

We usually handle those outcomes with .then() and .catch():

.then() handles the resolved value
.catch() handles errors or rejections Here is an example of wrapping XHR in a promise:

function apiGet(url) {
  return new Promise(function (resolve, reject) {
    var xhr = new XMLHttpRequest();

    xhr.onreadystatechange = function () {
      if (xhr.readyState === 4) {
        if (xhr.status >= 200 && xhr.status < 300) {
          var data = JSON.parse(xhr.responseText);
          resolve(data);
        } else {
          reject(new Error("Request failed with status " + xhr.status));
        }
      }
    };

    xhr.open("GET", url, true);
    xhr.send();
  });
}

apiGet("/api/user/42")
  .then(function (user) {
    console.log("User loaded:", user);
  })
  .catch(function (err) {
    console.error("Error:", err);
  });

Here, instead of accepting a callback, apiGet() returns a promise. Inside that promise, we call resolve() when the request succeeds and reject() when it fails.

This means the code that calls apiGet() can decide how to handle the result. That is a big improvement because it separates the request logic from the result-handling logic.

It also gave us a cleaner way to chain async steps together.

function getUser(userId) {
  return new Promise((resolve) => {
    setTimeout(() => {
      resolve({ id: userId, name: "Alice" });
    }, 500);
  });
}

function getPosts(userId) {
  return new Promise((resolve) => {
    setTimeout(() => {
      resolve([
        { id: 1, title: "First Post", userId: userId },
        { id: 2, title: "Second Post", userId: userId },
      ]);
    }, 500);
  });
}

function getComments(postId) {
  return new Promise((resolve) => {
    setTimeout(() => {
      resolve([
        { id: 1, text: "Nice post", postId: postId },
        { id: 2, text: "Thanks for sharing", postId: postId },
      ]);
    }, 500);
  });
}

getUser(42)
  .then((user) => {
    console.log("User:", user);
    return getPosts(user.id);
  })
  .then((posts) => {
    console.log("Posts:", posts);
    return getComments(posts[0].id);
  })
  .then((comments) => {
    console.log("Comments:", comments);
  })
  .catch((error) => {
    console.error("Something went wrong:", error);
  });

This is still asynchronous, but it is much flatter than the callback version. It reads in a more natural order and is easier to debug.

The Fetch API

As promises became more common, browsers introduced a newer and cleaner way to make HTTP requests called the Fetch API.

The Fetch API is built around promises, which means it works naturally with .then() and .catch(). It quickly became the more modern replacement for XHR and is now what most frontend developers use by default in the browser.

Here is a simple example:

fetch("https://api.example.com/data")
  .then((response) => {
    if (!response.ok) {
      throw new Error(`HTTP error: ${response.status}`);
    }
    return response.json();
  })
  .then((data) => console.log(data))
  .catch((error) => console.error(error));

Let’s break it down.

First, fetch() sends the request and returns a promise.

When that promise resolves, we get back a response object. That is not the final JSON yet, it is the full HTTP response, so the first thing we often do is check response.ok.

If the request failed, we throw an error so that .catch() can handle it.

If the request succeeded, we call response.json(). That also returns a promise, which is why we need another .then() after it. Once that promise resolves, we finally have access to the parsed data.

Compared to XHR, this is much shorter and easier to follow. We no longer need to manage readyState, create request objects manually, or put all our logic inside event handlers.

But even with fetch and promises, long chains of .then() could still become difficult to read in more complex applications.

That is where async/await made things even cleaner.

Async Await

async/await gave us a way to write asynchronous code that looks much closer to normal synchronous code.

It is important to note that async/await is still built on promises. It does not replace them underneath, it just gives us a nicer syntax to work with them.

There are two main parts:

async marks a function as asynchronous
await pauses that function until a promise settles

Here is a basic example using fetch():

async function getData() {
  try {
    const response = await fetch("https://api.example.com/data");

    if (!response.ok) {
      throw new Error(`HTTP error: ${response.status}`);
    }

    const data = await response.json();
    console.log(data);
  } catch (error) {
    console.error(error);
  }
}

getData();

Here’s what is happening.

First, we add the async keyword to the function. That tells JavaScript we want to use await inside it.

Then we use await with fetch(). Instead of chaining .then(), we store the resolved response in a variable.

After that, we check whether the request succeeded.

Then we use await again with response.json() because parsing the response body is also asynchronous.

Finally, we wrap everything in a try...catch block, which lets us handle errors in one place.

This is one of the reasons async/await became so popular. It is still asynchronous, but it reads more like normal top-to-bottom code.

Here is the earlier user-posts-comments example rewritten using async/await:

function getUser(userId) {
  return new Promise((resolve) => {
    setTimeout(() => {
      resolve({ id: userId, name: "Alice" });
    }, 500);
  });
}

function getPosts(userId) {
  return new Promise((resolve) => {
    setTimeout(() => {
      resolve([
        { id: 1, title: "First Post", userId: userId },
        { id: 2, title: "Second Post", userId: userId },
      ]);
    }, 500);
  });
}

function getComments(postId) {
  return new Promise((resolve) => {
    setTimeout(() => {
      resolve([
        { id: 1, text: "Nice post", postId: postId },
        { id: 2, text: "Thanks for sharing", postId: postId },
      ]);
    }, 500);
  });
}

async function loadUserData() {
  try {
    const user = await getUser(42);
    console.log("User:", user);

    const posts = await getPosts(user.id);
    console.log("Posts:", posts);

    const comments = await getComments(posts[0].id);
    console.log("Comments for first post:", comments);
  } catch (error) {
    console.error("Error loading data:", error);
  }
}

loadUserData();

This version is much easier to read because the steps happen in a clear order:

get the user
get the posts
get the comments

No deep nesting, no long promise chain, and much less repeated error handling.

One important thing to remember is that await only pauses the async function it is inside. It does not block the whole browser or freeze the rest of your application.

That is the key difference. It looks synchronous, but it still behaves asynchronously under the hood.

Conclusion

Asynchronous JavaScript has come a long way.

We started with callbacks and XMLHttpRequest, which worked but quickly became messy when multiple requests depended on each other. Then promises gave us a cleaner and more structured way to manage async code. After that, the Fetch API made browser requests easier to write, and finally, async/await made asynchronous code feel far more natural to read.

At the end of the day, all of these approaches are solving the same problem: letting JavaScript keep running while waiting for something else to finish.

If you are learning JavaScript today, async/await is probably what you will use most often. But understanding callbacks, promises, and fetch is still really useful, because it helps you understand what is happening underneath and why modern async code looks the way it does.

If you want to learn more about JavaScript, check out:

Hyu-Sync, my fun side project

Brendon O'Neill — Wed, 06 May 2026 16:23:47 +0000

Hyu-Sync

This website is here to help people pick colours for their projects. It includes a colour picker that generates colour harmonies and colour formats, making it easier to choose colours that work well together. There are also plenty of other features, like a contrast checker for accessibility and the ability to create your own custom palettes from colours you want to reuse.

Where it started

This project started because I wanted to create a colour wheel using canvas. After I got that working, I decided to build a colour picker that could convert colours into three different formats: Hex, HSL, and RGB.

Alongside that, I wanted a colour history feature to track colours I’d used before, since I was relying on different websites to store colours, look them up, check accessibility, and create palettes. So I decided to build one site that brought all of that together and made the whole process easier.

Features

Colour picker
Colour formater
Contrast checker
Colour history
Six different colour harmonies
HSL editor
Gradient editor
Custom palettes builder

Performance and Accessibility

I want this site to be accessible to everyone, so I’m continuing to improve its performance, such as avoiding re-rendering the colour picker on load. I’m also continuing to learn more about accessibility so I can make it as user-friendly as possible.

CSS isn't hard

Brendon O'Neill — Fri, 24 Apr 2026 09:38:09 +0000

When I’m browsing the web, I notice that CSS gets a lot of hate. Honestly, I get it, because I used to hate CSS too. But that was before I properly understood how it worked. Most of my frustration came from not really knowing what CSS was doing behind the scenes.

A lot of people jump straight into frameworks like Tailwind without learning the basics first. Tailwind is great, but what many people don’t realise is that understanding CSS makes Tailwind much easier to use. The concepts transfer over almost directly.

For example, this Tailwind:

<div class="flex flex-row justify-center w-60 h-60"></div>

is doing the same kind of job as this CSS:

<div class="box"></div>

.box{
 display: flex;
 flex-direction: row;
 justify-content: center;
 width: 15rem;
 height: 15rem;
}

Once you understand the basics of CSS, you’re not just learning one tool. You’re learning the foundations behind how styling works on the web, which also makes tools like Tailwind feel much less confusing.

So in this post, I’m going to walk through the basics of CSS, from selectors and specificity to sizing and resets, so you can build a stronger foundation and feel more confident styling your projects.

Selectors

Before you can style anything in CSS, you need a way to target the element you want to change. That’s what selectors do.

A selector tells CSS, "Apply these styles to this element." Some selectors are broad and affect lots of elements, while others are more specific and only target one particular thing.

There are quite a few types of selectors in CSS, and each one has its own use case. Some are used all the time, while others are more situational. It’s also worth knowing that selectors have different levels of specificity, which decides which style wins when multiple rules target the same element, but we’ll cover that properly later.

Let’s start with the most common ones.

Type selector

The type selector is usually the first selector people learn. It targets elements by their HTML tag name, like p, h1, div, or button.

This means if you write styles for p, every paragraph on the page will receive those styles unless something more specific overrides them.

p{
 color: red;
 font-size: 20px;  
}

h1{
 color: skyblue;
 font-size: 12px;
}

This is useful when you want to style all elements of the same type at once. For example, if you want every paragraph to have the same text colour or every heading to share a base font size, type selectors are a simple place to start.

Attribute selector

Attribute selectors target elements based on the attributes they contain.

This is especially useful for elements like links, inputs, or form fields, because they often have attributes such as href, title, name, or type.

For example, you might want to style only links with a certain URL, or only inputs with a specific name.

a[title]{
    color: orange;
}

a[href="https://www.youtube.com"] {
  color: cyan;
}


input[name="test"]{
    background-color: wheat;
    color: purple;
}

Here’s what each one is doing:

a[title] selects any a tag that has a title attribute
a[href="https://www.youtube.com"] selects an a tag with that exact href value
input[name="test"] selects an input whose name is "test"

These selectors are great when you need a bit more control without adding extra classes.

Class selector

Class selectors are probably the ones you’ll use the most in day-to-day CSS.

A class selector targets any element with a matching class attribute. This is useful because multiple elements can share the same class, which means you can reuse the same styles wherever you need them.

To write a class selector in CSS, use a dot followed by the class name.

<div class="box"></div>
<p class="heading">I'm a test heading.</p>

.box{
    height: 100px;
    width: 100px;
    background-color: violet;
}

.heading{
    color: tomato;
    font-size: 22px;
}

This is one of the most common ways to style a page because it gives you flexibility. Instead of styling every p tag the same way, you can choose exactly which paragraph gets a certain style by giving it a class.

ID selector

An ID selector targets an element using its id attribute.

Unlike classes, IDs should be unique. That means one ID should only be used once per page. Because of that, ID selectors are best for elements that are truly one of a kind, like a main heading, a single banner, or a specific section.

To write an ID selector, use a # symbol followed by the ID name.

#rect{
    height: 100px;
    width: 200px;
    background-color:cadetblue;
}

#sub-heading{
    color: tomato;
    font-size: 22px;
}

ID selectors work fine, but in most modern CSS, classes are usually preferred because they are easier to reuse and manage. IDs also have higher specificity, which can make your styles harder to override later.

Universal selector

The universal selector uses * and matches every element on the page.

That means if you apply a rule using *, it affects everything unless a more specific selector overrides it.

*{
    color: white;
    font-size: 22px;
    font-weight: normal;
}

This selector can be useful for broad rules, especially in reset styles or when setting something globally like box-sizing.

That said, you usually want to be a little careful with it. Since it applies to everything, it can sometimes affect more elements than you intended.

Nesting selector

CSS nesting lets you write selectors inside other selectors to show the relationship between parent and child elements more clearly.

If you’ve used Sass before, this idea might already look familiar. Native CSS nesting is becoming more common now, and it can make related styles easier to read.

div{
    width: 200px;
    height: 100px;
    background-color: cornsilk;
    padding: 16px;

    & p{
        color: blueviolet;
        font-weight: bold;
    }
}

In this example, the nested rule targets any p inside the div.

I don’t personally use nesting all that much, because I usually prefer to name elements clearly and style them directly. But it’s still useful to understand, especially if you come across it in other people’s code or in larger projects.

Now that we know how to target elements, the next step is understanding how to be more precise with those relationships. That’s where combinators come in.

Combinators

Once you understand basic selectors, the next step is learning combinators.

Combinators let us define relationships between elements. Instead of just saying "style all p tags," we can be more specific and say things like "style all p tags inside a div" or "style the first p that comes right after a div".

They’re really useful when your HTML starts getting more structured and you want your CSS to match that structure.

Let’s go through the most common ones.

Descendant combinator

The descendant combinator is written as a space between two selectors.

It selects elements that are inside another element, even if they are nested multiple levels deep.

div p{
        color: blueviolet;
        font-weight: bold;
}

This means "select every p that is somewhere inside a div".

So if a paragraph is inside the div directly, or even inside another element within that div, it will still be matched.

This is one of the most common combinators because it’s simple and flexible.

Child combinator

The child combinator uses the > symbol.

This one is more specific than the descendant combinator because it only selects elements that are direct children of the parent.

div > p{
        color: blueviolet;
        font-weight: bold;
}

This means "select any p that is directly inside a div".

If the paragraph is nested deeper, like inside a section that is inside the div, this rule will not apply.

Use this when you only want to target one level down.

Adjacent sibling combinator

The adjacent sibling combinator uses the + symbol.

It selects an element that comes immediately after another element, as long as they share the same parent.

div + p{
        color: blueviolet;
        font-weight: bold;
}

This means "select the first p that comes directly after a div".

I don’t use this one very often either, but it’s handy when you want to style something based on what comes right before it.

For example, you might want to style the first paragraph after a banner, image, or heading.

General sibling combinator

The general sibling combinator uses the ~ symbol.

This one selects all matching sibling elements that come after the first selector, not just the immediate next one.

div ~ p{
        color: blueviolet;
        font-weight: bold;
}

This means "select every p that comes after a div, as long as they share the same parent".

So unlike +, the paragraph does not need to come immediately after the div. It just needs to appear later in the same group of siblings.

This can be useful when you want to affect a set of elements that follow another one.

Grouping selectors

This one is not technically a combinator, but it fits naturally here because it’s another useful way to avoid repeating yourself.

If multiple selectors should share the same styles, you can group them together with commas.

div,p,h1{
  color: red;
  background: white;
}

This tells CSS to apply the same styles to all div, p, and h1 elements.

Grouping selectors is great for keeping your CSS shorter and cleaner, especially when several elements need the same rules.

Combinators are all about relationships. They help you target elements based on where they are and how they connect to other elements in your HTML.

Now that we’ve covered selectors and relationships between elements, the next thing to look at is how elements can be styled in different states. That’s where pseudo-classes come in.

Pseudo classes

Pseudo-classes let us style elements based on their state.

Instead of just targeting what an element is, we can target how it is behaving. Common examples are when a user hovers over something, clicks it, or focuses on an input field.

You’ll use these a lot for buttons, links, forms, and interactive elements.

div{
        width: 200px;
        height: 200px;
        background-color: aqua;
}

div:hover{
    background-color: chocolate;
}

In this example, the div starts with an aqua background. When the user hovers over it, the background changes to chocolate.

Some common pseudo-classes you’ll come across are:

:hover when the user moves over an element
:active when the element is being clicked
:focus when an input or button is selected
:first-child selects the first child inside a parent

They’re a simple but powerful way to make your page feel more interactive.

Now that we know how to target elements in different states, the next thing to understand is what happens when multiple CSS rules target the same element. That’s where specificity comes in.

Specificity

As your CSS grows, you’ll eventually run into moments where two different rules are trying to style the same element. When that happens, CSS has to decide which rule wins. That decision is based on specificity.

Specificity is basically the weight of a selector. The more specific the selector is, the more likely it is to override another one.

For example:

p {
  color: blue;
}

.text {
  color: green;
}

#main-text {
  color: red;
}

If all three selectors target the same paragraph, the #main-text rule wins because an ID selector is more specific than a class selector, and a class selector is more specific than a type selector.

A simple way to think about the order is:

type selectors like p or div
class selectors, attribute selectors, and pseudo-classes
ID selectors

So in general:

p is weaker than .text
.text is weaker than #main-text

Orders

If two selectors have the same specificity, then the rule written later in the CSS wins.

p {
  color: blue;
}

p {
  color: red;
}

Here, the paragraph will be red because that rule comes later.

This is why the order of your CSS file matters, especially when you reuse selectors.

Specificity is one of those CSS ideas that feels annoying at first, but once you understand it, a lot of styling bugs start to make sense.

Next, let’s look at sizing, because choosing between units like px, rem, and em is another big part of writing CSS well.

Sizes

Sizing in CSS can feel a little confusing at first because there are several different units, and they don’t all behave the same way. Over time, you’ll find the ones that make the most sense for different jobs.

When it comes to fonts, the main units you’ll usually see are px, em, and rem.

px is a fixed unit
em is relative to the font size of the parent element
rem is relative to the root HTML font size

h1 {
  font-size: 32px;
}

p {
  font-size: 1rem;
}

.small {
  font-size: 0.8em;
}

Out of these, I personally prefer using rem most of the time. It keeps sizing more consistent across a project and is usually easier to manage than em, especially once elements start nesting inside each other.

After font sizing, you’ll also come across units like % and vh when working with containers and layout.

% is relative to the size of the parent element
vh and vw stand for viewport height and width, so 100vh means the full height of the browser window and 100vw is the full width of the browser window

.container {
  width: 80%;
}

.hero {
  height: 100vh;
}

These are useful for creating flexible layouts. % works well when you want something to scale with its parent, and vh is common for sections like hero banners that should fill the screen.

There are plenty of sizing units in CSS, but these are some of the main ones you’ll use early on. For me, rem is usually the best choice for font sizing, while %, vw and vh are great for building containers and larger layout sections.

Next, let’s look at margin and padding, because choosing the size of an element is only part of the job, spacing it properly matters too.

Margin and padding

Once you’ve sized an element, the next thing to think about is spacing. This is where padding, margin, and borders come in.

Padding is the space inside an element. It sits between the content and the border.

Margin is the space outside an element. It creates distance between that element and the surrounding elements.

Borders sit between the padding and the margin. They wrap around the content and padding, and they can be styled with different widths, colours, and line types.

.box {
  padding: 20px;
  margin: 20px;
  border: 2px solid black;
}

In this example:

padding: 20px adds space inside the box
margin: 20px adds space outside the box
border: 2px solid black adds a visible edge around it

One small CSS trip-up that catches many people is margin collapsing. This usually happens with vertical margins.

If two elements sit on top of each other and both have margins, those margins do not always add up. Instead, they can collapse into one margin, and usually the larger value wins.

.box-one {
  margin-bottom: 20px;
}

.box-two {
  margin-top: 30px;
}

You might expect the total space between these boxes to be 50px, but in many cases it will only be 30px because the margins collapse.

This is one of the reasons I usually prefer using padding for spacing inside sections or containers. Padding feels more predictable, and it’s also often how I create height. Instead of forcing an element to have a fixed height, I’d usually rather let the content define the height naturally and use padding to give it space.

That tends to make layouts more flexible, especially when content changes or grows.

Spacing in CSS gets much easier once you understand where that space is actually being added. And one small reset rule can make this even easier to manage, setting box-sizing properly goes a long way.

Reset script

One of the most useful things you can add at the start of a CSS file is a reset.

Browsers all come with their own default styles. Things like margins, padding, heading sizes, and list spacing are often applied automatically before you write any CSS yourself. That can make your page look inconsistent across elements right from the start.

A reset is simply a way of clearing out some of those browser defaults so you can decide your own starting point.

It doesn’t have to be anything complicated either. A reset can be as small as setting box-sizing, margin, and padding for everything on the page.

*,
*::before,
*::after {
  box-sizing: border-box;
  margin: 0;
  padding: 0;
}

This is a really common place to start.

margin: 0 removes the browser’s default outer spacing
padding: 0 removes the default inner spacing
box-sizing: border-box makes width and height easier to work with, because padding and borders are included in the final size

Without border-box, if you set an element to width: 200px and then add padding, the element becomes wider than 200px. With border-box, the padding stays inside that width, which makes layouts much easier to control.

The nice thing about resets is that they can grow with you. You can start with a very basic one like this, and then build on it over time as you get more comfortable with CSS and figure out what defaults you do or don’t want.

So a reset isn’t really about deleting styles for the sake of it, it’s about giving yourself a cleaner and more predictable starting point.

Conclusion

CSS can feel frustrating at first, but once you understand the basics, it starts to make a lot more sense.

We’ve covered selectors, combinators, pseudo-classes, specificity, sizing, spacing, and resets, all the core pieces that help you build and style pages with more confidence.

The more you understand plain CSS, the easier it becomes to use any styling tool built on top of it, including Tailwind.

Start simple, keep practising, and over time CSS becomes a lot less of a struggle and a lot more of a tool you can rely on.

Conquering Tutorial Hell

Brendon O'Neill — Thu, 26 Mar 2026 11:27:42 +0000

Tutorial hell is something most developers hit at some point. I’ve been there myself, and to be honest, I still slip back into it now and again.

You follow along with a tutorial, everything makes sense, the project works… and then the moment you try to build something on your own, you hit a wall.

That’s usually the sign.

If you can’t create what you just learned without following step by step, then you’re relying on the tutorial more than you think.

In this blog, I’m going to walk through how I deal with tutorial hell and what has helped me move away from relying on it too much.

Recognising the Problem

Tutorials feel productive. You’re watching, typing, and seeing results straight away. But a lot of the time, you’re copying patterns without fully understanding them.

A simple way to see if you’ve fallen into tutorial hell is this:

Close the tutorial and try to rebuild a small part of it.

Can you do it?

If not, then you’re probably following along rather than actually learning. That’s not a failure, it just means you haven’t fully absorbed it yet.

The mistake is going straight back to another tutorial instead of slowing down and figuring out where the gap is. Are you actually coding along? Do you understand what each part is doing?

When you learn something new, test yourself on it. Try to break it. Change things. Ask yourself why it works the way it does.

You don’t need to memorise everything. No one does. What actually matters is knowing that something exists and knowing where to find it again.

That’s why it helps to collect your own resources. Documentation, articles, small notes, anything you can quickly refer back to when you get stuck. That way, you’re not starting from scratch every time.

Short Sessions Still Count

There’s this idea that you need long, focused hours every day to make progress. That’s not always realistic.

You can learn a lot in 20 to 30 minutes.

It might just be revising a concept. It might be understanding one small part of something that confused you yesterday. But those small sessions add up quickly.

Consistency matters more than cramming everything into one long session and burning out.

Sometimes it’s as simple as messing around with small things. Why do var and let behave differently? Why do closures work the way they do? Taking a bit of time to explore these small questions builds a much stronger understanding over time.

Start Building (Without a Tutorial)

This is the part most people avoid, because it’s uncomfortable.

Pick something small and try to build it without following a guide.

It will be messy. You will get stuck. Things won’t work the first time. That’s normal.

Some of my older projects are rough. Some barely worked the way I intended. But they were built from what I understood at the time.

Here’s an example of one of my first projects, built with basic HTML, CSS, and JavaScript:

Example project

And my first version of my portfolio:

Old version portfolio

Compare that to some of my newer work:

The difference is clear.

That progress didn’t come from watching more tutorials. It came from actually trying, failing, and figuring things out.

That’s where things start to click.

Challenge Yourself

Once you’re a bit more comfortable, push yourself into something new.

Pick a topic you don’t fully understand and build a small throwaway project around it. It doesn’t need to be perfect or even useful. The goal is to explore and learn.

When you remove the pressure of building something "important", it becomes easier to experiment, make mistakes, and actually understand what you’re doing.

I never thought I would be tackling backend development a couple of years ago, but I took that step and challenged myself to understand it.

I failed a lot. Things didn’t work the way I expected. But I learned from each attempt.

I went from having a very basic understanding of Node.js endpoints to working with Docker containers and creating child processes to encode videos using FFMPEG.

That kind of progress only happens when you push yourself outside of what feels comfortable.

Conclusion

Tutorials aren’t bad. They’re a great way to get introduced to something new. The problem is staying there too long.

At some point, you need to step away and try things on your own.

You don’t need to remember everything. You don’t need hours every day. You just need to be consistent, curious, and willing to struggle through the parts that don’t make sense yet.

That’s how you get out of tutorial hell.

The AI Stepping Stone

Brendon O'Neill — Fri, 27 Feb 2026 14:47:49 +0000

Introduction

There has been a lot of noise around AI lately. Some people treat it like a shortcut that removes the need to learn anything. Others treat it like a competitor that is coming to replace developers entirely. I see it differently.

If you use it properly, AI can speed up your learning in ways we didn’t have access to a few years ago. It’s not there to replace your thinking, it’s there to challenge it, refine it, and sometimes explain things in ways that finally make them click.

I used AI to improve my understanding of backend development. I only had a basic understanding of handling API endpoints. But by using AI alongside official documentation, I was able to build a media upload application for a wedding that ran without any hiccups. Along the way, I learned how to set up a VPS, configure S3 buckets for file storage, and use a PostgreSQL database to manage file information properly.

That’s the key difference. AI should support your learning, not do it for you.

Planned Study

Before jumping into any topic, create a rough plan of what you actually want to learn. Be specific. Do you want to understand authentication at a high level, or do you want to deeply understand JWTs, sessions, cookies, and their security implications?

Once you know the scope, you can ask AI to structure a learning roadmap for you. For example, you might say:

“Create a structured plan to learn Node.js for backend development.”
“Break this into beginner, intermediate, and advanced topics.”
“Suggest practical exercises for each stage.”

This gives you direction instead of random information.

You can also control the depth. If you want a surface-level understanding first, say that. If you want deep technical explanations, say that too. The quality of what you get depends heavily on how clearly you ask.

Explain how you prefer to learn. You might even provide an example of the structure you like. Maybe you prefer visual breakdowns of concepts, or maybe you like topics chunked into smaller pieces. When I’m using it, I often ask it to go line by line through code and explain exactly what is happening. That level of detail helps everything settle properly.

And if you’re unsure or not confident in its answer, ask for references. Ask where the information is coming from. Then go and read the documentation yourself. AI is powerful, but your real confidence comes from verifying and understanding the source material.

Dumb It Down

One of the most underrated ways to use AI is to ask it to simplify things.

There will always be topics that just don’t click the first time. Maybe it’s closures in JavaScript. Maybe it’s event loops. Maybe it’s how databases handle indexing. Instead of pretending you understand it, lean into it.

Ask it to explain the concept like you’re brand new to programming. Then ask it again in more technical detail. Then ask for examples. Then ask for edge cases.

There are no stupid questions here. And honestly, the “stupid” questions are usually the ones that unlock deeper understanding.

Sometimes I’ll even open a completely separate chat dedicated to one topic and just explore it. I’ll ask ten, fifteen, twenty questions on that single idea until I can explain it back in my own words. That kind of focused curiosity builds real skill.

Compare Your Understanding

One of the most powerful techniques is explaining the concept back in your own words.

After you think you understand something, write out your explanation and ask AI to critique it. For example, you might say, “Here’s how I understand how middleware works in Express…” Then paste your explanation and ask it to point out any mistakes, missing details, or areas that need clarification.

This forces you to think instead of passively reading. It also exposes gaps in your understanding that you might not notice on your own. Sometimes you’ll realise you only understood 70% of the concept, and that final 30% is where real confidence is built.

But here’s something important. Don’t treat every response as absolute truth. AI can occasionally fabricate details or confidently present outdated information. That’s why you should double-check critical concepts against official documentation.

Use AI as a reviewer, not as your only source of truth.

Practise

None of this matters if you don’t actually build something.

After learning a concept, create a small throw-away project. It doesn’t need to be perfect. It doesn’t even need to be useful. It just needs to force you to apply what you’ve learned.

You will fail. Something won’t work. You’ll misunderstand part of the implementation. That’s normal. Each failed attempt sharpens your understanding.

And sometimes, while experimenting, you’ll stumble across a completely new idea. A small test project might turn into a portfolio piece. A random experiment might turn into your next main application.

AI can guide you, but your hands on the keyboard is where the real growth happens.

Conclusion

AI is not your competition. It’s a tool. Like a calculator for math or Stack Overflow for debugging, it becomes powerful when you use it intentionally.

The doom and gloom around AI replacing developers can be discouraging, especially if you’re still learning. But tools don’t remove skill, they shift it. The developers who grow the fastest will be the ones who learn how to work with AI, not fear it.

Use it to plan. Use it to simplify. Use it to challenge your understanding. But always think for yourself and always build.

If you approach it the right way, AI won’t replace your skills. It will help you sharpen them.

If you enjoyed this blog and want to keep learning, check out these other blogs of mine:

Thanks for reading, and happy coding.

Hyu-Sync (My accidental colour picker)

Brendon O'Neill — Tue, 17 Feb 2026 14:32:08 +0000

Site: https://colour.ko-do.dev

This project started as a simple experiment: I wanted to learn how to build a colour picker using the Canvas API. It quickly grew into a full website where I pulled together tools and ideas from the colour-related sites I’m always using.

At its core, the site is a colour picker that lets you select two colours and then checks contrast ratios against black, white, and the second selected colour. The goal is to make it easy to see whether your choices meet WCAG accessibility contrast standards.

You can also type colours directly into a text input to view their different values. Right now, the supported formats are HSL, Hex, and RGBA (with plans to expand this later).

To make experimenting easier, I built a colour history section so you can quickly reselect colours you’ve already tried. Under that, there’s a set of common colour harmonieslike Complementary, Analogous, and Monochromatic, to help with palette building.

I also worked on improving repeat load performance. When you revisit the site, I store a blob of the canvas image and repaint it after reload, so the picker can restore faster. Colour history is saved in local storage as well, so it persists through refreshes.

Finally, there’s a section for palettes I like, and I’ll be adding more as I find them.

Planned features:

Gradient creator
Locally stored custom colour palettes
More colour harmonies
More supported input formats

Known Errors/Bugs

On rare occasions, the colour image isn't grabbed from indexDB
Screens under 380px width UI shifts out of containers.
screen size of around 768px is using the mobile version and pushed to the side.

Sorting Simply: Getting Started with Bubble Sort

Brendon O'Neill — Fri, 06 Feb 2026 12:07:51 +0000

Introduction

As we reach the doubly linked list in the DSA journey, it’s a good point to take a small detour away from data structures and start focusing on algorithms. Up until now, we’ve been learning how to store and organise data. From here on, we’ll begin looking at how we actually work with that data by following a set of defined rules.

The two main types of algorithms we’ll focus on are sorting and searching. These algorithms are designed to help us locate or organise information in a list more efficiently, rather than checking each value one by one.

Sorting plays a huge role in performance. Many searching algorithms rely on data being ordered beforehand, and without that structure, even simple searches can become unnecessarily slow. In this blog, we’ll start with one of the most basic sorting algorithms to understand the core idea before moving on to more efficient approaches later on.

Why do we need to sort

When we search through a list that isn’t sorted, finding a specific piece of information becomes much harder. In the worst case, we might have to check every single value until we find what we’re looking for.

Think of it like a phone book with no order at all. If the names weren’t sorted alphabetically, you’d have to scan through every entry from start to finish just to find one number. If there were hundreds of thousands of names, that would take a long time.

Sorting solves this problem by putting data into a predictable order. Once the data is sorted, we can make smart jumps instead of checking each item one by one. Now, if we have data sorted in our phone book, we can jump straight to the section for a specific letter, instantly narrowing down the search space.

This is why sorting is so important. It makes searching faster, more efficient, and far more scalable as your data grows.

With that foundation in place, let’s start with the most basic sorting algorithm. It’s quick and dirty, not the most efficient, but it’s a great way to understand how sorting works at a fundamental level.

Bubble sort

Bubble sort is one of the simplest sorting algorithms you’ll come across. It’s not fast, and it’s definitely not efficient for large datasets, but it’s a great place to start because the logic is easy to visualise and understand.

Imagine a row of bubbles rising through water. The larger bubbles naturally float upward faster than the smaller ones. Bubble sort works in a very similar way. As we move through the list, larger values gradually “bubble up” toward the end of the array, while smaller values sink toward the beginning.

The algorithm repeatedly steps through the list, comparing two neighbouring values at a time. If they’re in the wrong order, we swap them. After one full pass, the largest value has floated all the way to the end. With each additional pass, the next-largest value finds its correct position, and the unsorted portion of the list becomes smaller and smaller.

Let’s look at the implementation:

for (let i = 0; i < arr.length; i++) {
  for (let j = 0; j < arr.length - i - 1; j++) {
    if (arr[j] > arr[j + 1]) {
      let temp = arr[j];
      arr[j] = arr[j + 1];
      arr[j + 1] = temp;
    }
  }
}

How It Works

We use two loops:

The outer loop controls how many passes we make through the array.
The inner loop compares each value with the one next to it.

On each pass:

We compare arr[j] and arr[j + 1]
If the left value is greater than the right, we swap them
The largest value moves toward the end of the array

Notice the condition arr.length - i - 1 in the inner loop. Each time we complete a full pass, the largest remaining value is guaranteed to be at the end, so we don’t need to check it again. This slightly improves performance by avoiding unnecessary comparisons.

We repeat this process until every value is in the correct position and the array is fully sorted.

Let’s say we start with this array:

[5, 3, 8, 2]

We compare values from left to right, swapping when needed.

First pass:

[5, 3, 8, 2]   compare 5 & 3 → swap
[3, 5, 8, 2]   compare 5 & 8 → no swap
[3, 5, 8, 2]   compare 8 & 2 → swap
[3, 5, 2, 8]   ← 8 bubbles to the end

The largest value (8) has now floated to the end of the array.

Second pass:

[3, 5, 2, 8]   compare 3 & 5 → no swap
[3, 5, 2, 8]   compare 5 & 2 → swap
[3, 2, 5, 8]   ← 5 bubbles into place

Final pass:

[3, 2, 5, 8]   compare 3 & 2 → swap
[2, 3, 5, 8]   ← fully sorted

Each pass pushes the next-largest value toward the end, just like bigger bubbles rising to the surface. As more values settle into place, the number of comparisons needed gets smaller.

Swapping Values

In the example above, we used a temporary variable to swap values. Another common way to do this in JavaScript is with array destructuring:

[arr[j], arr[j + 1]] = [arr[j + 1], arr[j]];

Both approaches work the same way. The key idea is that we’re simply exchanging two adjacent values when they’re in the wrong order.

Complexity

Time Complexity: (O(n^2)) in the worst case, since we may need to compare every pair of values.
Space Complexity: (O(1)), because we’re sorting the array in place without using extra memory.

Bubble sort isn’t something you’d use in production for large datasets, but it’s a great starting point for understanding how sorting algorithms work before moving on to faster and more efficient ones.

Conclusion

And that’s our introduction to Bubble Sort, a simple and intuitive sorting algorithm that helps build a strong foundation for understanding how sorting works under the hood.

While it’s not the most efficient option for large datasets, bubble sort is a great learning tool. It shows how values can be compared, swapped, and gradually moved into place by following a clear set of rules.

As you continue through the DSA journey, we’ll build on these ideas with faster and more efficient sorting algorithms, and later combine them with searching techniques to make working with data even more powerful.

If you enjoyed this blog and want to keep learning, check out these other blogs of mine:

Thanks for reading, and happy coding as you keep growing your DSA skills!

Looking Back to Move Forward

Brendon O'Neill — Mon, 19 Jan 2026 14:40:40 +0000

I love looking back on my progress from the previous year and comparing it to where I am now. It really opens your eyes to how much you've grown. You might not realise it, but you are improving. I always have that doubt that I haven't progressed enough.

I began last year with only basic knowledge of the back end. I could handle simple API endpoints and fumbled my way through setting up authentication, hoping that when I tried to host on a site like Render or Vercel, my app would actually run. When it didn't, I'd spend hours trying to figure out what I was doing wrong.

Fast forward to today: I've built back-end systems that handle large files, streaming them to S3 buckets or feeding them into child processes for FFMPEG to encode videos into different formats. I now run Docker containers with custom networks, handle logs in a PostgreSQL database, and create automated backups of my database if it fails.

When it comes to hosting, I now maintain servers on Hetzner that I configure and update weekly. I've hooked up projects to subdomains using Nginx and Docker Compose, and I've grown far more comfortable with Linux, actually understanding what I'm doing on the server now.

I still have my ups and downs with AI and remain on the fence about how much I like it in my workflow, but I can't deny it's helped me become more confident tackling challenges I'd normally put off. Being able to ask those "dumb" questions that make you feel incompetent, or getting explanations for why we do things certain ways, has made understanding complex topics much easier. It can describe details in a more visual, accessible way.

So this year, challenge yourself to build that project you've been avoiding out of fear of failure, or finally learn that skill you've been putting off. Those failures are what help you grow and reach for greater heights.

Just remember: everyone has their own specialities and skill sets. Comparing your growth to others can be a hindrance, but it can also serve as motivation to improve.

Diving Into Doubly Linked Lists

Brendon O'Neill — Tue, 13 Jan 2026 11:55:55 +0000

Introduction

The deeper you go into Data Structures and Algorithms, the more you start noticing patterns. Each new structure doesn't just stand alone, it builds on what came before, layering on complexity while keeping familiar elements that make the learning curve feel less steep.

As I continue my DSA journey, this blog picks up right where my last one left off. If you haven't read it yet, I covered linked lists here the foundation we'll be extending today. This time, we're levelling up to the doubly linked list.

Think of it this way: a regular linked list is like a one-way street. Each node knows where to go next, but it has no memory of where it's been. A doubly linked list? That's a two-way street. Each node still points forward with next, but now it also looks backward with previous.

This simple change unlocks powerful new possibilities. We gain a tail property that works like head in reverse, letting us traverse from back to front just as easily as front to back. I'll show you exactly how that works later on.

By the end of this blog, you'll understand how doubly linked lists operate, how to build one in JavaScript, and why this "upgrade" makes certain operations more flexible even if they require a few extra considerations.

Linked List vs Doubly Linked List

If you recall from my last blog, a regular linked list is a one-way street. Each node only knows what's ahead:

A -> B -> C

This works fine until you need to go backwards. Forgot to handle a value? Tough luck, you're looping back from the start. It's like trying to retrace your steps in a maze where the path behind you disappears.

A doubly linked list fixes this by adding that previous pointer I mentioned. Now each node looks both ways:

Null <- A <-> B <-> C -> Null

Think of it like a text editor's undo/redo history. When you type "Hello", that's a node. When you backspace, that's another. Hit Ctrl+Z and you move previous through your changes. Hit Ctrl+Y and you move next to redo them. Each action remembers what came before and what comes after.

I'll admit, managing those two-way connections can feel like juggling at first, especially when you need to swap nodes around. But once you see the pattern, it clicks. And the payoff is worth it: you get a data structure that's far more flexible for certain problems.

Building a Doubly Linked List

Let's build this from the ground up, starting with the individual nodes.

If you remember from the last blog, a regular linked list node looks like this:

class Node {
  constructor(value) {
    this.value = value;
    this.next = null;
  }
}

value holds the actual data you want to store.
next is a pointer to the next node in the list.
If next is null, that means the node is the end of the list.

Each node holds some data and knows where to find the next one. But it's only looking forward, like a person who never looks over their shoulder.

For a doubly linked list, we just add one more property:

class Node {
  constructor(value) {
    this.value = value;
    this.next = null;
    this.prev = null;
  }
}

That prev pointer is the secret sauce. Now each node can glance backwards at its predecessor, creating those two-way connections we talked about.

Let me show you how this works by manually wiring up three nodes:

const node1 = new Node("A");
const node2 = new Node("B");
const node3 = new Node("C");

node1.next = node2;
node2.prev = node1;
node2.next = node3;
node3.prev = node2;

console.log(node1);
// Null <- A <-> B <-> C -> Null

See how we're creating a chain where each node introduces itself to its neighbours? Node A says "My next is B," and Node B says "My previous is A." It's like a digital handshake in both directions.

Now for the list itself. Since we're building on the linked list foundation, our class structure looks similar, but we need that tail property to track the end:

class LinkedList {
  length = 0;
  head = null;
  tail = null;

  size() {
    return this.length;
  }

  isEmpty() {
    return this.length === 0;
  }
}

Here's what each piece does:

head is our entry point - the first node in the list
tail is our exit point - the last node, which we'll use to traverse backwards
length keeps count, so we don't have to loop through to know how many nodes we have
size() and isEmpty() are convenience methods you'll use constantly

The foundation is set. Now we can start adding the real functionality, beginning with the most common operation: appending new nodes to the end.

Append (Add to End)

Let's start with the most common operation: adding a new node to the end. We call this appending.

Appending means we create a new node and place it after the current last element, making it the new tail.

If the list is empty, this new node simply becomes both the head and tail.

Here's the code:

append(value) {
    let node = new Node(value);

    if (this.head == null) {
      this.head = node;
      this.tail = node;
      this.length++;
      return;
    }

    this.tail.next = node;
    node.prev = this.tail;
    this.tail = node;
    this.length++;
    return
  }

Let's break this down step by step.

First, we create a new node. Then we check if the list is empty, meaning the head is null. If it is, this new node becomes both head and tail since it's the only element.

If the list isn't empty, we do three things:

Set the current tail's next pointer to our new node
Set our new node's prev pointer back to the current tail
Reassign tail to point to our new node (it's now the end)

Then we increment the length and we're done.

Example:

const list = new LinkedList();

list.append("A");
list.append("B");
list.append("C");

console.log(list.head);
// Null <- A <-> B <-> C -> Null

Time Complexity: O(1) we place the new node at the end of the list where the tail is, no traversal needed.
Space Complexity: O(1) we create only one new node regardless of list size.

Prepend (Add to Start)

While append adds to the end, prepend adds a new node to the beginning, right before the current head.

The process is straightforward: create a new node, link it to the existing head, then update the head to point to this new node.

Here's the implementation:

prepend(value) {
    let node = new Node(value);

    if (this.head == null) {
      this.head = node;
      this.tail = node;
      this.length++;
      return;
    }

    node.next = this.head;
    this.head.prev = node;
    this.head = node;
    this.length++;
    return;
  }

If the list is empty, the new node becomes both head and tail, the same as append.

If the list has nodes, we do three things:

Set the new node's next pointer to the current head
Set the current head's prev pointer back to the new node
Reassign the head to point to our new node

Then increment the length.

Example:

const list = new LinkedList();

list.append("A");
list.append("B");
list.append("C");
list.prepend("D");

console.log(list.head);
//  Null <- D <-> A <-> B <-> C -> Null

Time Complexity: O(1) we add the node directly at the start, no traversal needed.
Space Complexity: O(1) only one new node created.

Compared to arrays, where inserting at the start requires shifting every other element, linked lists make this effortless. You just hook up the new node and update a single pointer.

Delete (Remove a Node)

Now that we can add nodes, let's learn how to remove them. The delete() method removes a specific node by its value.

This operation is more involved than adding because we have to handle several edge cases: empty lists, removing the head or tail, and nodes in the middle.

Here's the implementation:

delete(value) {
    if (this.head == null) {
      return "Error: linked list is empty";
    }

    let curr = this.head;

    while (curr !== null) {
    if (curr.value === value) {
      break;
    }
    curr = curr.next;
    }

    if (curr === null) {
        return "Value wasn't in linked list";
    }

    if (curr === this.head) {
        this.head = curr.next;
    } else {
        curr.prev.next = curr.next;
    }

    if (curr === this.tail) {
        this.tail = curr.prev;
    } else {
        curr.next.prev = curr.prev;
    }

    curr.next = null;
    curr.prev = null;
    this.length--;

    return curr;
  }

Here's what happens step by step:

First, we check if the list is empty. If it is, we return an error.

Next, we start at the head and loop through until we find the node with the matching value. If we reach the end without finding it, we return another error.

Once we find the node, we handle four possible scenarios:

If it's the head: Move the head to point to the next node
If it's the tail: Move the tail to point to the previous node
If it's in the middle: Link the node's neighbours directly to each other (bypassing the current node)
If it's the only node: Both head and tail become null

Finally, we clean up by nullifying the removed node's pointers and decrementing the length.

Example:


const list = new LinkedList();

list.append("A");
list.append("B");
list.append("C");

list.delete("B");

console.log(list.head);
// Null <- A <-> C -> Null

Time Complexity: O(n) in the worst case, we might need to traverse the entire list to find the node.
Space Complexity: O(1) we only adjust pointers, no new data is stored.

Deleting can be tricky because you have to reassign all the links correctly. Double-check your logic, especially around the head and tail edge cases.

Get First and Get Last

These methods let you peek at the ends of your list without removing anything.

getFirst() {
  return this.head;
}

getLast() {
  return this.tail;
}

getFirst() → Time: O(1), Space: O(1)
getLast() → Time: O(1), Space: O(1)

Now that we’ve built all the core methods, let’s look at the full linked list.

Below is the complete class setup, including everything we’ve learned from creating nodes to appending, prepending, and deleting.

class Node {
  constructor(value) {
    this.value = value;
    this.next = null;
    this.prev = null;
  }
}

class LinkedList {
  length = 0;
  head = null;
  tail = null;

  size() {
    return this.length;
  }

  isEmpty() {
    return this.length === 0;
  }

  append(value) {
    let node = new Node(value);

    if (this.head == null) {
      this.head = node;
      this.tail = node;
      this.length++;
      return;
    }

    this.tail.next = node;
    node.prev = this.tail;
    this.tail = node;
    this.length++;
    return
  }

   prepend(value) {
    let node = new Node(value);

    if (this.head == null) {
      this.head = node;
      this.tail = node;
      this.length++;
      return;
    }

    node.next = this.head;
    this.head.prev = node;
    this.head = node;
    this.length++;
    return;
  }

  delete(value) {
    if (this.head == null) {
      return "Error: linked list is empty";
    }

    let curr = this.head;

    while (curr !== null) {
    if (curr.value === value) {
      break;
    }
    curr = curr.next;
    }

    if (curr === null) {
        return "Value wasn't in linked list";
    }

    if (curr === this.head) {
        this.head = curr.next;
    } else {
        curr.prev.next = curr.next;
    }

    if (curr === this.tail) {
        this.tail = curr.prev;
    } else {
        curr.next.prev = curr.prev;
    }

    curr.next = null;
    curr.prev = null;
    this.length--;

    return curr;
  }

  getFirst() {
    return this.head;
  }

  getLast() {
    return this.tail;
  }


}

Now that the full class is ready, let’s test it out with a few operations:

const list = new LinkedList();

list.append("A");
list.append("B");
list.append("C");

console.log("First:", list.getFirst().value); // A
console.log("Last:", list.getLast().value);  // C
console.log("Size:", list.size()); // 3

list.prepend("D");
list.delete("B");

console.log("After Updates:");
console.log("First:", list.getFirst().value); // D
console.log("Last:", list.getLast().value);  // C
console.log("Is Empty:", list.isEmpty()); // false
console.log("Size:", list.size()); // 3

Results:

First: A
Last: C
Size: 3
After Updates:
First: D
Last: C
Is Empty: false
Size: 3

Once you run this code, you'll see exactly how nodes connect and adjust as you add or remove data. There's no array indexing, no shifting elements around, everything happens through simple pointer management between nodes.

That's what makes doubly linked lists so powerful: you get a chain-like structure that's both simple and flexible, perfect for dynamic collections where you don't know how much data you'll need to handle upfront.

Extra Methods

I separated these methods because they're a bit more advanced. Once you're comfortable with the core operations, these will give you even more control over your list.

swapValue

This method swaps the values of two nodes without changing their positions.

swapValue(value1,value2) {
    let curr = this.head;
    let node1 = null;
    let node2 = null;

    while (curr !== null) {
    if (curr.value === value1) {
      node1 = curr;
    }
    if (curr.value === value2) {
      node2 = curr;
    }
    curr = curr.next;
    }

    if(node1 === null || node2 === null){
        return "Can't swap values as value is not in list";
    }

    let temp = node1.value
    node1.value = node2.value
    node2.value = temp
    return
  }

Here's what happens:

We traverse the entire list looking for both values. If we can't find either one, we return an error. Once we have both nodes, we use a temporary variable to swap their values.

Time complexity: O(n) since we might need to scan the whole list.
Space complexity: O(1) we're only swapping values, not moving nodes.

insertAt

This method inserts a new node at a specific position.

insertAt(value, pos) {
  if (pos < 0 || pos > this.length) {
    return "Invalid position.";
  }

  const newNode = new Node(value);

  if (pos === 0) {
    newNode.next = this.head;
    if (this.head) {
      this.head.prev = newNode;
    } else {
      this.tail = newNode;
    }
    this.head = newNode;
    this.length++;
    return;
  }

  if (pos === this.length) {
    newNode.prev = this.tail;
    if (this.tail) {
      this.tail.next = newNode;
    }
    this.tail = newNode;
    this.length++;
    return;
  }

  let count = 0;
  let curr = this.head;

  while (count < pos) {
    curr = curr.next;
    count++;
  }

  const prevNode = curr.prev;

  newNode.next = curr;
  newNode.prev = prevNode;
  prevNode.next = newNode;
  curr.prev = newNode;

  this.length++;
}

We handle three cases:

Position 0: Insert at the head using the same logic as prepend
Position at length: Insert at the tail using the same logic as append
Middle position: Traverse to the target position, then insert the new node between prevNode and curr

Time complexity: O(n) in the worst case when inserting in the middle.
Space complexity: O(1)

deleteAt

This method removes a node at a specific position.

deleteAt(pos) {
  if (pos < 0 || pos >= this.length) {
    return "Invalid position.";
  }

  let curr = this.head;

  if (pos === 0) {
    this.head = curr.next;
    if (this.head) {
      this.head.prev = null;
    } else {
      this.tail = null; 
    }
    curr.next = null;
    this.length--;
    return curr;
  }

  let count = 0;
  while (count < pos) {
    curr = curr.next;
    count++;
  }

  const prevNode = curr.prev;
  const nextNode = curr.next;

  prevNode.next = nextNode;

  if (nextNode === null) {
    this.tail = prevNode;
  } else {
    nextNode.prev = prevNode;
  }

  curr.next = null;
  curr.prev = null;
  this.length--;
  return curr;
}

We handle two main cases:

Position 0: Remove the head by moving the head to the next and cleaning up pointers
Other positions: Traverse to the target node, then bypass it by linking prevNode directly to nextNode. If we're removing the tail, we update tail to point to prevNode

We always clean up the removed node's pointers and decrement the length.

Time complexity: O(n) in the worst case
Space complexity: O(1)

These were just some of the more advanced methods you could come across to show how a doubly linked list works.

Conclusion

And that's our deep dive into Doubly Linked Lists, a simple but powerful upgrade to the singly linked list that gives you bidirectional traversal without sacrificing much performance.

Now that you understand how to build and manage one in JavaScript, you've added another versatile tool to your data structure toolkit, one that shines in scenarios like browser history, undo/redo systems, and anywhere you need to move both forward and backwards through data.

If you enjoyed this blog and want to keep learning, check out these other blogs in the series:

Understanding JavaScript Closures

Simple queue system

Helpful resources for your web development journey

Thanks for reading and happy coding as you keep building your DSA skills!

Linked Lists Joins the Fray! (JavaScript)

Brendon O'Neill — Mon, 22 Dec 2025 14:57:15 +0000

Introduction

When learning Data Structures and Algorithms, one of the first things you realise is that they are not just abstract concepts, they are the hidden logic that makes everyday software efficient.

As I continue my DSA study journey, this post is the next step in my ongoing series. The previous one explored hashmaps, stacks, and queues. These three structures handle data efficiently using different patterns of access and order. You can check that one out here.

In this blog, we move on to another fundamental structure that underpins many others, the Linked List.

At first glance, a linked list might look similar to an array since both store collections of items. But the difference lies in how they’re connected. Instead of every item sitting next to each other in memory like an array, a linked list connects elements through pointers, forming a flexible chain that can grow and shrink without rearranging everything.

By the end of this blog, you will understand how linked lists work, how to create one in JavaScript, and how common operations like inserting and deleting elements actually happen under the hood, as we do not have a built-in one in JavaScript.

What is a Linked List?

A linked list is a linear data structure made up of individual elements called nodes, where each node stores two things:

A value, which is the data itself.
A pointer (or reference) to the next node in the sequence.

That pointer acts as a link, joining each node to the next one, which is why it’s called a linked list. Unlike arrays, the nodes aren’t stored next to each other in memory. Instead, each one "knows" where the next is located.

You can imagine it like a chain of connected train carriages.

Each carriage holds some cargo (the value) and a connector (the pointer) that links it to the next carriage.

If you want to add or remove a carriage, you simply adjust the connectors without moving every other one in the chain.

This makes linked lists more flexible than arrays when it comes to inserting or deleting elements. You don’t have to shift indexes or worry about reallocating memory, you just redirect links between nodes.

However, this flexibility comes with a trade‑off. Because elements aren’t indexed by position, finding an element means starting at the head and moving through each node one by one. That’s why linked lists have O(n) access time instead of the O(1) access you get with arrays.

They can also get a bit tricky. When you’re updating pointers between nodes, you often need to store a temporary reference. Without that extra step, it’s easy to accidentally break a link and lose part of the list.

Before we begin coding, let’s break down the two building blocks of a linked list: the Node and the LinkedList class that manages them.

Building the Linked List

To understand how a linked list works, we’ll start from the smallest building block, the Node.

Each node stores a value and a reference (or pointer) to the next node in the list.

In JavaScript, that looks like this:

class Node {
  constructor(value) {
    this.value = value;
    this.next = null;
  }
}

value holds the actual data you want to store.
next is a pointer to the next node in the list.
If next is null, that means the node is the end of the list.

So, if we were to manually connect a few nodes:

const node1 = new Node("A");
const node2 = new Node("B");
const node3 = new Node("C");

node1.next = node2;
node2.next = node3;

console.log(node1);

The result would look something like this:

A -> B -> C -> null

Each node knows where the next one is, that’s all a linked list really is at its core.

Now that we understand how nodes link together, we’ll create a LinkedList class to manage them, adding new nodes, checking the list’s size, and performing operations like append, prepend, and delete.

Let’s start with the basic structure:

class LinkedList {
  length = 0;
  head = null;

  size() {
    return this.length;
  }

  isEmpty() {
    return this.length === 0;
  }
}

Here’s what each part does:

head stores the first node in the list.
length keeps track of how many nodes exist.
size() returns the total number of nodes.
isEmpty() is a quick way to check if the list has no elements.

We’ve now set up the foundation. Next, we’ll add methods that actually make the linked list come alive, starting with how to append new nodes to the end.

Append (Add to End)

Let’s start by adding a new node to the end of our linked list, this process is often called append.

Appending means we create a new node, then place it after the last element currently in the list.

If the list is empty, this new node simply becomes the head.

Here’s what it looks like in code:

append(value) {
  let node = new Node(value);

  if (this.head == null) {
    this.head = node;
    this.length++;
    return;
  }

  let curr = this.head;

  while (curr.next != null) {
    curr = curr.next;
  }

  curr.next = node;
  this.length++;
}

First, we create a node using the Node class, then we check if the list is empty. If so, the new node becomes the head, as this is where we access the linked list through its head.

If the linked list isn't empty, we loop through the nodes using a while loop until we reach the last one, the node where next is null. This means that we have reached the end of the linked list.

Then, we set that node’s next pointer to our new node and increase the length.

A quick example:

const list = new LinkedList();

list.append("A");
list.append("B");
list.append("C");

console.log(list.head);
// Node { value: 'A', next: Node { value: 'B', next: Node { value: 'C', next: null } } }

Results:

A -> B -> C -> null

Time Complexity: O(n) we must traverse the entire list to find the last node.
Space Complexity: O(1) we create only one new node regardless of list size.

Appending is one of the most common list operations, and while it’s linear, it’s still efficient compared to rearranging an array’s memory like you would for insertions there.

Prepend (Add to Start)

While append adds a node to the end of the list, prepend adds one to the beginning, right before the current head.

This operation is actually faster than appending because we don’t need to traverse the entire list.

We simply create a new node and point it to the existing head. Then, we update the head to the new node.

Here’s the implementation:

prepend(value) {
  let node = new Node(value);

  if (this.head == null) {
    this.head = node;
    this.length++;
    return;
  }

  node.next = this.head;
  this.head = node;
  this.length++;
}

We create a new node with the given value. If the list is empty, that node becomes the head.

If not, we point the new node's next to the current head and then resign the head to the new node. Finally, we increase the length to keep the count accurate.

Example:

const list = new LinkedList();

list.append("B");
list.append("C");
list.prepend("A");

console.log(list.head);
// Node { value: 'A', next: Node { value: 'B', next: Node { value: 'C', next: null } } }

Results:

A -> B -> C -> null

Time Complexity: O(1) we add the node directly at the start, no traversal needed.
Space Complexity: O(1) only one new node created.

Compared to arrays, where inserting at the start requires shifting every other element, linked lists make this process effortless.

Delete (Remove a Node)

Now that we can add items to our linked list, it’s time to remove them.

The delete() method lets us remove a specific node by its value.

Deleting in a linked list can be a little more involved than adding, because we need to handle a few special cases:

The list might be empty.
The node we want to remove might be the head.
Or it might be somewhere in the middle or end.

Here’s what the method looks like:

delete(value) {
  if (this.head == null) {
    return "Error: linked list is empty";
  }

  if (this.head.value == value) {
    let head = this.head;
    this.head = head.next;
    head.next = null;
    this.length--;
    return head;
  }

  let curr = this.head;

  while (curr.next != null) {
    if (curr.next.value == value) {
      break;
    }
    curr = curr.next;
  }

  if (curr.next == null) {
    return "Value wasn't in linked list";
  }

  let returningNode = curr.next;
  curr.next = returningNode.next;
  returningNode.next = null;
  this.length--;
  return returningNode;
}

We first check if the list is empty; if so, there is nothing to delete, so we return an error message.

Next, we check the head node matches the value we want to delete. If it does we point to the next node and detach the old one.

Otherwise, we loop through each node until the next one matches the value we want to remove. Once it’s found, we reconnect links by skipping over the target node, effectively "snipping" it out of the list.

Example:

const list = new LinkedList();

list.append("A");
list.append("B");
list.append("C");

list.delete("B");

console.log(list.head);
// Node { value: 'A', next: Node { value: 'C', next: null } }

Result:

A -> C -> null

Time Complexity: O(n) in the worst case, we might need to traverse the entire list to find the node.
Space Complexity: O(1) we only adjust pointers, no new data is stored.

Deleting elements in a linked list is flexible and efficient once you grasp the logic, but it’s also where most pointer mistakes happen.

A single wrong assignment can disconnect part of your list. Always check references carefully when removing nodes.

Get First and Get Last

Once we’ve added and deleted elements, the next step is being able to access specific nodes within the list.

The two simplest operations for this are getFirst() and getLast(). Retrieving the first and last nodes without modifying the list.

Let’s start with getting the first node:

getFirst() {
  return this.head;
}

That’s as simple as it gets. The head of the list is the first node. If the list is empty, this will just return null.

Now for the last node:

getLast() {
  if (this.head === null) {
    return null;
  }

  let curr = this.head;

  while (curr.next !== null) {
    curr = curr.next;
  }

  return curr;
}

We start at the head, we keep moving through the nodes using each next pointer until we find the one whose next is null. That node is the last in the list.

Example:

const list = new LinkedList();

list.append("A");
list.append("B");
list.append("C");

console.log(list.getFirst().value); // A
console.log(list.getLast().value);  // C

getFirst() → Time: O(1), Space: O(1)
getLast() → Time: O(n), Space: O(1), since we traverse through each node to reach the end.

Now that we’ve built all the core methods, let’s look at the full linked list in action.

Below is the complete class setup, including everything we’ve learned from creating nodes to appending, prepending, and deleting.

class Node {
  constructor(value) {
    this.value = value;
    this.next = null;
  }
}

class LinkedList {
  length = 0;
  head = null;

  size() {
    return this.length;
  }

  isEmpty() {
    return this.length === 0;
  }

  append(value) {
    let node = new Node(value);

    if (this.head == null) {
      this.head = node;
      this.length++;
      return;
    }

    let curr = this.head;
    while (curr.next != null) {
      curr = curr.next;
    }

    curr.next = node;
    this.length++;
  }

  prepend(value) {
    let node = new Node(value);

    if (this.head == null) {
      this.head = node;
      this.length++;
      return;
    }

    node.next = this.head;
    this.head = node;
    this.length++;
  }

  delete(value) {
    if (this.head == null) {
      return "Error: linked list is empty";
    }

    if (this.head.value == value) {
      let head = this.head;
      this.head = head.next;
      head.next = null;
      this.length--;
      return head;
    }

    let curr = this.head;

    while (curr.next != null) {
      if (curr.next.value == value) {
        break;
      }
      curr = curr.next;
    }

    if (curr.next == null) {
      return "Value wasn't in linked list";
    }

    let returningNode = curr.next;
    curr.next = returningNode.next;
    returningNode.next = null;
    this.length--;
    return returningNode;
  }

  getFirst() {
    return this.head;
  }

  getLast() {
    if (this.head === null) {
      return null;
    }

    let curr = this.head;
    while (curr.next !== null) {
      curr = curr.next;
    }

    return curr;
  }
}

Now that the full class is ready, let’s test it out with a few operations:

const list = new LinkedList();

list.append("A");
list.append("B");
list.append("C");

console.log("First:", list.getFirst().value); // A
console.log("Last:", list.getLast().value);  // C
console.log("Size:", list.size()); // 3

list.prepend("Start");
list.delete("B");

console.log("After Updates:");
console.log("First:", list.getFirst().value); // Start
console.log("Last:", list.getLast().value);  // C
console.log("Is Empty:", list.isEmpty()); // false
console.log("Size:", list.size()); // 3

Results:

First: A
Last: C
Size: 3
After Updates:
First: Start
Last: C
Is Empty: false
Size: 3

When you run this code, you can see how nodes connect and adjust as data is added or removed.

There’s no array indexing or shifting, everything happens through simple pointer management between nodes.

This chain‑like structure is what makes linked lists both simple and powerful, especially when dealing with dynamic collections of data.

Conclusion

And that’s our overview of Linked Lists, a simple but powerful data structure that forms the base for many others like stacks, queues, and graphs.

Now that you know how to build and manage one in JavaScript, you’ve taken another solid step in understanding how data really moves under the hood.

If you enjoyed this blog and want to keep learning, check out these other blogs:

Thanks for reading and happy coding as you keep building your DSA skills!

Just Keep Coding

Brendon O'Neill — Fri, 12 Dec 2025 13:48:58 +0000

Introduction

We all have those days where we go to fix a bug that we thought was an easy change, but end up spending a chunk of the day trying to solve it. And if we don’t figure it out, it ruins our afternoon, because it’s all we can think about. You start questioning your skills, replaying every step in your head, wondering how something that simple could take this long.

It’s that frustrating loop every developer knows. You try a different approach, read through the documentation, maybe even restart your editor, and yet nothing. Then the self-doubt kicks in: "Am I even good at this? Shouldn’t I know this by now?"

But here’s the truth: it’s completely okay to feel dumb when you’re coding. Every single developer, from beginners to senior engineers, has those exact moments. Coding isn’t just about typing correct syntax; it’s about patience, problem-solving, and sometimes knowing when to step back. Feeling lost or stuck just means you’re doing the hard part of learning.

You're Always Learning (and Forgetting)

One thing I’ve accepted over the years is that you’re never done learning when it comes to coding. Between switching from React to Vue, or juggling Node projects in between, I constantly have to refresh myself on how each framework structures things. I’ll open an older project thinking I remember exactly how the components were wired up, only to realise I’ve forgotten half the syntax.

At first, that used to frustrate me. I’d wonder how I could forget something I’d used a hundred times before. But over time, I realised that it’s not about remembering everything, it’s about knowing where to look when you get stuck. Whether that’s MDN, Stack Overflow, or your own repo from six months ago, being able to find the right answer quickly is far more valuable than trying to memorise every method or lifecycle hook.

That’s the real skill behind good developers, not perfect recall, but adaptability. When you can calmly say, "I don’t remember this, but I know how to figure it out," you’ve already won half the battle.

Story Time: When I Felt Dumb

My most recent experience of feeling dumb happened just a few days ago. I was working on my video converter application, and I’ve dealt with streaming files across Node.js applications plenty of times. I even use stream logging all the time to track app processes and catch random bugs. So this should’ve been familiar territory, right?

This time, though, I managed to make not one, but two mistakes that had me questioning my own sanity.

The first issue started with a file check I wrote. I wanted to make sure all file chunks were available before streaming them into the final file. So I set up a backoff function that would wait up to 15 seconds, checking with fs to see whether each file existed before continuing. Everything seemed fine, files were clearing properly, but during test runs, I noticed some output files were corrupted. I spent a few hours rewriting the function, debugging, stepping through lines, over and over. The files existed, so what was wrong?

And then it hit me. Yes, the files existed, but I never checked their size. My function was happy to pass files that were technically there but completely empty. When I realised what was happening, I just sat there staring at my screen in silence. Hours of chasing what turned out to be a zero-byte issue.

The second problem made me feel just as silly. Once my file check was complete, I started streaming the chunks into a single file. It worked fine for smaller test files, but once I moved to larger ones, I started seeing dropped data. It took me an embarrassing amount of time to remember that I wasn’t handling backpressure from the buffer, meaning the stream was getting overwhelmed and discarding some data mid-way. When I finally spotted it, I just laughed, grabbed a coffee, and stepped away for a bit before fixing it.

Honestly, that short break helped more than anything. It reminded me that being "dumb" isn’t really the issue, being human is. Sometimes you can know exactly what you’re doing, and still miss the simplest detail.

Step Back to Move Forward

That debugging session was a solid reminder that sometimes, the best way to fix your code is to walk away from it. Taking that coffee break wasn’t me giving up; it was me letting my brain cool off long enough to see the problem for what it really was. When you’re staring at the same few lines for hours, you stop reading the code and start seeing what you expect instead. That’s when it's time to step back.

I’ve learned that distance can be one of the best debugging tools. Whether that means going for a walk, switching tasks, or even explaining your code to someone else, that simple shift in perspective can uncover what hours of staring couldn’t. I’ve had times where I’ve spent an entire afternoon lost in code, only for a friend or coworker to glance over and immediately spot the issue I missed. It’s humbling, but also reassuring. Sometimes you just need another pair of eyes to break that tunnel vision.

And it’s not just about taking breaks in the moment, sometimes looking back at your old code can show you how far you’ve actually come. You’ll spot areas you’d now do differently, logic that could be cleaner, or patterns you didn’t even know existed at the time. It’s easy to forget your own progress when you’re deep in day-to-day problem solving, but seeing how much your style and understanding have evolved can be a great reminder that growth often happens quietly.

The truth is, it’s okay to need that kind of reset. Coding isn’t meant to be a never-ending grind of perfect focus. Every mistake, delay, or confused moment you have is also your brain learning how to handle problems better next time. A short break, a new perspective, or even a quick scroll through your old code can save you from burning out over something you’ll probably laugh about tomorrow.

You Won’t Be Good at Everything

Another thing that took me a long time to accept is that you’re not going to be good at everything and that’s completely fine. The tech world is huge. Even if you stay inside your favourite ecosystem, there’s a never-ending list of tools, frameworks, and libraries. You might spend months getting confident with React only to switch to Vue and feel like you’re starting from zero again.

Trying to master everything is impossible, and honestly, it’s not even necessary. The more you work on stuff, the more you realise that being a good developer isn’t about knowing everything, it’s about knowing your strengths, being curious, and staying adaptable. You start to specialise naturally in certain topics, tools, or technologies that fit the way you think. That’s how you build depth, not by chasing every new thing, but by growing where your curiosity pulls you.

The comparison trap is easy to fall into. We scroll through social media or see someone building something clever and start wondering if we’re behind. You’re not. Everyone’s brains work differently, and everyone’s path through tech looks different. What matters is that you keep learning, keep experimenting, and give yourself permission to not know everything right away.

Conclusion

Feeling dumb when you code doesn’t mean you’re a bad developer, it means you’re a real one. Every bug you chase, every "how did I miss that?" moment, every hour spent rereading documentation just to remember how something works, that’s all part of the process. Those moments are shaping how you think, debug, and approach problems in the future.

And when you look back at your old code, you start to realise how far you’ve actually come. The parts that once confused you now make sense. The messy logic that once felt "good enough" now sparks better ideas. That reflection isn’t about cringing, it’s about celebrating growth. You’ve improved quietly through every frustrating session and late-night "aha!" moment.

So when you catch yourself in that spiral of frustration, take a breath. Step away from the screen, talk it through, or revisit your older work to see how much progress you’ve already made. This isn’t about being perfect, it’s about persisting, learning, and giving yourself room to grow.

Next time you feel dumb after hours of debugging, remember: you’re not failing, you’re evolving.

Your DSA Toolkit: Hashmaps, Queues & Stacks (JavaScript)

Brendon O'Neill — Fri, 05 Dec 2025 12:09:36 +0000

Introduction

As I continue my DSA study journey, this blog is the next step in my ongoing series where I document what I’m learning and hopefully make it easier for others to follow along.

If you missed the previous one, it covered Big O notation and arrays, the foundations of understanding how our code performs and stores data. You can give it a read here

In this blog, we’re going to look at three new data structures: hashmaps, stacks, and queues. These structures appear everywhere, from handling data lookup and caching to managing order in algorithmic operations. They might sound abstract at first, but they’re surprisingly intuitive once you understand their behaviour and when to use them.

By the end, you’ll not only know what each one does, but also why they matter when designing systems, optimising code, or thinking like a developer who really understands how data moves.

Hashmaps

When I first started learning about hashmaps, they sounded like something complicated like hashing a password, but in reality, we use them all the time without realising it. In JavaScript, a hashmap is simply a way to store data as key-value pairs. You give it a unique key, and it quickly gives you back the value that’s linked to it.

In plain terms, you can think of a hashmap as a super‑efficient filing system.

Imagine you’re storing folders in a cabinet, each labelled with a name like "Projects", "Invoices", or "Receipts". When you need one, you don’t check every folder in order; you go straight to the label.

That’s how a hashmap works, it uses a hashing function behind the scenes to jump directly to where the data is stored, rather than searching one by one.

In JavaScript, the simplest way to represent a hashmap is with a plain object.

Objects let us store data by key, which means we can easily access, add, or delete values.

const person = {
firstName: "Simon",
surname: "Jackson",
job: "Painter",
};

console.log(person.firstName); // Simon 
console.log(person["job"]); // Painter

Here, the keys are "firstName", "surname", and "job", and each one is mapped to a string value.

When we access person.firstName, JavaScript doesn’t loop through every key like an array, it goes straight to the value through its internal hashing mechanism.

While objects are great, JavaScript also gives us a built‑in Map class that behaves like an upgraded hashmap.

The key difference is that Map allows any type of key (strings, numbers, even objects), and it remembers the insertion order of elements.

const person = new Map();

person.set("firstName", "Simon");
person.set("surname", "Jackson");
person.set("job", "Painter");

console.log(person.get("surname")); // Jackson

You can also use non‑string keys:

const person1 = { id: 101 };
const person2 = { id: 201 };

const people = new Map();
people.set(person1, "Patrick");
people.set(person2, "Greg");

console.log(people.get(person1)); // Patrick

The Map object stores each key using its own internal hashing process, giving you the same fast access pattern, no scanning, no searching.

Under the hood, a hashmap uses a hash function to convert each key into a unique index in memory (or as close as possible).

This means that instead of searching through every key, the program can access the associated value almost instantly by jumping to its hashed location.

If two different keys happen to produce the same hash (called a collision), the hashmap resolves it by storing multiple values at that index in a small list, but this is mostly abstracted away from us in JavaScript.

Insert

Adding a new entry into your object or map by setting a key-value pair. This has a time complexity of O(1) and space complexity of O(n) overall, since memory grows linearly with the number of stored key‑value pairs.

const cats = {
 tina: {age:10, breed: "ragdoll"},
 bella: {age:12, breed: "tabby"}
}

cats.juno = {age:12, breed: "Bombay"};

console.log(cats);
// {
  // tina: { age: 10, breed: 'ragdoll' },
  // bella: { age: 12, breed: 'tabby' },
  // juno: { age: 12, breed: 'Bombay' }
// }

const dogs = new Map();

dogs.set("Max", {age:5, breed:"cocker spaniel"});
dogs.set("Mellow", {age:2, breed:"golden retriever"});

console.log(dogs.get("Max"));
// { age: 5, breed: 'cocker spaniel' }

Access

After we have provided the object or map with key-value pairs, we can access them by calling the keys we inserted into them. The time complexity is O(1) as it uses the hashing function to jump directly to where the data is stored and the space complexity is O(1) as you are returning the value that was stored.

let cat1 = cats.tina;
let cat2 = cats["bella"];

console.log(cat1) // {age:10, breed: "ragdoll"}
console.log(cat2) // {age:12, breed: "tabby"}

let dog1 = dogs.get("Max")
let dog2 = dogs.get("Mellow")

console.log(dog1) // {age:5, breed:"cocker spaniel"}
console.log(dog2) // {age:2, breed:"golden retriever"}

Update

Updating is very similar to inserting, as you are setting a key-value pair. But instead, we use an already used key and change its value. As it is the same as inserting, it has a time complexity of O(1) and a space complexity of O(1), as you are just updating the key's value.

let person = {
 name: "Ben",
 age: 34
};

person.age = 35;

console.log(person.age); // 35

const person = new Map();

person.set("name", "Ben");
person.set("age", 34);

person.set("name","Sam");

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

Delete

When we don't need a value in our object or map we can delete it using the delete keyword or method. Because we are just removing one key-value pair, the time and space complexity are O(1).

let task = {
 place: "123 Baker Street",
 time: "10.00 pm"
};

delete task.place;

console.log(task); // {time: "10.00 pm"}

let task = new Map();

task.set("place","123 Baker Street");
task.set("time","10.00 pm");

task.delete("time");

console.log(task.get("time")); // undefined

Search

What if we want to check if a key-value pair exists without accessing and returning undefined. This can be done with a method in maps, but not for objects; they can use if statements. The time and space complexity is similar to the access O(1), as we are just returning a true or false if the key exists.

const game = {
genre: "Fantasy"
}

if(game.genre !== undefined)
{
 console.log(true);
}

const game = new Map();

game.set("genre", "Fantasy");

console.log(game.has("genre")); // true

console.log(game.has("name")); // false

Hashmaps are very helpful, as whenever you want a fast lookup or need to associate values to names, IDs, or keys. They’re ideal for counting occurrences of items in an array, storing cached results, tracking unique data and implementing sets or dictionaries.

In short, hashmaps are all about fast access and efficient organisation. But not every data structure prioritises speed, some focus on order. That’s where stacks and queues come in.

Stack

Before we jump into stacks, let's quickly talk about classes in JavaScript, since our example will use one.

A class is like a blueprint for creating objects with shared structure and behaviour. Instead of rewriting similar logic for each object, we can define it once inside a class and then create new instances using it.

Think of a class as a template, it describes what properties and functions its objects will have. When we create an instance with the new keyword, we’re building an individual object based on that blueprint.

class Example {
  constructor(name) {
    this.name = name;
  }

  greet() {
    console.log(`Hello, my name is ${this.name}`);
  }
}

const person = new Example("Alex");
person.greet(); // Hello, my name is Alex

Classes can also have private fields (marked with #), which means their properties can’t be accessed from outside the class. This helps keep internal data safe and predictable, something we’ll see in our Stack example.

What is a Stack

A Stack is a data structure that follows the LIFO principle, Last In, First Out.

This means the last item you add is the first one you take out.

A simple real‑world example is a stack of plates:

You add new plates on top of the pile, and when you remove one, you take from the top first.

Stacks are great for undo features, tracking function calls, and reversing actions, anywhere you need to go back in the reverse order things were added.

Here is a basic example of our stack class without any methods

class Stack{
    #length = 0;
    #data = [];
    #limit = 0;

    constructor(limit = 0)
    {
        this.#limit = limit;
    }
}

In this example, we have three private fields:

length: the size of the array.
data: where we store values we add to the stack.
limit: If we need to provide the stack with a limit.

The constructor checks whether a limit was provided when the class is created and sets it for the stack instance.

Push()

push() adds a new entry to the top of the stack, in our case, to the end of the internal array.

It has a time complexity of O(1) because we’re appending a value directly to the end, and a space complexity of O(1) since we’re only adding a single element.

However, in rare cases, when the array needs to resize its underlying memory, the operation can take O(n) time.

class Stack{

    #length = 0;
    #data = [];
    #limit = 0;

    constructor(limit = 0)
    {
        this.#limit = limit;
    }

    push(value)
    {
        if(!this.checkLimit())
        {
            console.log("Limit reached")
            return 
        }
        this.#data.push(value);
        this.#length++
    }
}

Pop()

pop() removes the top element from the stack, in our case, the last value in the internal array.

It has a time complexity of O(1) because it simply removes and returns the final element, and a space complexity of O(1) overall, since we’re not allocating any new memory.

In the worst case, when internal reallocation happens, it may take O(n) time, but this rarely occurs.

class Stack{
    #length = 0;
    #data = [];
    #limit = 0;

    constructor(limit = 0)
    {
        this.#limit = limit;
    }

    pop()
    {
        if(this.#length == 0)
        {
         console.log("Stack empty");
         return
        }
        this.#length--;
        return this.#data.pop()
    }
}

Peek()

peek() looks at the top element of the stack without removing it.

It has a time and space complexity of O(1), since it only accesses the final item in the array.

class Stack{
    #length = 0;
    #data = [];
    #limit = 0;

    constructor(limit = 0)
    {
        this.#limit = limit;
    }

    peek()
    {
        return this.#data[this.#length - 1];
    }
}

isEmpty()

isEmpty() checks whether the stack is empty.

It’s a simple conditional check, so both its time and space complexity are O(1).

class Stack{
    #length = 0;
    #data = [];
    #limit = 0;

    constructor(limit = 0)
    {
        this.#limit = limit;
    }

    isEmpty()
    {
        if(this.#length !== 0 )
        {
            return false;
        }
        return true;
    }
}

size()

size() returns the number of items currently in the stack.

Like the previous methods, it has a time and space complexity of O(1) because it only reads a stored property without looping or performing additional logic.

class Stack{
    #length = 0;
    #data = [];
    #limit = 0;

    constructor(limit = 0)
    {
        this.#limit = limit;
    }

    size()
    {
        return this.#length;
    }
}

All together with the check limit method:

class Stack{

    #length = 0;
    #data = []
    #limit = 0

    constructor(limit = 0)
    {
        this.#limit = limit
    }

    push(value)
    {
        if(!this.checkLimit())
        {
            console.log("Limit reached")
            return 
        }
        this.#data.push(value);
        this.#length++
    }

    pop()
    {
        if(this.#length == 0)
        {
         console.log("Stack empty");
         return
        }
        this.#length--;
        return this.#data.pop()
    }

    peek()
    {
        return this.#data[this.#length - 1]
    }

    checkLimit()
    {
        if(this.#limit === 0)
        {
            return true
        }

        if(this.#length === this.#limit)
        {
            return false
        }
        return true
    }

    isEmpty()
    {
        if(this.#length !== 0 )
        {
            return false;
        }
        return true;
    }

    size()
    {
        return this.#length;
    }

}

Example of the stack:

const stack = new Stack(3);

stack.push("A");
stack.push("B");
stack.push("C");

console.log(stack.peek()); // C
console.log(stack.size()); // 3

stack.pop(); 
console.log(stack.peek()); // B
console.log(stack.isEmpty()); // false

Stacks are used everywhere in computer science and real‑world applications, like Undo/Redo systems in editors, browser history navigation and in programming when you get a stack overflow when your program crashes.

Stacks give us a way to process data in reverse order, last in, first out. But what if we need to process data in the order it arrived?

That’s where Queues come in.

Queue

A Queue is a data structure that follows the FIFO principle, First In, First Out.

This means the first item you add is the first one to be removed.

A simple real‑world example is a line of people waiting for coffee.

Whoever joins the line first gets served first, and whoever arrives later waits their turn.

Unlike stacks that handle data in reverse order, queues handle data in the order it was added.

They’re especially useful in scheduling systems, task management, and algorithmic problems like breadth‑first search (BFS).

Our Queue basic structure is similar to our stack:

class Queue {
  #data = [];
  #length = 0;
  #limit = 0;

  constructor(limit = 0) {
    this.#limit = limit;
  }
}

enqueue()

enqueue() adds a new item to the end of the queue.

It has a time complexity of O(1) because we append directly to the array, and space complexity of O(1) since only one value is added each time.

If the optional limit is reached, the method prevents additional insertions.

class Queue {
  #data = [];
  #length = 0;
  #limit = 0;

  constructor(limit = 0) {
    this.#limit = limit;
  }

  enqueue(value) {
    if (!this.checkLimit()) {
      console.log("Limit reached");
      return;
    }

    this.#data.push(value);
    this.#length++;
  }
}

dequeue()

dequeue() removes the first element from the queue, the item that’s been waiting the longest.

This operation has a time complexity of O(n) since each removal from the start of an array shifts the remaining elements one position forward.

Its space complexity remains O(1) because we’re not allocating new space.

class Queue {
  #data = [];
  #length = 0;
  #limit = 0;

  constructor(limit = 0) {
    this.#limit = limit;
  }

  dequeue() {
    if (this.#length === 0) {
      console.log("Queue empty");
      return;
    }

    this.#length--;
    return this.#data.shift();
  }
}

peek()

peek() looks at the first item in the queue without removing it.

It has O(1) time and space complexity since it only accesses the first element.

class Queue {
  #data = [];
  #length = 0;
  #limit = 0;

  constructor(limit = 0) {
    this.#limit = limit;
  }

  peek() {
    return this.#data[0];
  }
}

isEmpty()

isEmpty() checks whether the queue currently contains any items.

Both time and space complexity are O(1).

class Queue {
  #data = [];
  #length = 0;
  #limit = 0;

  constructor(limit = 0) {
    this.#limit = limit;
  }

  isEmpty() {
    return this.#length === 0;
  }
}

size()

size() returns the number of items currently in the queue.

This operation is also O(1) for both time and space.

class Queue {
  #data = [];
  #length = 0;
  #limit = 0;

  constructor(limit = 0) {
    this.#limit = limit;
  }

  size() {
    return this.#length;
  }
}

Here’s the complete implementation of our Queue class with all methods combined, including the checkLimit() method to prevent overfilling.

class Queue {
  #data = [];
  #length = 0;
  #limit = 0;

  constructor(limit = 0) {
    this.#limit = limit;
  }

  enqueue(value) {
    if (!this.checkLimit()) {
      console.log("Limit reached");
      return;
    }

    this.#data.push(value);
    this.#length++;
  }

  dequeue() {
    if (this.#length === 0) {
      console.log("Queue empty");
      return;
    }

    this.#length--;
    return this.#data.shift();
  }

  peek() {
    return this.#data[0];
  }

  checkLimit() {
    if (this.#limit === 0) return true;
    return this.#length < this.#limit;
  }

  isEmpty() {
    return this.#length === 0;
  }

  size() {
    return this.#length;
  }
}

const queue = new Queue(3);

queue.enqueue("Task 1");
queue.enqueue("Task 2");
queue.enqueue("Task 3");

console.log(queue.peek()); // Task 1
console.log(queue.size()); // 3

queue.dequeue(); 
console.log(queue.peek()); // Task 2
console.log(queue.isEmpty()); // false

Queues are incredibly common in real‑world programming, like handling asynchronous requests, simulating waiting lines or processes and breadth‑first search (BFS) in data structures like trees and graphs.

In short, if you ever need to process items in the order they arrive, a queue is the perfect tool.

Conclusion

We’ve now added three powerful data structures to your DSA toolkit: hashmaps, stacks, and queues.

Each one solves a different problem: hashmaps for quick lookups, stacks for working in reverse order, and queues for processing tasks in order.

If you enjoyed this post and want to keep learning, check out my other blogs in this series:

Thanks for reading and happy coding as you keep building your DSA toolkit!