Forem: Peter Mbanugo

Practical Introduction to Async Generators in JavaScript

Peter Mbanugo — Sat, 31 Jan 2026 22:19:21 +0000

Generators enable you to do cooperative multitasking by allowing you to pause and resume functions at will. Put another way, they're functions that produce an iterable sequence of values on demand, instead of generating them all at once. This kind of computation is memory efficient because it doesn't require all values to be stored in memory at once.

Imagine you have to aggregate one billion rows from a text file. That function would:

Load the file contents into memory.
Parse the contents.
Aggregate the rows.
Return the aggregated result.

This would use a lot of memory and you have to wait for everything upfront. Another downside is that you might run out of memory and crash. Now, imagine if you could process each row as it comes in, without waiting for the entire file to load. Perhaps you could process it in smaller chunks and send progress updates to the user or calling function.

This is where generator functions come into play, and they can be synchronous or asynchronous.

A Simple Example

Let's start with a simple synchronous generator function that yields numbers from 1 to 3:

// This is a generator function
function* countUp(max) {
  console.log("Generator started!");
  for (let i = 1; i <= max; i++) {
    yield i; // Pause and hand back the value of 'i'
  }
  console.log("Generator finished!");
}

// 1. Get the generator object
const counter = countUp(3);

// 2. Use the generator object to get values when needed
console.log(counter.next().value); // Logs: Generator started! -> 1
console.log(counter.next().value); // Logs: 2
console.log(counter.next().value); // Logs: 3
console.log(counter.next().value); // Logs: Generator finished! -> undefined

The function* syntax defines a generator function. When you call it, it doesn't execute the function body immediately. Instead, it returns a generator object that conforms to both the iterable and iterator protocols. This object is then used to control the process of collecting values.

The yield keyword is used to pause and hand back a value. It waits, remembering its exact spot until you ask for the next value. When you call next(), the generator resumes execution until it hits the next yield or completes.

The next() method returns an object with two properties: value (the yielded value) and done (a boolean indicating if the generator has completed). This makes it incredibly memory-efficient. You don't need to hold all one billion numbers in memory. You just request for one row (or a limited number of rows), use it and then ask for the next.

The example manually calls next() to get each value. However, you can also use a for...of loop to automatically iterate over the values:

// use a for...of loop to iterate through the generator and delay each iteration by 100ms
async function iterateWithDelay(gen) {
  for (const value of gen) {
    console.log("Processing value:", value);
    await new Promise((resolve) => setTimeout(resolve, 100)); // Delay of 100ms
    console.log("Value processing complete:", value);
  }
}

const delayedCounter = countUp(5);
iterateWithDelay(delayedCounter);

In this example, the for...of loop automatically calls next() on the generator until it is done. You won't see an undefined value at the end because the loop stops when done is true.

Async Generators

What if the next value isn't ready yet? What if you have to wait for it to be downloaded or fetched from a database? This is where async generators come in. They are the perfect blend of:

Synchronous generators: They give you values one by one (yield or yield*).
Async/Await: They can await asynchronous tasks (like a network request) to finish before continuing.

Think of async generators like waiting for a new episode of a show to be released each week. You ask for the next episode, but you have to wait for it. While you're waiting, your app isn't frozen; it can do other things. This makes them ideal for working with files or other asynchronous data sources.

Due to the asynchronous nature of data streams, async generators are an elegant tool for transforming data streams (where both input and output are streams). They enable you to create modular, memory-efficient and highly readable stream-processing logic. I'll demonstrate this with a simple ETL (Extract, Transform, Load) pipeline that processes a stream of sales data from a CSV file.

Imagine you have a CSV file with sales data that looks like this:

orderID,product,quantity,unitPrice,country
1,Laptop,2,1200,USA
2,Mouse,5,15,USA
3,Keyboard,10,25,Canada
4,Webcam,20,5,UK
5,Monitor,1,300,Canada
6,USB-Cable,8,5,USA

Your task is to create a pipeline that can:

Extract: Reads the CSV file row by row as a stream.
Transform:

Calculates a totalPrice for each sale (quantity * unitPrice).
Enriches the data by adding a region based on the country (simulating an async API call).
Filters out sales with a total price below $50.

Load: Logs the final, processed data to the console.

This entire process will happen one record at a time, without ever loading the full dataset into memory. You'll create a separate generator function for each step in the pipeline. This makes it incredibly modular—easy to add, remove or reorder steps.

Extractor (CSV Stream Reader)

First, let's create a generator function that reads a CSV file line by line and yields each row as an object. We'll use the fs module to read the file as a stream and the readline module to process it line by line.

const fs = require("fs");
const readline = require("readline");
const { setTimeout } = require("timers/promises");

// E: EXTRACT - Reads a CSV and yields row objects
async function* processCsvStream(filePath) {
  const fileStream = fs.createReadStream(filePath);
  const rl = readline.createInterface({
    input: fileStream,
    crlfDelay: Infinity,
  });

  const iterator = rl[Symbol.asyncIterator]();
  const header = (await iterator.next()).value.split(",");

  for await (const line of rl) {
    const values = line.split(",");
    const row = header.reduce((obj, key, index) => {
      obj[key] = values[index];
      return obj;
    }, {});
    yield row;
  }
}

The first line in the CSV file is treated as the header, which is used to create an object for each subsequent row. Each row is yielded as an object, allowing us to process it one at a time. The rl object supports the async iterable protocol, so we can use for await...of to read and process each line.

The async iterator and iterable protocols are similar to the synchronous iterable and iterator protocols, except that each return value from the calls to the iterator methods is wrapped in a promise. Objects supporting these protocols have the methods [Symbol.asyncIterator](), next(), return() and throw() that return promises for objects with the properties value and done. See the MDN documentation for more details.

Transformers (Data Enrichment and Filtering)

Next, we'll create three transformer functions. The first will calculate the totalPrice, the second will enrich the data with a region based on the country, and the third will filter out sales below a certain threshold.

// T: TRANSFORM 1 - Adds a calculated totalPrice
async function* addTotalPrice(source) {
  for await (const row of source) {
    row.quantity = parseInt(row.quantity, 10);
    row.unitPrice = parseFloat(row.unitPrice);
    row.totalPrice = row.quantity * row.unitPrice;
    yield row;
  }
}

// A mock async function to simulate a network call
const getRegionForCountry = async (country) => {
  const regions = {
    USA: "North America",
    Canada: "North America",
    UK: "Europe",
  };
  await setTimeout(100); // Simulate latency
  return regions[country] || "Unknown";
};

// T: TRANSFORM 2 - Enriches with region data
async function* addRegion(source) {
  for await (const row of source) {
    row.region = await getRegionForCountry(row.country);
    yield row;
  }
}

// T: TRANSFORM 3 - Filters out low-value sales
async function* filterLowValueSales(source, minValue) {
  for await (const row of source) {
    if (row.totalPrice >= minValue) {
      yield row;
    }
  }
}

Assemble and Run the Pipeline

Finally, we can assemble the pipeline by chaining these async generator functions together. Here's how you can run the entire ETL process:

async function runPipeline() {
  // Create the dummy CSV file for the demo
  const csvContent =
    "orderID,product,quantity,unitPrice,country\n1,Laptop,2,1200,USA\n2,Mouse,5,15,USA\n3,Keyboard,10,25,Canada\n4,Webcam,20,5,UK\n5,Monitor,1,300,Canada\n6,USB-Cable,8,5,USA";
  fs.writeFileSync("./sales_data.csv", csvContent);

  console.log("🚀 Starting ETL Pipeline...");

  // 1. EXTRACT: Start with the source stream
  const rawRows = processCsvStream("./sales_data.csv");

  // 2. TRANSFORM: Chain the transformation steps
  const withTotalPrice = addTotalPrice(rawRows);
  const withRegion = addRegion(withTotalPrice);
  const finalDataStream = filterLowValueSales(withRegion, 50);

  // 3. LOAD: Consume the final stream and log the output
  console.log("\n--- Processed High-Value Sales ---");
  for await (const row of finalDataStream) {
    console.log(row);
  }

  console.log("\n✅ Pipeline finished.");
}

runPipeline();

This is where the magic happens! We chain the generator functions together in a clear, declarative way. The for await...of loop at the end pulls data through the entire pipeline on demand. When you run this code, you'll see the processed high-value sales logged to the console, each enriched with a totalPrice and region. The entire process is efficient and modular, demonstrating the power of async generators in handling streaming data. The output will look something like this:

🚀 Starting ETL Pipeline...

--- Processed High-Value Sales ---
{
  orderID: '1',
  product: 'Laptop',
  quantity: 2,
  unitPrice: 1200,
  country: 'USA',
  totalPrice: 2400,
  region: 'North America'
}
{
  orderID: '2',
  product: 'Mouse',
  quantity: 5,
  unitPrice: 15,
  country: 'USA',
  totalPrice: 75,
  region: 'North America'
}
{
  orderID: '3',
  product: 'Keyboard',
  quantity: 10,
  unitPrice: 25,
  country: 'Canada',
  totalPrice: 250,
  region: 'North America'
}
{
  orderID: '4',
  product: 'Webcam',
  quantity: 20,
  unitPrice: 5,
  country: 'UK',
  totalPrice: 100,
  region: 'Europe'
}
{
  orderID: '5',
  product: 'Monitor',
  quantity: 1,
  unitPrice: 300,
  country: 'Canada',
  totalPrice: 300,
  region: 'North America'
}

✅ Pipeline finished.

You should notice the slight delay as the rows are streamed and processed, simulating real-world scenarios where data might come from a network or a slow file read.

The fun part? You can easily swap out the data source or add more transformation steps without changing the overall structure. This makes async generators a powerful tool for building flexible and efficient data processing pipelines in JavaScript.

Wrapping Up

Async generators are a powerful way to process sequences of data lazily (one piece at a time) and asynchronously (waiting when necessary), leading to more efficient, composable and readable code.

Throughout this article, we've explored how they solve common challenges in modern web development:

Memory efficiency: By processing data on demand, you can handle massive datasets, even billions of rows—without crashing your application due to memory constraints.
Readable asynchronous code: Async generators allow you to write complex stream-processing logic that reads like simple, synchronous code, freeing you from callback hell.
Modular and composable code: The ETL example demonstrated how you can build clean, composable data processing pipelines by chaining generators. Each step is a self-contained unit, making your code easier to test, maintain and reason about.
Lazy evaluation: You only compute what you need, when you need it.

Whether you're reading large files, consuming real-time data from an API, or building complex data transformation workflows, async generators offer a robust and elegant solution. They encourage you to think in terms of streams, which is a fundamental paradigm for building scalable and resilient applications.

So next time you're faced with a data-intensive task, consider reaching for generator functions. You might be surprised at how much cleaner and more efficient your code becomes! No more wrangling with Buffers or backpressure—just smooth, flowing data processing.

Hand-written and originally published on Telerik's Blog

2025 Wrapup: Articles, Talks, Papers, and Software I Loved

Peter Mbanugo — Sat, 10 Jan 2026 14:13:47 +0000

2025 was an interesting year for me because it seemed like I hit a reset on various aspects of my life. My past/recent hobbies were taken over by the joy and stress of parenting a 1-year-old, which meant I had to be more selective about how I spent my time. I shifted focus towards projects I found meaningful or exciting, along the way discovering a lot of new content that inspired me.

Here are some of the articles, talks, research papers, and software tools that I found particularly impactful in 2025.

Talks

Systems that run forever self-heal and scale by Joe Armstrong.
1000x: The Power of an Interface for Performance by Joran Dirk Greef.
Designing for Performance by Martin Thompson.
Interaction Protocols: It's all about good manners by Martin Thompson. Highly recommend this. Ignore the title and watch it. Maybe it'll spark your curiosity about software engineering and further reading.
Engineering You by Martin Thompson.
Intuiting Latency and Throughput by Cassey Muratori.
How CPU Memory & Caches Work - Computerphile by Matt Godbolt.
Architecting LARGE Software Projects by Eskil Steenberg.

Articles

If Not React, Then What? by Alex Russell. The subtitle says it all: "Frameworkism isn't delivering. The answer isn't a different tool, it's the courage to do engineering". This article really resonated with me as I reflected on the state of frontend development and the over-reliance on frameworks. I've been part of various teams in the past 4 of 5 years and got tired of the status quo where people used Next.js (previously React + Webpack + Redux Thunk) for everything. No thought went into whether it was the right tool, or if they're building the right thing. This seems to get worse as a lot of people have moved towards "vibecoding" and have taken the phrase "ship fast and break things" to a whole new dimension. It further encouraged me to think critically about when and why to use certain tools.
Systemantics: How Systems Work and Especially How They Fail by John Gall. This classic article (and book) provides an insightful look into the nature of complex systems. It reminded me of the importance of simplicity and the pitfalls of over-engineering, especially in an era where complexity seems to be the default.
A couple of articles from Seth Godin got me thinking hard about my work, career, and forging forward with the current technological and economic shifts:

On Systems and Systems Thinking: My knowledge of thinking in systems expanded, as a result of reading "This is Strategy" by Seth Godin, with a lot of references to Donella Meadows' work on systems thinking.

Research Papers

Scalability! But at what COST? by Frank McSherry, Michael Isard, and Derek G. Murray. This paper challenges the conventional wisdom that scalability is always beneficial, highlighting the trade-offs involved in designing scalable systems. It made me reconsider how I approach system design, especially in the context of concurrent programming and distributed systems.
A Plea for Lean Software by Niklaus Wirth. This 1995 classic is a biting critique of "fat software" and the industry's tendency to let rapid hardware advances mask undisciplined engineering. Wirth’s core observation—that software slows down faster than hardware speeds up—is a sobering reminder that true performance comes from a "return to essentials" rather than feature bloat. It reinforced my belief that engineering excellence isn't about how much we can add, but how much we can simplify while remaining effective.

Software

ZeroMQ - A high-performance asynchronous messaging library that has been a game-changer for building distributed systems. Its simplicity and efficiency have made it a favorite tool in my toolkit for inter-process communication. I used it to implement a distributed event emitter for Node.js that I found useful in a couple of hobby projects. I find it to be much better than more popular tools (like Redis Pub/Sub or Kafka). I think it's not as popular because it's not a managed service, and some of the common patterns (like message persistence) have to be implemented by the user. However, for low-latency, high-throughput messaging, it's hard to beat ZeroMQ.
TigerBeetle - A high-performance, fault-tolerant ledger database that has impressed me with its speed and reliability. It's designed for financial applications, but its principles can be applied to any system requiring robust data integrity. What I'm most impressed about is their engineering philosophy and approach to building software. They focus on simplicity, correctness, and performance, which aligns with my renewed values as a developer.

What's Next?

2025 was a year of r relearning, reflection, and rediscovery. I read a lot more than I had in previous years, and wrote less code. Interestingly enough, a lot of the content I found impactful this year revolved around themes of simplicity, performance, and thoughtful engineering. As I move into 2026, I plan to continue exploring these themes, applying the lessons learned from these articles, talks, papers, and software tools to my work and personal projects.

Those were a few of the things I read in 2025. I've got a lot more planned for 2026, including writing more about my experiences and learnings. My goal is to do a monthly round-up of the things I read/watched and found interesting, alongside interesting facts from my experiments and hobby projects. Subscribe using the form at my website if you'd like to get notified when I publish new content.

Feel free to reach out if you have any recommendations or thoughts on topics I might find interesting!

2026 mantra -> Less is more. Build with purpose. Engineer with care.

On Software Complexity: Why Can't We Make Simple Software?

Peter Mbanugo — Thu, 04 Dec 2025 19:09:58 +0000

I got varying response to my LinkedIn post (one of them I had to block) about software complex systems designed with complexity vs simplicity. To re-iterate Gall's Law:

"A complex system that works is invariably found to have evolved from a simple system that worked. The inverse proposition also appears to be true: A complex system designed from scratch never works and cannot be made to work. You have to start over, beginning with a working simple system."—John Gall, Systems Theorist

One of the pushback was something in the lines of "Modern systems often cannot start simple because they must satisfy non-negotiable requirements from day one".

While there are non-negotiable constraints, this varies from project to project.

What I see often is "complexity by default" mindset. While we argue for the need for complexity for various reasons, I think we can make a distinction between "accidental complexity" and "essential complexity". An essential complexity is something you understand, and by doing so can handle. It doesn't have to leak into every component of your system.

The image I below (generated with Google's Gemini Nano Banana) is an excerpt from the paper—A Plea for lean software, by Niklaus Wirth.

Your end user doesn't have to suffer from your intentional or unintentional (?) accidental complexity. In fact, this is one of the reasons why software projects fail in the long run. It looks all fine in the moment. You get promoted because you spend hours in meetings bragging about using various flavours of SSR, SPA, MPA, SSG, or whatever acronym your merchant of complexity sells you. You show off your Kubernetes, Kafka, or fantastic Serverless architecture.

These tools are fine. They're not usually the cause for bloat, system or project failure. It's the default mindset of—It's got to be complex from day one. I've got to impress my engineering manager and peers because I used "modern architecture". Stop.

I'm not sure if "merchant of complexity" vendors are to be blamed, or the bootcamp/schools who teach frameworks rather than system and design thinking. I fell into this trap as well 🫠

Rethink your approach. Make sure you understand the system you're building. Aim for simplicity and build up from there.

Start by asking: Can I explain this entire system simply, and in 30 minutes or less? If not, you might be building the wrong thing.

Why "Best Practices" & Frameworks Are Keeping You Junior

Peter Mbanugo — Tue, 25 Nov 2025 18:42:38 +0000

There is a piece of advice that Experts or Senior programmers give to Juniors, which Juniors dutifully repeat to each other until it becomes a dogma:

"Don't reinvent the wheel."

On the surface, it makes sense. Why build a database when Postgres exists? Why write a message queue when you have NATS or Kafka? It seems efficient. It seems smart.

But if you blindly follow this advice, it will cap your career.

You will remain a "User" of software, never an "Engineer". You will be an expert at gluing together APIs you don't understand, terrified of the day the abstraction leaks and you have to debug a connection error that StackOverflow can’t solve.

Here is the uncomfortable truth: To become a 10x Engineer, you must reinvent the wheel. Not to use it in production, but to understand how it works.

The "Magic Box" Trap

Most developers treat their infrastructure like magic black boxes.

You send data to Redis. It comes back.
You open a WebSocket. It connects.
You send a request to a Serverless function. It runs.

But what happens when the latency spikes? What happens when the TCP connection hangs? If you have never used TCP socket directly, never handled buffer management, or never written a byte framing protocol, you are helpless. You are at the mercy of the vendor.

The "10x" Engineer isn't 10x faster at typing. They are 10x deeper in understanding.

They know that "Serverless" is just a server someone else manages. They know that a Message Queue is somewhat a fancy way of managing TCP sockets and in-memory buffers. They possess what Richard Feynman called "Generative Knowledge":

"What I cannot create, I do not understand."

The Path to 10x Sovereignty

If you want to move from "Senior React Dev" to "Senior Software/System Engineer," you need to stop consuming libraries and start building them.

You need to strip away the frameworks, the ORMs, and the "easy mode" tools. You need to look at the metal.

Don't just use HTTP. Build a parser that reads raw bytes off the wire and decodes the headers.
Don't just use Pub/Sub. Build a message broker that handles topics, wildcards, and fan-out patterns.
Don't just use JSON. Write a binary serializer to understand endianness or framing.

When you do this, something shifts in your brain. The "magic" disappears, replaced by foundational knowledge. You stop guessing why your system is slow, and you start knowing.

Protocol Zero: The Initiation

This isn't about building a startup; it's about building you.

I created Protocol Zero for the engineers who are tired of the black boxes. It is a refusal to be a "glue-code" developer.

It's a workshop with a Discord community of like-minded engineers. In this workshop, we are going to do the irrational thing. We are going to build a NATS-compatible Distributed Pub/Sub server from scratch.

No frameworks.
No magic.
Just raw TCP sockets, protocols, and the code you write with your own hands.

We will fail, we will debug, and we will reconstruct the wheel so that you never have to fear messaging protocols.

Stop being a user. Become an Senior Engineer. 👇🏽

[ ACCESS THE PROTOCOL ] to join the workshop

Write Your Own FIFO Queue: An Essential Data Structure for Modern Systems

Peter Mbanugo — Tue, 18 Nov 2025 20:25:58 +0000

You have used a queue today—probably dozens of times. Waiting at the supermarket checkout. Messages loading in order on your phone. Background tasks processing on your server. The queue data structure is everywhere because it solves a fundamental problem: making sure things happen in the right order, without overwhelming your system.

Think of waiting at a supermarket checkout. You join the back of the line and wait for your turn, whilst the cashier deals with the person at the front.

In computing, a queue works exactly the same way—it is a line of data waiting to be processed. Whether you are processing webhook events in the order they arrive, handling print jobs sent to a shared printer, or managing background tasks in a web application, the queue ensures everything happens in the right sequence. This makes it essential for handling concurrent tasks, message passing between threads, and building systems like message brokers and event loops.

In this article, we will implement a Queue from scratch in Zig to understand the fundamental mechanics and performance trade-offs. While the code is in Zig, the explanation and simplicity of the logic will help you implement something similar in Rust, C, or whichever language you prefer.

Fundamental and Core Operations

A Queue follows a First-In, First-Out (FIFO) principle. This is why you'll often hear it called a FIFO Queue or just FIFO. The structure is like a pipe: the first item to enter one end is the first to exit the other. You can't reach into the middle and pull an item out. This sequential processing is exactly how many systems, from HTTP servers to event streaming platforms, handle requests.

In technical terms, the entry point is called the back (or tail), and adding an item is called an enqueue operation. The exit point is the front (or head), and removing an item is a dequeue operation.

For a queue to be reliable in high-performance or concurrent systems, enqueue and dequeue must be fast. Specifically, they need to complete in constant time—often written as O(1) time complexity. This means the operation takes the same amount of time regardless of whether the queue holds two items or two million. If an operation slows down as the queue grows, it creates a bottleneck. This performance guarantee is the central engineering challenge we must solve.

Building the Queue Struct in Zig

Even though most standard libraries provide a queue implementation, building one yourself is a fantastic way to understand its inner workings. We will start with a simple implementation, then solve its biggest problem using a technique called a circular buffer.

Let's begin with the basics. In Zig, we can create a generic function that returns a custom type. Think of it like a template in C++ or generics in other languages. The comptime keyword means this happens at compile time.

Before we dive into the code, here's a quick note about Zig's error handling: the try keyword propagates errors up the call stack, similar to the ? operator in Rust or throwing exceptions in other languages. When you see try queue.enqueue(10), it means "attempt this operation, and if it fails, return the error to the caller."

const std = @import("std");

// Helper function for logging
fn log(value: i32) void {
    std.debug.print("{d}\n", .{value});
}

// A generic function to create a Queue type with a specific capacity.
fn Queue(comptime capacity: usize) type {
    return struct {
        // The array that will store our queue's elements.
        data: [capacity]i32 = [_]i32{0} ** capacity,
        // 'front' is the index of the next element to be dequeued.
        front: usize = 0,
        // 'back' is the index where the next element will be enqueued.
        back: usize = 0,
        // 'count' tracks the current number of elements in the queue.
        count: usize = 0,

        // A constant to refer to the struct itself. A common Zig pattern.
        const Self = @This();

        // Adds an item to the back of the queue.
        pub fn enqueue(self: *Self, value: i32) !void {
            if (self.count >= capacity) {
                return error.QueueFull;
            }
            self.data[self.back] = value;
            self.back += 1;
            self.count += 1;
        }

        // Removes an item from the front of the queue.
        pub fn dequeue(self: *Self) !i32 {
            if (self.count == 0) {
                return error.QueueEmpty;
            }
            const value = self.data[self.front];
            self.front += 1;
            self.count -= 1;
            return value;
        }
    };
}

Let's break down that array initialisation syntax, as it is quite specific to Zig. When you write [_]i32{0} ** capacity, you're telling the compiler to create an array filled with zeros. The [_] syntax means "infer the size from what follows." The {0} is your initialiser value, and the ** operator repeats that value to fill the entire array. So if capacity is 4, this expands to an array with four zeros: [4]i32{0, 0, 0, 0}. It is a compact way to initialise arrays without manually writing out each element.

A few other Zig-specific details worth noting: The !void and !i32 return types mean these functions can return either a value or an error. The *Self parameter means we're passing a pointer to the struct, allowing us to modify it. The @This() built-in function returns the type of the current struct. It is Zig's way of avoiding repetition when you need to refer to your own type.

Here's how you would use it:

var queue = Queue(4){};
try queue.enqueue(10);
try queue.enqueue(20);
try queue.enqueue(30);

// Dequeue and print data
log(try queue.dequeue());
log(try queue.dequeue());

Which prints:

10
20

This seems to work well, but there's a critical flaw lurking beneath the surface.

The Problem: Running Out of Space When There Is Room

Imagine you create a queue with capacity for four items. You add four items, then remove two. Your queue now has two items in it, with plenty of space. But here is the trap: self.back is now at index 4 (the end of the array), while self.front is at index 2. If you try to add another item, the code will try to write to data[4], which is out of bounds!

Our queue with a capacity of 4:
┌───┬───┬───┬───┐
│10 │20 │30 │40 │ data
└───┴───┴───┴───┘
  0   1   2   3   (indices)

After two dequeues:
┌───┬───┬───┬───┐
│   │   │30 │40 │  (Logically empty)
└───┴───┴───┴───┘
          ↑       ↑
        front=2   back=4

The problem: `back` is at the end. We have two empty slots at the start, but our simple logic cannot see them. The queue is effectively broken.

We could fix this by shifting all elements back to the start of the array after each dequeue, similar to how people in a physical checkout queue shuffle forward. But that is expensive. Moving elements takes more time as the queue grows, which breaks our promise of constant-time operations. We need something better.

The Solution: Circular Buffers (Ring Buffers)

The elegant solution is to treat the array as circular. Instead of thinking of it as a line with a start and end, imagine it as a ring. When you reach the last position, you wrap around to the beginning. This is called a circular buffer or ring buffer.

Here's a text-based visualisation of how this works. Imagine a queue with capacity for 4 items. To make the logic work (as we will explain in a moment), we actually use 5 slots in memory:

Initial state (empty queue):
┌───┬───┬───┬───┬───┐
│   │   │   │   │   │
└───┴───┴───┴───┴───┘
  ↑
  front = 0, back = 0

After enqueue(10), enqueue(20), enqueue(30):
┌───┬───┬───┬───┬───┐
│10 │20 │30 │   │   │
└───┴───┴───┴───┴───┘
  ↑           ↑
  front = 0   back = 3

After dequeue() twice:
┌───┬───┬───┬───┬───┐
│   │   │30 │   │   │
└───┴───┴───┴───┴───┘
          ↑   ↑
    front = 2 back = 3

Now enqueue(40), enqueue(50) — watch the wrap-around:

1. We enqueue(40). `back` moves from 3 to 4.
2. We enqueue(50). `back` tries to move from 4 to 5. Using our modulo formula `(4 + 1) % 5`, it wraps around to 0. The value `50` is placed at index 0. `back` now points to the *next* empty slot, which is 1.
┌───┬───┬───┬───┬───┐
│50 │   │30 │40 │   │
└───┴───┴───┴───┴───┘
      ↑   ↑
back = 1  front = 2

The queue is now storing `30`, `40`, and `50`. The `front` pointer is at index 2 (ready to dequeue `30`), and the `back` pointer is at index 1 (ready for the next enqueue). The wrap-around worked perfectly!

The key to making this work is understanding how we calculate the wrap-around. When we want to move to the next position, we use this formula:

next_position = (current_position + 1) % array_size

The % symbol is the modulo operator. It gives you the remainder after division. Here's how it creates the wrap-around effect:

(0 + 1) % 5 = 1 — moving from index 0 to 1
(1 + 1) % 5 = 2 — moving from index 1 to 2
(2 + 1) % 5 = 3 — moving from index 2 to 3
(3 + 1) % 5 = 4 — moving from index 3 to 4
(4 + 1) % 5 = 0 — here's the magic! Moving from index 4 wraps back to 0

When you divide 5 by 5, you get 1 with a remainder of 0. The modulo operator gives us that remainder. This is why it works so perfectly for circular buffers—any number divided by the array size will always give you a remainder between 0 and (array_size - 1), which are exactly the valid indices of our array.

The Extra Slot Trick

There is one clever trick we need: we allocate capacity + 1 slots instead of just capacity. This extra slot helps us distinguish between "completely full" and "completely empty."

Here is why this matters. Without the extra slot, imagine a 3-item queue with 3 slots:

Empty queue:               Full queue:
┌───┬───┬───┐             ┌───┬───┬───┐
│   │   │   │             │10 │20 │30 │
└───┴───┴───┘             └───┴───┴───┘
  ↑                         ↑
  front = 0, back = 0       front = 0, back = 0 (after wrapping)

Both states look identical! When front equals back, we cannot tell if we have zero items or three items. The queue is ambiguous.

With the extra slot, we get this behaviour:

Empty queue (4 slots for 3 items):
┌───┬───┬───┬───┐
│   │   │   │   │
└───┴───┴───┴───┘
  ↑
  front = 0, back = 0

Full queue (3 items stored):
┌───┬───┬───┬───┐
│10 │20 │30 │   │  ← One slot always remains empty
└───┴───┴───┴───┘
  ↑           ↑
  front = 0   back = 3

Now it is clear: the queue is full when back is one position
behind front (with wrapping). The queue is empty when they are equal.

The queue is full when the next position after back would equal front. This means we always keep one slot empty as a sentinel, making the full/empty detection unambiguous.

A sentinel is a special value used to indicate a particular state, such as the end of a data structure or a specific condition being met. In this case, the empty slot acts as a sentinel to differentiate between full and empty states of the queue.

Here is the complete implementation:

fn Queue(comptime capacity: usize) type {
    return struct {
        // We allocate one extra slot to distinguish full from empty
        data: [capacity + 1]i32 = [_]i32{0} ** (capacity + 1),
        front: usize = 0,
        back: usize = 0,

        const Self = @This();

        pub fn enqueue(self: *Self, value: i32) !void {
            // Calculate where 'back' would be after adding this item
            // The modulo ensures we wrap around to 0 if we exceed capacity
            const next_back = (self.back + 1) % (capacity + 1);

            // If that would make back equal front, we are full
            if (next_back == self.front) {
                return error.QueueFull;
            }

            self.data[self.back] = value;
            // Move back to its new position (wrapping around if needed)
            self.back = next_back;
        }

        pub fn dequeue(self: *Self) !i32 {
            // If front equals back, the queue is empty
            if (self.front == self.back) {
                return error.QueueEmpty;
            }

            const value = self.data[self.front];
            // Move front forward, wrapping around if we reach the end
            self.front = (self.front + 1) % (capacity + 1);
            return value;
        }

        pub fn isEmpty(self: *const Self) bool {
            return self.front == self.back;
        }

        pub fn isFull(self: *const Self) bool {
            return (self.back + 1) % (capacity + 1) == self.front;
        }
    };
}

Notice we no longer need the count field. We can determine whether the queue is empty or full just by comparing front and back. Both enqueue and dequeue remain constant-time operations. No matter if the queue holds two items or two thousand, the operations take the same amount of time because we are just updating indices, not moving data around.

Let's test it with a more thorough example to see the circular behaviour in action:

var queue = Queue(3){}; // Capacity of 3 items

try queue.enqueue(10);  // back moves from 0 to 1
try queue.enqueue(20);  // back moves from 1 to 2
try queue.enqueue(30);  // back moves from 2 to 3

log(try queue.dequeue()); // 10 - front moves from 0 to 1
log(try queue.dequeue()); // 20 - front moves from 1 to 2

// Now we can add more items, reusing the space at the front
try queue.enqueue(40);  // back moves from 3 to 0 (wraps around!)
try queue.enqueue(50);  // back moves from 0 to 1

log(try queue.dequeue()); // 30 - front moves from 2 to 3
log(try queue.dequeue()); // 40 - front moves from 3 to 0 (wraps around!)
log(try queue.dequeue()); // 50 - front moves from 0 to 1

Which prints:

This circular buffer technique is used in many applications in systems programming—from audio processing buffers to network packet queues—because it is simple, fast, and memory-efficient.

Why Arrays Over Linked List?

You can implement a Queue using a Linked List as well. You might wonder: why not use a Linked List? They can grow dynamically without a fixed capacity, which sounds appealing on the surface.

The answer comes down to how modern computers actually work.

Arrays store data in one contiguous block of memory. This means your CPU can load chunks of it into its cache all at once. Think of it like reading a book—it is much faster to read the next page when the book is already open in front of you, rather than walking to a library shelf to fetch every single page individually.

Linked List scatter data across memory, forcing the CPU to jump around to find the next item. Those jumps are expensive. In real-world systems, scattered memory access can be 10 to 100 times slower than sequential array access. When you are handling thousands of queue operations per second, that performance difference compounds quickly.

There is also the allocation cost. Every enqueue operation with a Linked List requires asking the system for memory—a "syscall" that involves context switching and bookkeeping. With an array-based Queue, you just write to a pre-allocated slot. It is the difference between renting a new storage unit every time you need to store a box versus having a warehouse ready and waiting.

For most use cases, especially in performance-critical systems, the array-based circular buffer strikes the best balance. You get predictable memory usage, excellent cache performance, no allocation overhead, and guaranteed constant-time operations.

Wrap Up

The queue is a simple yet powerful data structure that operates on a FIFO principle, making it perfect for processing tasks in order. We have built a complete, working implementation using a circular buffer—a technique that solves the "running out of space" problem while maintaining constant-time performance.

I encourage you to try implementing this queue in your favourite programming language. The circular buffer pattern translates well to any language with arrays and basic arithmetic. Whether you are working in Rust, C, Go, or even higher-level languages like Python or JavaScript, the concepts remain the same.

In the next article, we will tackle concurrent queues—how to make this data structure safe when one thread produces items while another consumes them. This single-producer, single-consumer pattern is crucial for building high-performance systems. Want to be notified when it is published? Subscribe at pmbanugo.me and feel free to share this with colleagues who would benefit from understanding the fundamentals.

Why Zig is cool and I'm jumping ship to Ziglang

Peter Mbanugo — Sat, 08 Nov 2025 13:02:07 +0000

Peter Mbanugo

Nov 8 '25

Ziglang is so cool: Why I'm Going All-In on Zig

#webdev #programming #rust #zig

Comments

4 min read

Ziglang is so cool: Why I'm Going All-In on Zig

Peter Mbanugo — Sat, 08 Nov 2025 13:01:09 +0000

I’m writing this to make a public commitment. A means to quiet the lizard brain—that primal, anxious voice that urges us to quit when things get hard. For the next 12 months, I’m committing to a new path, and I'm not going it alone. I'm inviting you to follow along.

I feel a familiar mix of excitement and anxiety. I've decided to dive deep into a set of challenging goals, and I'll be sharing my progress, struggles, and insights right here on my blog, in my newsletter, and on my YouTube channel. The centrepiece of this journey is learning to build software with the Zig programming language. So, to my regular readers, brace yourselves for something new.

This shift might surprise those who know me for my work in web development and DevOps. But if you’ve been following closely, you may have noticed my content slowly drifting towards a new obsession: performance. This led me to start a YouTube podcast where I could learn from experts in the field, and it has set me on a trajectory I can no longer ignore.

The Search for a New Path

I want to be part of an ecosystem that builds software with a clear set of values: simplicity, high performance, reliability, and durability—software designed to stand the test of time.

I’ve chased these ideals throughout my career, but it’s easy to get swept up in a current of vendor lock-in, fleeting web frameworks, and tools that promise a quick fix but deliver a mountain of complexity. I see it at conferences and meetups. It’s a stark contrast to the conversations I have when I attend Elixir events; even though I don't use the language professionally, I leave feeling inspired by the community's focus on craftsmanship and long-term thinking.

Maybe I’m bored. Or inspired. The familiar patterns of web development no longer hold the same challenge. I feel a pull to explore the foundations, to understand what it truly takes to build software that uses system resources efficiently, and to get closer to the metal.

It's a strange feeling to consciously move away from the mainstream. Phil Eaton's post, "From web developer to database developer in 10 years," struck a chord with me. His account of moving from the familiar world of web development to the 'black boxes' of databases—was the final push I needed. It solidified my resolve: this isn’t just a whim; it’s a deliberate choice to build a different kind of expertise.

That’s why I'm going all-in on Zig for the next 12 months (at least!). It will be my vehicle for learning not just a new language, but the timeless principles of data structures, algorithms, concurrency, and computer architecture.

Why Zig? Why Now?

I can already hear the questions. "Why Zig when there's Rust and C++? There are no Zig jobs! The language isn't even 1.0 yet!"

These are fair points, whether they come from a place of genuine concern or from a language zealot/bigot. But every language has its trade-offs, and choosing a tool is sometimes more than just market demand. It could be about the joy and satisfaction from using it. As for my career, I’ll continue my freelance work in the web ecosystem, so you’ll still see content from me in that space.

I believe that with enough time and the right conditions, the Zig ecosystem will flourish. You can either get in early and help build the future you want to see, or you can wait for it to arrive. Today, remarkable products like the TigerBeetle database and the Ghostty terminal are already proving Zig’s power in production. Joran Dirk Greef's talk on TigerBeetle is a masterclass in this philosophy.

What truly captured my interest wasn't just the syntax, but the mindset. I was drawn to Zig's simplicity, and I'm staying for the profound wisdom I gain listening to its creator, Andrew Kelley, and other community members talk about software engineering. Their philosophy resonates deeply with me. The TigerStyle guide, for example, is more than a style guide; it’s a manifesto for building correct, simple, and performant software.

The recent financial commitments from pillars of the community like Mitchell Hashimoto, Synadia, and TigerBeetle have only strengthened my resolve. This isn't a hobbyist language; it's a serious project with a bright future.

The Road Ahead: Learning in Public

While this post centres on Zig, the language is the means, not the end. My real goal is to master the fundamentals.

I plan to build projects that force me to confront these topics head-on, and I’ll share every step of the process. I have a few ideas brewing, but I’m open to suggestions. If you have an interesting problem you think would be a great challenge, please reach out on X (formerly Twitter) or LinkedIn.

My hope is to eventually contribute to the Zig ecosystem itself. I don't know what form that will take yet, but I'm excited to find out.

I won't pretend this will be easy. I’m worried I’ll pick a project that’s too ambitious and fall flat. Concepts like manual memory management and pointers are still new territory for me. But that’s the point of learning in public. You see the messy parts, the failures, and the breakthroughs.

I'm stepping out of my comfort zone, and I'm asking you to come along for the ride. Let’s see how this goes.

Thank you for reading, and I look forward to the interactions we'll have along the way.

Practical Introduction to Angular Signals

Peter Mbanugo — Fri, 10 Oct 2025 10:25:28 +0000

Angular Signals represent a fundamental shift in how we manage reactive state in Angular applications. If you're coming from RxJS observables or other state management libraries, signals offer a more intuitive, performant and granular approach to reactivity. Unlike the zone-based change detection that runs for entire component trees, signals provide fine-grained reactivity that updates only what actually changed.

In this tutorial, we'll build a practical countdown timer application that demonstrates the core concepts of Angular Signals. You'll learn how signals provide automatic dependency tracking, eliminate the need for manual subscriptions and create more predictable reactive applications.

Example Overview: Reactive Countdown Timer

A countdown timer is an excellent example for learning signals because it involves multiple reactive states that depend on each other. The timer will demonstrate how signals naturally handle:

State management: Timer duration, current time and running state
Derived state: Formatted time display and progress percentage
Side effects: Completion alerts and UI updates

Real-world applications for this pattern include:

Recording studios: Session time tracking and break timers
Live events: Speaker time limits and presentation countdowns
Productivity apps: Pomodoro timers and focus sessions
Fitness apps: Workout intervals and rest periods

It will feature start/stop/reset controls, preset time buttons, visual progress indicators and completion messages. All built with signals to showcase their reactive capabilities.

Setting Up the Project

Let's start by creating a new Angular project with the latest version that includes signals support:

npm install -g @angular/cli
ng new countdown-timer --routing=false --style=css
cd countdown-timer

You could use npx if you don't want to install Angular CLI globally: npx -p @angular/cli@20 ng new countdown-timer --routing=false --style=css.

Create the timer component:

ng generate component countdown-timer --standalone

Update src/app/app.ts to import and use the countdown timer component:

import { CountdownTimer } from "./countdown-timer/countdown-timer";

@Component({
  // rest of the component metadata
  imports: [CountdownTimer],
})

Update src/app/app.html to render the new component:

<div class="app-container">
  <h1>Angular Signals Countdown Timer</h1>
  <app-countdown-timer></app-countdown-timer>
</div>

Add some basic styling to src/app/app.css:

.app-container {
  max-width: 600px;
  margin: 0 auto;
  padding: 2rem;
  text-align: center;
  font-family: "Segoe UI", Tahoma, Geneva, Verdana, sans-serif;
}

h1 {
  color: #2c3e50;
  margin-bottom: 2rem;
}

Angular Signals Fundamentals

Signals are reactive primitives that hold values and notify consumers when those values change. Let's start by implementing the core timer state in the CountdownTimer component. Copy and paste the code below into src/app/countdown-timer/countdown-timer.ts file:

import { Component, signal, computed, effect, OnDestroy } from "@angular/core";
import { CommonModule } from "@angular/common";

@Component({
  selector: "app-countdown-timer",
  standalone: true,
  imports: [CommonModule],
  templateUrl: "./countdown-timer.html",
  styleUrl: "./countdown-timer.css",
})
export class CountdownTimer implements OnDestroy {
  // Writable signals for managing timer state
  private timeRemaining = signal(60); // seconds
  private isRunning = signal(false);
  private initialTime = signal(60);

  // Expose read-only versions for the template
  readonly timeLeft = this.timeRemaining.asReadonly();
  readonly running = this.isRunning.asReadonly();

  private intervalId: number | null = null;

  constructor() {
    console.log("Timer initialized with:", this.timeLeft());
  }

  ngOnDestroy(): void {
    // Clean up interval when component is destroyed
    this.stop();
  }
}

The code creates a writable signal with an initial value using the syntax signal(initialValue). Writable signals provide an API for updating their values directly. Afterward, it creates read-only versions of those signals for use in the template. It keeps a reference to the intervalId to make sure the timer is cleaned up properly. You may have noticed that, unlike observables, signals don't require explicit subscriptions. It keeps track of where and how they're used and updates them automatically.

Building the Core Timer Logic

Now let's implement the timer functionality with signal-based state management. Add the following code to the CountdownTimer component:

export class CountdownTimer {
  // ... previous code ...

  // Timer control methods
  start(): void {
    if (this.isRunning()) return;

    this.isRunning.set(true);

    this.intervalId = window.setInterval(() => {
      this.timeRemaining.update((time) => {
        if (time <= 1) {
          this.stop();
          return 0;
        }
        return time - 1;
      });
    }, 1000);
  }

  stop(): void {
    this.isRunning.set(false);
    if (this.intervalId) {
      clearInterval(this.intervalId);
      this.intervalId = null;
    }
  }

  reset(): void {
    this.stop();
    this.timeRemaining.set(this.initialTime());
  }

  setTime(seconds: number): void {
    this.stop();
    this.initialTime.set(seconds);
    this.timeRemaining.set(seconds);
  }
}

The set() and update() methods change the value of a writable signal. The difference between them is that the .update() method receives the current value and returns the new value. This functional approach enables immutability and makes state changes predictable.

Computed Signals

Computed signals derive their values from other signals and automatically recalculate when dependencies change. Add these derived states to the component:

export class CountdownTimer implements OnDestroy {
  // ... previous code ...

  // Computed signals for derived state
  readonly formattedTime = computed(() => {
    const time = this.timeLeft();
    const minutes = Math.floor(time / 60);
    const seconds = time % 60;
    return `${minutes.toString().padStart(2, "0")}:${seconds.toString().padStart(2, "0")}`;
  });

  readonly progressPercentage = computed(() => {
    const initial = this.initialTime();
    const remaining = this.timeLeft();
    if (initial === 0) return 0;
    return ((initial - remaining) / initial) * 100;
  });

  readonly isCompleted = computed(() => this.timeLeft() === 0);

  readonly buttonText = computed(() => (this.running() ? "Pause" : "Start"));
}

Computed signals are read-only and lazily evaluated—they only recalculate when accessed and when their dependencies change. This is more efficient than manually managing derived state with observables.

Signal Effects

Effects are asynchronous operations that run when one or more signals change. They're useful for tasks like logging, analytics or adding custom DOM behavior that can't be expressed with template syntax. Add the following effects to log info when the countdown completes:

export class CountdownTimer implements OnDestroy {
  // ... previous code ...

  constructor() {
    // Effect for logging state changes (useful for debugging)
    effect(() => {
      console.log(
        `Timer state: ${this.formattedTime()}, Running: ${this.running()}`,
      );
    });

    // Effect for completion handling
    effect(() => {
      if (this.isCompleted()) {
        // Trigger completion event or notification
        this.onTimerComplete();
      }
    });
  }
  // Handle timer completion
  private onTimerComplete(): void {
    // In a real app, emit an event, show toast notification, play sound, etc.
    // This makes the code testable and follows Angular best practices
    console.log("Timer has completed - handle completion here");
  }

  ngOnDestroy(): void {
    // Clean up interval when component is destroyed
    this.stop();
  }
}

Effects automatically track their signal dependencies and rerun when any dependency changes. Unlike RxJS subscriptions, you don't need to manually unsubscribe because Angular handles cleanup automatically when the component is destroyed.

Important: Avoid using effects for propagation of state changes. Use computed signals instead. Effects should only be used for side effects like DOM manipulation that can't be expressed with template syntax.

Visualizing the Timer

It's time to show you how to use signals to build reactive user interfaces. Let's add preset time buttons and a visual progress indicator. Update your template (countdown-timer.html):

<div class="timer-container">
  <!-- Time Display -->
  <div class="time-display">{{ formattedTime() }}</div>

  <!-- Progress Bar -->
  <div class="progress-container">
    <div class="progress-bar" [style.width.%]="progressPercentage()"></div>
  </div>

  <!-- Control Buttons -->
  <div class="controls">
    <button (click)="running() ? stop() : start()" [disabled]="isCompleted()">
      {{ buttonText() }}
    </button>

    <button (click)="reset()">Reset</button>
  </div>

  <!-- Preset Time Buttons -->
  <div class="presets">
    <button (click)="setTime(30)" [disabled]="running()">30s</button>
    <button (click)="setTime(60)" [disabled]="running()">1min</button>
    <button (click)="setTime(300)" [disabled]="running()">5min</button>
    <button (click)="setTime(600)" [disabled]="running()">10min</button>
  </div>
</div>

Add the corresponding styles (countdown-timer.css):

.timer-container {
  background: #f8f9fa;
  border-radius: 12px;
  padding: 2rem;
  box-shadow: 0 4px 6px rgba(0, 0, 0, 0.1);
}

.time-display {
  font-size: 4rem;
  font-weight: bold;
  color: #2c3e50;
  margin-bottom: 1.5rem;
  font-family: "Courier New", monospace;
}

.progress-container {
  width: 100%;
  height: 8px;
  background-color: #e9ecef;
  border-radius: 4px;
  margin-bottom: 2rem;
  overflow: hidden;
}

.progress-bar {
  height: 100%;
  background: linear-gradient(90deg, #28a745, #ffc107, #dc3545);
  transition: width 0.3s ease;
}

.controls,
.presets {
  display: flex;
  gap: 1rem;
  justify-content: center;
  margin-bottom: 1rem;
}

button {
  padding: 0.75rem 1.5rem;
  border: none;
  border-radius: 6px;
  background: #007bff;
  color: white;
  cursor: pointer;
  font-weight: 500;
  transition: background-color 0.2s;
}

button:hover:not(:disabled) {
  background: #0056b3;
}

button:disabled {
  background: #6c757d;
  cursor: not-allowed;
}

Notice how the template directly uses signal values with function call syntax: formattedTime(), progressPercentage(), running(). Angular's template engine automatically tracks these dependencies and updates only the affected DOM nodes.

Signal vs RxJS Observables

Signals provide several benefits over the former observable-based approach:

// Traditional approach with observables
export class TraditionalComponent {
  private timeSubject = new BehaviorSubject(60);
  time$ = this.timeSubject.asObservable();

  formattedTime$ = this.time$.pipe(
    map((time) => {
      const minutes = Math.floor(time / 60);
      const seconds = time % 60;
      return `${minutes.toString().padStart(2, "0")}:${seconds.toString().padStart(2, "0")}`;
    }),
  );

  ngOnDestroy() {
    // Manual subscription management required
    this.timeSubject.complete();
  }
}

// Signal approach
export class SignalComponent {
  private timeRemaining = signal(60);

  readonly formattedTime = computed(() => {
    const time = this.timeRemaining();
    const minutes = Math.floor(time / 60);
    const seconds = time % 60;
    return `${minutes.toString().padStart(2, "0")}:${seconds.toString().padStart(2, "0")}`;
  });

  // No manual cleanup needed
}

Key benefits:

Granular updates: Only components using changed signals rerender
No subscription management: Automatic dependency tracking and cleanup
No async pipe complexity in templates
Tree-shakable: Unused computations are automatically optimized away

Best Practices

Use readonly signals for public APIs:

private _count = signal(0);
readonly count = this._count.asReadonly();

Prefer computed signals over manual derivation:

// ✅ Good
readonly isEven = computed(() => this.count() % 2 === 0);

// ❌ Avoid
get isEven() { return this.count() % 2 === 0; }

Use effects sparingly for side effects only:

// ✅ Good - logging, localStorage, DOM manipulation
effect(() => {
  localStorage.setItem("timerState", JSON.stringify(this.timerState()));
});

effect(() => {
  console.log(`Timer state changed: ${this.formattedTime()}`);
});

// ❌ Avoid - direct UI interactions in effects
effect(() => {
  if (this.isCompleted()) {
    alert("Done!"); // Better to emit events or call methods
  }
});

Implement proper cleanup for components with intervals/timers:

export class TimerComponent implements OnDestroy {
  ngOnDestroy(): void {
    this.stop(); // Clean up intervals
  }
}

Keep signal updates simple and predictable:

// ✅ Good
this.count.update((n) => n + 1);

// ❌ Avoid complex logic in updates
this.count.update((n) => {
  // Complex business logic here...
  return someComplexCalculation(n);
});

Conclusion

Angular Signals represent a paradigm shift toward more intuitive and performant reactive programming. Through building this countdown timer, you've learned its core concepts and best practices. The timer demonstrates how signals naturally handle complex reactive scenarios with writable signals, computed signals and effects. The declarative nature of computed signals and the automatic dependency tracking make your code more predictable and easier to reason about.

Follow these steps to adopt signals in your production applications:

Start small: Convert simple reactive state from observables to signals
Identify computed values: Look for derived state that can become computed signals
Migrate gradually: Signals interop well with observables during transition
Leverage effects: Replace subscription-based side effects with signal effects

As Angular continues to evolve, signals will become increasingly central to the framework's reactive model.

Additional Resources

Written by me and originally published on Telerik's blog

Optimising Node.js for High-Performance Processing

Peter Mbanugo — Tue, 07 Oct 2025 15:18:31 +0000

Peter Mbanugo

Oct 7 '25

Node.js Performance: Processing 14GB Files 78% Faster with Buffer Optimization

#node #webdev #typescript #javascript

Comments

10 min read

Node.js Performance: Processing 14GB Files 78% Faster with Buffer Optimization

Peter Mbanugo — Tue, 07 Oct 2025 15:14:41 +0000

It all started on a quiet weekend. My wife and son were away, leaving me with a rare block of uninterrupted time, fueled by curiosity and a slightly obsessive streak. As a freelancer who spends my days helping companies wring more speed out of their web apps, Node.js services, and CI/CD pipelines, I usually tackle performance as part of someone else's puzzle. But this time, I decided to take on a challenge purely for the thrill.

The Crime Scene: 14.80 GB of weather data

The Evidence: 1 billion rows of temperature measurements

The Victim: My MacBook Pro M1's dignity
Time of Death: 5 minutes, 49 seconds

My Mission: Make it faster. Much, much faster.

What followed was a series of experiments, dead ends, and small breakthroughs that felt like uncovering clues in a complex mystery. I moved from single-threaded runs to considering Node.js worker threads, juggled data structures in Node.js, and chased down the hidden costs of syscalls. Along the way, I even tested the same code on Deno and Bun, only to find that the promises of faster runtimes were mostly a mirage for this particular workload.

By the end of the weekend, what started as idle curiosity turned into an 78% speedup—but the story of how I got there is far more interesting than the numbers alone.

The Challenge: Processing 1 Billion Rows of Text in Node.js

The data was deceptively simple: a text file containing 1 billion rows of temperature measurements from weather stations around the world. Each row followed a strict format: <string: station name>;<double: measurement>, with the temperature having exactly one fractional digit.

The task? Read the file, calculate the min, mean, and max temperature for each station, then write the sorted results to a new file.

Simple, right?

Establishing the Baseline: readline() and createReadStream() for Large File Processing

I started with what any reasonable developer would write: a straightforward Node.js script using readline to process the file line by line. Split each line on the semicolon, parse the temperature as a float, update the statistics in a JavaScript object. Clean, readable, obvious.

const stations = {};

rl.on("line", (line) => {
  if (line) {
    const [station, tempStr] = line.split(";");
    const temperature = parseFloat(tempStr);
    if (!stations[station]) {
      stations[station] = {
        min: temperature,
        max: temperature,
        sum: temperature,
        count: 1,
      };
    } else {
      const stationData = stations[station];
      stationData.min = Math.min(stationData.min, temperature);
      stationData.max = Math.max(stationData.max, temperature);
      stationData.sum += temperature;
      stationData.count++;
    }
  }
});

It worked. The results were correct. And it took 5 minutes and 49 seconds to complete.

In performance terms, that's an eternity. I knew something had to give.

The First Lead: A Theory About Strings

Before reaching for the obvious solution—parallelization with worker threads—I wanted to exhaust the single-threaded approach. Call it professional pride, but I suspected there was more performance hiding in plain sight.

I formed a theory: the file was UTF-8 encoded, but JavaScript strings are UTF-16, requiring an expensive encoding conversion for every line. That meant every line required an encoding conversion. A billion times. Every split operation, every string allocation, every parsed float—they all had a cost.

What if I could work directly with the bytes?

I prompted GitHub Copilot with my hypothesis, and what came back was intriguing. Instead of decoding strings, the new approach parsed raw bytes in a streaming fashion:

const readableStream = fs.createReadStream(inputFilePath);

let leftover = null;
let lineStart = 0;
let stationName = null;
let state = 0; // 0 = reading station, 1 = reading temperature
let tempSign = 1;
let tempInt = 0; // Integer tenths accumulator

readableStream.on("data", (chunk) => {
  const buffer = leftover ? Buffer.concat([leftover, chunk]) : chunk;
  const bufferLength = buffer.length;

  for (let byteIndex = lineStart; byteIndex < bufferLength; byteIndex++) {
    const currentByte = buffer[byteIndex];

    if (state === 0) {
      if (currentByte === SEMI) {
        // ';'
        stationName = buffer.toString("utf8", lineStart, byteIndex);
        state = 1;
        tempSign = 1;
        tempInt = 0;
      }
      continue;
    }

    // Temperature parsing with fast-path digit accumulation
    if (currentByte === NEWLINE) {
      const tempTenths = tempSign * tempInt;
      let stationData = stations.get(stationName);
      if (stationData) stationData.update(tempTenths);
      else stations.set(stationName, new StationData(tempTenths));

      stationName = null;
      state = 0;
      lineStart = byteIndex + 1;
      continue;
    }

    if (currentByte === DASH && tempInt === 0) {
      tempSign = -1;
      continue;
    }
    if (currentByte === DOT) continue;

    // Direct byte-to-digit conversion
    tempInt = tempInt * 10 + (currentByte - ZERO);
  }
});

The clever part? It stored temperatures as integers: 25.3°C became 253 tenths of a degree. No floating-point math until the very end. The parser also switched from using a plain object to a Map for better memory patterns, and added a StationData class for tighter updates.

But the real magic was in this single line:

tempInt = tempInt * 10 + (currentByte - ZERO);

Each digit byte (say, 52 for the character 4) gets converted to its integer value by subtracting the byte value of 0 (which is 48). So 52 - 48 = 4. That digit accumulates into tempInt by multiplying the current value by 10 and adding the new digit. For a temperature like 12.3:

'1' (byte 49) → tempInt = 0 * 10 + (49-48) = 1
'2' (byte 50) → tempInt = 1 * 10 + (50-48) = 12
'.' (byte 46) → skipped
'3' (byte 51) → tempInt = 12 * 10 + (51-48) = 123

No string decoding. No floating-point arithmetic. Just raw bytes and integer math.

Time to test the theory.

To speed up iteration, I scaled down to 10 million rows (158MB) for testing. The original naive version took 3.5 seconds on this smaller dataset.

The optimized version? 1.8 seconds.

I stared at the terminal. Nearly 50% faster 🥳.

But a good detective knows when the case isn't closed. I took a cup of hot chocolate, sat back, and onto the next lead.

The Second Lead: A False Trail (or Three)

The speedup was intoxicating, but I couldn't shake a nagging thought: we were still decoding station names. Every single time we encountered a station, we converted its bytes to a UTF-16 string to use as a Map key. For stations that appeared millions of times, this was wasteful.

What if I could avoid decoding until absolutely necessary?

I chased three leads.

Lead #1: String Interning

Dead end—you have to decode the string first to intern it. That's like filing evidence you haven't collected yet.

Lead #2: Buffer Slices as Map Keys

This one seemed promising in theory. Use raw Buffer slices as keys instead of strings, avoiding conversion altogether. But JavaScript's Map compares objects by reference, not content. Two identical buffers pointing to different memory addresses = two different keys = corrupted data. I briefly considered using JavaScript Symbols as a workaround—create a unique Symbol for each station and use that as the key. But wait... that still requires decoding the string first to check if it has seen this station before. Yet another dead end.

Lead #3: Custom Hash Map

I spent hours on this one. Built it from scratch, tested it thoroughly, and... it was slower than plain objects. Sometimes the murder weapon is your own cleverness. 😉

Then it hit me at 2 AM, staring at the code with bleary eyes: what if I hashed the buffer before converting to a string?

The Breakthrough: Hash First, Decode Later

The solution was elegant in its simplicity: compute a 32-bit hash while scanning for the semicolon. Use that hash as the Map key. Only convert the buffer to a string when absolutely necessary—at the very end, when writing output.

But there was a catch. Hash collisions could corrupt the data. Two different station names producing the same hash would merge their data, poisoning the results. I needed a failsafe: a collision resolution strategy.

Enter the linked list. Here's how the new approach worked:

function processChunk(chunk) {
  const mergedBuffer = carryoverBuffer
    ? Buffer.concat([carryoverBuffer, chunk])
    : chunk;
  const bufferLength = mergedBuffer.length;
  let cursor = 0;

  while (cursor < bufferLength) {
    const stationNameStartIndex = cursor;

    // Compute DJB2 hash while scanning to ';'
    let stationHash = 5381 >>> 0;
    while (cursor < bufferLength) {
      const currentByte = mergedBuffer[cursor];
      if (currentByte === SEMI) break;
      stationHash = ((stationHash << 5) + stationHash + currentByte) >>> 0;
      cursor++;
    }

    if (cursor >= bufferLength) {
      carryoverBuffer = mergedBuffer.subarray(stationNameStartIndex);
      return;
    }
    const stationNameEndIndex = cursor;

    // Lookup by 32-bit hash; resolve collisions via linked list
    let stationEntry = stations.get(stationHash);
    if (stationEntry === undefined) {
      stationEntry = new StationEntry(
        mergedBuffer.subarray(stationNameStartIndex, stationNameEndIndex),
      );
      stations.set(stationHash, stationEntry);
    } else {
      // Traverse collision chain
      let currentNode = stationEntry;
      let previousNode = null;
      while (currentNode !== null) {
        if (
          buffersEqual(
            mergedBuffer,
            stationNameStartIndex,
            stationNameEndIndex,
            currentNode.name,
          )
        ) {
          stationEntry = currentNode;
          break;
        }
        previousNode = currentNode;
        currentNode = currentNode.nextInBucket;
      }
      if (currentNode === null) {
        // Not found; append new entry to chain
        const newStationEntry = new StationEntry(
          mergedBuffer.subarray(stationNameStartIndex, stationNameEndIndex),
        );
        previousNode.nextInBucket = newStationEntry;
        stationEntry = newStationEntry;
      }
    }

    // ... temperature parsing continues ...
  }
}

The buffersEqual() function handled collision resolution by comparing buffer lengths first, then bytes:

function buffersEqual(
  sourceBuffer,
  sliceStartIndex,
  sliceEndIndex,
  referenceBuffer,
) {
  const sliceLength = sliceEndIndex - sliceStartIndex;
  if (sliceLength !== referenceBuffer.length) return false;
  for (let offset = 0; offset < sliceLength; offset++) {
    if (sourceBuffer[sliceStartIndex + offset] !== referenceBuffer[offset])
      return false;
  }
  return true;
}

This approach deferred all string creation out of the hot parse loop—eliminating per-line string allocations and reducing GC pressure. After streaming ended, I'd walk all the chains once: materialize each Buffer to a string, aggregate results, sort, and write to file.

I held my breath and ran it.

821 milliseconds.

Down from 1,852.

I had to run it again to believe it. Another 2.25x speedup. Cumulatively, from my starting point, I was now at roughly 4.3x faster on the 10 million row dataset.

This felt like the limit for single-threaded optimization. Time to test on the full dataset.

The full 1 billion rows completed in 1 minute and 14 seconds—down from the original 5 minutes and 49 seconds. I experimented with increasing the read stream's high water mark to see if larger chunks would help, but the gains were marginal. I settled on 256KB chunks as the sweet spot.

Testing the Alibi: Could Different Runtimes Be Faster?

Before closing the case, I had to rule out one possibility: maybe Node.js itself was the bottleneck?

Given the performance accolades of Deno and Bun, I ran the exact same code across all three runtimes. Here's what happened:

Bun (1.2.15) 🥇: 1 minute and 5 seconds
Node.js (24.6.0) 🥈: 1 minute and 14 seconds
Deno (2.4.5) 🥉: 1 minute and 21 seconds

Bun edged ahead by about 9 seconds, but the differences weren't dramatic. I was honestly surprised by Deno's performance given its reputation for speed. The real insight here? The bottleneck was never the runtime. It was the algorithm all along.

This is why I'm skeptical of generic benchmarks and marketing claims. In the real world, your specific problem determines the winner. Node.js remains my daily driver—it's stable, mature, has a vast ecosystem, and its performance is competitive for most applications. While Bun and Deno offer nice features like built-in TypeScript support, I haven't experienced game-changing performance benefits in practice. Some Node.js modules (especially native addons) still don't work well in these alternative runtimes despite their compatibility efforts.

The lesson here is to evaluate based on your use case, not salesy benchmark suites.

The Final Clue: What the Profiler Revealed

But here's the thing about good detective work: you need evidence that stands up in court. I couldn't just trust my timer—I needed to see inside the machine, to prove beyond doubt that we'd eliminated every bottleneck worth eliminating.

I started Node.js with --inspect-brk, connected Chrome DevTools, and hit record. For the next 60 seconds, I watched the flame graph paint a story in real-time, each colored bar a thread of execution, each spike a moment of computational intensity.

When it finished, I stared at the results.

The smoking gun was right there.

processChunk() consumed 50,722 milliseconds of self time—that's 87% of the total execution time. Everything else? Noise. The wrapper function, garbage collection, even file I/O—they were all bit players in this performance drama.

I dove into the heap snapshots next, looking for memory leaks or bloat that might explain any remaining slowness:

StationEntry objects: 8,872 instances. Perfect. One for each weather station.
Buffer allocations: Modest and short-lived. The streaming approach kept memory pressure low.
Garbage collection activity: Barely a whisper. The pauses were so brief they didn't even register as bottlenecks.

The evidence was conclusive. This wasn't a memory crime—no bloated objects, no runaway allocations, no GC thrashing. This was a pure CPU bottleneck.

We had done it! We'd eliminated the string conversions, the redundant parsing, the hidden allocations. The hot path was as lean as JavaScript would allow. Every microsecond had been accounted for, every inefficiency hunted down and eliminated.

But here's the thing about detective work: there's always another case or clue. The profiler confirmed what I already suspected—we were CPU-bound. One detective working alone, no matter how efficient, can only move so fast.

The next breakthrough wouldn't come from algorithmic cleverness or byte-level optimization. It would come from parallelization—splitting the work across multiple cores, multiple detectives working the same case simultaneously.

Worker threads could potentially cut this time in half again. Maybe more.

But that's a case for another day.

Case Closed (For Now)

Final Time: 1 minute, 14 seconds

Starting Time: 5 minutes, 49 seconds

Speedup: 78% (4.7x faster)

What started as weekend curiosity became a masterclass in hunting bottlenecks. The clues were there all along: unnecessary string conversions, redundant decoding, the hidden costs of abstractions we take for granted.

But here's what this case really taught me: performance optimization is detective work. You form theories, test them, follow false leads, and sometimes discover the answer was hiding in plain sight. The most effective solutions often require the least amount of change—if you're looking in the right place.

Each optimization built on the last:

Byte-level parsing eliminated string overhead
Integer arithmetic replaced floating-point math
Hashing deferred string creation to the last possible moment

Small, incremental improvements that compounded into massive gains.

The Case Remains Open

Worker threads could push this even further—potentially cutting the time in half again by utilizing all CPU cores. There are other mysteries in this data, other patterns waiting to be found.

Are you chasing bottlenecks in your Node.js applications or deployment pipeline? I love a good mystery. Feel free to reach out via email or any of my social handles—I'd be happy to help you track down those performance criminals. I'm also open to technical writing opportunities if you know anyone looking for a writer who loves deep-diving into performance optimization.

Evidence Summary: What We Learned

78% faster processing: Reduced 14.8GB file processing from 5:49 to 1:14 using buffer optimization techniques
Byte-level parsing eliminates overhead: Working directly with UTF-8 buffers instead of converting to UTF-16 strings delivered a 50% speedup
Integer arithmetic beats floats: Storing temperatures as integer tenths (253 instead of 25.3) avoided floating-point operations in the hot path
Hash-first, decode-later strategy: DJB2 hashing with collision chains deferred string creation until final output, achieving 2.25x additional speedup
CPU-bound, not I/O-bound: Profiling revealed 87% of execution time in processChunk()—streaming and buffer management were already optimal
Runtime differences are marginal: Bun (1:05), Node.js (1:14), and Deno (1:21) showed algorithm matters more than runtime choice for this workload
Further gains require parallelization with worker threads to utilize multiple CPU cores

Evidence Locker: The complete code on GitHub with detailed commit messages

Next Case: Multi-threaded optimization (TBD -> Become a subscriber to find out!)

If you decide to explore the worker threads approach or have questions about any of these techniques, let me know. The investigation continues... 🕵🏼‍♂️

Building React Apps with Bun: A Modern Development Experience

Peter Mbanugo — Tue, 02 Sep 2025 11:02:54 +0000

Bun has been making waves in the JavaScript ecosystem as an all-in-one runtime designed to be faster than Node.js while providing built-in bundling, testing and package management. For React developers, this presents an interesting opportunity to streamline the development workflow without sacrificing the tools and patterns we're familiar with.

Instead of juggling multiple tools like webpack, Vite or Create React App, Bun provides everything you need in a single package. Today, we'll explore what it's like to build a React application using Bun by creating a simple blog app with Tailwind CSS styling.

Getting Started with Bun

First, you'll need to install Bun on your system. The installation is straightforward:

curl -fsSL https://bun.sh/install | bash

You can read other installation options on the Bun installation page.

Once installed, creating a new React project with Tailwind CSS is remarkably simple. Bun provides a template that sets up everything for you with a single command: bun init --react=tailwind my-blog-app. That command creates a React project with Tailwind CSS preconfigured, using Bun's bundler and development server. No need to manually configure Tailwind, set up build scripts or wrestle with bundler configurations.

Let's get started building the blog. Open your terminal and run the following commands to create a new Bun project with React and Tailwind CSS:

bun init --react=tailwind my-blog-app
cd my-blog-app

Let's examine what Bun generated for us. The project structure looks familiar to any React developer:

my-blog-app/
├── src/
│   ├── App.tsx
│   ├── frontend.tsx
│   ├── index.tsx
│   ├── index.html
│   ├── index.css
│   ├── logo.svg
│   └── APITester.tsx
├── package.json
├── build.ts
└── bunfig.toml

The package.json file reveals something interesting–there are minimal dependencies. Bun handles most of the tooling internally, so you won't see the usual suspects like Webpack, Babel, or development servers cluttering your dependency list. The build script (build.ts) is responsible for handling the bundling and optimization of your application. You'd likely not need to touch this unless you want to customize the build process.

The files index.tsx and frontend.tsx are the entry points for your application, where index.tsx has the server routing information which can include API routing, while frontend.tsx is where your React components live. The index.html file is a simple template that Bun uses to inject your React app. The index.css file is where Tailwind CSS styles are imported and you can start adding your custom styles.

Start the development server with:

bun dev

You'll notice the server starts incredibly fast. Bun's speed isn't just marketing hype; the development experience feels noticeably snappier than traditional React setups. You can open your browser to http://localhost:3000 to see the default Bun React app running.

Building the Blog Foundation

Let's transform the default app into a blog. First, we'll need some routing since we'll have a home page listing posts and individual post pages. For this, we'll use wouter, a lightweight routing library perfect for our needs. Install it using Bun's package manager:

bun add wouter

Create a components directory in src and add the blog components. First, we'll create a BlogList component to display a list of blog posts:

// src/components/BlogList.tsx
import { Link } from "wouter";
import { Post } from "./BlogPost";

interface BlogListProps {
  posts: Post[];
}

const BlogList = ({ posts }: BlogListProps) => {
  return (
    <div className="max-w-4xl mx-auto p-6">
      <h1 className="text-4xl font-bold text-gray-900 mb-8">My Blog</h1>
      <div className="space-y-6">
        {posts.map((post) => (
          <article key={post.id} className="border-b border-gray-200 pb-6">
            <Link href={`/post/${post.slug}`}>
              <div className="block group">
                <h2 className="text-2xl font-semibold text-gray-900 group-hover:text-blue-600 mb-2">
                  {post.title}
                </h2>
                <p className="text-gray-600 mb-2">{post.excerpt}</p>
                <time className="text-sm text-gray-500">{post.date}</time>
              </div>
            </Link>
          </article>
        ))}
      </div>
    </div>
  );
};

export default BlogList;

Next, we'll create a BlogPost component to display individual blog posts. This component will render the post content and provide a link back to the home page:

// src/components/BlogPost.tsx
import { Link } from "wouter";

export interface Post {
  id: number;
  slug: string;
  title: string;
  excerpt: string;
  date: string;
  content: string;
}

interface BlogPostProps {
  post: Post | undefined;
}

const BlogPost = ({ post }: BlogPostProps) => {
  if (!post) {
    return (
      <div className="max-w-4xl mx-auto p-6">
        <p className="text-gray-600">Post not found</p>
        <Link href="/">
          <div className="text-blue-600 hover:underline">← Back to home</div>
        </Link>
      </div>
    );
  }

  return (
    <div className="max-w-4xl mx-auto p-6">
      <Link href="/">
        <div className="text-blue-600 hover:underline mb-6 inline-block">
          ← Back to home
        </div>
      </Link>
      <article>
        <h1 className="text-4xl font-bold text-gray-900 mb-4">{post.title}</h1>
        <time className="text-gray-500 mb-6 block">{post.date}</time>
        <div className="prose prose-lg prose-gray max-w-none text-gray-900">
          <div dangerouslySetInnerHTML={{ __html: post.content }} />
        </div>
      </article>
    </div>
  );
};

export default BlogPost;

Now, let's update our main App.tsx to handle routing:

// src/App.tsx
import { Route, Switch } from "wouter";
import BlogList from "./components/BlogList";
import BlogPost, { Post } from "./components/BlogPost";
import "./App.css";

// Mock blog data
const blogPosts: Post[] = [
  {
    id: 1,
    slug: "getting-started-with-bun",
    title: "Getting Started with Bun",
    excerpt:
      "Exploring the new JavaScript runtime that's changing how we build applications.",
    date: "December 15, 2025",
    content: `
      <p>Bun is revolutionizing JavaScript development with its incredible speed and built-in tooling. Unlike traditional setups that require multiple tools, Bun provides everything you need in one package.</p>
      <p>The development experience is remarkably smooth, with near-instant startup times and excellent TypeScript support out of the box.</p>
      <p>Whether you're building React applications, APIs, or full-stack projects, Bun's unified approach simplifies the entire development workflow.</p>
    `,
  },
  {
    id: 2,
    slug: "react-performance-tips",
    title: "React Performance Optimization Tips",
    excerpt:
      "Learn practical techniques to make your React applications faster and more efficient.",
    date: "December 10, 2025",
    content: `
      <p>Performance optimization in React doesn't have to be complicated. Start with these fundamentals:</p>
      <ul>
        <li>Use React.memo for expensive components</li>
        <li>Implement proper key props in lists</li>
        <li>Lazy load components with React.lazy</li>
        <li>Optimize re-renders with useMemo and useCallback</li>
      </ul>
      <p>Remember, premature optimization is the root of all evil. Measure first, then optimize based on actual performance bottlenecks.</p>
    `,
  },
  {
    id: 3,
    slug: "tailwind-design-patterns",
    title: "TailwindCSS Design Patterns",
    excerpt:
      "Common design patterns and best practices when working with TailwindCSS.",
    date: "December 5, 2025",
    content: `
      <p>TailwindCSS encourages a utility-first approach that can feel overwhelming at first. Here are some patterns that help:</p>
      <p>Create component classes for repeated patterns, use @apply directive sparingly, and leverage Tailwind's design tokens for consistency.</p>
      <p>The key is finding the right balance between utility classes and component abstractions for your team and project.</p>
    `,
  },
];

export function App() {
  return (
    <div className="min-h-screen bg-gray-50">
      <Switch>
        <Route path="/" component={() => <BlogList posts={blogPosts} />} />
        <Route path="/post/:slug">
          {(params) => {
            const post = blogPosts.find((p) => p.slug === params.slug);
            return <BlogPost post={post} />;
          }}
        </Route>
      </Switch>
    </div>
  );
}

export default App;

We used mock data to keep things simple. You can replace it with actual data fetching from a CMS or use Markdown. You can try the application by running bun dev and navigating to http://localhost:3000. You should see the blog list, and clicking on a post will take you to the individual post page.

Adding Content and Styling

The beauty of this setup is how Tailwind CSS works seamlessly with Bun's bundler. You don't need to worry about CSS processing–it just works. The utility classes are automatically purged in production builds, keeping your CSS bundle small.

If you want to use Markdown files instead of the hardcoded content, you could add a markdown parser like marked:

bun add marked

Then process your markdown content in the BlogPost component. For this tutorial, the mock data works perfectly to demonstrate the concepts without getting bogged down in file processing details.

The Tailwind CSS integration deserves special mention. Bun's bundler uses a Tailwind plugin bun-plugin-tailwind, so features like JIT compilation and CSS purging work without additional configuration. This is particularly nice when you're prototyping–you can use any Tailwind class and trust that unused styles won't bloat your final bundle.

Development Experience with Bun

Working with Bun feels refreshingly simple. Module resolution is fast and intuitive, supporting both CommonJS and ES modules without the usual configuration headaches. TypeScript works out of the box–no need for additional configuration or compilation steps.

Hot reloading is nearly instantaneous when you save files, making the development feedback loop incredibly tight. Unlike other setups where you might wait several seconds for changes to reflect, Bun's development server updates your browser almost immediately.

The built-in package manager is another nice touch. The bun add and bun install commands are noticeably faster than npm or yarn, and the lockfile format is more efficient. For React development, this means less time waiting for dependencies to install and more time building features.

Building for Production

When you're ready to deploy, building for production is straightforward:

bun run build

Bun's bundler creates optimized builds with automatic code splitting, tree shaking, and minification. The build process is fast–often completing in seconds for small to medium applications.

The bundler is intelligent about React optimizations, automatically applying production builds of React, removing development warnings and optimizing bundle sizes. You get all the benefits of modern bundlers without the configuration complexity.

If you're building a full-stack application with API routes, you can use bun start to run both your frontend and backend in production. This command starts the API server and serves both frontend and backend together in a single process, making deployment simpler for full-stack applications.

For static-only deployments, the build output from bun run build works with any static hosting provider. The generated files are standard HTML, CSS, and JavaScript that can be served from CDNs, Netlify, Vercel or traditional web servers.

When to Choose Bun for React

Bun shines in several scenarios. If you're starting a new React project and want minimal configuration overhead, Bun's templates get you productive immediately. The speed improvements are particularly noticeable on larger codebases or when working with slower development machines.

For teams wanting to reduce their tooling complexity, Bun consolidates many separate tools into one cohesive experience. No more juggling webpack configs, babel presets and multiple CLIs–everything works together seamlessly.

However, Bun is still relatively new. If you're working on a large enterprise application with complex build requirements, you might want to stick with more established toolchains until Bun's ecosystem matures further.

Wrapping Up

Building React applications with Bun offers a glimpse into a simpler future for JavaScript development. The speed, simplicity and built-in tooling create a developer experience that feels both modern and approachable.

Our simple blog app demonstrates how quickly you can get productive with Bun. From project initialization to production builds, the entire workflow feels streamlined and fast. While Bun may not be ready for every use case yet, it's definitely worth exploring for new React projects.

The JavaScript ecosystem moves fast. However, Bun's approach of combining runtime, bundler, and package manager into one cohesive tool feels like a natural evolution. For React developers tired of configuration fatigue, Bun offers a refreshing alternative that lets you focus on building great applications.

Originally published on Telerik's blog.

The Best React Library for Data-driven Applications - Your fave might not be on that list

Peter Mbanugo — Thu, 21 Aug 2025 11:11:01 +0000

Peter Mbanugo

Aug 13 '25

Looking for the Best React Data Grid (Table)? It's Probably on This List

#webdev #react #javascript #typescript

Comments 2

8 min read