Forem: Jeff Riggle

JavaScript’s Promise Rejected Its Namesake

Jeff Riggle — Tue, 17 Mar 2026 11:30:00 +0000

JavaScript promises aren’t actually the promises they were named after. The concept of a promise originated from distributed computation as a linguistic solution to a complex problem. Barbara Liskov needed a better way to work with RPC and call streams, and the promise was the answer.

In the original proposal of the promise, these key tenets emerged.

Strong types: the result and failure modes of a promise are strongly typed.
Multiple Claims: the result of a promise could be claimed any number of times.
Blocking: When a promise is claimed, the process blocks until the value is available.

Through a long series of events, we find JavaScript with a different promise. What was originally a solution for distributed systems became a means to handle asynchronous workloads with callbacks.

Now this piqued my interest. How divergent are these views of promises? To validate this, I attempted to recreate some of the examples from Barbara’s paper in JavaScript. The result was painful.

Recreating Liskov's grade example

Consuming the result of multiple promises creates a mandatory callback that aggregates the result and failure case.

// Simple version of the grade example
let studentGrades = {};

// Simulate some database activity that returns the average
function recordGrade(student, grade) {
    return new Promise((resolve, reject) => {
        setTimeout(() => {
            let grades = studentGrades[student];
            grades.push(grade);
            resolve(grades.reduce((prev, g) => prev + g, 0) / grades.length)
        }, 1);
    });
}

function main() {
    let targetStudents = [{ name: 'test', grade: 10 }, { name: 'foo', grade: 50 }, { name: 'bar', grade: 100 }];
    let averages = [];

    for (let student of targetStudents) {
        studentGrades[student.name] = [];
        averages.push(recordGrade(student.name, student.grade));
    }

    Promise.all(averages).then(values => {
        for (let i = 0; i < targetStudents.length; i++) {
            console.log('Student ', targetStudents[i].name, ' has average ', values[i]);
        }
    }).catch(e => console.error('Got unexpected error ', e));
}

main();

This works, but notice what we had to do? We needed to collect each promise, then wait on them together using Promise.all.

Sequential resolution

Now let's look at resolving them one by one to see how much more difficult it gets.

// Print the student averages as they are available
let studentGrades = {};
let targetStudents = [{ name: 'test', grade: 10 }, { name: 'foo', grade: 50 }, { name: 'bar', grade: 100 }];
let averages = [];
let updateTime = 1;

// Simulate some database activity that returns the average
function recordGrade(student, grade) {
    return new Promise((resolve, reject) => {
        updateTime = updateTime * 10;
        setTimeout(() => {
            let grades = studentGrades[student];
            grades.push(grade);

            resolve(grades.reduce((prev, g) => prev + g, 0) / grades.length)
        }, updateTime);
    });
}

function printStudent(studentIndex, average) {
    return average.then(a => {
        console.log('Student ', targetStudents[studentIndex].name, ' has average ', a);
        studentIndex++;
        if (studentIndex < targetStudents.length) {
            return printStudent(studentIndex, averages[studentIndex])
        }
    }).catch(e => console.error('Got unexpected error ', e));
}


function main() {
    for (let student of targetStudents) {
        studentGrades[student.name] = [];
        averages.push(recordGrade(student.name, student.grade));
    }
    printStudent(0, averages[0])
        .then(() => console.log('Operation success'))
        .catch(e => console.error('Got unexpected error ', e));
} 

main();

Multiple claim resolution

In the original paper, you could resolve a claim multiple times after it was resolved. In promises, you can do the same, but doing so requires a leap of faith that callbacks happen in registration order.

This is specified, but the callbacks could arguably create some initial discomfort.

If you call the then() method twice on the same promise object (instead of chaining), then this promise object will have two pairs of settlement handlers. All handlers attached to the same promise object are always called in the order they were added. Moreover, the two promises returned by each call of then() start separate chains and do not wait for each other's settlement.

function simplePromise() {
    return new Promise((resolve, reject) => {
        setTimeout(() => {
            resolve('hi');
        }, 5000);
    });
}

// Resolve a single promise 4 times. Notice this program should
// take ~5 seconds not ~20 seconds.
function main() {
    const p = simplePromise();
    for (let i = 0; i < 5; i++) {
        p.then(v => console.log('Invoke: ', i, ', value: ', v));
    }
    p.then(r => {
        console.log('Promises resolved');
    });
} 

main();

Two years after Promise was added to ECMAScript, the async/await pattern was added. While it is not perfect, it is far closer to the spirit of Liskov's promises.

Multiple claims with async/await

To demonstrate the impact async/await creates, let’s revisit the last example, but with async/await instead.

function simplePromise() {
    return new Promise((resolve, reject) => {
        setTimeout(() => {
            resolve('hi');
        }, 5000);
    });
} 

async function main() {
    let p = simplePromise();
    for (let i = 0; i < 5; i++) {
        console.log('Invoke: ', i, 'value: ', await p);
    }

    console.log('Promises resolved');
} 

main();

About those types

Now, getting back to those types. Clearly, JavaScript doesn’t have types, so comments about types do not apply. However, TypeScript is a different story. Unfortunately, TypeScript only allows typing the resolved value of a promise. The rejection path remains untyped, meaning we still lose one of the key guarantees Liskov originally proposed.

If you are interested in a more thorough history of promises, I wrote a deeper dive here.

I wouldn’t say that JavaScript promises are wrong. They filled a gap that could only really be solved at the language level. Libraries could mimic the pattern, but only the engine could properly integrate asynchronous work into the runtime.

So, what do you think? If JavaScript promises are not really Liskov’s promises, should we still call them promises at all?

Best animation you have seen or created?

Jeff Riggle — Tue, 24 Feb 2026 22:48:47 +0000

It could be the way I interact with the internet, but most sites I use today follow a pretty predictable set of patterns. I think this is great for usability and accessibility, but it can also accidentally narrow our sense of what’s possible on the web.

Most of the creative decisions I often see include, “What component library do you want to use?” and “What visual overrides do you want apply to it?” In other cases, it might be “How can I build a component library that fits my business's needs?” In some rare cases, it might be “What CSS library/framework can I adopt for my use?”

On most sites, the most surprising flow I might find is some sort of drag-and-drop behavior on a DOM element. Even rarer might be a position transition animation, for instance, a dropdown that slowly opens up.

I spent some time thinking about this and realized I have a personal website with no stakeholders where I could take a weirder path if I so choose. Armed with this observation, I created some animations and generally weird or atypical patterns. While I still don't fully like the outcome, it was a neat excuse to attempt strange CSS patterns I wouldn't normally try, as well as some 2D canvas work that I almost never get to do.

In the spirit of finding more interesting animations or patterns out there, what is the best animation you have ever created or seen on a website?

I Assumed Java Streams Had Minimal Overhead. They Didn’t

Jeff Riggle — Wed, 11 Feb 2026 02:57:38 +0000

Many of us have heard the same mantra: idiomatic code comes at little to no cost. The benefit to legibility vastly outweighs the performance boost.

I recently finished evaluating performance trade-offs, which I previously suggested in passing. Digging into the JIT output, I was surprised by how much additional assembly was generated to support the abstractions I use.

Until now, I mostly accepted the conventional wisdom. Fueled by the assumption that any difference was in the margin of error. On the rare occasion I tested this, in a hand-wavy, pseudo-scientific manner. For once, I wanted to measure it in a more rigorous way.

The Experiment

The prior test I mentioned was a bit too involved. So, I decided to create a very simple test. In this case, I would pit the tried-and-true for loop against the newer Streams API. The goal of this was just to find the cost of aggregating 1,000,000 double values using the two mechanisms.

double retVal = 0;
for (double val : values) {
    retVal += val;
}

versus

double result = Arrays.stream(test).sum();

Benchmark Methodology

JMH was my go-to for doing the benchmark. JMH allows you to test different implementations and does so with rigour. This ensures the code is run enough times to maximize the effectiveness of the JIT.

For this test, I ran on OpenJDK 17 (Hotspot) with a target architecture of ARM64. JMH was configured to have a warmup of 5 iterations and 5 forks. Results were consumed to avoid dead-code elimination, and the input array was pre-generated in a setup step.

Results

I knew to expect some performance degradation between the two approaches, but I was not prepared for what happened next. On my machine, the for loop outperformed the Streams implementation by roughly five times the operations per second.

What The JIT Produced

This didn't settle well with me. So, I generated the hotspot log file to see the disassembly for this program. In this particular compilation, the Streams version produced hundreds more instructions and significantly more memory loads/stores.

When you stack it up, there is a clear correlation between memory access instructions and operations per second.

Is The Cost Justified?

Many will be quick to notice that this is a toy benchmark and is not representative of real-world usage. To that end, you would be right. However, what this does do is boil a problem down to something simple and measurable. When you boil away all the complexity, we can see the real cost of the abstraction by itself.

This isn't to say that all code needs to be optimized. In fact, I have quite enjoyed the legibility of streams. However, it does come at a cost. The next time you are staring down some critical section of code, remember that something as simple as changing your iteration strategy can make all the difference.

Execution Is Easy Now. That’s the Problem

Jeff Riggle — Sun, 18 Jan 2026 20:52:31 +0000

At the end of last year, I had come to a stopping point on one of my many long-running side projects. I had an opportunity to double down and spend who knows how many more months on a project that no one was going to use, or do something different. Instead of trudging on, I decided to take some time and reflect.

What made this transition different was the rise of agentic coding tools such as Cursor’s plan mode and Speckit, which can execute a plan with minimal guidance. If there is one thing I have learned about AI, it is that AI is an execution monster. It enables rapid progress, often before the understanding has had time to take root. When I looked back at the graveyard that is my GitHub, I noticed a trend. I completed projects across a wide range of domains and problem spaces. These projects ranged from an Enigma machine built to understand WASM to a text adventure creator written in Java. Was it time to pick a domain and go deep? Was I doing something that was better left to AI?

For the last month or so, I have been reflecting on my first public GitHub project, the text adventure creator. If you enjoy long-winded three-part blogs with “hints of self-deprecating humor”, as LLMs like to inform me of, you can read that here.

Lessons From a Different Time

Now I could just say my piece and move on, but where is the fun in that? In that series of blogs, I journey through my first project, a decade-long slog to deliver an unused product to no one. By all means, it felt like a massive failure. However, I uncovered something I wasn’t expecting. I had learned a great deal from this failure, and many of the lessons may sound familiar.

Following industry standards without understanding the context is a great way to waste time.
If you are going leverage an ecosystem, take the time to learn it.
Building domain models by mirroring the real world isn’t engineering; it’s linguistic torture inflicted on a machine.
Solving the core problem is more important than the number of features you built.

I could stop here and say these are the lessons I learned, and you should take them to heart. Plot twist, that isn’t the message I want to deliver. Times change. These are the lessons I learned in an era long gone. The days of being able to build software without an internet connection, or with no access to an LLM optimized for coding, or even a good answer on Stack Overflow, are long gone. It is possible that the lessons to be learned now are completely different.

Execution Is Cheap. Learning Isn’t.

Output is easy to measure. Learning isn’t. During this time, I wasn’t producing anything of value; I was honing my craft. I was hustling, spending years iterating on a single project during my nights and weekends. I didn’t have extra time; I made it. Real learning comes from hard-earned mistakes over a long period of time. AI, if used uncritically, makes it easy to skip the mistakes that real learning depends on. AI is great at getting a job done quickly, validating an idea you want to pursue is worth building, or building that application you wouldn’t build otherwise. If you want to ship faster, start with the machine. If you want to learn, start with your head and ride out the struggle.