DEV Community: eachampagne

A Farewell to ActionScript

eachampagne — Mon, 09 Feb 2026 12:26:08 +0000

My first programming language was JavaScript, but my favorite for years has been ActionScript (3, to be precise). Many years ago, I learned ActionScript to try to make a Flash game, and fell in love with programming somewhere during the process of creating a character that could walk across the screen. Since then, ActionScript has been the standard for what I look for in a programming language, even as I moved one to other projects.

A Personal Baseline

It's been years since I worked in ActionScript, so I dug out some of my own code to look at it now that I have more experience under my belt. It's quite interesting to see how working with this language (or any language) influences the assumptions I've brought into my later work. Let's look at some samples:


public class WorldSprite {
    public var charname:String;
    public var currentFrame:Bitmap;
    public var follower:WorldSprite;
    public var hasFollower:Boolean = false;

    protected var _stage:DisplayObjectContainer;
    protected var _scale:Number;
    protected var _spritesheet:SpriteSheet;
    protected var _coors:Array;
    protected var _x:Number;
    protected var _y:Number;
    protected var _z:Number;
    protected var _dir:uint; //0 = down, 1 = up, 2 = right, 3 = left
    protected var _walkFrameCounter:uint;
    protected var _commandArray:Array = [];
    protected var _stepArray:Array = [];
    protected var _moving:Boolean = false;
    protected var _framesToMoveTiles:uint = 8;
    protected var _followerNextStepDir:uint;
    protected var _pressedArray:Array = [];
    protected var _isPC:Boolean;
    protected var _isFollower:Boolean;
    protected var _currentMap:TileMap;

    // constructors, functions, etc

}

First, we have the beginning of a declaration for a (probably overengineered) character class. I've found it strange that in JavaScript, properties are added onto an object whenever necessary rather than declaring them upfront as I did here (although upfront declarations can be done). JavaScript is really a prototypal language - its class syntax is sugar over setting up the prototype under the hood. ActionScript, however, has both prototype and class inheritance. I prefer the upfront declarations for clarity, but JavaScript's system makes more sense not that I understand the reason for the discrepancy.

I also have always appreciated ActionScript's strong typing. TypeScript gives me something similar, but it requires installing types for every package and occasionally overloading types that are wrong. I never had such issues with ActionScript (though to be fair, I never used anything beyond the standard libraries). I also like that ActionScript has separate types for unsigned integers, signed integers, and floating point numbers, rather than a catch-all number class.

Let's take a look at another sample from later in the same class:


protected function step(dir:uint):void { //This does *NOT* have the walkable logic! Use addStepCommand if external!
    this._moving = true;
    if(!this._isFollower && coorsOnMap(this._currentMap,this._coors)) {
        this._currentMap.editDynamicMap(this._coors,null);
    }
    this._dir = dir;
    this.changeFrame(this._dir * 2);

    this._walkFrameCounter = 0;
    if(this.hasFollower) {
        var followerDir:int = this.calcFollowerStep(); //Bad things happen if this is a uint
        if(followerDir != -1) {
            this.follower.step(followerDir);
        }
    }
    if(dir == 0) {
        this._coors[1] += 1;
        adjustZ(); //All get adjusted at the end of the step, but this must be done sooner to avoid clipping through the tile
    } else if (dir == 1) {
        this._coors[1] -= 1;
    } else if (dir == 2) {
        this._coors[0] += 1;
    } else if (dir == 3) {
        this._coors[0] -= 1; 
    }
    if(!this._isFollower && coorsOnMap(this._currentMap,this._coors)) {
        this._currentMap.editDynamicMap(this._coors,this); //means you can't walk through things
    }
    this.currentFrame.addEventListener(Event.ENTER_FRAME,_walkFrame);
}

We can see that JavaScript and ActionScript have almost identical syntax, which makes sense as both are ECMAScript implementations, though there are a few differences besides the explicit typing. For example, ActionScript uses the double equal sign rather than triple for equality checking because it handles type coercion differently. The ENTER_FRAME event also points to the differing ways the browser and Flash handle rendering. Flash had discrete frames and associated events, and attempted to play at a steady framerate, so I treated frames as reliable units of time for animation. (If ActionScript had some sort of delta variable to handle frame stuttering, I didn't know about it.) I still find myself thinking in terms of frames - 'on the next frame, my page should render such-and-such' - even when I'm not explicitly working with frames (though it is possible in the browser, such as by using the requestAnimationFrame() method).

A Brief Hope

Unfortunately for me, the death of Flash pretty much ended my hopes to write in ActionScript. Flash wasn't the only thing that used AS3, of course. I never looked into Adobe AIR because I'd gotten the impression it was really for Mac, and by the time I learned that it had Windows runtimes I'd already moved to Linux. I learned while researching this, however, that Adobe Flex had evolved into Apache Flex and now Apache Royale, which still uses ActionScript. Perhaps I could use my favorite language again!

As I read more about the project, I became increasingly excited. Royale adds some JavaScript features I particularly rely on to ActionScript, such as arrow functions and the null conditional operator. It boasts the ability to compile to JavaScript and even to use JavaScript libraries (Node.js and Apache Royale), increasing the odds that any project I created would be usable. I installed and ran Royale's Hello World, and wrote my first ActionScript in years.

Unfortunately, I quickly ran into problems.

Too Good to be True

Once I got the Hello World set up, I had no idea how to proceed. I could write ActionScript within the script tag or in other .as files, run it, and see output in my browser console, but I couldn't figure out how to interact with the page from my script, much less draw graphics.

Royale is based on AS3 and MXML, a markup language similar to HTML, but which was totally new to me. If I had experience with Flex, it would have been easier to adapt, but even then all the libraries have changed. I had trouble finding information about which namespaces were available, much less what options they all contained, and to be honest, I'm really more interested in writing ActionScript than learning MXML.

Some of this was a documentation problem. Sections of the website are incomplete or missing. I found information on setting up a front end application with Royale, but nothing on just drawing a single rectangle. One of the strengths of Flash was the ease of using graphics, since it was so geared to animations and games, so I was disappointed not to find anything. Given that the project itself last major update was December 2024, I'm not optimistic that things will change soon.

Final Thoughts

I really, really wanted this to work. I was so excited to discover that ActionScript was still around, and I was looking forward to creating even a proof of concept project with it. I'm sure it can be done, but the effort to wade through missing documentation and a markup language I don't understand just isn't justified by the few features I feel like I'm missing in JavaScript. I might continue to check in on Royale every once in a while, but I don't intend to put much time into fighting it in its current state.

In some ways this feels like closing a door. I've come full circle and am working in JavaScript again, though it's come a long way since I first learned to declare variables with var in Khan Academy's Drawing and Animation course. For games in particular, Haxe often gets recommended as the next step from Flash, and of course there are other options for complete engines such as Godot. And ActionScript wouldn't have been much help for my ultimate goal of scientific programming. I'll always be fond of ActionScript and thankful for what I've learned working with it, but it's just not the tool for me anymore.

An Adventure in WebGL

eachampagne — Mon, 26 Jan 2026 14:05:37 +0000

Overview

WebGL is an API for drawing computer graphics on the GPU in a web browser, usually used for browser-based 3D graphics.

The general process of creating a WebGL application involves writing vertex and fragment shaders, linking them into a shader program, and passing data into that program. While the shaders themselves are written in GLSL, most of the process is done in JavaScript, which allows the use of dynamic data and considerable interactivity.

Demo

This post is not a tutorial. If you're looking to get started with WebGL, I recommend MDN's series of tutorials, which walk you through your first WebGL project. I learn better by experimentation, so once I got to the spinning cube part of the tutorial I branched off to try things on my own. This article summarizes my results.

Click and drag to rotate

The tutorial left me with a perpetually spinning cube, but I wanted more control. I wanted to be able to drag to rotate the cube to any orientation.

Rotation is controlled by a series of mat4.rotate() calls in drawScene(), which rotate modelViewMatrix about each of the three axes. This rotates the camera about the scene, creating the illusion that cube itself is rotating. To control the rotation directly, I moved the definition, translation, and rotation of modelViewMatrix out of drawScene() and into my main file, then passed the transformed modelViewMatrix into drawScene(). Setting up event handlers to rotate the matrix while dragging is fairly standard, but determining how to rotate the matrix required some calculations.

I decided that, while dragging the mouse in a particular direction, I wanted the cube to rotate about the axis perpendicular both to the movement of the mouse and to the line of sight into the page. I can get the mouse's direction of motion by comparing its current position to its position the last time the mousemove event fired. Reversing the x and y components gives me the perpendicular vector in the xy-plane.

function handleMouseMove(event) {
  if (isRotating) {
    const deltaX = event.offsetX - x;
    const deltaY = event.offsetY - y;

    // reset x and y for next mousemove event
    x = event.offsetX;
    y = event.offsetY;

    const screenAxis = vec3.fromValues(deltaY, deltaX, 0);
    const magnitude = Math.sqrt(deltaX*deltaX + deltaY*deltaY);
    vec3.normalize(screenAxis, screenAxis);

    // ...
  }
}

This gets me the desired axis of rotation projected onto the plane of the screen. When the program first starts, this will match the intended axis of rotation. However, once the scene has been rotated, the screen and scene axes will be misaligned. To compensate for the scene's rotation, we first retrieve the current rotation as a quaternion:

const rotationQuat = quat.create();
mat4.getRotation(rotationQuat, modelViewMatrix);

(Quaternions are one of several ways to encode three-dimensional rotation. Fortunately, the matrix library takes care of the actual computations.)

We then transform the screen axis by the inverse of the rotation quaternion to "undo" the scene's rotation and find the axis that is projected onto the screen axis:

mat4.getRotation(rotationQuat, modelViewMatrix);
quat.invert(rotationQuat, rotationQuat);

const rotationAxis = vec3.create();
vec3.transformQuat(rotationAxis, screenAxis, rotationQuat);

Finally we rotate modelViewMatrix about the rotation axis, proportionally to the mouse velocity:

mat4.rotate(
  modelViewMatrix,
  modelViewMatrix,
  magnitude / 100,
  rotationAxis
);

The scene is redrawn with the new rotation, and we can turn our cube any way we like.

The full function to handle rotating the scene is as follows:

function handleMouseMove(event) {
  if (isRotating) {
    const deltaX = event.offsetX - x;
    const deltaY = event.offsetY - y;

    // reset x and y for next mousemove event
    x = event.offsetX;
    y = event.offsetY;

    const screenAxis = vec3.fromValues(deltaY, deltaX, 0);
    const magnitude = Math.sqrt(deltaX*deltaX + deltaY*deltaY);
    vec3.normalize(screenAxis, screenAxis);


    const rotationQuat = quat.create();
    mat4.getRotation(rotationQuat, modelViewMatrix);
    quat.invert(rotationQuat, rotationQuat);

    const rotationAxis = vec3.create();
    vec3.transformQuat(rotationAxis, screenAxis, rotationQuat);

    mat4.rotate(
      modelViewMatrix,
      modelViewMatrix,
      magnitude / 100,
      rotationAxis
    );
  }
}

Programmatic Stars

Once I had control over my scene, I wanted to draw something more interesting than our cube. I've always been interested in space, so I decided to create a WebGL galaxy with scattered points as my stars.

Much of the scene setup can remain the same, including our click and drag functionality, but a few things need to change. Most immediately, we need to change from drawing gl.TRIANGLES to gl.POINTS in our gl.drawElements() call. That doesn't quite work on its own, because WebGL doesn't know how big to draw each point, so we need to add the line gl_PointSize = 1.0; to the vertex shader source (within the main function) to draw each point as one pixel.

Because we're drawing individual points rather than triangles, using an index buffer to reuse vertices in different triangles doesn't help us. So we can remove the index buffer and change gl.drawElements (which uses the index buffer) back to gl.drawArrays (which doesn't). (If you're following along, you need to undo many of the changes in the Creating 3D objects using WebGL step.)

We still need vertex and color buffers, but now we want to randomly distribute our points instead of declaring them all manually. I found it simplest to create arrays of points and colors first, then pass those arrays into initPositionBuffer and indexColorBuffer to reuse the existing logic for binding the buffers.

Now it's just a matter of creating the stars. I left them all white (although the final result would be prettier with some variation - some regions of the galaxy should have more blue stars, others more red), but I had some fun coming up with ways to distribute them.

I split the galaxy into its disk and its bulge. For the disk, I evenly distributed the stars along r and z, but for theta I needed them to cluster into spiral arms. I played around with Wolfram|Alpha a bit to get the equation right but ended up with:

// maxRadius - radius of the whole galaxy
// rateOfCurvature - controls how tight the spiral arms are
// smearFactor - controls how "wide" the spiral arms are
// thicknessRatio - how thick the galaxy is, as a function of its radius
// numArms - how many spiral arms
function distributeDisk(maxRadius, rateOfCurvature, smearFactor, thicknessRatio, numArms = 2) {
  const thickness = thicknessRatio * maxRadius; // thickness of disk relative to radius

  const r = Math.random() * maxRadius;

  const thetaSeed = Math.random();

  // 2 pi thetaSeed - spreads the stars evenly around the disk
  // sin(2 pi numArms * thetaSeed) / (numArms * smearFactor) - makes the stars group together in spiral arms
  // r * rateOfCurvature - changes the angles of peak and trough density as r increase - "bends" the arms
  const theta = 2 * Math.PI  * thetaSeed + Math.sin(thetaSeed * 2 * numArms * Math.PI) / (numArms * smearFactor) + r * rateOfCurvature;

  const z = Math.random() * thickness - (thickness / 2);

  return [r, theta, z];
}

Not astrophysically accurate by any means, but clearly a spiral galaxy!

The bulge was simpler - just create a sphere, then compress it a bit along the z axis to make an ellipsoid.

// maxRadius: radius of the bulge (before compressing)
// compressionFactor (< 1): - multiplies the z-height of the bulge to make it an ellipsoid
function distributeBulge(maxRadius, compressionFactor) {
  const r = Math.random() * maxRadius;
  const theta = Math.random() * Math.PI;
  const phi = Math.random() * 2 * Math.PI;

  const [x, y, z] = sphericalToCartesian([r, theta, phi]);

  return [x, y, z * compressionFactor];
}

My very own galaxy!

I left out a lot of the details (coordinate transformations, passing parameters around, etc.) in favor of getting to the most interesting details. I used 10000 stars, and while there's a noticeable pause while they're all created and assigned positions, once the initial setup is finished there's no lag while rotating the galaxy.

I also left myself a few parameters to tweak my results:

Rate of curvature 2:

Rate of curvature 4:

I don't consider myself particularly artistic, so it's exciting to be able to create (and customize) something like this!

Websockets with Socket.IO

eachampagne — Mon, 12 Jan 2026 10:09:53 +0000

This post contains a flashing gif.

HTTP requests have taken me pretty far, but I’m starting to run into their limits. How do I tell a client that the server updated at midnight, and it needs to fetch the newest data? How do I notify one user when another user makes a post? In short, how do I get information to the client without it initiating the request?

Websockets

One possible solution is to use websockets, which establish a persistent connection between the client and server. This will allow us to send data to the client when we want to, without waiting for the client’s next request. Websockets have their own protocol (though the connection is initiated with HTTP requests) and are language-agnostic. We could, if we wanted, implement a websocket client and its corresponding server from scratch or with Deno… or we could use one of the libraries that’s already done the hard work for us. I’ve used Socket.IO in a previous project, so we’ll go with that. I enjoyed working with it before, and it even has the advantage of a fallback in case the websocket fails.

Colorsocket

For immediate visual feedback, we’ll make a small demo where any one client can affect the colors displayed on all. Each client on the /color endpoint has a slider to control one primary color, plus a button to invert all the other /color clients. (The server assigns a color in order to each client when the client connects, so you just have to refresh a few times until you get all three colors. I did make sure duplicate colors would work in sync, however.) The /admin user can turn primary colors on or off. Here’s the app in action:

The clients aren’t all constantly making requests to the server. How do they know to update?

Establishing Connections

When each client runs its <script>, it creates a new socket, which opens a connection to the server.

// color.html
const socket = io('/color'); // we’ll come back to the argument

The script then assigns handlers on the new socket for the various events we expect to receive from the server:

// color.html
socket.on('assign-color', (color, colorSettings, activeSettings) => {
  document.getElementById('color-name').innerText = color;
  controllingColor = color;
  currentBackground = colorSettings;
  active = activeSettings;
  colorSlider.disabled = !active[controllingColor];
  document.getElementById('active').innerText = active[controllingColor] ? 'active' : 'inactive';
  colorSlider.value = colorSettings[controllingColor];
  updateBackground();
});

socket.on('set-color', (color, value) => {
  currentBackground[color] = value;
  if (controllingColor === color) {
    colorSlider.value = value;
  }
  updateBackground();
});

socket.on('invert', () => {
  inverted = !inverted;
  document.getElementById('inverted').innerText = inverted ? '' : 'not ';
  updateBackground();
});

socket.on('toggle-active', (color) => {
  active[color] = !active[color];
  if (controllingColor === color) {
    colorSlider.disabled = !active[color];
  }
  document.getElementById('active').innerText = active[controllingColor] ? 'active' : 'inactive';
  updateBackground();
});

Meanwhile, the server detects the new connection. It assigns the client a color, sends that color and current state of the application to the client, and sets up its own handlers for events received through the socket:

// index.js
colorNamespace.on('connection', (socket) => {
  const color = colors[colorCount % 3]; // pick the next color in the list, then loop
  colorCount++;

  socket.emit('assign-color', color, colorSettings, activeSettings); // synchronize the client with the application state
  socket.data.color = color; // you can save information to a socket’s data key, but I didn’t end up using this for anything

  socket.on('set-color', (color, value) => {
    colorSettings[color] = value;
    colorNamespace.emit('set-color', color, value);
  });

  socket.on('invert', () => {
    socket.broadcast.emit('invert');
  });
});

The /admin page follows similar setup.

Sending Information to the Client

Let’s follow how user interaction on one page changes all the others.

When a user on the blue page moves the slider, the slider emits a change event, which is caught by the slider’s event listener:

// color.html
colorSlider.addEventListener('change', (event) => {
  socket.emit('set-color', controllingColor, event.target.value);
});

That event listener emits a new set-color event with the color and new value. The server receives the client’s set-color, then emits its own to transmit that data to all clients. Each client receives the message and updates its blue value accordingly.

Broadcasting to Other Sockets

But clicking the “Invert others” button affects the other /color users, but not the user who actually clicked the button! The key here is the broadcast flag when the server receives and retransmits the invert message:

// server.js
socket.on('invert', () => {
  socket.broadcast.emit('invert'); // broadcast
});

This flag means that that the server will send the event to every socket except the one it’s called on. Here this is just a neat trick, but in practice, it might be useful to avoid sending a post to the user who originally wrote it, because their client already has that information.

Namespaces

You may have noticed that the admin tab isn’t changing color with the other three. For simplicity, I didn’t set up any handlers for the admin page. But even if I had, they wouldn’t do anything, because the admin socket isn’t receiving those events at all. This is because the admin tab is in a different namespace.

// color.html
const socket = io('/color');

// =======================

// admin.html
const socket = io('/admin');

// =======================

// index.js
const colorNamespace = io.of('/color');
const adminNamespace = io.of('/admin');

…

colorNamespace.emit('set-color', color, value); // the admin page doesn’t receive this event

(For clarity, I gave my two namespaces the same names as the two endpoints the pages are located at, but I didn’t have to. The namespaces could have had arbitrary names with no change in functionality, as long as the client matched the server.)

Namespaces provide a convenient way to target a subset of sockets. However, namespaces can communicate with each other:

// admin.html
const toggleFunction = (color) => {
  socket.emit('toggle-active', color);
};

// =======================

// index.js
// clicking the buttons on the admin page triggers changes on the color pages
adminNamespace.on('connection', (socket) => {
  socket.on('toggle-active', color => {
    activeSettings[color] = !activeSettings[color];
    colorNamespace.emit('toggle-active', color);
  });
});

// =======================

// color.html
socket.on('toggle-active', (color) => {
  active[color] = !active[color];
  if (controllingColor === color) {
    colorSlider.disabled = !active[color];
  }
  document.getElementById('active').innerText = active[controllingColor] ? 'active' : 'inactive';
  updateBackground();
});

In all of the examples, events were caused by some interaction on one of the clients. An event was emitted to the server, and a second message was emitted by the server to the appropriate clients. However, this is only a small sample of the possibilities. For example, a server could use websockets to update all clients on a regular cycle, or get information from some API and pass it on. This demo is only a small showcase of what I’ve been learning and hope to keep applying in my projects going forward.

References and Further Reading

Socket.IO, especially the tutorial, which got me up and running very quickly
Websockets on MDN – API reference and glossary, plus the articles on writing your own clients and servers (Deno version)

Cover Photo by Scott Rodgerson on Unsplash

Garbage Collection

eachampagne — Mon, 17 Nov 2025 14:45:10 +0000

It’s easy to forget, while working in the abstract in terms of functions and algorithms, that the memory our programs depend on is real. The values we use in our programs actually exist on the hardware at specific addresses. If we don’t keep track of where we’ve stored data, we run the risk of overwriting something important and getting the wrong information when we go to look it up again. On the other hand, if we’re too guarded about protecting our data, even after we’re finished with it, we waste memory that the program could better use on other tasks.

Most programming languages today implement garbage collection to automate periodically releasing memory we no longer need. The garbage collector cannot predict exactly which values will be used again by our program, but it can find some that cannot due to no longer having any way to use them, and safely free them.

Garbage Collection Algorithms

Reference Counting

The simplest algorithm is just to keep a count of references to a piece of memory. If the number of references ever reaches zero, that memory can no longer be reached and can be safely disposed of. However, this strategy fails with circular references. If two objects, for example, reference each other, their reference counts with never reach zero, even if they are otherwise inaccessible from the main program.

Tracing

Tracing (usually mark-and-sweep), is a more sophisticated approach to memory management. Starting from some defined root(s), the garbage collector visits every piece of memory accessible from either the root or its descendants, marking that memory as still reachable. Any memory not traversed is unreachable and is garbage collected. This avoids the problem of circular references “trapping” memory, since the cycle will not be reached from the main memory graph. However, this approach has more overhead than the reference counting strategy.

Many garbage collectors reduce the overhead of mark-and-search by having two (or more) “generations” of allocations. The generational hypothesis states that most allocations die young (think how many variables you use once in a for loop and never again), but those that survive are much more likely to survive a long time. Thus, the pool of young allocations (the “nursery”) is garbage collected frequently, while the old (“tenured”) pool is checked less often.

It’s possible to combine both strategies in a hybrid collector. For example, Python uses reference counting as its primary algorithm, then uses a mark-and-sweep pass over the (now smaller) pool of allocated memory to find and eliminate circular references.

The Downsides of Garbage Collection

Of course, the garbage collector itself introduces some overhead. Depending on the implementation, it may bring the program to a halt while it scans and frees data or defragments the remaining memory. It is also impossible to create a perfectly efficient garbage collector due to the inherent uncertainty in which values will be used again.

Other Approaches to Memory Management

There are alternatives to garbage collection. A few languages, such as C and C++, require the programmer to manage memory manually (although you can add garbage collectors to both languages yourself if you wish), both while allocating memory to new variables and when deciding when to free memory. Manual memory management avoids the overhead of garbage collection, but adds to program complexity, since this now must be handled by the code itself rather than happening in the background. This also gives the programmer many opportunities to make mistakes, from creating floating pointers by freeing too soon to leaking memory by freeing too late or not at all, to say nothing of the difficulty of using pointers themselves.

Rust takes a third option and introduces the concept of “ownership” – only one variable can own a piece of data at a time, and that data is released as soon as its owner goes out of scope. This eliminates the need for garbage collection at runtime, as well with its associated performance costs. However, the programmer has to keep track of ownership and borrowing of data, which limits how data can be read or changed at certain points of the program. This requires thinking in a different way from other languages, since some familiar patterns simply won’t compile, and increases Rust’s learning curve sharply.

Garbage Collection in JavaScript

JavaScript follows the majority of programming languages in using a garbage collector. However, the garbage collector itself is implemented and run by the JavaScript engine, not the script we write ourselves, so implementation varies slightly across engines. However, the general principles are the same. Modern JavaScript libraries all use a mark-and-sweep algorithm with the global object as the algorithm’s root. Since I regularly use Firefox and Node, I’ll look at their engines in a bit more detail.

SpiderMonkey, the engine used by Firefox, applies the principle of generational collection, dividing allocations into young and old. It attempts to garbage collect incrementally to avoid long pauses, and runs parts of garbage collection in parallel with itself or concurrently with the main thread when possible.

The V8 engine’s Orinoco garbage collector, has three generations: nursery, young, and old, and claims (as of 2019) to be a “mostly parallel and concurrent collector with incremental fallback.” V8 also brags about interweaving garbage collection into the idle time between drawing frames when possible, minimizing the time spent forcing JavaScript execution to pause.

Based only on these descriptions, V8’s garbage collector seems a bit more advanced, perhaps because V8 used by Chromium-based browsers in addition to Node.js and thus has more support. However, they seem to have independently converged to similar architectures. The serious demands to provide a smooth user experience means that browser-based garbage collectors must be efficient and eliminate as much overhead as possible, because, as the Node guide to tracing garbage collection neatly summarizes, “when GC is running, your code is not.”

I admit I’ve rather taken memory management for granted, since most of the languages I’ve studied have garbage collectors. I’ve been fascinated by Rust for years but haven’t managed to wrap my head around its ownership and borrowing rules. (Maybe this is the time it will finally click for me.) But if I struggle with memory management when the compiler itself is looking out for me, I’m not sure how I’d fare in a manual memory management scheme without guardrails. So for now, I’m very grateful to garbage collectors everywhere for making my life easier.

The Memory Management Reference was invaluable while researching this blog post, in addition to many other engine- and language-specific references (linked throughout the text).

Parallelization

eachampagne — Mon, 10 Nov 2025 14:37:31 +0000

If you’ve ever checked your computer’s resource usage while waiting for a script that just wouldn’t finish, you may have been dismayed to find that while one CPU core was chugging along at top speed, the others were sitting idle. If they just worked together, you may have thought, I’d be done by now.

Enter parallelization!

Parallelization is a programming paradigm in which a problem is split into small parts to be executed simultaneously – i.e., in parallel. This allows multiple processors, or even multiple computers, to contribute to solving the problem, cutting execution time dramatically (Adefemi). You’ve probably benefited from your browser performing tasks in the background to avoid slowing down a webpage or your CPU offloading graphics processing to the GPU to get hyper-realistic graphics at 60 FPS – both examples of parallel computing. However, applications of parallelization run the gamut from these personal uses to scientific research on supercomputers at my alma mater, or even on distributed networks of thousands or millions of volunteer computers worldwide, such as the network used by folding@home to simulate protein folding and understand its role in disease.

Unfortunately, parallelization has some drawbacks. First, the mechanisms to transfer data between threads or processors and to synchronize results introduce overhead costs in time, memory, and program complexity. Second, not all programs can be parallelized. Code that relies on earlier results must wait until those results are calculated. Thus, highly sequential programs cannot be parallelized, or can be parallelized so minimally that the costs outweigh the gains. The problems that benefit most from parallel programming have many parts that can be run independently in no particular order (Adefemi, Factors Impacting Parallelization).

With these constraints in mind, let’s see how to use parallelization in JavaScript. JavaScript is single-threaded, but it has some features, such as web workers, that allow us to split processes off into separate threads. If we delegate parts of our workload to several of those web workers, they can handle our calculations in parallel and give us the results when they finish.

Fortunately, we don’t have to create and manage those web workers ourselves. Instead, we can use parallel.js, a library which does exactly what we want. It creates web workers, sets up an environment for them, assigns jobs, and allows access to the processed data. We’ll use parallel.js to parallelize my solution to the n-queens problem to see how it works.

First, we have to decide how to split up the problem into chunks that can run in parallel. Since the first queen has to go somewhere in the first row, I can refactor my code into a function that takes a column position for the first queen and solves the rest of the board from there. I won’t show the whole algorithm, but the function signature is useful to see:

function countSolutionsFromStartingColumn (n, col) {
    ...
}

To solve the whole board, I simply iterate over every possible first column position. (Actually, I can do better that – I can exploit the symmetry of the problem to iterate over half of the board and multiply by two. Odd boards take a little more finesse to not double count the center column but proceed similarly.)

solveQueensInSeries = function (n) {
    const halfwayPoint = Math.floor(n / 2) - 1;

    let solutionCount = 0;

    //count the solutions for half the board
    for (let i = 0; i <= halfwayPoint; i++) {
        solutionCount += countSolutionsFromStartingColumn(n, i);
    }

    //multiply the first half of the board by 2 to count the other half of the board
    solutionCount *= 2;

    //if n is odd, count the solutions for the center file of the board (this doesn't get multiplied by 2)
    if (n % 2 === 1) {
        solutionCount += countSolutionsFromStartingColumn(n, halfwayPoint + 1);
    }

    return solutionCount;
}

In the parallel case, I can divide each of these starting columns among my workers. Parallel.js has a handy .map() function that, like the native .map(), applies a callback function to each item of an array. We create the array of starting columns, and our library takes care of assigning jobs to workers. (Note that the results get written into the input array in place.)

async function solveQueensInParallel(n, maxWorkers) {
    const halfwayPoint = Math.floor(n / 2) - 1;

    let startingColumns = [];

    for (let i = 0; i <= halfwayPoint; i++) {
        startingColumns.push(i);
    }

    if (n % 2 === 1) {
        startingColumns.push(halfwayPoint + 1);
    }

    let p = new Parallel(startingColumns, {
            env: {
                n: n
            },
            evalPath: '/eval.js',
            maxWorkers: maxWorkers
        }).require(countSolutionsFromStartingColumn, "src/BitwiseBoardCopy.js");

    function curriedSolver(col) {
        return countSolutionsFromStartingColumn(global.env.n, col);
    }

    await p.map(curriedSolver);

    let solutionCount = 0;

    for (let i = 0; i <= halfwayPoint; i++) {
        solutionCount += p.data[i];
    }

    solutionCount *= 2;

    if (n % 2 === 1) {
        solutionCount += p.data[halfwayPoint + 1];
    }

    console.log(solutionCount);
    return solutionCount;
}

I did have some problems setting up the environment for the workers. Web workers operate in their own global scope (either shared among several or specific to one), not the window object of the main script, so I had to pass in functions and external scripts using .require() and variables with the env object in the constructor options. I actually used a less efficient solution that had fewer dependencies and so didn’t require me to figure out how to give the workers access to other libraries.

So, after all of this restructuring, did the parallel solver do any better? I timed my solvers by simply subtracting the end time from the start time using Date.now(). I don’t think this is the most precise benchmarking method, but is good enough for a single, long-running function like these. My results were:

Run	Time in seconds	Approx. time in minutes
No parallelization	1164.807	19.4
2 cores	748.732	12.5
4 cores	588.162	9.8
8 cores	444.225	7.4

(These are each recorded from one run. It would be better to do several runs and take the average, but given that even the fastest took several minutes to complete, I opted not to.)

So the parallel version is faster, but it’s far from the “divide the runtime by the number of workers” rule that I expected. I thought perhaps the columns took different amounts of time to run, so the work wasn’t really being evenly distributed across the workers. Timing each starting column individually (without the parallel wrapper) gave me:

Column	Time in seconds
0	111.319
1	128.719
2	140.936
3	147.07
4	153.836
5	157.853
6	161.02
7	164.17
Sum	1164.923
Worst 2	325.19
Worst 4	636.879

So there is some variance in the runtimes, but not enough to explain the discrepancy. The 8 workers case is particularly surprising, since each worker should handle one column, so I’d expect the total runtime to be approximately the same as the slowest column. However the actual runtime is more than twice the length of column 7. I don’t understand what’s causing so much delay. Is that simply the expected overhead due to parallelization? Perhaps my CPU gets less efficient the more cores are in use, or perhaps the web worker setup is more expensive than I expected.

Despite some lingering questions, I have dramatically improved my runtime for this problem, and I’m confident I will find more use cases for parallel programming in the future. If you think you might too, I absolutely recommend the article What Every Computer Scientist Needs to Know About Parallelization by Temitayo Adefemi, which I referenced several times. The article goes into much greater detail, especially on implementation and as the types of problems that benefit from parallelization, and was a very thorough introduction to the topic.

Graphing in JavaScript

eachampagne — Mon, 03 Nov 2025 10:59:09 +0000

I feel incomplete without a graphing utility.

It probably has something to do with majoring in physics. Visualizing relationships in space – “thinking in graphs” – is a natural way for me to explore a problem or communicate an idea. In Python, things were easy. Matplotlib was more or less the standard graphing library, and was more than sufficient for my purposes. Now that I’m getting a handle on JavaScript, one of my first priorities is to find a native way to accomplish the same thing.

Let’s try recreating a matplotlib graph from an old class project. The premise was to calculate the electric field of a not-quite-spherically symmetric shell of charge, both analytically and computationally, and then compare the results. I’ve slightly edited the code for brevity and clarity, but you can see my original project here. (One day I’d like to go back and reimplement this – I can think of several things I could improve. At the time, however, I was very proud of my code for matching the analytical solution so well.)

Here’s the (edited) Python script:

import matplotlib.pyplot as plt
import numpy as np
import numpy.ma as M
import math

#Initiate plot
fig = plt.figure()

#Create a list of z values
z = np.linspace(0,5,501)

#Opens a text file containing the output of ElectricField.py, reformatted to have only the z-values
#I could have appended all the graphing stuff to the end of the other program, but that would require recalculating the field every
#time I wanted to regraph
f = open("sample.txt", 'r');
zOutput = []

#Collect calculated field values into a list
for i in f:
    zOutput.append(float(i))

f.close()

R = 1
PI = math.pi
degCos = math.cos(PI/180)

#Formula I derived, with adjustments so the "units" match
eField = -2*PI*((R+z)/(z*z*pow((z*z+R*R+2*z*R),0.5))-(R-z*degCos)/(z*z*pow((z*z+R*R-2*z*R*degCos),0.5)))

#Actually graph stuff
plt.plot(z,eField,'r',label="Analytical Field")
plt.scatter(z,zOutput,10,label="Computational Field")

#Labels and such
plt.title('Electric Field of a Charged Shell with a Hole')
plt.legend()
plt.xlabel('Positions along Z-axis (R)')
plt.ylabel('Z-Component of the Electric Field (Q/(A4πε(0)))')

#Actually display stuff
plt.show()

And it produces this graph:

It’s pretty simple – a scatter plot and a line graph, axes, and legends. Nothing too fancy. How can we replicate this in JavaScript?

It turns out we have many options for graphing libraries. Let’s take a look at D3. It advertises itself as “the JavaScript library for bespoke data visualization,” and is also the base of several other graphing libraries, including Observable Plot (developed by the same team as D3), Vega, and Plotly (we’ll come back to that one). The fact that so many people built other projects on top of D3 should give us an idea of what we’re in for – it’s clearly very useful, but probably not so easy to use.

Some notes before we get started:

For the purposes of this blog post we'll skip module and script setup and skip straight to the graphing code. However, if you'd like to try following along in a Jupyter notebook, I found this sample notebook (designed for Observable Plot) helpful for getting my charts to work.
Likewise, reading from a file is beyond the scope of the article, so we'll assume we already have an array called data that has all the computational field data.
Finally, D3 creates SVGs, but I’ve snipped and embedded them as bitmaps to make things easier.

Ready for a challenge? Let's start with the sample on the D3 Getting Started page. (I won't paste the whole thing now, but I'll show you what I change step by step and paste the finished product at the end).

For now, we'll use the sample to make sure we have our environment working, and use it as a scaffolding for the rest of our project. Running it as-is gives us:

We've proven we can draw something, at least. We've also learned that D3 works by creating each element of the graph – in this case, the x- and y-axis – and then appending all of those elements to an svg, which we then display. Let's start by changing out x-axis to be linear, rather than dates, and adjusting our y-axis domain to fit out data. We can also move the x-axis to the top:

// Declare the x (horizontal position) scale.
const x = d3.scaleLinear()
    .domain([0, 5])
    .range([marginLeft, width - marginRight]);

// Declare the y (vertical position) scale.
const y = d3.scaleLinear()
    .domain([-12, 0])
    .range([height - marginBottom, marginTop]);

// Add the x-axis.
svg.append("g")
    .attr("transform", `translate(0,${marginTop})`)
    .call(d3.axisTop(x));

The axes look pretty good so far. Now we need some way to create a line graph and a scatter plot, plus add titles for the axes and the whole chart. Let's move over to the Line Chart tutorial linked to from the D3 website.

It looks like we can add labels to our axes by appending text and setting the attributes appropriately. A little guessing and checking on positioning, plus a quick search on rotating text in an SVG, gives us:

// Add the x-axis.
svg.append("g")
    .attr("transform", `translate(20,${marginTop+40})`)
    .call(d3.axisTop(x))
    .call(g => g.append("text")
         .attr("x", width / 2)
         .attr("y", -30)
         .attr("fill", "black")
         .text("Positions along Z-axis (R)"));

// Add the y-axis.
svg.append("g")
    .attr("transform", `translate(${20+marginLeft},40)`)
    .call(d3.axisLeft(y))
    .call(g => g.append("text")
         .attr("fill", "black")
         .attr("transform", "rotate(-90)")
         .attr("x", -90)
         .attr("y", -30)
         .text("Z-component of the Electric Field"));

That gives us our axis labels. We can add a title to the chart the same by appending text directly to the svg instead of to one of the axes:

svg.append("text")
    .attr("fill", "black")
    .attr("x", width / 2 - 125)
    .attr("y", 15)
    .text("Electric Field of a Charged Shell with a Hole");

That looks reasonable. I don't like that I had to center the title by eye – there must be a better way. But for now let's move on to actually graphing our data. First we need to clean up our data. We ultimately want arrays of objects that we can deconstruct to get x and y values. (Note that due to a division by zero problem for z = 0, we're slicing off the first entry in the analytic field.)

const R = 1, degCos = Math.cos(Math.PI / 180);

let eOfZ = function(z) {
    return -2 * Math.PI * ((R + z)/(z*z*Math.pow((z*z + R*R + 2*z*R), 0.5))-(R-z*degCos)/(z*z*Math.pow((z*z+R*R-2*z*R*degCos), 0.5)))
}

let eFieldComputational = [];
let eFieldAnalytic = [];

for (let i = 0; i <= 500; i++) {
    let z_i = i/100;
    eFieldComputational.push({
        z: z_i,
        E: data[i]
    });
    eFieldAnalytic.push({
        z: z_i,
        E: eOfZ(i/100)
    });
}

eFieldAnalytic = eFieldAnalytic.slice(1);

Now let's try the line generator and line path (still from the line chart example):

// Declare the line generator.
const line = d3.line()
    .x(d => x(d.z))
    .y(d => y(d.E));

// Append a path for the line
svg.append("path")
    .attr("fill", "none")
    .attr("stroke", "red")
    .attr("stroke-width", 1.5)
    .attr("transform", "translate(20,40)")
    .attr("d", line(eFieldAnalytic));

I had to manually adjust the position of the curve to match where I had moved the axes. The SVG doesn't know or care that it's supposed to be a graph with real mathematical meaning, and will let you put any element wherever. This could easily lead to highly misleading graphs, either through error or malice, so be attentive!

Now we just need to plot the computational field as a scatter plot (preferably underneath the curve). We have another example to refer to, which leads us to:

// Add a layer of dots
svg.append("g")
        .attr("stroke", "blue")
        .attr("stroke-width", 1.5)
        .attr("fill", "none")
        .attr("transform", "translate(20,40)")
    .selectAll("circle")
    .data(eFieldComputational)
    .join("circle")
        .attr("cx", d => x(d.z))
        .attr("cy", d => y(d.E))
        .attr("r", 1.5);

So that is a complete graph. It could certainly use some polishing. Somewhere along the line I cut off the ends of the axes, probably while shifting the positions to make room for the axis labels. The original graph had a legend, but I'm not brave enough to face more text nodes. And I don't feel like this is really "my" code - it's a Frankensteined mix of example codes until I got something that fit my purposes.

To recap, our final, complete graphing script is:

// Declare the chart dimensions and margins.
const width = 640;
const height = 400;
const marginTop = 20;
const marginRight = 20;
const marginBottom = 30;
const marginLeft = 40;

// Declare the x (horizontal position) scale.
const x = d3.scaleLinear()
    .domain([0, 5])
    .range([marginLeft, width - marginRight]);

// Declare the y (vertical position) scale.
const y = d3.scaleLinear()
    .domain([-12, 0])
    .range([height - marginBottom, marginTop]);

// Create the SVG container.
const svg = d3.create("svg")
    .attr("width", width)
    .attr("height", height);

// Declare the line generator.
const line = d3.line()
    .x(d => x(d.z))
    .y(d => y(d.E));

// Add the x-axis.
svg.append("g")
    .attr("transform", `translate(20,${marginTop+40})`)
    .call(d3.axisTop(x))
    .call(g => g.append("text")
         .attr("x", width / 2)
         .attr("y", -30)
         .attr("fill", "black")
         .text("Positions along Z-axis (R)"));

// Add the y-axis.
svg.append("g")
    .attr("transform", `translate(${20+marginLeft},40)`)
    .call(d3.axisLeft(y))
    .call(g => g.append("text")
         .attr("fill", "black")
         .attr("transform", "rotate(-90)")
         .attr("x", -90)
         .attr("y", -30)
         .text("Z-component of the Electric Field"));

svg.append("text")
    .attr("fill", "black")
    .attr("x", width / 2 - 125)
    .attr("y", 15)
    .text("Electric Field of a Charged Shell with a Hole");

// Add a layer of dots
svg.append("g")
        .attr("stroke", "blue")
        .attr("stroke-width", 1.5)
        .attr("fill", "none")
        .attr("transform", "translate(20,40)")
    .selectAll("circle")
    .data(eFieldComputational)
    .join("circle")
        .attr("cx", d => x(d.z))
        .attr("cy", d => y(d.E))
        .attr("r", 1.5);

// Append a path for the line
svg.append("path")
    .attr("fill", "none")
    .attr("stroke", "red")
    .attr("stroke-width", 1.5)
    .attr("transform", "translate(20,40)")
    .attr("d", line(eFieldAnalytic));

// Append the SVG element.
container.append(svg.node());

I could use this - I could save it, and use it as a starting point every time I need a new graph. That's actually pretty similar to the way I use Matplotlib - most of my graphs are descendants of the code I provided, which is itself a descendant of the Matplotlib documentation and whichever tutorials I happened to find in 2019. But tweaking a couple of parameters in my Matplotlib code - and knowing that, all else aside, at least my data points will align with the axis - is a lot less of a hassle than appending elements to an SVG one by one.

Let's try Plotly. No particular reason – it was one of the first things I found when I searched for "JavaScript graphing library" so I've been curious about it since. Plotly is "[b]uilt on top of d3.js and stack.gl," so hopefully it'll take care of a lot of things that made the last chart such a pain. Conveniently, they have one tutorial that covers both line and scatter plots. We do need to restructure our data into arrays of x and y values rather than objects, but that's not so bad.

let z_values = eFieldComputational.map(data => data.z);
let computational = eFieldComputational.map(data => data.E);
let analytic = eFieldComputational.map(data => data.E);

let computationalTrace = {
    x: z_values,
    y: computational,
    mode: 'markers',
    type: 'scatter'
};

let analyticTrace = {
    x: z_values.slice(1), //the analytic solution had a problem at z = 0
    y: analytic,
    mode: 'lines',
    type: 'scatter'
}

let plotlyData = [computationalTrace, analyticTrace];

Plotly.newPlot('plotlyContainer', plotlyData);

Well.

It's not perfect – I haven't put labels, for one thing – but I think the brevity of the code speaks for itself.

There's a lot to be said for learning D3. It's certainly very powerful, and I'm sure understanding it would make learning any graphing library built on top of it trivial by comparison. And I admit some of the example graphs (like this gorgeous star map) have enchanted me. But for capping off a project that I've already spend countless hours on, and just want to present my results and be done? Let's just say I'm happy D3 isn't my only choice.

Memoization

eachampagne — Fri, 05 Sep 2025 16:08:20 +0000

This post was designed as a Jupyter Notebook. You can access the notebook here. I used the Deno kernel for JavaScript.

For the small problems of an introductory coding course, we generally don't worry too much about the efficiency of our code because it executes almost instantaneously (barring mistakes like infinite while loops). However, this isn't guaranteed, and as the size and complexity of our problems increases, we need increasingly clever solutions to keep our runtimes down. One technique that can cut down on repeated computation is memoization - saving previous results to look up later.

Let's take the Fibonacci sequence as an example. (I had originally planned to use the Collatz conjecture as my example but it didn't slow down enough to illustrate my point. It turns out the Fibonacci sequence seems to be a popular example for this use case - it was actually the example given by the Underscore.js documentation. ) The Fibonacci sequence is familiar as the sequence we get when, starting with 0 and 1, we repeatedly add the last two terms together. However, the precise mathematical definition is actually recursive:

\text{ for } n=0

\text{ for } n=1

\text{ otherwise}

Let's implement that in Javascript:

function fibonacci(n) {
    if (n === 0) {
        return 0;
    } else if (n === 1) {
        return 1;
    } else {
        return fibonacci(n-1) + fibonacci(n-2);
    }
}

Looks good! However, if we start calling our function for bigger and bigger numbers, we'll find that the function takes a noticeably long time to return. On my machine I start getting worried around F(40) - F(45).

console.log(fibonacci(45));

What's going on here?

Because the Fibonacci sequence is defined recursively, every time we call it, it calls itself twice. But each of those calls invoke the function twice again, and so on...

F (n) = F (n - 1) + F (n - 2)

= (F (n - 2) + F (n - 3)) + (F (n - 3) + F (n - 4))

= ((F (n - 3) + F (n - 4)) + (F (n - 4) + F (n - 5))) + ((F (n - 4) + F (n - 5)) + (F (n - 5) + F (n - 6))

= ...

So the number of calculations needed to compute the $n^{th}$ term of the Fibonacci sequence is about $2^n$ , which quickly gets out of hand, even for relatively small values of n. No longer can we assume our code will execute immediately.

Of course, in this case we could sidestep the issue entirely by refactoring the Fibonacci function to use a for loop instead of recursion, but not every recursive function can be rewritten, and some expensive functions aren't recursive at all. Instead, notice that our function is calling itself on the same inputs multiple times, sometimes even several times in a row. Every call to F(n) will always give the same output, so once we know that output we don't need to recompute it. Let's see if we can store the outputs somehow so we reuse them later.

let inputs = [];
let outputs = [];

function fibExternalMemo(n) {
    if (inputs.includes(n)) {
        let index = inputs.indexOf(n);
        return outputs[index];
    }

    if (n === 0) return 0;
    if (n === 1) return 1;

    let result = fibExternalMemo(n - 1) + fibExternalMemo(n - 2);
    inputs.push(n);
    outputs.push(result)
    return result;
}

console.log(fibExternalMemo(45));

Our code runs much faster now!

Every time we call our function, it checks to see if it's already seen the current input before. If so, it simply looks up the answer and returns. Only for new inputs where it doesn't already know the answer does it calculate from scratch, and the recursive calls also use the memo functionality. This is the basic premise of memoization - don't recalculate things we don't have to.

This works because the Fibonacci sequence is deterministic - the same input will always give the same output, so looking up prior inputs is a reliable way to determine the output. If our function depended on other factors, such as global variables or object states, we couldn't know for certain that the same input would always yield the same output.

Unfortunately, our reliance on external arrays breaks our function's independence, plus is a bit unwieldy. In our Underbar assignment, we created a wrapper function that uses closures to contain our inputs and outputs while keeping them out of way. We simply pass our function into the higher-order memoize function and get back a new function that we can use like the old one, but that handles all the input checking for us.

//assuming for simplicity that the input function takes only one input of a simple data type
//This avoids having to deeply compare the inputs in our example
function memoize(f) {
    let inputs = [];
    let outputs = [];

    function memoized(input) {
        for (let i = 0; i < inputs.length; i++) {
            if (inputs[i] === input) {
                return outputs[i];
            } 
        }

        let newResult = f(input);
        inputs.push(input);
        outputs.push(newResult);
        return newResult;
    }

    return memoized;
}

However if we try to feed our original fibonacci() function directly into memoize(), we'll find out that while it will almost instantly return any number in has seen before (as expected), it won't calculate new values any faster.

let wrappedFib = memoize(fibonacci);

console.log(wrappedFib(45)); //takes forever
console.log(wrappedFib(45)); //executes immediately now that 45 has been seen

This is because once it realizes it hasn't seen our input before, it calls the inner function, which recursively calls itself, never checking for seen values again. The inner function doesn't get the benefit of memoization and ends up doing everything the hard way.

We can do better than that!

I was actually quite stumped by this. Of course I could hand-craft a memoized Fibonacci function like so...

function makeMemoFib() {
    let inputs = [];
    let outputs = [];

    let fibonacci = function(n) {
        if (inputs.includes(n)) {
            let index = inputs.indexOf(n);
            return outputs[index];
        }

        if (n === 0) return 0;
        if (n === 1) return 1;

        let result = fibonacci(n - 1) + fibonacci(n - 2);
        inputs.push(n);
        outputs.push(result)
        return result;
    }

    return fibonacci;
}

let manuallyMemoized = makeMemoFib();

console.log(manuallyMemoized(45));

This accomplishes the goal of isolating the lookup arrays, but this function works exclusively for this case. If I wanted to memoize different recursive function, I'd have to write it from scratch.

Figuring I wasn't person to have this problem, I consulted the Underscore.js documentation to see if they had any tips. As it happened, the very example they provided for the _.memoize() function was the Fibonacci sequence (I mentioned it's popular), and the example code snippet gave me the (obvious in retrospect) answer:

Memoized recursive functions must be defined recursively.

let memoizedFib = memoize(n => {
    if (n === 0) {
        return 0;
    } else if (n === 1) {
        return 1;
    } else {
        return memoizedFib(n-1) + memoizedFib(n-2);
    }
});

console.log(memoizedFib(45));
console.log(memoizedFib(100));
console.log(memoizedFib(1000));

And there we have it! It takes a bit of dexterity with JavaScript's function syntax, but is much more flexible than having to write a function maker for every tricky function we want to memoize.

Of course memoization isn't a panacea. What it saves in time it costs in memory, since it has to store every input/output pair somewhere. Plus it's only useful if at least some inputs really will be duplicated - there's no point in storing every output if every input only gets used once. And as I discussed before, memoization doesn't help at all for functions that depend on exterior states.

However, for the cases where it does work, memoization really shines! Last Advent of Code I used memoization (of the global variable variety) for two problems (that I remember), and I expect knowing how to use higher-order memoizers will come in handy this year. And of course it's always a good idea to have more optimization techniques in our toolbox.