DEV Community: Brendon O'Neill

CSS Grid vs Flexbox: Why It's the Wrong Question

Brendon O'Neill — Wed, 01 Jul 2026 14:08:45 +0000

Whenever I read posts online, I keep seeing the same question come up: should I learn Flexbox first or Grid first? Or sometimes, why should I learn Flexbox if I already know Grid?

I completely understand where that question comes from. For a long time, I mainly used Flexbox for most of my CSS layouts. In my head, Grid felt like something you would only use for table-like designs or stiff-looking website structures. I thought Flexbox was the more practical choice for real projects, so I kept reaching for it again and again.

But I was wrong to ignore Grid for so long.

The more I worked on different layouts, the more I realised that only relying on Flexbox was actually limiting me. Some layouts felt harder than they needed to be, and I was spending extra time trying to force one tool to do everything. Once I started using Grid properly, it became much easier to see that Flexbox and Grid are not competing tools. They solve different layout problems, and they work even better when you use them together.

Flexbox is great for one-dimensional layout, while Grid shines in two-dimensional layout. Once you stop asking which one is better and start asking which problem you are solving, layout becomes much easier.

So in today’s blog, I want to go through the real difference between Flexbox and Grid, when each one makes more sense, and why learning both will give you much more control over your layouts.

The real difference between them

Before deciding which one to use, it helps to understand what each one is actually built for. A lot of the confusion around Flexbox and Grid comes from people treating them like they do the exact same job. They don’t.

Flexbox is a one-dimensional layout system. That means it works in one direction at a time, either in a row or in a column. It is really good when you want items to line up nicely, share space evenly, or stay aligned without needing to control the whole page structure.

Grid is a two-dimensional layout system. That means it lets you work with both rows and columns together. Instead of only thinking left to right or top to bottom, you can think about the full layout at once. This makes Grid much better for larger layout structures and for designs where placement matters.

Here is the simplest way I think about it:

Flexbox

One-dimensional
Best for laying items out in a row or a column
Great for alignment and distributing space

Grid

Two-dimensional
Best for controlling rows and columns together
Great for page sections and structured layouts

If I had to explain it in one sentence, I would say this: Flexbox helps you arrange items inside a space, while Grid helps you define the space itself.

That is why Flexbox feels so natural for things like navigation links, buttons, card content, or small groups of elements. You usually just want things to sit beside each other, wrap when needed, and stay nicely aligned. Flexbox handles that really well.

Grid feels better when you already know the structure you want. Maybe you want a sidebar on the left, a header across the top, and a main content area that takes up the rest of the page. Or maybe you want a gallery of cards that fits into clear columns and rows. That is where Grid starts to shine, because it gives you much more control over the overall layout.

A big mistake people make is thinking one of these tools is more modern, more powerful, or a replacement for the other. But really, they are just solving different layout problems. Flexbox is not a lesser version of Grid, and Grid is not just Flexbox with more features. They each have their own strengths.

Once you understand that difference, things start to click much faster. Instead of asking which one is better, you can ask a much more useful question: am I arranging items in one direction, or am I building a layout that needs rows and columns working together?

That question usually points you to the right answer.

Why learning only one causes problems

Once you understand the difference between Flexbox and Grid, the next thing to realise is that only learning one of them can make your layouts harder than they need to be.

You can still build a lot with just one tool, and that is usually why people delay learning the other one. At first, it feels fine. You find a way to make the layout work, the page looks correct, and you move on. But over time, you start noticing that some layouts feel awkward to build, harder to maintain, or more complicated than they should be.

That is usually the point where one tool is being pushed beyond what it is best at.

If you only learn Flexbox

If Flexbox is the only layout tool you are comfortable with, you will probably start using it for everything. I did the same myself. The problem is that while Flexbox is excellent for rows, columns, alignment, and spacing, it can become frustrating when the layout needs more structure.

You may end up forcing complex page layouts into nested rows and columns, adding wrapper after wrapper just to get things into the right place. It works, but it can feel like you are constantly adjusting margins, widths, and alignment rules just to keep everything under control.

This usually leads to a few common problems:

You force complex page layouts into rows and nested wrappers
You end up fighting spacing and alignment
Two-dimensional layouts become harder than they need to be

In other words, Flexbox can handle a lot, but that does not mean it is always the best tool for the job. If the layout depends on both rows and columns working together, Grid will usually get you there faster and with less frustration.

If you only learn Grid

The opposite can happen too. If you mainly learn Grid and try to use it for everything, small interface elements can start to feel more complicated than they need to be.

Grid is great when you want structure and precise placement, but not every part of a layout needs that level of control. Sometimes you just want a few items to sit in a row, space themselves out nicely, or stay centered vertically. That is exactly the kind of job Flexbox is very good at.

If you only rely on Grid, you may notice these issues:

-You may overcomplicate simple UI components

Small alignment tasks can feel awkward
You miss how efficient Flexbox is for buttons, navbars, and card content

So while Grid is powerful, it is not always the quickest or cleanest option for smaller one-direction layouts.

The real issue

Neither tool becomes a problem on its own. The problem starts when you expect one of them to solve every layout task you come across.

That is when CSS starts feeling more difficult than it really is. You are not always struggling because the layout is advanced. Sometimes you are struggling because you are using the wrong layout tool for that specific job.

Learning both gives you more freedom. It means you can stop forcing a solution and start choosing one that fits naturally. And once you get used to that mindset, building layouts becomes much more straightforward.

Next, let’s look at the situations where Flexbox is usually the better choice.

When Flexbox is the better choice

Flexbox is usually the better choice when your layout only needs to move in one direction. That could be a row or a column. If your main goal is to line items up, control spacing, or align content neatly inside a container, Flexbox is often the simplest option.

This is why it shows up so often in everyday interface design. A lot of UI elements are not full page layouts, they are smaller groups of content that just need to sit nicely beside each other or stack cleanly.

Some common examples are:

Navigation bars
Button groups
Centering content
Form controls in a row
Card internals
Toolbars
Tag or chip lists

What makes Flexbox so useful here is that it works well with the natural flow of content. Items can grow, shrink, wrap, and space themselves out without you needing to define a strict structure for every part of the layout.

For example, if you have a row of buttons and one has a longer label than the others, Flexbox handles that naturally. If your navigation links need to spread across the available space, Flexbox makes that easy. If you want to center something both vertically and horizontally, Flexbox is often one of the first tools people reach for because it does that job really well.

Flexbox is especially useful when:

You care about content flow
Items should adapt naturally
Alignment and spacing matter more than rigid placement

That is really the key idea. Flexbox is not about placing everything into a fixed structure. It is about letting content behave more naturally inside the space it has been given.

Here is a simple example:

.navbar {
  display: flex;
  justify-content: space-between;
  align-items: center;
}

With just a few lines, you can place items in a row, push them apart, and line them up vertically. That is part of why Flexbox feels so nice to work with for smaller layout tasks. You can often get the result you want without writing much code.

So if the layout feels like it should grow, shrink, wrap, or align naturally, Flexbox is usually the better choice. It shines when the content itself should help decide how the layout behaves, rather than being locked into strict row and column positions.

Next, we will look at when Grid becomes the better tool.

When Grid is the better choice

Grid is the better choice when your layout needs structure. While Flexbox works well when content flows in one direction, Grid works best when you want to control both rows and columns at the same time.

This is where Grid starts to feel much more powerful. Instead of thinking about one line of items at a time, you can think about the whole layout in one go. You can decide how many columns you want, how rows should behave, and where each section should sit.

That makes Grid especially useful for layouts like:

Page-level layout
Dashboard layouts
Card galleries
Pricing tables
Magazine or article layouts
Any layout with clear rows and columns

For example, if you are building a page with a sidebar, a header, a main content area, and maybe a footer, Grid is usually the cleaner option. You can define the page structure first, then place each section where it belongs. The same goes for card galleries, where you want items to sit in neat columns and wrap into new rows automatically.

Grid is best when:

You want explicit structure
You need rows and columns working together
Placement matters more than natural content flow

That last point is usually what tells you Grid is the right tool. If you already know where things should go on the page, Grid gives you a much clearer way to build that layout.

Here is a simple example:

.layout {
  display: grid;
  grid-template-columns: 250px 1fr;
  grid-template-rows: auto 1fr;
  gap: 1rem;
}

With this, you are not just lining items up in one direction. You are defining a layout system. One column can hold a sidebar, the other can hold the main content, and your rows can separate the header from the rest of the page.

That is why Grid feels so good for bigger layout decisions. You are creating the structure first, rather than trying to shape content into place afterwards.

So if the layout has clear sections, depends on rows and columns, or needs more intentional placement, Grid is usually the better choice. It gives you more control without needing lots of extra wrappers or layout tricks.

Next, we can move on to the section that ties everything together: real projects use both.

Real projects use both

In real projects, I do not usually sit down and say I am only going to use Flexbox or I am only going to use Grid. I try to use the best tool for the situation. That said, sometimes I also use what feels most comfortable if the layout is simple and I know it will not cause problems later.

I think that is a more realistic way to look at it.

A lot of the time, the “best” choice is not about following a strict rule. It is about understanding what the layout needs, what will keep the code cleaner, and what will make the most sense when you come back to it later. Sometimes both Flexbox and Grid could work, but one of them will usually feel more natural once you look at the structure.

That is also why real projects often use both together. One tool handles the bigger layout, while the other handles the smaller pieces inside it.

Here are a few examples of how I approach projects.

For my Kanji learning app, I had a list of kanji to list out and with the flow of the list, it made sense to use flexbox as it allows me to wrap the list once a row is full, as each time the list increases and decreases.

For my colour selection project I mainly used, as I had a set style I wanted that got complex and I needed to format my data to fit into each section that lined up in a clean style.

In my game database project, I used Grid for the layout and Flexbox for the list in each section. This was the first project that I started to use both together and understand the pros and cons of each.

It always comes down to what works best for your situation, and you don't have to follow strict guidelines.

Next is: where do I go to learn about Grid or Flexbox?

Where to learn

So what are the ways you can learn about Grids or Flexbox?

First, there are the MDN docs where you will get a deep explanation of each:

Grid
Flexbox

Second, if you want more of a quick explanation with more visuals, CSS Tricks has a great guide for both:

Grid
Flexbox

Third, maybe you want to play a game while learning each; there are two games: Grid Garden and Flexbox Froggy.

Grid
Flexbox

Finally, if you just want to watch a video on the go, Coding2Go has two great videos on the topics:

Grid
Flexbox

Conclusion

Flexbox and Grid are not competing tools, they just solve different problems. The more you understand what each one does well, the easier it becomes to choose the right one for the layout in front of you.

In real projects, you will often end up using both. And once you stop thinking of it as Flexbox versus Grid, CSS layout starts to make a lot more sense.

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.