Eli Bendersky's website - JavaScript

Teaching coding with JavaScript and p5.js

2025-05-10T08:57:00-07:00

When asked which programming language to learn first - especially for kids - my usual answer is JavaScript [1]. Nothing beats the direct feedback you get from code that's able to paint things on the screen, without having to install anything.

One library that makes it a particularly pleasant process is p5.js, which was created specifically for this educational purpose. I've had good experience teaching kids basic programming using p5.js. Here's a simple example of what I mean:

(You should see some circles moving on the canvas; click on the canvas to add more)

Even though this demo is so trivial, it has many of the elements of creating simple games - colorful stuff is drawn on the screen, things are moving around according to simple physical laws, and there's interactivity!

Here's the entire code required to implement this with p5.js:

let circles = [];

function setup() {
    createCanvas(400, 400);

    for (let i = 0; i < 5; i++) {
        circles.push(randomCircleAtPos(
            width / 2 + random(-100, 100),
            height / 2 + random(-100, 100)));
    }
}

function draw() {
    background(240);

    for (let c of circles) {
        c.x += c.xSpeed;
        c.y += c.ySpeed;

        // Bounce off the walls
        if (c.x + c.size / 2 > width || c.x - c.size / 2 < 0) {
            c.xSpeed *= -1;
        }
        if (c.y + c.size / 2 > height || c.y - c.size / 2 < 0) {
            c.ySpeed *= -1;
        }
        fill(c.color);
        circle(c.x, c.y, c.size);
    }
}

function mousePressed() {
    circles.push(randomCircleAtPos(mouseX, mouseY));
}

function randomCircleAtPos(x, y) {
    return {
        x: x,
        y: y,
        size: random(20, 80),
        color: color(random(255), random(255), random(255)),
        xSpeed: random(-2, 2),
        ySpeed: random(-2, 2)
    };
}

There are many niceties provided by p5.js here:

No need to write any HTML! The createCanvas call will create a canvas element and all subsequent drawing and interaction happens on it [2].
setup is a "magic" function that gets invoked once at the beginning of the program.
draw is another magic function that gets automatically called for every animation frame (p5.js arranges the correct requestAnimationFrame calls behind the scenes).
There are many useful helper functions for drawing, without having to deal with the HTML canvas API, e.g. background, fill, circle. In particular, there's no need to deal with canvas contexts or paths.
mousePressed is yet another magic function that is called on mouse clicks within the canvas; mouseX and mouseY are magic globals that specify the mouse location within the canvas (without having to worry about client position offsets, etc.)
Utility functions like color and random have convenient, simple APIs. p5.js has many others, specifically tuned for developing simulations and games. There are vectors, utilities for smooth random noise, functions for mapping between linear ranges, etc.

I also wrote a version of the same animation without p5.js, using plain JS and canvas APIs instead. It's available on GitHub - feel free to compare!

Some history

It all started with Processing, a 25-year-old Java library designed to teach people how to code by creating animations and games (and conversely, giving artists and animators simple tools to enhance their work with code). In 2007, John Resig (of jQuery fame) developed Processing.js - a JS clone of Processing; Khan Academy started using Processing.js for a programming unit on their website.

p5.js was created in 2013; here's a brief history from their GitHub repository:

p5.js was created by Lauren Lee McCarthy in 2013 as a new interpretation of Processing for the context of the web. Since then we have allowed ourselves space to deviate and grow, while drawing inspiration from Processing and our shared community. p5.js is sustained by a community of contributors, with support from the Processing Foundation.

As a result of p5's growth in popularity, Processing.js has been archived a few years ago and new users are directed to p5.js.

While p5.js has a very similar feel to the original Java Processing library, I strongly recommend the former. With the ubiquity of the web these days, there's really no reason to use the Java variant with all the complexity of installation and running separate tools it requires. The browser is all you need!

Educational resources

At the time of writing, Khan Academy's Computer Programming course (starting at unit 4) still uses Processing.js, but it's similar enough to p5.js that I recommend ignoring the difference and just doing it - it's a great resource.

The Coding Train is another fantastic resource that uses p5.js directly to teach programming for beginners in a friendly and engaging style. If you prefer a book format with more advanced material, check out Nature of Code from the same author.

Finally, p5.js comes with its own online editor, where you can create an arbitrary number of projects (each with multiple files, if you want), and have a live preview of everything in the browser.

Using p5.js for professional programming?

OK, so p5.js is a great resource for beginners learning to write code. Is it recommended for professional programming, though? Should you incorporate p5.js in your frontend work?

This depends, but in general I'd recommend against it. At the end of the day, it all comes down to the benefits of dependencies as a function of effort. p5.js has a very wide and shallow API - if you're already a seasoned programmer familiar with JS, the additional functionality p5.js provides is fairly trivial [3]. Sooner or later you'll find yourself at odds with p5.js's abstraction or implementation of some concept and will start looking for a way out. For experienced programmers, the raw canvas API isn't that bad to deal with, so the biggest benefits of p5.js dissipate rather quickly.

That said, if you want to hack together a quick game or simulation and p5.js makes your life easier - why not! Just remember the benefit vs. effort curve.

[1]

This sometimes raises eyebrows for experienced programmers, because JavaScript has a certain reputation. My view is that none of this matters for beginners - they typically don't care about our pedantic nuances, and for them JS is as good as any other language. But the environment in which JS executes is the real boon. Imagine you're a kid with a Chromebook; to create a simple game with JS, you don't have to install anything. Just open any web-based JS IDE (e.g. CodePen, JSFiddle, or - better yet - p5.js's own online editor) and start coding. With some honest copy pasting, you can go from blank screen to colorful objects moving around and interacting with your mouse in less than a minute.

[2]

If you follow the source of my animation on this page, you'll notice I'm cheating a bit - I do need to create an explicit canvas element in HTML because I have to properly embed it within this blog post. But for demos where all you have on the screen is that canvas - this isn't needed. Beginning programmers can completely ignore the existence of HTML and CSS when starting with p5.js!

[3]	As an example of what I mean, here's p5min - a minimal clone of p5.js sufficient to run the circles demo shown earlier in this post. It's not hard to keep extending it gradually to implement additional functionality, as needed.

Notes on running Go in the browser with WebAssembly

2024-09-14T06:05:00-07:00

Recently I've had to compile Go to WebAssembly to run in the browser in a couple of small projects (#1, #2), and in general spent some time looking at WebAssembly. I find WebAssembly to be an exciting technology, both for the web and for other uses (e.g. with WASI); specifically, it's pretty great that we can take existing projects and components written in Go and run them in the browser.

In this post, I will summarize some useful patterns in running Go in the browser via WebAssembly. All the patterns are demonstrated by small, self-contained programs you can find in this GitHub repository.

Basics: calling Go from JS

This sample serves as the basis for other samples in this post: let's write a Go function that we'll call in the browser using JS. This function uses Go's math/big stdlib package to calculate the sum of the harmonic series for some duration [1], and returns the result with high precision:

// calcHarmonic calculates the harmonic series for approximately the given
// number of seconds and returns the accumulated result in a string.
func calcHarmonic(nsecs float64) string {
  d := time.Duration(nsecs * float64(time.Second))
  start := time.Now()
  r1 := big.NewRat(1, 1)
  for i := 2; ; i++ {
    addend := big.NewRat(1, int64(i))
    r1 = r1.Add(r1, addend)

    if i%10 == 0 && time.Now().Sub(start) >= d {
      break
    }
  }
  return r1.FloatString(40)
}

To export this function to JS in the browser, we add the following code:

func main() {
  // Export the name "calcHarmonic" to JS, with our wrapper as value
  js.Global().Set("calcHarmonic", jsCalcHarmonic)

  // The Go main function compiled to WASM is expected to block
  // indefinitely.
  select {}
}

// wrap calcHarmonic to be callable from JS
var jsCalcHarmonic = js.FuncOf(func(this js.Value, args []js.Value) any {
  if len(args) != 1 {
    panic("want one argument")
  }

  s := calcHarmonic(args[0].Float())
  return js.ValueOf(s)
})

This Go file is compiled to the WASM/js target with:

GOOS=js GOARCH=wasm go build -o harmonic.wasm harmonic.go

And load it from JS:

// Instantiate a new Go object (defined in from wasm_exec.js)
const go = new Go();
WebAssembly.instantiateStreaming(fetch("harmonic.wasm"), go.importObject).then(
    (result) => {
        go.run(result.instance);
    });

The JS code that calls calcHarmonic is:

let buttonElement = document.getElementById("submitButton");
document.getElementById("submitButton").addEventListener("click", () => {
    let input = document.getElementById("timeInput").value;
    let s = calcHarmonic(parseFloat(input));
    document.getElementById("outputDiv").innerText = s;
});

Finally, the wasm_exec.js file from the Go distribution has to be included with something like:

<script src="wasm_exec.js"></script>

The easiest way to obtain this file is download it from the Go project's GitHub mirror (for the same Go version your Go code is compiled with); this is handled by the Makefile in our sample project:

wasm_exec.js:
  wget https://raw.githubusercontent.com/golang/go/release-branch.go1.24/lib/wasm/wasm_exec.js

This is the basic recipe for invoking Go from JS in the browser: the Go code is platform-agnostic and presents some API and all the glue logic is done in JS. The next samples show some variations on this basic scheme.

Link to the full code for this sample.

DOM manipulation from Go

In the previous example, Go implemented the calcHarmonic function, but the rest of the program's logic was in JS - setting up an event listener for a button click, updating output, etc.

We can move more of the code to Go, if we want. The calcHarmonic remains unchanged, but our main function in Go becomes:

func main() {
  doc := js.Global().Get("document")
  buttonElement := doc.Call("getElementById", "submitButton")
  inputElement := doc.Call("getElementById", "timeInput")
  outputElement := doc.Call("getElementById", "outputDiv")

  buttonElement.Call("addEventListener", "click", js.FuncOf(
    func(this js.Value, args []js.Value) any {
      input := inputElement.Get("value")
      inputFloat, err := strconv.ParseFloat(input.String(), 64)
      if err != nil {
        log.Println(err)
        return nil
      }
      s := calcHarmonic(inputFloat)
      outputElement.Set("innerText", s)
      return nil
    }))

  select {}
}

We obtain JS values from the js.Global() context and can call functions or set attributes on them. If you squint, this looks very similar to JS code, but written in Go-ish.

This code sample demonstrates some useful capabilities of DOM manipulation in Go:

Adding event listeners on DOM elements, with Go callbacks
Getting values from DOM elements
Setting attributes on DOM elements

The only code JS remaining in our index.html is the WebAssembly loader:

const go = new Go();
WebAssembly.instantiateStreaming(fetch("harmonic.wasm"), go.importObject).then(
    (result) => {
        go.run(result.instance);
    });

All the rest is done in Go! Link to the full code for this sample.

For a more full-featured sample, check out this directory. It implements a simple Game of Life running in the browser, entirely in Go. All the game logic, canvas manipulation and event management is done in Go; here too, the only JS code in the project is the few lines used to load the WebAssembly module.

I personally prefer keeping the UI logic in JS, but if you're interested in Go purity all the way - it's definitely feasible.

Using TinyGo as an alternative compiler

The Go compiler's support for WebAssembly is pretty good these days, but there's a small snag that may be important to users: the entire Go runtime is compiled into the WASM binary. On my machine, the .wasm files produced for the sample Go code weigh in at around 2.5 MiB, which will take some time to load in the browser - especially on slow connections [2].

There's an alternative: TinyGo is a Go toolchain "for small places", specializing in embedded controllers; the same considerations apply to WASM. The TinyGo runtime is lightweight compared to Go, and the binaries are about 1/4 the size. Not everything is perfect with TinyGo, though: compilation is much slower, and the resulting code is a bit slower as well. Finally, TinyGo has some limitations that make stdlib packages that rely on reflection not work; this can be painful when interacting with JS because encoding/json relies on reflection - so you may need to look for an alternative JSON package.

The dom-in-go sample directory also shows how to build the project with TinyGo; take a look at the Makefile. Note that TinyGo has its own wasm_exec.js support file - it won't work with the one taken from the standard Go distribution; the Makefile handles this too.

Keeping the main thread free: WebAssembly in a web worker

If we come back to the original sample and run the calculation for some non-trivial amount of time (say, 2 seconds or more) - you may notice something: the page appears "frozen" while the calculation is running. You can't interact with the UI in any way, can't select text with the mouse; if you try to add periodic console.log printouts or some spinner animation - nothing will show until calcHarmonic returns with the result.

This is the expected behavior for JS when it calls a blocking, CPU-intensive function! Let's revisit the code again:

 let buttonElement = document.getElementById("submitButton");
 document.getElementById("submitButton").addEventListener("click", () => {
     let input = document.getElementById("timeInput").value;
     let s = calcHarmonic(parseFloat(input));
     document.getElementById("outputDiv").innerText = s;
 });

The highlighted line will block the main thread for 2+ seconds, but the main thread in JS is also used for all the UI interaction. This is one of the most common manifestations of function coloring problem - blocking is problematic. Luckily, all modern browsers support Web Workers - isolated threads that can execute concurrently.

It's not hard to make web workers work with WebAssembly, which is what our next demo shows. The main HTML file includes, in addition to the UI logic:

const worker = new Worker("worker.js");
worker.onmessage = ({ data }) => {
    let { action, payload } = data;
    switch (action) {
        case "log":
            console.log(`worker.log: ${payload}`);
            break;
        case "result":
            resultReady(payload);
            break;
        default:
            console.error(`Unknown action: ${action}`);
    }
};

Where worker.js is:

importScripts("wasm_exec.js");
console.log("Worker is running");

// Load the WASM module with Go code.
const go = new Go();
WebAssembly.instantiateStreaming(fetch("harmonic.wasm"), go.importObject).then(
    (result) => {
        go.run(result.instance);
        console.log("Worker loaded WASM module");
    }).catch((err) => {
        console.error("Worker failed to load WASM module: ", err)
    });

onmessage = ({ data }) => {
    let { action, payload } = data;
    postMessage({
        action: "log",
        payload: `Worker received message ${action}: ${payload}`,
    });
    switch (action) {
        case "calculate":
            let result = calcHarmonic(payload);
            postMessage({ action: "result", payload: result });
            break;
        default:
            throw (`unknown action '${action}'`);
    }
};

(The Go code remains unchanged.)

We see that the worker does the WebAssembly loading now, meaning that the Go code executes in a separate thread and the UI thread is free to run while the computation is ongoing. This sample adds a spinner that animates until the web worker returns calcHarmonic's answer, to show the effect.

Link to the full code for this sample.

Talking on a Web Socket with Go

A few years ago I published a sample of a Go server talking via web sockets with JavaScript client code. Well, since the theme here is porting all client code to Go, how about we replace that JavaScript client with yet more Go?

This turns out to be fairly simple - not much different from the "DOM manipulation in Go" section, in fact. But there are some nuances I want to cover.

The application is simple - we display a box, and whenever there's mouse movement over the box, the client sends messages to the server via a web socket; the server echoes the message back and the client uses it to update a text div:

The server code is standard Go using the golang.org/x/net/websocket package. On the client, however, we have to use browser APIs. Here's the interesting part of the code:

const wsServerAddress = "ws://127.0.0.1:4050"

// These are equivalent to the following in JS:
//
//   ws = new WebSocket(addr) ...
//
wsCtor := js.Global().Get("WebSocket")
wsEcho := wsCtor.New(wsServerAddress + "/wsecho")
wsTime := wsCtor.New(wsServerAddress + "/wstime")

To send on a web socket, we'll use this function:

// wsSend sends a message on a web socket; the web socket must be active and
// open (otherwise wsSends logs an error and doesn't send anything).
// The message will be serialized to JSON prior to sending.
func wsSend(sock js.Value, msg any) {
  if !sock.IsNull() || sock.Get("readyState").Equal(js.Global().Get("WebSocket").Get("OPEN")) {
    b, err := json.Marshal(msg)
    if err != nil {
      log.Fatal(err)
    }
    sock.Call("send", string(b))
  } else {
    log.Println("socket is not open")
  }
}

And here's how receiving looks, registering the message event listener:

wsEcho.Call("addEventListener", "message", js.FuncOf(
  func(this js.Value, args []js.Value) any {
    event := args[0]
    var ev Event
    if err := json.Unmarshal([]byte(event.Get("data").String()), &ev); err != nil {
      log.Fatal(err)
    }
    coordMsg := fmt.Sprintf("Coordinates: (%v, %v)", ev.X, ev.Y)
    outputElement.Set("innerText", coordMsg)
    return nil
  }))

As before, this is just straightforward translation of JS into Go [3]. Note something interesting that's going on here: we have two different Go programs, talking over web sockets with each other using completely different underlying libraries. One uses a Go-native implementation of web sockets; the other uses the browser implementation, exposed via a JS API. In a realistic program, it would make sense to abstract over these details so the same code could be used to send/receive data over web sockets, whether it runs on the server or the client.

Link to the full code for this sample.

Testing locally with Node.js

This section isn't strictly about "running in the browser", but it covers the important topic of local testing. Sometimes we don't want the browser in the loop for our tests; well, good news - we can leverage Node.js's ability to load and execute WebAssembly modules to run GOOS=js GOARCH=wasm Go binaries locally!

The intersting tidbit here is that we can leverage special support implemented in the Go toolchain to make these invocations similar to running/testing regular Go programs. Here's an excerpt from go help run describing it:

By default, 'go run' runs the compiled binary directly: 'a.out arguments...'.
If the -exec flag is given, 'go run' invokes the binary using xprog:
  'xprog a.out arguments...'.
If the -exec flag is not given, GOOS or GOARCH is different from the system
default, and a program named go_$GOOS_$GOARCH_exec can be found
on the current search path, 'go run' invokes the binary using that program,
for example 'go_js_wasm_exec a.out arguments...'. This allows execution of
cross-compiled programs when a simulator or other execution method is
available.

The Makefile in our sample handles this fully; we can run a test like this locally, without opening the browser:

//go:build js && wasm

package main

import (
  "log"
  "syscall/js"
  "testing"
)

func TestJSArr(t *testing.T) {
  log.Println("hello from test in js/wasm")

  objs := js.Global().Call("eval", `({
arr: [41,42,43],
})`)

  arr := objs.Get("arr")
  if got := arr.Length(); got != 3 {
    t.Errorf("got %#v, want %#v", got, 3)
  }

  if got := arr.Index(1).Int(); got != 42 {
    t.Errorf("got %#v, want %#v", got, 42)
  }
}

With an invocation like:

GOOS=js GOARCH=wasm go test -exec=supportfiles/go_js_wasm_exec -v .

Link to the full code for this sample.

[1]	The harmonic series is known to diverge, but very slowly. You need over 200 million elements to get to the sum of 20, etc. (see A004080).

[2]	There are some additional mitigations we can explore, like compressing the WASM binary. This is outside the scope of this post, and it applies to the TinyGo output as well.

[3]	To be honest, this makes me appreciate JS as an extension language. It has such a simple ABI! Everything is an object, and we can get/set object properties (which can be other objects), and call functions/methods - that's all we need to access all of the browser APIs.

Asking an LLM to build a simple web tool

2024-07-09T20:09:00-07:00

I've been really enjoying following Simon Willison's blog posts recently. Simon shows other programmers the way LLMs will be used for code assistance in the future, and posts full interactions with LLMs to build small tools or parts of larger applications.

A recent post caught my attention; here Simon got an LLM (Claude 3.5 Sonnet in this case) to build a complete tool that lets one configure/tweak box shadow settings and copy the resulting CSS code for use in a real application. One thing that seemed interesting is that the LLM in this case used some heavyweight dependencies (React + JSX) to implement this; Almost 3 MiB of dependency for something that clearly needs only a few dozen lines of HTML + JS to implement; yikes.

So I've decided to try my own experiment and get an LLM to do this without any dependencies. It turned out to be very easy, because the LLM I used (in this case ChatGPT 4o, but it could really have been any of the top-tier LLMs, I think) opted for the no-dependency approach from the start. I was preparing to ask it to adjust the code to remove dependencies, but this turned out to be unnecessary.

The resulting tool is very similar to Simon's in functionality; it's deployed at https://eliben.org/box-shadow-tool/; here's a screenshot:

Here are my prompts:

CSS for a slight box shadow, build me a tool that helps me twiddle settings and preview them and copy and paste out the CSS

ChatGPT produced a working tool but it didn't really look good on the page.

Yes, make the tool itself look a bit better with some CSS so it's all centered on the screen and there's enough space for the preview box

It still wasn't quite what I wanted.

the container has to be wider so all the text and sliders fix nicely, and there's still not enough space for the shadows of the preview box to show without overlapping with other elements

Now it was looking better; I wanted a button to copy-paste, like in Simon's demo:

this looks better; now add a nice-looking button at the bottom that copies the resulting css code to the clipboard

The code ChatGPT produced for the clipboard copy operation was flagged by vscode as deprecated, so I asked:

it seems like "document.execCommand('copy')" is deprecated; is there a more accepted way to do this?

The final version can be seen in the online demo (view-source). The complete ChatGPT transcript is available here.

Insights

Overall, this was a positive experience. While a tool like this is very simple to implement manually, doing it with an LLM was even quicker. The results are still not perfect in terms of alignment and space, but they're good enough. At this point one would probably just take over and do the final tweaks manually.

I was pleasantly surprised by how stable the LLM managed to keep its output throughout the interaction; it only modified the parts I asked it to, and the rest of the code remained identical. Stability has been an issue with LLMs (particularly for images), and I'm happy to see it holds well for code (there could be some special tuning or prompt engineering for ChatGPT to make this work well).

ES Module imports in Node.js and the browser

2023-10-23T20:58:00-07:00

For a recent project, I wanted to have some JS code (in multiple files) available for testing from the command-line with Node.js, but also to be able to load the same code into a web page to be invoked directly from a browser.

I've encountered this same issue before for my in-browser 8080 assembler and simulator project, and used a combination of CommonJS requires with a bundler tool to make it work. But we're in 2023 now, and CommonJS is supposed to be phasing out. So my goal for the new project was to do this using ES modules (ESM) and without any separate tooling.

Let's see how it works.

Project structure

Here's the structure of the js-gauss-spline project serving as our demo:

$ tree
.
├── eqsolve.js
├── package.json
├── plot.html
├── README.md
├── spline.js
└── test
    └── test.js

The files eqsolve.js and spline.js implement the functionality we want to both test on the command-line and import in the browser. Their functionality is exposed via exported functions.

Testing in Node.js

The test code lives in test/test.js, and it starts like this:

import assert from 'node:assert/strict';
import { solve } from '../eqsolve.js';
import { buildSplineEquations } from '../spline.js';

The exported functions we want to test are imported with relative paths. The file also imports Node's built-in assert functionality; it uses asserts directly, without any unit-testing framework.

To run the tests, simply invoke node (which has to be a recent version that properly supports ES modules):

$ node --version
v20.5.0
$ node test/test.js
success

Running in the browser

So far so good. Now let's import these files into a web application running in the browser; in our project, the main entry point is plot.html. It has more custom JS code, along with whatever HTML elements are needed. Here's the JS part that imports functions from eqsolve.js and spline.js:

<script type="module">
    import * as d3 from "https://cdn.jsdelivr.net/npm/d3@7/+esm";
    import { buildSplineEquations } from "./spline.js";
    import { solve } from "./eqsolve.js";

    // ... more web-app JS code here
</script>

According to MDN, browsers have supported ES modules for quite a while now, so if you have a reasonably recent browser it should support script type="module" and import statements.

Note that our code here imports an additional JS library using ESM - d3, directly from a URL.

When testing this web page locally, opening it as a file with the file:/// scheme won't work; you'll get CORS errors in the browser console, because importing local files from the page is not supported. We'll need to serve the directory locally using a file server.

Luckily this is very easy to do with my static-server project [1]:

$ static-server .
2023/10/21 07:07:44.168573 Serving directory "." on http://127.0.0.1:8080

With this server running, opening http://127.0.0.1:8080/plot.html should successfully load everything.

Direct support of JS imports in the browser is a big step forward for the ecosystem; now it's easy to properly structure non-trivial web applications without requiring a separate build step with external tooling.

[1]	If you don't have `go` installed, the NPM http-server package will work just as well.

Cubic spline interpolation

2023-10-12T05:57:00-07:00

This post explains how cubic spline interpolation works, and presents a full implementation in JavaScript, hooked up to a SVG-based visualization. As a side effect, it also covers Gaussian elimination and presents a JavaScript implementation of that as well.

I love topics that mix math and programming in a meaningful way, and cubic spline interpolation is an excellent example of such a topic. There's a bunch of linear algebra here and some calculus, all connected with code to create a useful tool.

Motivation

In an interpolation problem, we're given a set of points (we'll be using 2D points X,Y throughout this post) and are asked to estimate Y values for Xs not in this original set, specifically for Xs that lie between Xs of the original set (estimation for Xs outside the bounds of the original set is called extrapolation).

As a concrete example, consider the set of points (0, 1), (1, 3), (2, 2); here they are plotted in the usual coordinate system:

Interpolation is estimating the value of Y for Xs between 0 and 2, given just this data set. Obviously, the more complex the underlying function/phenomenon, and the fewer original points we're given, interpolation becomes more difficult to do accurately.

There are many techniques to interpolate between a given set of points. Polynomial interpolation can perfectly fit N points with an N-1 degree polynomial, but this approach can be problematic for large a N; high-degree polynomials tend to overfit their data, and suffer from other numerical issues like Runge's phenomenon.

Instead of interpolating all the points with a single function, a very popular alternative is using Splines, which are piece-wise polynomials. The idea is to fit a low-degree polynomial between every pair of adjacent points in the original data set; for N points, we get N-1 different polynomials. The simplest and best known variant of this technique is linear interpolation:

Linear interpolation has clear benefits: it's very fast, and when N is large it produces reasonable results. However, for small Ns the result isn't great, and the approximation is very crude. Here's the linear spline interpolation of the Sinc function sampled at 7 points:

We can certainly do much better.

How about higher-degree splines? We can try second degree polynomials, but it's better to jump straight to cubic (third degree). Here's why: to make our interpolation realistic and aesthetically pleasing, we want the neighboring polynomials not only to touch at the original points (the linear splines already do this), but to actually look like they're part of the same curve. For this purpose, we want the slope of the polynomials to be continuous, meaning that if two polynomials meet at point P, their first derivatives at this point are equal. Moreover, to ensure smoothness and to minimize needless bending [1], we also want the second derivatives of the two polynomials to be equal at P. The lowest degree of polynomial that gives us this level of control is 3 (since the second derivative of a quadratic polynomial is constant); hence cubic splines.

Here's a cubic spline interpolating between the three points of the original example:

And the Sinc function:

Because of the continuity of first and second derivatives, cubic splines look very natural; on the other hand, since the degree of each polynomial remains at most 3, they don't overfit too much. Hence they're such a popular tool for interpolation and design/graphics.

All the plots in this post have been produced by JavaScript code that implements cubic spline interpolation from scratch. Let's move on to learn how it works.

Setting up equations for cubic spline interpolation

Given a set of N points, we want to produce N-1 cubic polynomials between these points. While these are distinct polynomials, they are connected through mutual constraints on the original points, as we'll see soon.

More formally, we're going to define N-1 polynomials in the inclusive range i \in\{0 ...N-2\}:

\[p_i(x)=a_ix^3+b_ix^2+c_ix+d_i\]

For each polynomial, we have to find 4 coefficients: a, b, c and d; in total, for N-1 polynomials we'll need 4N-4 coefficients. We're going to find these coefficients by expressing the constraints we have as linear equations, and then solving a system of linear equations. We'll need 4N-4 equations to ensure we can find a unique solution for 4N-4 unknowns.

Let's use our sample set of three original points to demonstrate how this calculation works: (0, 1), (1, 3), (2, 2). Since N is 3, we'll be looking for two polynomials and a total of 8 coefficients.

The first set of constraints is obvious - each polynomial has to pass through the two points it's interpolating between. The first polynomial passes through the points (0, 1) and (1, 3), so we can write the equations:

\[\begin{align*} p_0(0)&=0a_0 + 0b_0 + 0c_0 + d_0=1\\ p_0(1)&=a_0+b_0+c_0+d_0=3 \end{align*}\]

The second polynomial passes through the points (1, 3) and (2, 2), resulting in the equations:

\[\begin{align*} p_1(1)&=a_1+b_1+c_1+d_1=3\\ p_1(2)&=8a_1 + 4b_1 + 2c_1 + d_1=2 \end{align*}\]

We have 4 equations, and need 4 more.

We constrain the first and second derivatives of the polynomials to be equal at the points where they meet. In our example, there are only two polynomials that meet at a single point, so we'll get two equations: their derivatives are equal at point (1, 3).

Recall that the first and second derivatives of a cubic polynomial are:

\[\begin{align*} p_i'(x)&=3a_ix^2+2b_ix+c_i\\ p_i''(x)&=6a_ix+2b_i \end{align*}\]

The equation we get from equating the first derivatives is:

\[p_0'(1)=3a_0+2b_0+c_0=p_1'(1)=3a_1+2b_1+c_1\]

Or, expressed as a linear equation of all coefficients:

\[3a_0+2b_0+c_0-3a_1-2b_1-c_1=0\]

Similarly, the equation we get from equating the second derivatives is:

\[p_0''(1)=6a_0+2b_0=p_1''(1)=6a_1+2b_1\]

Expressed as a linear equation of all coefficients:

\[6a_0+2b_0-6a_1-2b_1=0\]

This brings us to a total of 6 equations. The last two equations will come from boundary conditions. Notice that - so far - we didn't say much about how our interpolating polynomials behave at the end points, except that they pass through them. Boundary conditions are constraints we create to define how our polynomials behave at these end points. There are several approaches to this, but here we'll just discuss the most commonly-used one: a natural spline. Mathematically it says that the first polynomial has a second derivative of 0 at the first original point, and the last polynomial has a second derivative of 0 at the last original point. In our example:

\[\begin{align*} p_0''(0)=0\\ p_1''(2)=0 \end{align*}\]

Substituting the second derivative equations:

\[\begin{align*} p_0''(0)&=2b_0=0\\ p_1''(2)&=12a_1+2b_1=0 \end{align*}\]

We have 8 equations now:

\[\begin{align*} d_0&=1\\ a_0+b_0+c_0+d_0&=3\\ a_1+b_1+c_1+d_1&=3\\ 8a_1 + 4b_1 + 2c_1 + d_1&=2\\ 3a_0+2b_0+c_0-3a_1-2b_1-c_1&=0\\ 6a_0+2b_0-6a_1-2b_1&=0\\ 2b_0&=0\\ 12a_1+2b_1&=0 \end{align*}\]

To restate the obvious - while our example only uses 2 polynomials, this approach generalizes to any number. For N original points, we'll interpolate with N-1 polynomials, resulting in 4N-4 coefficients. We'll get:

2N-2 equations from setting the points these polynomials pass through
N-2 equations from equating first derivatives at internal points
N-2 equations from equating second derivatives at internal points
2 equations from boundary conditions

For a total of 4N-4 equations.

The code that constructs these equations from a given set of points is available in this file.

Solving the equations

We now have 8 equations with 8 variables. Some of them are trivial, so it's tempting to just solve the system by hand, and indeed one can do it very easily. In the general case, however, it would be quite difficult - imagine interpolating 10 polynomials resulting in 36 equations!

Fortunately, the full power of linear algebra is now at our disposal. We can express this set of linear equations as a matrix multiplication problem Ax=b, where A is a matrix of coefficients, x is a vector of unknowns and b is the vector of right-hand side constants:

\[Ax=b\Rightarrow \begin{pmatrix} 0 & 0 & 0 & 1 & 0 & 0 & 0 & 0\\ 1 & 1 & 1 & 1 & 0 & 0 & 0 & 0\\ 0 & 0 & 0 & 0 & 1 & 1 & 1 & 1\\ 0 & 0 & 0 & 0 & 8 & 4 & 2 & 1\\ 3 & 2 & 1 & 0 & -3 & -2 & -1 & 0\\ 6 & 2 & 0 & 0 & -6 & -2 & 0 & 0\\ 0 & 2 & 0 & 0 & 0 & 0 & 0 & 0\\ 0 & 0 & 0 & 0 & 12 & 2 & 0 & 0\\ \end{pmatrix}\begin{pmatrix} a_0 \\ b_0 \\ c_0 \\ d_0 \\ a_1 \\ b_1 \\ c_1 \\ d_1\end{pmatrix}=\begin{pmatrix} 1\\ 3\\ 3\\ 2\\ 0\\ 0\\ 0\\ 0 \end{pmatrix}\]

Solving this system is straightforward using Gaussian elimination. Our JavaScript implementation does this in a few steps:

Performs Gaussian elimination to bring A into row-echelon form, using the algorithm outlined on Wikipedia. This approach tries to preserve numerical stability by selecting the row with the largest (in absolute value) value for each column [2].
Further transforms the resulting matrix into reduced row-echelon form (a.k.a. Gauss-Jordan elimination)
Extracts the solution.

In our example, the solution ends up being the vector (-0.75, 0, 2.75, 1, 0.75, -4.5, 7.25, -0.5); therefore, the interpolating polynomials are:

\[\begin{align*} p_0(x)&=-0.75x^3+2.75x+1\\ p_1(x)&=0.75x^3-4.5x^2+7.25x-0.5 \end{align*}\]

Performing the interpolation itself

Now that we have the interpolating polynomials, we can generate any number of interpolated points. For all x between 0 and 1 we use p_0(x), and for x between 1 and 2 we use p_1(x). In our JavaScript code this is done by the doInterpolate function. We've already seen the result:

Code

The complete code sample for this post is available on GitHub. It includes functions for constructing equations for cubic splines from an original set of points, code for solving linear equations with Gauss-Jordan elimination, and a demo HTML page that plots the points and linear/spline interpolations.

The code is readable, heavily-commented JavaScript with no dependencies (except D3 for the plotting).

An additional demo that uses similar functionality is line-plotting; it plots arbitrary mathematical functions with optional interpolation (when the number of sampled points is low).

[1]

This requirement actually has neat historical roots. In the days before computers, "splines" were elastic rulers engineers and drafters would use to interpolate between points by hand. These rulers would bend and connect at the original points, and it was considered best practice to minimize bending.

[2]	This helps avoid division by very small numbers, which may cause issues when using finite-precision floating point.