DEV Community: Brendon O'Neill

Conquering Tutorial Hell

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

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

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

That’s usually the sign.

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

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

Recognising the Problem

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

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

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

Can you do it?

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

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

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

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

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

Short Sessions Still Count

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

You can learn a lot in 20 to 30 minutes.

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

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

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

Start Building (Without a Tutorial)

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

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

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

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

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

Example project

And my first version of my portfolio:

Old version portfolio

Compare that to some of my newer work:

The difference is clear.

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

That’s where things start to click.

Challenge Yourself

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

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

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

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

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

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

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

Conclusion

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

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

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

That’s how you get out of tutorial hell.

The AI Stepping Stone

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

Introduction

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

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

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

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

Planned Study

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

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

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

This gives you direction instead of random information.

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

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

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

Dumb It Down

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

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

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

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

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

Compare Your Understanding

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

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

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

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

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

Practise

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

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

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

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

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

Conclusion

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

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

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

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

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

Thanks for reading, and happy coding.

Hyu-Sync (My accidental colour picker)

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

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

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

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

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

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

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

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

Planned features:

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

Known Errors/Bugs

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

Sorting Simply: Getting Started with Bubble Sort

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

Introduction

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

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

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

Why do we need to sort

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

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

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

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

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

Bubble sort

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

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

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

Let’s look at the implementation:

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

How It Works

We use two loops:

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

On each pass:

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

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

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

Let’s say we start with this array:

[5, 3, 8, 2]

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

First pass:

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

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

Second pass:

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

Final pass:

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

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

Swapping Values

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

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

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

Complexity

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

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

Conclusion

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

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

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

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

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

Looking Back to Move Forward

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

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

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

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

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

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

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

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

Diving Into Doubly Linked Lists

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

Introduction

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

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

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

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

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

Linked List vs Doubly Linked List

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

A -> B -> C

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

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

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

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

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

Building a Doubly Linked List

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  size() {
    return this.length;
  }

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

Here's what each piece does:

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

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

Append (Add to End)

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

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

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

Here's the code:

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

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

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

Let's break this down step by step.

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

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

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

Then we increment the length and we're done.

Example:

const list = new LinkedList();

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

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

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

Prepend (Add to Start)

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

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

Here's the implementation:

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

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

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

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

If the list has nodes, we do three things:

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

Then increment the length.

Example:

const list = new LinkedList();

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

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

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

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

Delete (Remove a Node)

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

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

Here's the implementation:

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

    let curr = this.head;

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

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

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

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

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

    return curr;
  }

Here's what happens step by step:

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

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

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

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

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

Example:


const list = new LinkedList();

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

list.delete("B");

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

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

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

Get First and Get Last

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

getFirst() {
  return this.head;
}

getLast() {
  return this.tail;
}

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

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

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

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

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

  size() {
    return this.length;
  }

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

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

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

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

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

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

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

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

    let curr = this.head;

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

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

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

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

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

    return curr;
  }

  getFirst() {
    return this.head;
  }

  getLast() {
    return this.tail;
  }


}

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

const list = new LinkedList();

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

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

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

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

Results:

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

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

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

Extra Methods

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

swapValue

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

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

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

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

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

Here's what happens:

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

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

insertAt

This method inserts a new node at a specific position.

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

  const newNode = new Node(value);

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

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

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

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

  const prevNode = curr.prev;

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

  this.length++;
}

We handle three cases:

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

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

deleteAt

This method removes a node at a specific position.

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

  let curr = this.head;

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

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

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

  prevNode.next = nextNode;

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

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

We handle two main cases:

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

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

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

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

Conclusion

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

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

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

Understanding JavaScript Closures

Simple queue system

Helpful resources for your web development journey

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

Linked Lists Joins the Fray! (JavaScript)

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

Introduction

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

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

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

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

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

What is a Linked List?

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

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

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

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

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

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

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

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

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

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

Building the Linked List

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

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

In JavaScript, that looks like this:

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

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

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

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

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

console.log(node1);

The result would look something like this:

A -> B -> C -> null

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

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

Let’s start with the basic structure:

class LinkedList {
  length = 0;
  head = null;

  size() {
    return this.length;
  }

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

Here’s what each part does:

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

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

Append (Add to End)

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

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

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

Here’s what it looks like in code:

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

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

  let curr = this.head;

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

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

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

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

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

A quick example:

const list = new LinkedList();

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

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

Results:

A -> B -> C -> null

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

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

Prepend (Add to Start)

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

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

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

Here’s the implementation:

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

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

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

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

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

Example:

const list = new LinkedList();

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

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

Results:

A -> B -> C -> null

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

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

Delete (Remove a Node)

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

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

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

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

Here’s what the method looks like:

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

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

  let curr = this.head;

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

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

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

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

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

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

Example:

const list = new LinkedList();

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

list.delete("B");

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

Result:

A -> C -> null

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

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

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

Get First and Get Last

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

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

Let’s start with getting the first node:

getFirst() {
  return this.head;
}

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

Now for the last node:

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

  let curr = this.head;

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

  return curr;
}

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

Example:

const list = new LinkedList();

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

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

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

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

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

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

class LinkedList {
  length = 0;
  head = null;

  size() {
    return this.length;
  }

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

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

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

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

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

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

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

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

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

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

    let curr = this.head;

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

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

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

  getFirst() {
    return this.head;
  }

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

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

    return curr;
  }
}

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

const list = new LinkedList();

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

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

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

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

Results:

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

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

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

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

Conclusion

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

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

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

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

Just Keep Coding

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

Introduction

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

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

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

You're Always Learning (and Forgetting)

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

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

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

Story Time: When I Felt Dumb

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

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

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

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

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

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

Step Back to Move Forward

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

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

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

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

You Won’t Be Good at Everything

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

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

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

Conclusion

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

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

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

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

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

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

Introduction

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

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

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

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

Hashmaps

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

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

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

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

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

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

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

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

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

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

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

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

const person = new Map();

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

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

You can also use non‑string keys:

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

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

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

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

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

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

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

Insert

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

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

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

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

const dogs = new Map();

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

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

Access

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

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

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

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

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

Update

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

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

person.age = 35;

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

const person = new Map();

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

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

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

Delete

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

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

delete task.place;

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

let task = new Map();

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

task.delete("time");

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

Search

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

const game = {
genre: "Fantasy"
}

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

const game = new Map();

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

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

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

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

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

Stack

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

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

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

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

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

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

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

What is a Stack

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

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

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

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

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

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

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

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

In this example, we have three private fields:

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

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

Push()

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

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

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

class Stack{

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

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

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

Pop()

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

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

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

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

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

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

Peek()

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

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

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

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

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

isEmpty()

isEmpty() checks whether the stack is empty.

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

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

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

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

size()

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

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

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

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

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

All together with the check limit method:

class Stack{

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

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

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

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

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

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

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

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

    size()
    {
        return this.#length;
    }

}

Example of the stack:

const stack = new Stack(3);

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

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

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

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

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

That’s where Queues come in.

Queue

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

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

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

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

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

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

Our Queue basic structure is similar to our stack:

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

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

enqueue()

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

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

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

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

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

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

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

dequeue()

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

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

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

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

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

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

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

peek()

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

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

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

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

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

isEmpty()

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

Both time and space complexity are O(1).

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

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

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

size()

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

const queue = new Queue(3);

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

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

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

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

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

Conclusion

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

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

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

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

Let's learn Node.js

Brendon O'Neill — Thu, 20 Nov 2025 15:41:20 +0000

Introduction

When I first started using APIs on the frontend, things felt simple. I fetch some data, display it nicely, and done. That worked perfectly until I needed to use an API key. I tried everything to hide it like environment variables, build tools, and even hosting tricks. But no matter what I did, the key still showed up somewhere in the browser. That’s when I learned a hard truth, if the browser can access it, the user can too.

The only way to really protect your API keys is to handle them on a server. Instead of fetching data directly from the client side, your app can send a request to a small server you control. That server then talks to the external API using your keys safely behind the scenes.

In this post, I’ll show you how to build that server yourself using Node.js. We’ll start with the core Node.js setup (no extra packages), then move on to Express to make it cleaner, add routes, serve HTML, and handle common issues like CORS and body parsing. By the end, you’ll see that creating your own backend isn’t hard, it’s just JavaScript with a new purpose.

Node.js basics

Before jumping straight into Express, it’s important to understand what’s happening under the hood. Express is just a library that makes Node.js easier to work with, so let’s start with plain Node, no packages, no shortcuts.

Every Node server starts by using the built-in http module to create and listen for requests. Think of this as Node opening a door (a port) and waiting for someone to knock. Each “knock” is an incoming request, and Node decides how to respond.

Here’s a simple example of a server that handles both GET and POST requests:

// server.js
const http = require("http");

// Basic server setup
const server = http.createServer((req, res) => {
  // Set response headers
  res.setHeader("Content-Type", "application/json");

  // Handle routes
  if (req.method === "GET" && req.url === "/") {
    res.writeHead(200);
    res.end(JSON.stringify({ message: "Hello from Node server!" }));
  } else if (req.method === "POST" && req.url === "/data") {
    let body = "";

    // Collect data chunks from request
    req.on("data", (chunk) => {
      body += chunk.toString();
    });

    // Once all data is received
    req.on("end", () => {
      let parsedData;
      try {
        parsedData = JSON.parse(body);
      } catch {
        parsedData = {};
      }

      res.writeHead(200);
      res.end(
        JSON.stringify({ message: "Data received", data: parsedData })
      );
    });
  } else {
    res.writeHead(404);
    res.end(JSON.stringify({ error: "Route not found" }));
  }
});

// Start server
server.listen(3000, () => {
  console.log("Server is running on http://localhost:3000");
});

Let's break down what is going on in the above code block. First, we use the built-in HTTP module. It handles all communication over HTTP, you don’t need to install anything. Then we call http.createServer() to create the server. This method listens for incoming requests and runs a callback for each one. The callback receives two arguments:

req (request): contains all the details about the incoming request such as the URL, method, headers, and body.
res (response): used to send data back to whoever made the request.

Because we want the browser to understand our response, we set a response header with res.setHeader("Content-Type", "application/json"). Headers are pieces of metadata sent with each request or response. They tell the receiver how to interpret the data being transmitted, for example, what format it’s in or how it should be cached.

Inside the if block, we handle both the GET and POST requests. For the GET request, we check if the method is "GET" and the endpoint is /. Endpoints are the paths added to your domain, like /feed/subscriptions in https://www.youtube.com/feed/subscriptions. Here, our root ( / ) is the home endpoint. We respond with status 200 and send a JSON object back to the client.

For the POST request, we handle incoming data. The req.on("data") event receives small pieces of the request body called "chunks". These are combined into one string and then parsed into an object when the req.on("end") event fires. After parsing the body, we return a JSON response confirming the data was received.

Finally, we start the server with server.listen(3000), telling Node to listen for connections on port 3000. Visiting http://localhost:3000 will show your first response from Node. We can test this by running it in the terminal with "node server.js".

At this stage, you now have a functioning backend that accepts requests, responds to clients, and can handle incoming data. But managing routes and parsing bodies manually like this can quickly get messy as your app grows.

That’s where Express comes in, it simplifies everything we just built into shorter, cleaner, and easier-to-read code.

Express

After writing your first Node server, you might have noticed how repetitive it can get. You have to check the request method, compare URLs, manually parse body data, and write custom responses every single time. Once your app has more than a few routes, this gets complicated quickly.

That’s where Express comes in. Express is a small library built on top of Node’s http module, designed to make creating APIs and serving web content simpler. It doesn’t replace Node, it just gives us the tools to write cleaner, more manageable code.

To get started, open your project in a terminal and run:

npm init -y
npm install express

This installs Express and creates a simple package.json file. Then create a file named server.js and add the following:

// server.js
const express = require("express");
const app = express();
const PORT = 3000;

From here, we’ll break down how Express simplifies our Node server with middleware and endpoints.

Middleware

Middleware is what makes Express flexible and clean.

It acts like a series of checkpoints or layers that your request passes through before reaching its destination (your endpoint). Each layer can modify the request, check for conditions, or even stop it completely. It’s your chance to prepare data before sending a response.

// Middleware to log every request
app.use((req, res, next) => {
  console.log(`${req.method} - ${req.url}`);
  next(); // move to the next middleware or route
});

// Middleware to parse incoming JSON bodies
app.use(express.json());

Here’s what’s happening, the first middleware logs the method and URL of every request. This is useful for debugging or just seeing what the frontend is sending. The second middleware, express.json(), automatically parses JSON data that comes from POST requests and attaches it to req.body. In the plain Node example earlier, we had to manually listen for "data" and "end" events. Express takes care of all that for you.

Endpoints

Endpoints are the different paths or “addresses” of your backend where specific actions happen. In Express, defining them is simple, you just call a method for the HTTP verb (get, post, put, delete) and assign it a path. Let’s recreate our Node example using Express routes:

// GET endpoint
app.get("/", (req, res) => {
  res.json({ message: "Hello from Express server!" });
});

// POST endpoint
app.post("/data", (req, res) => {
  const data = req.body;
  console.log(data);
  res.json({ message: "Data received", data });
});

Let’s break down what’s happening. The GET "/" is when someone goes to the root of your site (http://localhost:3000/) with a GET request, which sends a simple JSON message back. The POST "/data" is when someone sends a POST request to /data, Express automatically parses the body and stores it in req.body. We can immediately access and use that data.

And finally, don’t forget to tell your app to listen for connections:

app.listen(PORT, () => {
  console.log(`Server running on http://localhost:${PORT}`);
});

All together now:

const express = require("express");
const app = express();
const PORT = 3000;

app.use((req, res, next) => {
  console.log(`${req.method} - ${req.url}`);
  next();
});

app.use(express.json());

app.get("/", (req, res) => {
  res.json({ message: "Hello from Express server!" });
});

app.post("/data", (req, res) => {
  const data = req.body;
  console.log(data);
  res.json({ message: "Data received", data });
});

app.listen(PORT, () => {
  console.log(`Server running on http://localhost:${PORT}`);
});

Now your Express version of the server is fully working. You can send a GET request to see the welcome message, or send a POST request to see the data returned.

Here is an example form to test the post:

<!DOCTYPE html>
<html>
    <head>
        <meta charset="utf-8">
        <meta http-equiv="X-UA-Compatible" content="IE=edge">
        <title></title>
        <meta name="description" content="">
        <meta name="viewport" content="width=device-width, initial-scale=1">
        <link rel="stylesheet" href="">
    </head>
    <body>
        <form>
            <label for="userName"> Name
                <input type="text" name="userName" id="userName">
            </label>
            <label for="userAge"> Age
                <input type="number" name="userAge" id="userAge">
            </label>
            <input type="submit" id="userSubmit" value="Send">
        </form>
        <script>
            const submit = document.getElementById("userSubmit");

            const userName = document.getElementById("userName");
            const userAge = document.getElementById("userAge");


            submit.addEventListener("click", (e) => {
                e.preventDefault();
                fetch("http://localhost:3000/data",{method: "POST", body: JSON.stringify({userName: userName.value, userAge:userAge.value}), headers: { "Content-Type":"application/json"}})
            })
        </script>
    </body>
</html>

Express has now replaced all the manual work we did earlier with just a few lines of code, and it’s much easier to expand.

When you try sending the form data, you might see this error in your browser console:

Access to fetch at 'http://localhost:3000/data' from origin 'http://localhost' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource.

This is a common next step every frontend developer hits a CORS (Cross-Origin Resource Sharing) issue.

Let’s talk about what it means and how to solve it.

CORS

What is CORS?

CORS stands for Cross-Origin Resource Sharing. It’s a security feature that browsers use to control how web pages from one website (or origin) can request data from another.

Here’s a quick way to think about it:

Imagine you’re visiting a restaurant (your browser) and ordering food (data) from the kitchen (a server). Normally, you can only order from the kitchen that belongs to that restaurant (the same origin). If you suddenly start ordering from a kitchen next door (another origin), the restaurant wants to make sure it’s allowed, so it asks the other kitchen for permission before delivering that food to you.

That permission step is what CORS handles. It makes sure your browser doesn’t just start pulling sensitive data from any random site on the internet.

To fix our problem, we need to install CORS package:

npm install cors

Now update the server file with this:

const express = require("express");
const cors = require("cors");
const app = express();
const PORT = 3000;

app.use(cors()); // Enable CORS for all routes
app.use(express.json());

That one line app.use(cors()); tells Express to automatically add the correct CORS headers, which basically say: "It’s okay for any origin to access this server." Now, if you reload your form page and server, then send data again, the error disappears. Everything works.

While allowing all origins is great for testing, in production you’ll probably want to limit who can access your server. Let’s change the configuration to only allow requests from the frontend running on your own localhost:

app.use(
  cors({
    origin: "http://localhost:5500", // replace with your actual frontend port
  })
);

Now, if someone tries to send a request from any other site or port, the browser will block it again. This is how you keep your API open for the right users while still staying secure. If you’re unsure what origin to use, open your frontend in the browser and check the URL bar, everything before the first / after the domain is your origin.

Other Common Trip-Ups

While you’re working with Node and Express for the first time, you might bump into a few other common issues.

Forgetting to use express.json()

If your server logs undefined instead of the request body, make sure you’ve added app.use(express.json()) before your routes. Without it, Express doesn’t parse incoming JSON.

Using the wrong fetch Content-Type

When sending JSON from the frontend, always include the header. Otherwise, the body won’t be parsed correctly:

headers: { "Content-Type": "application/json" }

Not restarting the server

Remember, changes to your backend code don’t auto-refresh. Use a tool like nodemon for development so it restarts automatically whenever you save.

Each of these is completely normal to run into, especially when you’re connecting your frontend and backend for the first time. Now that CORS is sorted out and your server can talk safely with your frontend, you can start building more interesting connections, like serving HTML pages, fetching data from external APIs, or even adding authentication.

Serving HTML and Handling API keys

Now that our server can handle requests safely, let’s bring everything full circle, serving content and making API calls securely.

Serving HTML with Express

You can serve an HTML page directly from your server using sendFile(). First, create a folder called public and drop your HTML form inside it, e.g. public/index.html.

Then, update your server.js:

const path = require("path");
app.use(express.static("public"));

app.get("/", (req, res) => {
  res.sendFile(path.join(__dirname, "public", "index.html"));
});

Now, when you visit http://localhost:3000, your form loads directly from the server, no more “file://” setup issues, and it’s easier to pair frontend and backend together.

Connecting to an External API

Let’s go back to the reason we started all this, keeping API keys safe. Instead of calling a third‑party API directly from the browser, you send the request to your server, and it calls the external API for you.

app.get("/weather", async (req, res) => {
  try {
    const response = await fetch(
      `https://api.open-meteo.com/v1/forecast?api_key=12345`
    );
    const data = await response.json();
    res.json({ weather: data.current_weather });
  } catch (error) {
    res.status(500).json({ error: "Failed to fetch weather data" });
  }
});

The browser never sees your API key or the third‑party URL directly, it just communicates with your server, and the server handles the rest behind the scenes.

Conclusion

You’ve now created a simple but complete setup. A backend built with Express handling both GET and POST requests, CORS configured safely and a route that can call external APIs securely.

It’s the same JavaScript you already know, just running in a different space. From here, you can connect your server to a database, deploy it to a platform like Render or Vercel, or build your own small API for other apps to use.

That one small step, moving your API calls to Node, you can start your backend journey.

DSA: Array (JavaScript)

Brendon O'Neill — Fri, 14 Nov 2025 15:21:54 +0000

Introduction

Every time I start diving into Data Structures and Algorithms, I tell myself, “This time, I’ll stick with it.” I usually get as far as learning about graphs, and then I find myself distracted by, maybe a project breaks and needs refactoring, or I remember a topic I wanted to research and lose track of my DSA studies. I often tell myself “I do front-end, it’s not that important, I’ll learn it later.” But now that I’ve gone deeper into back-end programming, I keep seeing DSA (Data Structures and Algorithms) mentioned, and I know it’s time to really learn them.

So this post is part of my self-study journey. I’m using it as a reference to recall key concepts as I go, but I also hope it helps others who are starting their DSA studies or, like me, need a refresher.

To begin, I’ll focus on Big O notation, what it means and why it’s important and then look at arrays, one of the most common data structures in JavaScript. Arrays are a great way to connect how time and space complexity actually apply in practice.

Big O notation

When you start looking into DSA, one of the first things you’ll come across is Big O notation. At first, it looks like strange math symbols with a weird graph that people casually throw around, but it’s really just a way to describe how efficient a piece of code is as the amount of data grows.

Big O helps us measure how long it might take to run a piece of code (time complexity) or how much memory it uses (space complexity). It’s not about the exact time your code runs, it’s about how it scales.

The way I like to think about Big O is how we do tasks in life. If I have a list of 20 names in alphabetical order, I could scan the list name by name to find the one I’m looking for. That could work each time, but what if I had a phone book of names and tried to start from the beginning and read every name? That could take hours and isn’t the best way to achieve our goal.

Instead, we look for the first letter of the name and remove 25 sections of the book down to one. Then we do the same for the second letter until we find the name or not. This is like using an algorithm to speed up the search.

Great Site with a clear graph

Constant Time O(1)

Constant time is one of the fastest time complexities, as we don’t need to look over the whole array. Since we already know the index of the value we want, we can directly access that one index to get our value.

let numbers = [2, 4, 6, 8, 10];
console.log(numbers[0]); // 2

Linear Time O(n)

Linear time is like a loop that goes through an array from start to finish. We look at each value one by one. This array can be any size and still be considered linear time, as we will check each value in the array.

let numbers = [2, 4, 6, 8, 10];

for (let i = 0; i < numbers.length; i++) {
    console.log(numbers[i]); // 2 4 6 8 10
}

Quadratic Time O(n²)

Quadratic time is when there is a loop within a loop. It takes longer because for each element in the outer loop, we also run through the entire inner loop.

let values = [[1,2,3],[4,5,6],[7,8,9]];

for (let i = 0; i < values.length; i++) {
    for (let j = 0; j < values[i].length; j++) {
        console.log(values[i][j]);
    }
}
// 1 2 3
// 4 5 6
// 7 8 9

When people talk about Big O, most of the focus goes toward time, how fast the code runs, but space complexity is just as important. Space complexity is about how much extra memory your code needs to complete its task. If the logic in your function creates new variables, copies arrays, or stores temporary data, all of that uses extra space. Sometimes it’s unavoidable, sometimes it’s just a side effect of how a problem is solved.

Constant Space O(1)

Constant space uses the same amount of extra memory regardless of the input size. As it is a single value, it is considered constant space, as we don't need to loop over it like an array.

let number = 0;

Linear Space O(n)

Linear space uses memory proportional to the size of the input. As an array gets more values, the larger our memory grows as the array grows.

let numbers = [1,2,3,4,5,6,7,8,9,10];

Quadratic Space O(n²)

Quadratic space is memory usage that grows with the square of the input size. As you create nested arrays, the memory usage grows at a larger rate.

let numbers = [[1,2,3],[4,5,6],[7,8,9],[10]];

Big O notation isn’t just theory. It’s a way to think critically about your code’s performance before those problems show up. When your front-end app slows down or your API response lags, often it’s because something that seemed “fast enough” at a small scale actually has a poor time complexity.

For me, learning Big O is less about memorising every notation and more about developing a sense of scale.

Can this code grow comfortably if my dataset doubles?

Am I storing unnecessary data that takes up too much space?

Once you start asking those questions, you’re already thinking like a DSA-minded developer.

Arrays

Arrays are one of the most common data structures used in JavaScript, but when we talk about them in DSA terms, it’s important to remember that JavaScript arrays are actually array lists. This means they don’t have a fixed size, they grow and shrink as we add or remove elements.

This flexibility is useful, but it also means operations can have different time complexities depending on what we’re doing.

Not every array method performs the same way. Some are nearly instant regardless of array size, while others slow down as the array grows because items need to be shifted or copied in memory.

Push()

Push adds an element to the end of an array. This has a time complexity of O(1) and a space complexity of O(1), as we don’t need to loop over the array or create a new one.

let arr = [1,2,3,4,5];

arr.push(6);
console.log(arr); // [1,2,3,4,5,6]

Pop()

Pop removes the last element from an array. This has a time complexity of O(1) and a space complexity of O(1), as we simply remove the last value without looping or copying data.

let arr = [1,2,3,4,5];

arr.pop();
console.log(arr); // [1,2,3,4]

Shift()

Shift removes an element from the beginning of an array. This has a time complexity of O(n) and a space complexity of O(1) because all remaining values need to shift one position to fill the empty index. The method returns the removed value.

let arr = [1,2,3,4,5];

arr.shift();
console.log(arr); // [2,3,4,5]

Unshift()

Unshift adds a new element to the beginning of an array. This has a time complexity of O(n) and a space complexity of O(1), as all other elements must shift one position to create space for the new value.

let arr = [1,2,3,4,5];

arr.unshift(6);
console.log(arr); // [6,1,2,3,4,5]

Splice()

Splice can add, remove or replace elements in an array. This usually has a time complexity of O(n) and a space complexity of O(n), since the array must shift values to make room or close gaps. When used to remove elements, it returns a new array containing the removed values. If no values are removed, space complexity can be considered O(1).

let arr = [1,2,3,4,5];

arr.splice(2,1);
console.log(arr); // [1,2,4,5]

Slice()

Slice returns a shallow copy of a portion of an array. It has a time complexity of O(n) and a space complexity of O(n), as a new array is created containing the copied section.

let arr = [1,2,3,4,5];

let newArr = arr.slice(2,4);
console.log(newArr); // [3,4]

Map()

Map returns a new array populated with the results of calling a given function on each element. This method has a time complexity of O(n) and a space complexity of O(n), since it creates a new array with the updated values.

let arr = [1,2,3,4,5];

let newArr = arr.map((x) => x * 2);
console.log(newArr); // [2,4,6,8,10]

Filter()

Filter returns a shallow copy of the array elements that pass a test function. It also has a time complexity of O(n) and a space complexity of O(n), as it must loop through all values and store the ones that meet the condition in a new array.

let arr = [1,2,3,4,5];

let newArr = arr.filter((x) => x <= 3);
console.log(newArr); // [1,2,3]

ForEach()

forEach executes a provided function on each element in the array. It has a time complexity of O(n) and a space complexity of O(1), since it only loops through the array and doesn’t create a new one.

let arr = [1,2,3,4,5];

arr.forEach((x) => console.log(x)); // 1 2 3 4 5

Limiting arrays length

One important thing about arrays in JavaScript is that they’re dynamic, meaning new elements can be added or removed at any time. However, this also means that the array might reallocate memory internally as it grows beyond its initial storage size, which can cause small performance hits when scaling up.

If you know the approximate number of elements your array will hold, you can predefine its size to reduce internal resizing operations.

let limit = 5;
let preSizedArray = new Array(limit);

By setting a starting size, JavaScript can allocate enough memory ahead of time, avoiding multiple reallocations as the array grows. This doesn’t create a true fixed array like in lower-level languages, but it makes performance more predictable when dealing with large data sets.

Arrays in DSA Context

In DSA, a traditional array has a fixed size, while a dynamic array (like in JavaScript) automatically resizes itself as new elements are added. That resizing typically happens when the internal storage becomes full, JavaScript allocates a new block of memory and copies all existing elements into it. This resizing process has a cost of O(n) time.

So even though push() is usually efficient, occasionally it can take longer when the array resizes. Understanding this behaviour helps write more stable and optimised code, especially when working with larger data sets.

Conclusion

I hope this was helpful to anyone who, like me, is trying to strengthen their understanding of DSA while coding in JavaScript. Knowing how to measure time and space complexity and how arrays behave underneath can make a big difference when working on larger projects.

This post was mainly for my self‑study, but if it helps you think a bit more about performance and scalability, then that’s even better.

Dev Journal: This week's progress

Brendon O'Neill — Fri, 07 Nov 2025 14:54:33 +0000

Introduction

I have been working on my media converter project this week. I finished off where I had the frontend displaying the data from the video streams and the backend worked using a hard-coded solution. This week, I wanted to connect both sides and have a basic version working that copies the video file over to another video file, that renames the file and sets it in the location the user selected.

Project functionality

This is a basic rundown of phase 1 of the project. This is a project that allows users to select a video locally and upload it to the application, where it will chunk the file and send it to a second server that has FFMPEG, which will use FFPROBE and return the video file information and display the information on the client.

This will also generate a list of streams on the video file that the user can update or remove from the video file. Updates include changing the video container (e.g. mp4, mov, avi...), changing the frames per second, changing the video dimensions and switching audio channels. Once the user has selected their choices, they can set a location for the new file, but if they don't, it will default to the folder provided in the application. They can also rename the new file before uploading it.

When the user uploads the file, it will be sent to a server in a Docker container. This is because when you use FFMPEG, it uses as much CPU and RAM as it needs to encode files, and if we want this to run locally we need to limit what it can use by limiting the Docker container. Once all chunks are sent over, the chunks are streamed back into a file and passed into a queue to be processed. When the queue has an item, it starts the queue system and generates a command for FFMPEG then creates a child process to run FFMPEG, which will either just copy the file or re-encode the file to the new settings. When the file is complete, it will be sent back to the main server, where it will check for a location and stream the chunks into the new file. The user will then get a notification via web sockets to inform them of the new file and where it is located.

Day 1

Day 1, I worked on removing the hard-coded command as I was testing with one video to make sure it all worked. I planned out what was needed for the command from the frontend and created an information object that stored details on the user's choices and details I needed about the video file. To pass this information around the application without having to pass it from one function to another, I created a map storage that stored it temporarily while the video is being encoded. To track this, I added the UUID library to generate IDs for each object.

Day 2

Day 2, I was going to work on the command generation, but I realised a flaw in my design last night that would cause the first video to be stuck if other videos were added to the queue. For some reason, I await each function to complete. This is a problem, as when the queue is empty and an item is added, it activates the queue system that runs until the queue is empty. But because the next in the queue video just added the files and returned a 200 to the user, this added to the wait time of the first video each time a new video was added.

So I spent most of the day refactoring how the flow of the server worked and cleaned up some unnecessary code that was bloating functions. It wasn't too bad, as I had already broken up parts into functions, it was more about fixing the flow of the system.

Day 3

Day 3, I got to work on the command generation, and it was going smoothly until I found a hurdle I never knew was there. I was testing out commands, it was working at a basic level, no problems until I used a MKV file. These files have another stream called attachments that most other video file formats don't have. These streams are actually binary blobs embedded in the container's metadata. These hold data on Fonts, Cover art and Licenses, so when I tried to encode the file, I kept getting an error about analyze duration and probe size, so I updated these values to help FFMPEG encode the file, but it kept happening. I then did some research to find out about these attachment streams and from what I found is FFMPEG can't encode these streams as they are just raw files embedded inside the container.

So my only solutions were to remove these streams from videos and encode the file losing this data or to dump the raw data, encode the video and then re-embed the data back into the video file. So I worked on another section of the application to change how I handle the location feature and until I researched the best solution to dumping and re-embedding the data, I removed the data from MKV files.

Day 4 & Day 5

For these days, I mainly did research and refactored the code. The application is working fully in a basic pass-through, but I needed to start handling errors and messy code to make it easier to understand the flow of the system without having to look through every file to find what I am looking for. I also worked on handling my logs, as I need to keep clean logs to find what works and where it fails. This wasn't too bad, as I had a logging system in my previous application that was helpful.

Conclusion

My application is on the right track, it is working at a basic level with a few bumps in the road, but once I complete this section, I can move on to handling images with the same system.