DEV Community: Sk

I Tried Vibe Coding an Audio Streaming System in C++: Here Are the Results

Sk — Thu, 15 Jan 2026 12:40:04 +0000

“Vibe coding” is causing a pretty serious rift in the developer community, so I figured I’d do the responsible thing and actually try it, hands off, vibes only, and see if I could form a real opinion instead of just reacting.

For context: I’ve been programming since 2018. I’m comfortable in C/C++ and JavaScript, and I’ve built real systems, not just demos. One example is tessera - How I Built a Renderer for Node.js, which is the renderer this audio streaming system is meant to plug into.

I’ll say this upfront: I’m anti-vibe coding.

Not anti-LLM.
Anti vibe coding.

It’s one of the most misleading and outright harmful terms we’ve managed to invent. The marketing around it is especially egregious: turn off your brain, let the vibes take over. That’s a cute idea, for anything serious, it’s nonsense.

I use LLMs constantly. ChatGPT, Claude, DeepSeek. Boilerplate, ideation, sanity checks. But the hype framing this as “you no longer need to understand anything” is bad. Especially for beginners, who are about to discover the hard way that coding was never the hard part to begin with.

Everyone has ideas. If ideas plus vibes were enough, we’d be drowning in revolutionary new software by now. We’re not. But skepticism aside, I decided to let go and follow the vibes.

Letting the Vibes Drive
The Real Cost: Reading Code
Where I Actually Landed
Final Thought

Letting the Vibes Drive

To be clear, I didn’t go in totally blind. I nudged the LLM in the right direction because I understand audio streaming, ring buffers, and how this needs to integrate into a renderer. Even so, the result was… exactly what I expected.

It works.
No crashes.
No obvious errors.

But if you look closely, it doesn’t really work.

What I got was the probabilistic average of how someone might implement audio streaming. No novelty. No awareness that this stream lives inside a renderer. Just the most statistically likely solution.

And honestly, being average isn’t even the worst part.

The worst part is this:

2.1 thousand lines of something.

I wish I was exaggerating.

This has nothing to do with AMP, by the way, it’s a great tool. Their free-to-paid transition is actually impressive. These are just frontends to LLMs doing what LLMs do.

For reference: audio streaming with something like raylib (which is the case here) is sub-100 lines of clean C++ if you know what you’re doing.

So what are those 2k+ lines?

Look closely at the end. The TODOs.

At first glance, you might not see the problem. Here’s the problem:

I now have an average solution that I must read and debug
My repo is polluted with thousands of lines of autogenerated markdown “documentation”
I waited a long time for this to generate, time in which I could’ve just written the thing

The Real Cost: Reading Code

If you’ve ever inherited a codebase, you already know this pain.
If you haven’t, here’s an exercise: fork any project you rely on and try reading it.

Reading code you didn’t write is hard.
It’s not connected to your mental model.
It doesn’t live in your head.

Now try reading code that mostly works, but not quite.

There’s an old saying in low-level circles: “I like segfaults because they tell me exactly what’s wrong.” And it’s true. There’s nothing more terrifying than code that looks reasonable, runs, and silently does the wrong thing.

That’s what vibe coding gave me.

In the end, I spent more time dealing with this than I would’ve spent just writing it myself, using my brain, plus LLMs where they actually help.

Now imagine someone with no programming background.
How many times do they re-prompt?
What do they even say is “wrong”?

Where I Actually Landed

As I write this, I’m honestly demotivated. I have zero desire to look at those changes.

So I’m going to use an LLM the way I actually recommend using one: as a tool.

“Claude, comb through this and give me a concise outline of how it works, plus links.”

That’s it.

Final Thought

Anti–vibe coders aren’t anti-LLM. We’re anti brainless, the marketing fantasy, and the very real damage it does to beginners. That’s all we’ve been saying from the start.

But hey. It’s your life.
Use it however you see fit.

Building a Smooth 60fps Video Player in Node.js.

Sk — Thu, 15 Jan 2026 12:00:00 +0000

I had to bring back Big Buck Bunny for this one.

If you were around during the 2018 Blender / creative-coding boom, you already know this video.

What you’re seeing below is Big Buck Bunny playing entirely inside Node.js.

Still holding 60 FPS, frame after frame.

You can clone the repo and try it yourself:

git clone https://github.com/sklyt/nodejs-videoplayer.git
cd nodejs-videoplayer && npm i
node video_player/main.js "path/to/any/video/file"

But… how is this even possible?
The Renderer
The Decoder
The Hard Part: Synchronization
The Core Problem: Time Drift
- Approach 1 (naïve)
- Approach 2 (correct)
The Fix: Absolute Time
Final Result

But… how is this even possible?

Simple idea, really.

A video is just a sequence of images.

An image is just a grid of pixels.

A pixel looks like this:

const pixel = { r, g, b, a }

Or more accurately, as linear memory:

Uint8Array([r, g, b, a])

A collection of these pixels forms an image, a frame.

So if we can decode a video into raw frame pixels, all we need is a renderer that knows how to draw them fast.

We already have both.

The Renderer

I built tessera.js, a zero-copy, raw-buffer renderer for Node.js.

0 ms buffer swap
~0.02 ms draw time
Takes pixels. That’s it.

How I Built a Renderer For Node.js
https://github.com/sklyt/tessera.js/tree/main

Here’s a simple example writing directly into a pixel buffer:

function generateSimplexNoise(data, width, height, options = {}) {
  const scale = options.scale || 0.01;

  for (let y = 0; y < height; y++) {
    for (let x = 0; x < width; x++) {
      const idx = (y * width + x) * 4;
      const value = Math.sin(x * scale) * Math.cos(y * scale);
      const normalized = (value + 1) * 0.5 * 255;

      data[idx]     = normalized;
      data[idx + 1] = normalized;
      data[idx + 2] = normalized;
      data[idx + 3] = 255;
    }
  }
}

generateSimplexNoise(cache.data, canvas.width, canvas.height);

If you can write pixels, tessera can render them.

The Decoder

ffmpeg, the greatest video tool ever created.

ffmpeg can decode a video straight into raw RGBA frames, piped directly to stdout:

// decoder.js
const ff = spawn("ffmpeg", [
  "-i", videoFile,
  "-vf", `scale=${width}:${height}`,
  "-r", String(fps),
  "-f", "rawvideo",
  "-pix_fmt", "rgba",
  "-threads", "1",
  "pipe:1"
], { stdio: ["ignore", "pipe", "pipe"] });

Node spawns ffmpeg, ffmpeg streams raw frames, and Node feeds them into tessera.

The “magic” lives in main.js, inside the loop:

if (available > 0) {
  const slotOffset = framesBase + readIdx * frameSize;
  const src = new Uint8Array(shared, slotOffset, frameSize);

  if (canvas.data.set) canvas.data.set(src);
  else Buffer.from(shared).copy(canvas.data, 0, slotOffset, slotOffset + frameSize);

  canvas.markRegion(0, 0, canvas.width, canvas.height);

  readIdx = (readIdx + 1) % FRAME_COUNT;
  Atomics.store(meta, 1, readIdx);
  lastFrameRead++;

  canvas.upload(); // mark for swap
}

This single line:

canvas.data.set(src);

copies whatever frame is most recent from ffmpeg straight into the renderer.

The Hard Part: Synchronization

Rendering wasn’t the hard part.

Timing was.

ffmpeg runs as fast as it possibly can.

On a good machine, it can decode hundreds of frames per second.

But we only want 60 FPS.

That creates a few problems:

Buffers fill up
Frames get dropped
Playback jumps ahead
Renderer starts chasing ffmpeg

The naïve solution is something like:

setTimeout(loop, 1000 / 60);

I tried that.

Bad idea.

The Core Problem: Time Drift

Imagine clapping once per second.

Approach 1 (naïve)

Wait 1 second, clap
Wait 1 second, clap
Wait 1 second, clap

Approach 2 (correct)

Note the start time
Clap at start + 1s
Clap at start + 2s
Clap at start + 3s

Why does approach 1 fail?

Because setTimeout isn’t precise.

If “1 second” is actually 1.01s, after 100 claps you’re a full second late.

Your code starts dropping frames to “catch up”, but it’s still chasing a drifting clock, so it never truly syncs.

That’s exactly what was happening here.

The Fix: Absolute Time

Instead of waiting between frames, I anchor everything to a single absolute start time.

This runs in the worker:

const startTime = Date.now(); // absolute reference point

function tick() {
  const targetTime = startTime + (frameNumber * targetMs);
  const now = Date.now();
  const drift = now - targetTime;

  // If we're more than 2 frames behind, skip ahead
  if (drift > targetMs * 2) {
    const framesToSkip = Math.floor(drift / targetMs) - 1;
    const actualSkip = Math.min(framesToSkip, pendingFrames.length);

    if (actualSkip > 0) {
      pendingFrames.splice(0, actualSkip);
      frameNumber += actualSkip;
      Atomics.add(meta, 3, actualSkip);
    }
  }

  const frame = pendingFrames.shift();
  if (frame) {
    const writeIdx = Atomics.load(meta, 0);
    const nextWrite = (writeIdx + 1) % frameCount;
    const readIdx = Atomics.load(meta, 1);

    // Overwrite oldest frame if buffer is full
    if (nextWrite === readIdx) {
      Atomics.store(meta, 1, (readIdx + 1) % frameCount);
      Atomics.add(meta, 3, 1);
    }

    const slotOffset = framesBase + writeIdx * frameSize;
    new Uint8Array(shared, slotOffset, frameSize).set(frame);

    Atomics.store(meta, 0, nextWrite);
    Atomics.add(meta, 2, 1);
    frameNumber++;
  }

  // Resume ffmpeg if we’ve drained enough frames
  if (pendingFrames.length < 5 && ffmpegPaused) {
    ff.stdout.resume();
    ffmpegPaused = false;
  }

  const nextFrameTime = startTime + (frameNumber * targetMs);
  const delay = Math.max(0, nextFrameTime - Date.now());
  setTimeout(tick, delay);
}

tick();

Every frame knows exactly when it should exist relative to the start of playback.

No drifting.

No chasing.

Final Result

ffmpeg decodes as fast as it wants
Node buffers intelligently
Renderer consumes frames at a fixed cadence
Time never drifts

Once everything is anchored to absolute time…

…it just works.

I'm Building a Game Engine in Node.js (Yes, Really)

Sk — Thu, 08 Jan 2026 13:10:43 +0000

As crazy as the title sounds… it’s happening.
And it’s looking really good.

The results are already interesting:

Godot like scene tree

Dual screen + culling

Physics

Character controller with a procedurally generated map

Once you read the Node.js source code, or any runtime, really,you realize how novel and powerful this stuff is. And at that point, you can’t stop yourself. You have to build.

So that’s how Nexus came to be. Also based on another project a C++ N-API renderer for Node.js. More on that here:
How I built a Renderer for Node.js

But every project has its problems. I’d say it’s about 70% boilerplate and 30% real programming, and that 30% is the novel, painful, decision-heavy part.

A big chunk of that 30% was physics and camera.
Spoiler: very difficult.

To be fair, I’ve built a physics engine from scratch in C before. But JavaScript is a different story. It’s less expressive, garbage-collected, single-threaded, an entirely new frontier of problems.

Still… it’s looking good.
Also I have a plan to aggressively optimize see I Tried to Beat WebAssembly With Node.js.

Camera

The problem: your screen is static.
It doesn’t move. It doesn’t resize.

So what happens when the player is at screen size + 1 pixel?

The world is infinite.
The screen is finite.

I can’t move the real screen, but what if I create a pseudo screen?
A simulated one. Not real. One that can move freely.

World (large area)
+-------------------------------------------------------------+
|                                                             |
|   . . . . . . . . . . . . . . . . . . . . . . . . . . .     |
|   |----------------------- Screen ---------------------|    |
|   |                                                   |    |
|   |                                                   |    |
|   |                                                   |    |
|   |                                                   |    |
|   |                                                   |    |
|   |---------------- (real screen) -------------------|    |
|                ^                                            |
|                |                                            |
|          (player P)                                         |
|               P                                             |
|                                                            C|
|         [Camera viewport]  ------------------               |
|         .----------------------------------.                |
|         |                                |                 |
|         |            CAMERA (C)           |                 |
|         |                                |                 |
|         '----------------------------------'                |
|                                                             |
+-------------------------------------------------------------+
Legend:
- Big box = World
- Inner rectangle labeled "Screen" = the real screen (inside the world)
- "P" = Player point placed outside the real screen
- Dashed/smaller rectangle near P labeled Camera = the pseudo screen / camera viewport that can move freely

Whatever this pseudo screen sees gets translated onto the real screen.

That’s your frustum → viewport → screen translation.

Sounds simple, until you realize you now have two coordinate systems for every object and component:

Top-left ← renderer
Free-flowing, center-based ← camera

The real pain is translating to and from these systems.

And that’s not even the end of it.

Once the camera exists, it has to be useful:
a controller that actually follows the player smoothly,
culls pixels outside the frustum/viewport,
translates every pixel into screen space (and back, if needed).

On top of translation madness, now you add follow behavior, shake, culling, multiple cameras…

Still, it’s looking decent, as you saw from Character controller with a procedurally generated map,

Physics Engine

Like I said, I’ve built a physics engine in C before.

It’s hard, not just because it’s real-time, but because it’s simulated real-time. Things move fast. Things collide fast. You can’t console.log your way out of that.

So this time I went with Matter.js. Pure JS. Solid library. It works.

Until I realized it doesn’t support kinematic bodies, the centerpiece of almost every 2D game: your sensors, your AI, moving platforms, and a lot more.

An engine usually has three body types:

Static - immovable; used for terrain/scenery, not affected by forces
Dynamic - fully simulated; affected by forces and collisions
Kinematic - moves by script/control; collides but isn’t driven by physics forces

Kinematic bodies are the core of gameplay.

But I’m a developer, so I thought:
“Easy. A kinematic body is just a static body that moves.”

Huge mistake.

Static bodies don’t collide with other static bodies (for example, a bullet won’t collide with a kinematic enemy or moving platform in this case), because the engine assumes static means never moves. Now I’m trying to bend Matter.js and manually handle collisions myself.

It did not go well.

I’m simulating outside the simulator, feeding tainted results back in, hoping the physics engine plays nice.

It’s possible.
It’s also incredibly annoying.

So instead of burning four more days on this, I did the sane thing and switched engines, to planck.js, which actually supports everything I need.

Of course… it wouldn’t be programming without more problems.

Planck’s coordinate system is bottom-left.

So now I’m translating between three systems:

Top-left ← renderer
Middle-center ← camera
Bottom-left ← planck.js

And as if that wasn’t enough, Planck speaks meters, while the renderer and camera speak pixels.

That’s yet another translation layer.

Yep.
So that’s what I’m dealing with right now: migrating to a new physics engine, building a whole new translation layer.

And somehow… still having fun.

I Tried to Beat WebAssembly With Node.js

Sk — Thu, 08 Jan 2026 12:10:33 +0000

Wasm is fast, there’s no question.
But can I, with conscious optimizations, beat it with Node.js?

The results surprised even me.

I’ve been building a profiler for Node.js as we speak, sitting at sub 100 nanoseconds latency. For perspective: native C++ Tracy profiling lives around 5-40 nanoseconds. Hitting ~100ns from Node is honestly insane.

And that process taught me one thing very clearly:

Aggressive optimizations, and real command of Node.js, change everything.

So I kept having this idea floating around:

Who can simulate 125,000 particles faster? between wasm and node.js

Starting with basic, unoptimized JavaScript. No tricks yet.

But first, we need to agree on something.

Wasm Is Insanely Fast

There’s no debate here.

Wasm is fast because it:

exposes raw linear memory
is fully typed

And anytime you hear typed, most of the time you should think fast, for one simple reason:

It’s easier to optimize for the devil you know.

Imagine living somewhere where the weather changes every hour. Worse: it can go from extremely hot to freezing cold, or hot to extremely hot, completely unpredictably.

How do you optimally dress for that?

That’s dynamic code to a compiler.
That’s JavaScript.

In JavaScript, a variable can go from a string, to a number, to an object, in the same context, in milliseconds:

// rapid type churn - triggers polymorphism / deopts
let x = 0;
for (let i = 0; i < 1e6; i++) {
  x = i;               // number
  x = String(x);      // string
  x = { i: x };       // object
  x = x.i.length ? 0 : i; // back to number (maybe)
}

How does a compiler optimize for that?

So yes, the basis for Wasm being fast is not in question.

The real question is this:

Can a few conscious optimization tricks in Node.js beat Wasm?

To test that, there’s nothing better than a brutal workload:
a field of 125,000 particles.

Setup

You can clone the repo and run everything yourself:

git clone https://github.com/sklyt/wasmvsnode.git

For visualization, I’m using my own C++ N-API renderer, tessera.js.
You can learn more about it here:
How I built a renderer for Node.js

125k JS Objects vs Wasm

This setup is already insane.

JS objects are:

scattered all over memory
cache-unfriendly
expensive to access and update
made worse by prototype chains

Objects in JS are the epitome of unpredictable weather.

So how do they fare against Wasm?

Results

wasm avg (60fps):     0.512ms
js objects avg:       1.684ms

A few notes:

These results are slightly affected by the recording setup (Windows being Windows), but the conclusion is clear: Wasm is ~3× faster.

Also note this line in obj.js:

const wasmStart = performance.now();

wasmUpdate(0, PARTICLE_COUNT, WIDTH, HEIGHT, Math.floor(dt * 1000));

wasmTime = performance.now() - wasmStart;

wasmUpdate crosses the JS → Wasm boundary. That includes call overhead, yet Wasm is still blazing fast.

This result is expected.

But now comes one of the most beautiful optimization concepts I’ve ever learned.

Data-Oriented Design

Instead of representing entities like this (line 43 in obj.js):

const jsParticles = [];

for (let i = 0; i < PARTICLE_COUNT; i++) {
  jsParticles.push({
    x: Math.random() * WIDTH,
    y: Math.random() * HEIGHT,
    vx: (Math.random() - 0.5) * 200,
    vy: Math.random() * -100
  });
}

What if we flatten the data?

Use the most cache-friendly structure possible, a linear array:

particle 1      particle 2      ...
[x, y, vx, vy,  x, y, vx, vy]

Now memory access is linear.
No pointer chasing.
No jumping around memory.

This idea is everywhere in game engines:

sparse sets
ECS
struct-of-arrays

This is how engines do ridiculous amounts of work in sub-0.16ms.

So I flattened the data, and went further.

I used typed arrays.

const jsParticles = new Float32Array(PARTICLE_COUNT * 4);

Types. Predictability.
The weather just got calmer.

(I have no idea why dev to is de-optimizing the gif so bad so here's a picture):

Results

wasm avg (60fps):     0.520ms
js typed avg:         0.684ms

Insane speed up for node, now Wasm is only ~1× faster.

We’re close.

But can we do more?

Throwing Threads at It

Node.js isn’t just “single-threaded”.

That one thread is:

running timers
handling callbacks
scheduling work
cleaning garbage
synchronizing async tasks

Meanwhile, most machines have 4-16 cores, and we’re hammering one.

So let’s split the work.

Using SharedArrayBuffer, we get zero-copy sharing:

const controlBuffer = new SharedArrayBuffer(Int32Array.BYTES_PER_ELEMENT);
const control = new Int32Array(controlBuffer);

All I’m doing is dividing the particle rows between four workers, updating physics in parallel.

Worker code (line 61):

const CHUNK = workerData.chunkSize;

That’s it.

The results are insane.

Results

wasm avg (60fps):               0.520ms
js typed + workers avg:         0.400ms

JavaScript is now 1.26× faster on average.

Final Thoughts

Does this mean Wasm is slow?

Absolutely not.

Just like Node.js, Wasm can be aggressively optimized too. And honestly, the Node optimizations here aren’t even extreme, I could still push:

branchless programming
tighter batching
SIMD-friendly layouts

The point is simple:

Node.js can be insanely fast.
It’s C++ under the hood, you just need to know how to talk to it.

And once you do, the gap between “high-level” and “low-level” starts to look a lot smaller than people think.

Building A Binary Compiler For Node.js.

Sk — Tue, 06 Jan 2026 12:08:47 +0000

A binary compiler takes a data format and produces pure, flat binary data.

data -> buffer

The reason these things exist (protobufs, flatbuffers, you name it) is simple: the current standard for internet communication is bloated. Yes, JSON is insanely inefficient, but that’s the tax we pay for debuggability and readability.

This number right here → 1 is 200% larger in JSON than in pure binary.

'1'  = 8 bits
'"'  = 8 bits
'"'  = 8 bits
----------------
Total: 24 bits

In pure binary it’s just 8 bits.
But that’s not even the crazy part.

Every value in JSON also requires a key:

{
  "key": "1"
}

Take a second and guess how many bits that is now.

Don’t take my word for it, here’s proof.

This object:

const obj = {
  age: 26,
  randNum16: 256,
  randNum16: 16000,
  randNum32: 33000,
  hello: "world",
  thisisastr: "a long string lowkey",
}

Size comparison:

obj.json 98  kb
obj.bin  86  kb   # <- no protocol (keys + values serialized)
obj2.bin 41  kb   # <- with protocol (values only, protocol owns the keys)

Even with keys encoded, pure binary is still way leaner.
And this compounds fast as payloads grow.

It’s also pretty fast, near native:

Execution time comparison (milliseconds):

Name | Count | Min(ms) | Max(ms) | Mean(ms) | Median(ms) | StdDev(ms)
-----+-------+---------+---------+----------+------------+-----------
JSON | 100   | 0.000   | 0.000   | 0.000    | 0.000      | 0.000
TEMU | 100   | 0.000   | 1.000   | 0.010    | 0.000      | 0.099

The longest run took 1 ms, which is misleading, it’s a single outlier in 100 samples. My guess? Node allocating the initial buffer.

So… why a binary compiler?

Why a Binary Compiler?

I’ve been building more real-time systems and tools for Node.js lately, and JSON is just a bandwidth hog. It’s borderline inconceivable to build a low-latency system with JSON as your primary transport.

That’s why things like protobuf exist, especially for server-to-server communication. They’re insanely fast and way leaner.

Instead of using a generic solution, I’m experimenting with rolling my own, mainly as groundwork for the stuff I want to bring to Node.js:

tessera.js – a C++ N-API renderer powered by raw bytes (SharedArrayBuffers) (How I built a renderer for Node.js)
shard – a sub-100 nanosecond latency profiler (native C/C++ usually sits around 5–40ns)
nexus – a Godot-like game engine for Node.js

This experiment is really about preparing solid binary encoders/decoders for those projects.

Building the Compiler

Note: this is experimental. I literally opened VS Code and just started coding, no research, no reading papers.

Honestly, this is the best way to learn anything:
build it badly from intuition first, then go see how experts do it.

You’ll notice there’s zero thought put into naming, just pure flow. That’s intentional. This is how I prototype.

Utils and Setup

import { writeFileSync, fstatSync, openSync, closeSync } from "fs";

const obj = {
  age: 26,
  randNum16: 256,
  randNum16: 16000,
  randNum32: 33000,
  hello: "world",
  thisisastr: "a long string lowkey",
  // stack: ['c++', "js", "golang"],
  // hobbies: ["competitive gaming", "hacking node.js", "football"]
}

const TYPES = {
  numF: 1,   // float
  numI8: 2,  // int8
  numI16: 3, // int16
  numI32: 4, // int32
  string: 5,
  array: 6,
}

function getObjectKeysAndValues(obj) {
  // JS preserves property order per spec
  const keys = Object.keys(obj);
  const values = Object.values(obj);
  return [keys, values]; 
}

function isFloat(num) {
  return !Number.isInteger(num)
}

Serializing Keys

Simple protocol:

[allKeysLen | keyLen | key] -> buffer

function serKeys(keys) {
  let len = 0;

  for (let i = 0; i < keys.length; i++) {
    len += keys[i].length;
  }

  const finalLen = len + keys.length + 2;
  const buf = Buffer.allocUnsafe(finalLen);

  buf.writeUInt16BE(finalLen); // total key section length
  let writer = 2;

  for (const k of keys) {
    if (k.length > 255)
      throw new Error(`Key too long: "${k}" (${k.length} bytes)`);

    buf.writeUInt8(k.length, writer++);
    const written = buf.write(k, writer, 'utf8');
    writer += written;
  }

  return buf;
}

Deserializing is just the reverse: read length → read key → move pointer.

function deserKeys(buf) {
  let reader = 2;
  let keys = [];

  while (reader < buf.length) {
    const keyLen = buf.readUInt8(reader++);
    const key = buf.slice(reader, reader + keyLen);
    keys.push(key.toString("utf8"));
    reader += keyLen;
  }

  return keys;
}

Supported Types (For Now)

Only numbers and strings.

Strings

function seString(str) {
  const buf = Buffer.allocUnsafe(str.length + 3);
  buf.writeInt8(TYPES.string, 0);
  buf.writeInt16BE(str.length, 1);
  buf.write(str, 3, "utf8");
  return buf;
}

Numbers

function seNumber(num) {
  let buf;

  if (isFloat(num)) {
    buf = Buffer.allocUnsafe(5);
    buf.writeInt8(TYPES.numF, 0);
    buf.writeFloatBE(num, 1);
    return buf;
  }

  let type;
  if (num >= -128 && num <= 127) type = "8";
  else if (num >= -32768 && num <= 32767) type = "16";
  else type = "32";

  buf = Buffer.allocUnsafe(type === "8" ? 2 : type === "16" ? 3 : 5);

  switch (type) {
    case "8":
      buf.writeInt8(TYPES.numI8, 0);
      buf.writeInt8(num, 1);
      break;
    case "16":
      buf.writeInt8(TYPES.numI16, 0);
      buf.writeInt16BE(num, 1);
      break;
    case "32":
      buf.writeInt8(TYPES.numI32, 0);
      buf.writeInt32BE(num, 1);
      break;
  }

  return buf;
}

You’ll notice the same pattern everywhere:

[type | len? | data]

Length is optional, numbers encode it via type:

i8  -> 8 bits
i16 -> 16 bits
i32 -> 32 bits

The Compiler

Serialize:

function gen(obj, protocol = false) {
  if (typeof obj !== "object")
    throw new Error("Must be Object");

  let cache = new Map();
  const [keys] = getObjectKeysAndValues(obj);

  let serk;
  if (!protocol) {
    serk = serKeys(keys);
  }

  let length = 0;

  for (const key of keys) {
    let buf;

    switch (typeof obj[key]) {
      case "number":
        buf = seNumber(obj[key]);
        break;
      case "string":
        buf = seString(obj[key]);
        break;
      default:
        continue;
    }

    length += buf.length;
    cache.set(key, buf);
  }

  const dataBuf = Buffer.allocUnsafe(length);
  let writer = 0;

  for (const key of keys) {
    const b = cache.get(key);
    if (b) {
      b.copy(dataBuf, writer);
      writer += b.length;
    }
  }

  return protocol ? dataBuf : Buffer.concat([serk, dataBuf]);
}

Deserialize:

function unserData(buf) {
  let reader = 0;
  let data = [];

  while (reader < buf.length) {
    const t = buf.readInt8(reader++);
    switch (t) {
      case 1:
        data.push(buf.readFloatBE(reader));
        reader += 4;
        break;
      case 2:
        data.push(buf.readInt8(reader++));
        break;
      case 3:
        data.push(buf.readInt16BE(reader));
        reader += 2;
        break;
      case 4:
        data.push(buf.readInt32BE(reader));
        reader += 4;
        break;
      case 5:
        const len = buf.readInt16BE(reader);
        reader += 2;
        data.push(buf.subarray(reader, reader + len).toString("utf8"));
        reader += len;
        break;
    }
  }

  return data;
}

Unified parser:

function ungen(buf, protocol = false) {
  if (!protocol) {
    const keysLen = buf.readInt16BE(0);
    const keysBuf = buf.subarray(0, keysLen);
    deserKeys(keysBuf);
    return unserData(buf.subarray(keysLen));
  }
  return unserData(buf);
}

Running It

Sanity check:

let samples = { JSON: [], TEMU: [] };

function J() {
  const start = process.hrtime.bigint();
  JSON.parse(JSON.stringify(obj));
  const end = process.hrtime.bigint();
  samples.JSON.push((end - start) / 1_000_000n);
}

function T() {
  const start = process.hrtime.bigint();
  const b = gen(obj, true);
  ungen(b);
  const end = process.hrtime.bigint();
  samples.TEMU.push((end - start) / 1_000_000n);
}

Sampling:

const WARMUP = 100_000;
const SAMPLE = 100;

for (let i = 0; i < WARMUP; i++) {}
for (let i = 0; i < SAMPLE; i++) J();

for (let i = 0; i < WARMUP; i++) {}
for (let i = 0; i < SAMPLE; i++) T();

console.dir(samples.TEMU);

It works.

The real question is:
after doing proper research, how much better can this get?

Building Single-Executable Node.js Apps (Without the Pain)

Sk — Wed, 31 Dec 2025 14:00:06 +0000

Node.js was never meant to ship like it does currently.

By the end of this article, you’ll have a running command-line executable.

No Node install.

No npm install.

No “works on my machine”.

Just a binary.

And not just CLI, a real GUI executable, shipped the same way.

Node.js is an unbelievable C++ runtime if you know how to command it properly. Sadly, the tooling story, and the endless CommonJS vs ESM compatibility mess, can be a real pain.

So, in the spirit of bringing better tooling to Node.js, inspired by the most beautiful bundler I’ve ever seen, the Zig bundler

No external tools. The same language you build with is the one doing the bundling.

So I decided to lean into Node’s most underused feature:

Single Executable Applications (SEA).

And then I built tooling that actually makes it usable.

// build.js
import { release } from "sea-builder";

const production = {
  entry: 'app/index.js',
  name: 'myapp',
  platforms: ['linux-x64', 'win-x64'],
  outDir: './dist',
  assets: {
    'README.md': './README.md'
  }
};

release(production)
  .then(res => {
    console.log(res);
  })
  .catch(err => console.log(err));

That’s it. You get an executable.

Why SEA actually matters

Your app, runtime, and assets ship as one file
Startup is fast (especially with code cache) < - you also have low level utility like snapshots etc.
Native modules are predictable
The user experience matches real software, not a dev environment

This is how Go ships.

This is how Rust ships.

This is how Zig ships.

Node can do this too, it just never had good tooling around it.

That’s what sea-builder is.

Example 1: Simple Script

Note: You’ll need Node.js 20+

Check your version:

node -v

Start a project:

npm init -y && npm i sea-builder

Folder structure

app/
  index.js
  README.md
cross-build.js

`index.js`

const { getAsset, isSea } = require('node:sea');

console.log(`Hello, ${process.argv[2] || 'World'}!`);
console.log(`Running from: ${process.execPath}`);
console.log(`Platform: ${process.platform}`);
console.log('Running as SEA!\n');

const readme = getAsset('README.md', 'utf8');
console.log('readme:', readme);

// binary asset (returns ArrayBuffer)
const configBinary = getAsset('README.md');
console.log('Binary size:', configBinary.byteLength, 'bytes');

Put anything you want in README.md. Plain text is fine.

`cross-build.js`

const { release } =  require("sea-builder");

const production = {
  entry: 'app/index.js',
  name: 'myapp',
  platforms: ['linux-x64', 'win-x64'],
  outDir: './dist',
  assets: {
    'README.md': './README.md'
  }
};

release(production)
  .then(res => {
    console.log(res);
  })
  .catch(err => console.log(err));

Run the build:

node cross-build.js

sea-builder handles downloading the correct Node binary and patching it.

Easy, no?

But let’s do something more fun, a windowed app.

Example 2: `tessera.js`

tessera.js is a Node.js renderer I built. You can read more about it here How I Built a Graphics Renderer for Node.js, but since this article is about SEA, I’ve prepped a repo for you.

Clone it:

git clone https://github.com/sklyt/tessera-seaexample.git

Install dependencies:

npm i

Run the build:

node .\tesseraexample\build.js

Exe

.\dist\img.exe

The key difference here is that we compile everything down to CommonJS first, because ESM is the enemy of everything good, including SEA.

// inside build.js

await build({
  entryPoints: [entryJs],
  bundle: true,
  platform: 'node',
  target: 'node22', // adjust to your minimum Node target
  format: 'cjs',
  outfile: bundlePath,

  // Native binaries stay external
  external: ['*.node', '*.dll'],

  sourcemap: false,
  logLevel: 'info',

  define: {
    require: 'require'
  }
});

Once the code is bundled to CommonJS, we call sea-builder as usual.

const bundlerOptions = {
  entry: bundlePath, // <-- bundled entry, your bundled script
  name: appName,
  platforms: targets,
  outDir: outDir,
  assets: {
    'win-x64': {
      'prebuilds/win32-x64/renderer.node': join(__dirname, '/prebuilds/win32-x64/renderer.node'),
      'prebuilds/win32-x64/glfw3.dll': join(__dirname, '/prebuilds/win32-x64/glfw3.dll'),
      'prebuilds/win32-x64/raylib.dll': join(__dirname, '/prebuilds/win32-x64/raylib.dll')
    },
    'linux-x64': {
      'prebuilds/linux-x64/renderer.node': join(__dirname, '/prebuilds/linux-x64/renderer.node')
    }
  },

  // optional flags (code cache works only on the current platform not cross compile use ci workflows for that)
  useCodeCache: false, 
  useSnapshot: false
};

console.log('Calling sea() with bundled entry and platform assets...');
await sea(bundlerOptions);

console.log('sea() finished. Outputs are in', path.resolve(outDir));

tessera.js is configured to load assets from an SEA via this helper in img.js:

const getter = (name) => {
  try {
    return getAsset(name); // string or ArrayBuffer
  } catch {
    return null;
  }
};

const { Renderer, FULLSCREEN, RESIZABLE } =
  loadRendererSea({ assetGetterSync: getter });

And that’s it, you now have a sharable executable.

In an upcoming version of sea-builder, the terminal won’t launch alongside GUI executables. Still figuring that out. Worst case, I’ll patch the binary headers directly.

But honestly?

It already works.

Common Build Profiles

module.exports = {
  // Development build - fast iteration
  dev: {
    entry: 'src/index.js',
    name: 'myapp-dev',
    platforms: 'current',
    outDir: './build',
    useCodeCache: true
  },

  // Production build - all platforms
  production: {
    entry: 'src/index.js',
    name: 'myapp',
    platforms: 'all',
    outDir: './dist',
    clean: true,
    assets: {
      'config.json': './config/production.json',
      'README.md': './README.md',
      'LICENSE': './LICENSE'
    }
  },

  // Server build - Linux only
  server: {
    entry: 'src/server.js',
    name: 'myapp-server',
    platforms: ['linux-x64', 'linux-arm64'],
    outDir: './dist/server',
    useCodeCache: true,
    assets: {
      'config.json': './config/server.json'
    }
  },

  // CLI tool - small and portable
  cli: {
    entry: 'src/cli.js',
    name: 'myapp-cli',
    platforms: 'all',
    outDir: './dist/cli'
  }
};

Note: useCodeCache: true only works on the current platform since it’s platform-specific. Use CI to build cached binaries per target.

Profile usage

// build.js
const { sea } = require('sea-builder');
const config = require('./sea.config');

// node build.js production
const profile = process.argv[2] || 'dev';

if (!config[profile]) {
  console.error(`Unknown profile: ${profile}`);
  console.log('Available profiles:', Object.keys(config).join(', '));
  process.exit(1);
}

console.log(`Building with profile: ${profile}`);

sea(config[profile]).then(results => {
  console.log(`\nBuilt ${results.length} executable(s)`);
});

tessera.js repo

Thanks for reading!

Find me here:

X/Twitter
Substack ← devlogs, deep dives, and long-form content.

Building Crash-Tolerant Node.js Apps with Clusters.

Sk — Thu, 18 Dec 2025 10:00:00 +0000

Ever wondered why a browser tab can crash without taking down the whole browser?
Or why a telecom system is “never really down”, unless it’s down down?

Yet your Node.js app crashes all the time.

It’s all code, right?
So why does their stuff survive explosions and yours doesn’t?

But to understand that, you need to briefly understand how a program is loaded into memory.

The Kernel

The kernel is the core component of an operating system (for example, the Linux kernel).

Its job is to:

manage every running program
assign each program its own memory space
isolate programs from each other

If you’re running two applications:

app1 | app2

The kernel keeps them separated so they can’t corrupt each other’s memory.

If app2 crashes, the kernel makes sure it implodes in isolation and doesn’t affect app1.

That part most people know.

Here’s the part most people miss:

The kernel doesn’t just kill the crashing app, it reports the crash to whoever launched it.

Conceptually, it looks like this:

int main() {
  return 0; // <- kernel forces an exit code on crash
}

Now this is where things get interesting.

Booting an App Inside Another App

What happens when you launch an app from another app?

app1 | app2 | app1_child

A more intuitive picture:

app1_child
app1        | app2

The child process still gets its own memory space, fully isolated.

But when it crashes…
who does the kernel report that crash to?

Exactly.

The parent. The runner.

And that is the secret behind crash-tolerant software.

The parent stays alive.
The child dies.
The parent restarts it.

This Pattern Is Everywhere

You’ve already been using this idea without realizing it:

Browser tabs
Kubernetes pods
Telecom infrastructure
Databases
Supervisors in Erlang

Sometimes it’s hardware-backed (real OS processes).
Sometimes it’s software-simulated (Erlang-style lightweight processes).

Same idea either way:

Let things crash, just don’t let them take everything with them.

That’s why phone lines don’t really “die.”
That’s why browsers feel unkillable.

Node.js Can Do This Too

You can do the exact same thing in Node.js using clusters.

Clusters are not threads.
They are real OS processes.

When you fork a cluster, you are literally booting another Node.js instance on top of the current one.

I use this all the time.

For example:
My profiler receives real-time events in worker clusters, while the GUI runs in the main process.

If a worker explodes?
The UI stays alive.

reference: How I Built a Graphics Renderer for Node.js

Clusters in Node.js

Here’s a simple example: a server running in a cluster that randomly crashes and automatically restarts.

const cluster = require('cluster');
const os = require('os');

if (cluster.isPrimary) {
  console.log(`primary ${process.pid} is running`);

  const numCPUs = os.cpus().length;

  // fork a couple of workers
  for (let i = 0; i < Math.min(numCPUs, 2); i++) {
    cluster.fork();
  }

  cluster.on('exit', (worker, code, signal) => {
    console.log(`Worker ${worker.process.pid} died (code=${code}, signal=${signal})`);

    setTimeout(() => {
      console.log('Restarting worker...');
      cluster.fork();
    }, 1000);
  });

  cluster.on('online', (worker) => {
    console.log(`Worker ${worker.process.pid} is online`);
  });

} else {
  console.log(`Worker ${process.pid} started`);

  const http = require('http');

  const server = http.createServer((req, res) => {
    res.writeHead(200);
    res.end(`Hello from worker ${process.pid}`);
  });

  server.listen(3000, () => {
    console.log(`Worker ${process.pid} listening on port 3000`);
  });

  // simulate random crashes
  const crashTimeout = Math.floor(Math.random() * 30000) + 10000;
  setTimeout(() => {
    console.log(`Worker ${process.pid} will crash in 5 seconds...`);

    setTimeout(() => {
      throw new Error(`Simulated crash in worker ${process.pid}`);
    }, 5000);
  }, crashTimeout);

  process.on('SIGTERM', () => {
    console.log(`Worker ${process.pid} shutting down gracefully`);
    server.close(() => process.exit(0));
  });
}

Everything inside the else block runs in a dedicated cluster process.

In this example, we spin up two workers:

for (let i = 0; i < Math.min(numCPUs, 2); i++) {
  cluster.fork();
}

The if block is the main app.
If that crashes - everything dies.

But if a worker crashes?
The parent notices and boots a new one.

That’s the whole trick.

This is obviously a high-level overview, but clusters are incredibly powerful when you want:

fault isolation
crash recovery
long-running systems that don’t fall over

If you want the gritty details, the Node.js docs are worth a read.

tessera.js repo

Thanks for reading!

Find me here:

X/Twitter
Substack ← devlogs, deep dives, and long-form content.

Evolutionary Algorithms, Rendered Live in Node.js

Sk — Wed, 17 Dec 2025 13:00:50 +0000

Reinforcement learning, evolutionary algorithms, and anything that lets computers see are some of the most visually satisfying problems to work on. Watching something learn in real time never gets old.

This article is really just an excuse to show off a tiny graphics renderer I built for Node.js: tessera.js.

And I honestly can’t think of a better demo than the hello world of evolutionary algorithms:
a bunch of random colors mutating and slowly evolving toward a target color.

If you’re new to graphics programming, don’t worry, the unit of everything visual in the digital world is surprisingly simple. I cover that here:
Graphics 101: A Node.js Renderer

Finding the Target Color

Install tessera:

npm i tessera.js@latest

Start the renderer:

import { loadRenderer, PixelBuffer, ShapeDrawer } from "tessera.js";

const { Renderer } = loadRenderer();
const renderer = new Renderer();

if (!renderer.initialize(1200, 800, "Evolution Algos Hello World")) {
  console.error("failed to init renderer");
  process.exit(1);
}

renderer.targetFPS = 60;
const canvas = new PixelBuffer(renderer, 1200, 800);

Parameters and the Genome (the “species”)

// Target color we're evolving toward
const TARGET = { r: 120, g: 80, b: 150 };

/**
 * Genome = full DNA
 * Genotype = specific gene values
 * Phenotype = what we actually see
 *
 * Here: genome is just RGB.
 */
class Genome {
  constructor(r = null, g = null, b = null) {
    this.r = r ?? Math.floor(Math.random() * 256);
    this.g = g ?? Math.floor(Math.random() * 256);
    this.b = b ?? Math.floor(Math.random() * 256);
    this.fitness = 0;
  }
}

const MUTATION_RATE = 0.3;   // more chaos
const ELITE_COUNT = 5;      // more stability
const POP_SIZE = 150;       // slower but more thorough

let population = Array.from({ length: POP_SIZE }, () => new Genome());
let generation = 0;
let bestEver = null;

The Core Evolution Algorithm

// Fitness: lower distance = better
function evaluateFitness(genome) {
  const dr = genome.r - TARGET.r;
  const dg = genome.g - TARGET.g;
  const db = genome.b - TARGET.b;
  genome.fitness = Math.sqrt(dr * dr + dg * dg + db * db);
}

// Tournament selection
function selectParent(pop) {
  const tournamentSize = 3;
  let best = pop[Math.floor(Math.random() * pop.length)];
  for (let i = 1; i < tournamentSize; i++) {
    const candidate = pop[Math.floor(Math.random() * pop.length)];
    if (candidate.fitness < best.fitness) best = candidate;
  }
  return best;
}

// Crossover: mix genes
function crossover(p1, p2) {
  const child = new Genome();
  child.r = Math.random() < 0.5 ? p1.r : p2.r;
  child.g = Math.random() < 0.5 ? p1.g : p2.g;
  child.b = Math.random() < 0.5 ? p1.b : p2.b;
  return child;
}

function randomGaussian() {
  return Math.sqrt(-2 * Math.log(Math.random())) *
         Math.cos(2 * Math.PI * Math.random());
}

// Mutation
function mutate(genome) {
  if (Math.random() < MUTATION_RATE)
    genome.r = Math.max(0, Math.min(255, genome.r + randomGaussian() * 60));
  if (Math.random() < MUTATION_RATE)
    genome.g = Math.max(0, Math.min(255, genome.g + randomGaussian() * 60));
  if (Math.random() < MUTATION_RATE)
    genome.b = Math.max(0, Math.min(255, genome.b + randomGaussian() * 60));
}

Tie Everything Together

function evolve() {
  population.forEach(evaluateFitness);
  population.sort((a, b) => a.fitness - b.fitness);

  if (!bestEver || population[0].fitness < bestEver.fitness) {
    bestEver = { ...population[0] };
  }

  const newPop = [];

  // Elitism
  for (let i = 0; i < ELITE_COUNT; i++) {
    newPop.push(new Genome(
      population[i].r,
      population[i].g,
      population[i].b
    ));
  }

  while (newPop.length < POP_SIZE) {
    const p1 = selectParent(population);
    const p2 = selectParent(population);
    const child = crossover(p1, p2);
    mutate(child);
    newPop.push(child);
  }

  population = newPop;
  generation++;
}

Render Everything

function render() {
  canvas.clear(20, 20, 25, 255);

  // Target
  ShapeDrawer.fillRect(canvas, 50, 50, 150, 150, TARGET.r, TARGET.g, TARGET.b, 255);

  // Best current
  const best = population[0];
  ShapeDrawer.fillRect(canvas, 250, 50, 150, 150, best.r, best.g, best.b, 255);

  // Best ever
  if (bestEver) {
    ShapeDrawer.fillRect(canvas, 450, 50, 150, 150, bestEver.r, bestEver.g, bestEver.b, 255);
  }

  // Population grid
  const gridX = 50, gridY = 250, cellSize = 20, cols = 10;
  population.forEach((g, i) => {
    const x = gridX + (i % cols) * (cellSize + 5);
    const y = gridY + Math.floor(i / cols) * (cellSize + 5);
    ShapeDrawer.fillRect(canvas, x, y, cellSize, cellSize, g.r, g.g, g.b, 255);
  });

  canvas.upload();
}

renderer.onRender(() => {
  canvas.draw(0, 0);

  renderer.drawText("TARGET", { x: 50, y: 30 }, 16, { r: 1, g: 1, b: 1, a: 1 });
  renderer.drawText("BEST NOW", { x: 250, y: 30 }, 16, { r: 1, g: 1, b: 1, a: 1 });
  renderer.drawText("BEST EVER", { x: 450, y: 30 }, 16, { r: 1, g: 1, b: 1, a: 1 });

  const best = population[0];
  renderer.drawText(
    `Gen: ${generation} | Fitness: ${best.fitness.toFixed(2)} | RGB: (${best.r}, ${best.g}, ${best.b})`,
    { x: 50, y: 650 },
    16,
    { r: 1, g: 1, b: 1, a: 1 }
  );
});

The Loop

let frameCount = 0;
const FRAME_DELAY = 60;

evolve();

function Loop() {
  frameCount++;
  renderer.input.GetInput();

  if (frameCount % FRAME_DELAY === 0) {
    evolve();
  }

  render();

  if (renderer.step()) {
    setImmediate(Loop);
  } else {
    renderer.shutdown();
  }
}

Loop();

In ~100 lines (minus boilerplate), we’ve got a fully animated evolutionary algorithm running in Node.js.

If graphics programming is something you’re curious about, I’ve got more content coming.

Check out the repo:
https://github.com/sklyt/render
Star it and browse the examples if this kind of stuff is your thing.

Thanks for reading!

Find me here:

X/Twitter
Substack ← devlogs, deep dives, and long-form content.

Building A Distributed Video Transcoding System with Node.js.

Sk — Wed, 17 Dec 2025 12:52:56 +0000

Brokers are the hello world of distributed systems, for two reasons:

Easy to get up and running
They enforce the hive / master-node pattern, which scales naturally

node  <-->              
node  <-->  hive / broker <-->  client-facing server  <-->  client
node  <-->                                            <-->  client

So I thought: why not bring a pure JavaScript broker to Node.js?

// broker.js
import Bunny from "bunnimq";
import path from "path";
import { fileURLToPath } from "url";

Bunny({
  port: 3000,
  DEBUG: true,
  cwd: path.dirname(fileURLToPath(import.meta.url)), // path to the .auth file
  queue: {
    Durable: true,
    MessageExpiry: 60 // 1 hour
  }
});

To be honest, low-level Node.js is super impressive. It took a few days, but it works, with a few optimizations:

Object → binary compiler
SharedArrayBuffers and threads

It can actually be way better, which (by the way) Node supports seamlessly:

const buffer = new SharedArrayBuffer();
const worker = new Worker(); // <-

So here’s an example of an FFmpeg distributed system running purely in Node.js.

But first, make sure you have FFmpeg installed and available in your PATH. Test it in the terminal:

ffmpeg -i img.jpg img.png

A Distributed Video Transcoding Example

Start a Node project:

npm init -y && npm i bunnimq bunnimq-driver

Folder structure:

ffmpegserver/
  server.js    # <- the hive
  producer.js  # client-facing server
  consumer.js  # node servers / workers
  .auth        # credentials for producer and consumer verification (like .env)

`.auth`

Put your secret credentials here: username:password:privileges
(see privileges in the repo)

sk:mypassword:4
jane:doeeee:1
john:doees:3

`server.js`

Simple, non-TLS setup (TLS is supported - see the GitHub repo):

import Bunny from "bunnimq";
import path from "path";
import { fileURLToPath } from "url";

Bunny({
  port: 3000,
  DEBUG: true,
  cwd: path.dirname(fileURLToPath(import.meta.url)), // for .auth file
  queue: {
    Durable: true,
    QueueExpiry: 0,
    MessageExpiry: 3600
  }
});

`producer.js`

This is the server browsers and other clients talk to.
It accepts requests and pushes jobs into the hive.

import BunnyMQ from "bunnimq-driver";
import fs from "node:fs/promises";

const bunny = new BunnyMQ({
  port: 3000,
  host: "localhost",
  username: "sk",
  password: "mypassword",
});

Create the queue if it doesn’t exist:

bunny.queueDeclare(
  {
    name: "transcode_queue",
    config: {
      QueueExpiry: 60,
      MessageExpiry: 20,
      AckExpiry: 10,
      Durable: true,
      noAck: false,
    },
  },
  (res) => {
    console.log("Queue creation:", res);
  }
);

Usually videos come from the client.
For the demo, we’ll just read from a local folder:

async function processVideos() {
  const videos = await fs.readdir(
    "C:/Users/[path to a folder with videos]/Videos/Capcut/test"
  ); // usually a storage bucket link

  for (const video of videos) {
    const job = {
      id: Date.now() + Math.random().toString(36).substring(2),
      input: `C:/Users/[path to a folder with videos]/Videos/Capcut/test/${video}`,
      outputFormat: "webm",
    };

    // put into the queue
    bunny.publish("transcode_queue", JSON.stringify(job), (res) => {
      console.log(`Job ${job.id} published:`, res ? "ok" : "400");
    });
  }
}

processVideos();

`consumer.js`

These are the nodes, the workers that pull jobs, transcode videos, and report back.

import BunnyMQ from "bunnimq-driver";
import { spawn } from "child_process";
import path from "path";

const bunny = new BunnyMQ({
  port: 3000,
  host: "localhost",
  username: "john",
  password: "doees",
});

Consume the transcode queue:

bunny.consume("transcode_queue", async (msg) => {
  console.log("Received message:", msg);

  try {
    const { input, outputFormat } = JSON.parse(msg);

    // normalize paths
    const absInput = path.resolve(input);
    const output = absInput.replace(/\.[^.]+$/, `.${outputFormat}`);

    console.log(
      `Spawning: ffmpeg -i "${absInput}" -f ${outputFormat} "${output}" -y`
    );

    await new Promise((resolve, reject) => {
      const ffmpeg = spawn(
        "ffmpeg",
        ["-i", absInput, "-f", outputFormat, output, "-y"],
        { shell: true } // helps Windows find ffmpeg.exe
      );

      ffmpeg.on("error", reject);

      // FFmpeg logs to stderr
      ffmpeg.stderr.on("data", (chunk) => {
        process.stderr.write(chunk);
      });

      ffmpeg.on("close", (code, signal) => {
        if (code === 0) {
          console.log(`Transcoding complete: ${output}`);
          return resolve(
            bunny.Ack((ok) => console.log("Ack sent:", ok))
          );
        }

        reject(
          new Error(
            signal ? `Signaled with ${signal}` : `Exited with code ${code}`
          )
        );
      });
    });
  } catch (error) {
    console.error("Error processing message:", error);
    if (bunny.Nack) bunny.Nack();
  }
});

Open multiple terminals:

node .\server.js   # terminal 1
node .\producer.js # terminal 2

The nodes can be as many terminals as you want, that’s the parallel, distributed part:

node .\consumer.js

This is the entire pattern.
Simple, powerful, and it just scales, because the hive is responsible for that.

You can take this exact pattern and translate it to RabbitMQ and it’ll work.
I built bunnimq mostly as a joke after reading RabbitMQ’s source and how it works… and somehow it worked.

But that’s the point:

Brokers are the hello world of distributed systems.
It’s actually really hard to fail at them.

How I Built a Graphics Renderer in Node.js

Visualizing Evolutionary Algorithms in Node.js

tessera.js repo

Thanks for reading!

Find me here:

X/Twitter
Substack ← devlogs, deep dives, and long-form content.

Graphics Programming 101 in Node.js (Yes, It’s Actually Possible).

Sk — Tue, 16 Dec 2025 12:17:10 +0000

Graphics programming, besides being both intellectually and visually stimulating, is the nucleus of literally everything you see and experience on a screen.

From visual effects (VFX)

to particle systems

to image detection/editing/engineering

to the rendering pipeline in that game engine, the beautiful UI, and much more.

But all of it stems from one simple fact.

If you take a screen:

_______________
|             |
|             |
|             |   <- screen (it’s 2D)
|             |
|_____________|

and divide it into rows and columns:

|------------|
|------------|
|------------|
|------------|

     ^
     |
     imagine columns here

then unwrap it into rows only:

row 1      row 2      .... row n
--------  --------     --------
--------  --------     --------

You end up with an array.

But not a typical array.

It’s an array of bytes - contiguous memory, a raw chunk of memory called a buffer.

In Node.js, it looks like this:

const buf = Buffer.alloc(1024); // <- raw memory

Now take that buffer and fill it with numbers between 0 and 255, using this simple formula:

(y * width + x) * 4; // 4 channels: r, g, b, a

This maps screen coordinates (x, y), with (0, 0) being the top-left of the screen, directly into the buffer.

What you get are pixels:

[ R, G, B, A, R, G, B, A, R, G, B, A, ... ]  // Linear array
  ˄                   ˄                   ˄
Pixel 0            Pixel 1            Pixel 2
(x=0,y=0)         (x=1,y=0)          (x=2,y=0)

Pixels give you an image.

Do that 60 times per second (FPS), or more, and you get an animated image.

That buffer is called a framebuffer.

That’s graphics programming 101.

To make this concrete, I put together a few examples below.

I extracted a renderer from my Node.js game engine into a standalone package
(yes, it’s possible - with a little C++ magic):

tessera.js
How I built A Graphics Renderer For node.js

That’s what we’ll use for the rest of this article.
All you need is Node.js, preferably a newer LTS version.

Installation

Create a new npm project and install the renderer:

npm i tessera.js

Set up a simple render loop:

import { loadRenderer, PixelBuffer, DirtyRegionTracker } from "tessera.js";

const { Renderer, FULLSCREEN, RESIZABLE } = loadRenderer();
const renderer = new Renderer();

// width, height, title
if (!renderer.initialize(1920, 910, "Renderer")) {
    console.error("Failed to initialize renderer");
    process.exit(1);
}

renderer.setWindowState(RESIZABLE);
renderer.targetFPS = 60;

const canvas = new PixelBuffer(renderer, 650, 400); // framebuffer: every pixel lives here
canvas.clear(50, 1, 1, 255);

renderer.onRender(() => {
    // C++ calls you here before rendering, this is where you "draw"
    canvas.draw(0, 0); // top-left
});

function Loop() {
    renderer.input.GetInput(); // keyboard / mouse state
    // update would happen here
    if (renderer.step()) { // calls the render callback and draws to screen
        setImmediate(Loop);
    } else {
        console.log("loop ended");
        renderer.shutdown();
    }
}

Loop(); // non-blocking: step runs in C++, not JS

process.on("SIGINT", () => {
    console.log("\nshutting down gracefully...");
    renderer.shutdown();
    process.exit(0);
});

All your rendering logic lives here:

renderer.onRender(() => {
});

Let’s draw something simple, a diagonal line from the top-left corner:

const data = canvas.data; // "pointer" to the framebuffer
const tracker = new DirtyRegionTracker(canvas); // update only touched pixels

for (let i = 0; i <= canvas.width; i++) {
    const idx = (i * canvas.width + i) * 4;

    data[idx]     = 255; // r
    data[idx + 1] = 10;  // g
    data[idx + 2] = 20;  // b
    data[idx + 3] = 255; // a

    tracker.mark(i, i + 4);
}

tracker.flush();   // apply changes
canvas.upload();   // send to GPU

renderer.onRender(() => {
    canvas.draw(0, 0);
});

A line is just a collection of points between two anchor points, a start and an end.

If you understood everything up to this point, you’ve already grasped the core of rasterization, turning data into pixels.

That’s true for all renderers, even 3D ones.

You’ll often see this quote about OpenGL:

The process of transforming 3D coordinates to 2D pixels is managed by the graphics pipeline of OpenGL.
The graphics pipeline can be divided into two large parts: the first transforms your 3D coordinates into 2D coordinates and the second part transforms the 2D coordinates into actual colored pixels.

And that second part?

That’s exactly what we just did.

but we can take it further.

Take the line example above.

If we draw four lines, two pairs of parallel ones, we get a stroked rectangle.

import { ShapeDrawer } from "tessera.js";

ShapeDrawer.strokeRect(
  canvas,
  100, 100,
  280, 100,
  5,          // thickness
  40, 45, 55, // r g b
  200         // a
);

canvas.upload(); // drawer utilities handle patching internally

renderer.onRender(() => {
  canvas.draw(0, 0);
});

Under the hood, that’s really just four points connected by lines:

.----------.
|          |
|   line   |
|          |
.----------.

Once you accept that, it’s easy to go further.

Instead of fixed rectangles, you can define a list of arbitrary points and weave a line through them, now you’re drawing polygons.

Polygons → UI

Here’s a simple button built from a rounded polygon:

import { ShapeDrawer, PolygonDrawer } from "tessera.js";

class CreateButton {
  constructor(x, y, width, height, borderRadius, color = { r: 40, g: 45, b: 55, a: 200 }) {
    this.x = x;
    this.y = y;
    this.width = width;
    this.height = height;
    this.borderRadius = borderRadius;
    this.color = color;
    this.isHovered = false;
  }

  contains(px, py) {
    return (
      px >= this.x && px < this.x + this.width &&
      py >= this.y && py < this.y + this.height
    );
  }

  draw(canvas) {
    const points = PolygonDrawer.createRoundedRect(
      this.x,
      this.y,
      this.width,
      this.height,
      this.borderRadius
    );

    PolygonDrawer.fillPolygon(
      canvas,
      points,
      this.color.r,
      this.color.g,
      this.color.b,
      255
    );

    // Border
    PolygonDrawer.strokePolygon(
      canvas,
      points,
      2,
      this.isHovered ? 120 : 80,
      this.isHovered ? 140 : 100,
      this.isHovered ? 160 : 120,
      255
    );
  }
}

Mouse Interaction

Detecting hover is just geometry.

import { InputMap } from "tessera.js";

const im = new InputMap(renderer.input);

const btn = new CreateButton(200, 200, 100, 48, 7);
btn.draw(canvas);
canvas.upload();

function Loop() {
  renderer.input.GetInput();

  const mouse = im.mousePosition;
  btn.isHovered = btn.contains(mouse.x, mouse.y);

  if (btn.isHovered) {
    console.log("button hovered");
  }
}

At this point, you’re already building UI from scratch.

The point is simple: everything graphical you’ll ever see starts with a framebuffer.
Lines, shapes, buttons - it’s all just pixels.

So what about animation?

Same idea. You don’t draw once, you draw many times, usually ~60 times per second.

Let’s build my favorite example: a radial particle system.

Particle System Example

function createParticleSystem() {
  const particles = [];
  const centerX = canvas.width / 2;
  const centerY = canvas.height / 2;

  for (let i = 0; i < 100; i++) {
    particles.push({
      x: centerX,
      y: centerY,
      vx: (Math.random() - 0.5) * 4,
      vy: (Math.random() - 0.5) * 4,
      life: 1.0,
      decay: 0.0005 + Math.random() * 0.01,
      color: {
        r: Math.floor(100 + Math.random() * 155),
        g: Math.floor(100 + Math.random() * 155),
        b: Math.floor(200 + Math.random() * 55),
      },
    });
  }

  return particles;
}

const particles = createParticleSystem();

Bring Them to Life

function animate() {
  const tracker = new DirtyRegionTracker(canvas);

  particles.forEach(p => {
    // Integrate motion
    p.x += p.vx;
    p.y += p.vy;
    p.life -= p.decay;

    // Bounce off walls
    if (p.x <= 0 || p.x >= canvas.width - 1) {
      p.vx *= -0.8;
      p.x = Math.max(0, Math.min(canvas.width - 1, p.x));
    }
    if (p.y <= 0 || p.y >= canvas.height - 1) {
      p.vy *= -0.8;
      p.y = Math.max(0, Math.min(canvas.height - 1, p.y));
    }

    // Radial pull toward center
    const dx = canvas.width / 2 - p.x;
    const dy = canvas.height / 2 - p.y;
    const dist = Math.sqrt(dx * dx + dy * dy);

    if (dist > 0) {
      p.vx += dx * 0.0001;
      p.vy += dy * 0.0001;
    }

    // Draw particle
    if (p.life > 0) {
      const size = Math.floor(p.life * 3) + 1;

      for (let py = -size; py <= size; py++) {
        for (let px = -size; px <= size; px++) {
          if (px * px + py * py <= size * size) {
            const x = Math.floor(p.x + px);
            const y = Math.floor(p.y + py);

            if (x >= 0 && x < canvas.width && y >= 0 && y < canvas.height) {
              const idx = canvas.coordToIndex(x, y);
              canvas.data[idx + 0] = p.color.r;
              canvas.data[idx + 1] = p.color.g;
              canvas.data[idx + 2] = p.color.b;
              canvas.data[idx + 3] = 255;
              tracker.mark(x, y);
            }
          }
        }
      }
    } else {
      // Respawn
      p.x = canvas.width / 2;
      p.y = canvas.height / 2;
      p.vx = (Math.random() - 0.5) * 4;
      p.vy = (Math.random() - 0.5) * 4;
      p.life = 1.0;
    }
  });

  tracker.flush();
  canvas.upload();
}

Call it from the loop:

function Loop() {
  canvas.clear(15, 15, 35, 255); // deep space blue
  animate();

  if (renderer.step()) {
    setImmediate(Loop);
  }
}

The particles naturally gravitate toward the center.
Tweak velocity, decay, or gravity constants and you get wildly different behaviors.

What you just learned is rasterization - the final stage of the graphics pipeline.

It’s the same idea behind charts, UI toolkits, visualizers, and real-time systems like games.

Once you understand pixels and a framebuffer, everything else is just creativity.

tessera.js repo

Thanks for reading!

Find me here:

X/Twitter
Substack ← devlogs, deep dives, and long-form content.

How I Built a Graphics Renderer for Node.js

Sk — Tue, 16 Dec 2025 11:32:05 +0000

Anything remotely intensive in Node.js that needs visuals: tracing, telemetry, profiling, you basically have no choice but to depend on the browser.

And the browser, while great, idles at around ~2GB of memory minimum.
Not to mention constant alt-tabbing.

But why?

Node.js is just as much C++ as the next browser. There’s nothing stopping it from rendering things.

I remember trying to profile a real-time system once, it was awful. Constant context switching to the browser, memory exploding, losing flow. It felt wrong.

So I built a software renderer, you know the thing responsible for everything visual you see in the digital world, from UIs to games.
It’s backed by raylib, C++, and shaders and it’s fast.

For example, this animated noise demo:

800 × 600 = 480,000 pixels
Per pixel: 2 trig calls
That’s ~960,000 trig calls per frame <- very expensive

Unoptimized, it still clocks around 90 FPS.

Threaded, it jumps to about 200 FPS.

I’m also working on my own real-time profiler, shard.js, using the same renderer

All of this is possible because of one simple idea:

the framebuffer.

Once you understand that, everything clicks.

If you take a screen:

_______________
|             |
|             |
|             |   <- screen (it’s 2D)
|             |
|_____________|

and divide it into rows and columns:

|------------|
|------------|
|------------|
|------------|

     ^
     |
     imagine columns here

then unwrap it into rows only:

row 1      row 2      .... row n
--------  --------     --------
--------  --------     --------

You get an array.

But not a typical array.

It’s an array of bytes, contiguous memory; a raw chunk of memory called a buffer.

In Node.js, it looks like this:

const buf = Buffer.alloc(1024); // <- raw memory

Now take that buffer and fill it with numbers between 0 and 255, using this simple formula:

(y * width + x) * 4; // 4 channels: r, g, b, a

This maps screen coordinates (x, y) - with (0, 0) being the top-left of the screen, directly to this linear memory buffer.

What you get are pixels:

[ R, G, B, A, R, G, B, A, R, G, B, A, ... ]  // Linear array
  ˄                   ˄                   ˄
Pixel 0            Pixel 1            Pixel 2
(x=0,y=0)         (x=1,y=0)          (x=2,y=0)

Pixels give you an image.

Do that 60 times per second (FPS), or more, and you get an animated image.

That buffer is the framebuffer.

If you understand that, you now understand graphics programming 101.

So what does this have to do with Node.js and my renderer?

Thinking About Node.js

Here’s a rough mental model for Node.js:

average Node.js usage -> via JavaScript
 -------------------------------------
|                                    |
      v8 / bytecode
      whole world of C++

So the question becomes:

What if I put a buffer between the world of C++ and JavaScript?

Because that’s literally all you need to paint the screen.

This isn’t new, it’s a classic systems technique: shared memory.
And Node.js gives us exactly that:

const buf = new SharedArrayBuffer(size);

Threads use this all the time for zero-copy access. It’s blazingly fast, but also easy to mess up. Shared memory bugs can get nasty fast.

So I built a controlled version of that idea.

This is roughly how the core of tessera.js works.

How Tessera Works

import { PixelBuffer, loadRenderer } from "tessera.js"; // raw memory
const { Renderer, FULLSCREEN, RESIZABLE } = loadRenderer();

const renderer = new Renderer();
renderer.initialize(1920, 910, "Renderer");
const canvas = new PixelBuffer(renderer, 1200, 800);

Under the hood:

C++ creates two buffers (double buffering): a read buffer and a write buffer
The read buffer is what’s currently on screen
C++ creates a GPU texture and links it to that buffer
JavaScript requests the current read buffer (raw memory, insanely fast)

From there, JavaScript just writes pixels:

const data = canvas.data;
const tracker = new DirtyRegionTracker(canvas);

// random star-like noise (direct memory access)
for (let i = 0; i < 2000; i++) {
    const x = Math.floor(Math.random() * width);
    const y = Math.floor(Math.random() * height);
    const brightness = 100 + Math.random() * 155;
    const idx = (y * width + x) * 4;

    data[idx]     = brightness;
    data[idx + 1] = brightness;
    data[idx + 2] = brightness;
    data[idx + 3] = 255;

    tracker.mark(x, y);
}

Then you notify C++ only about what changed:

tracker.flush(); // send dirty regions only

And issue one cheap command to update the GPU texture:

canvas.upload(); // very cheap

The screen updates.

While JavaScript is mutating memory, C++ keeps rendering the last valid texture.
Both worlds run in tandem.

What makes this powerful is raw memory.

Raw memory is absurdly fast in Node.js. And because canvas.data is a SharedArrayBuffer, we can write to it from multiple threads.

canvas.data // SharedArrayBuffer

That’s how the animated noise example, which is insanely expensive, jumps from ~80 FPS to ~200 FPS when threaded.

You can check out the tessera.js repo for more examples and docs.

Below is a full, minimal demo you can run locally.

Demo

npm i tessera.js

Your js file:

import { loadRenderer, PixelBuffer, DirtyRegionTracker } from "tessera.js";

const { Renderer, RESIZABLE } = loadRenderer();
const renderer = new Renderer();

if (!renderer.initialize(1920, 910, "Renderer")) {
    console.error("Failed to initialize renderer");
    process.exit(1);
}

renderer.setWindowState(RESIZABLE);
renderer.targetFPS = 60;

const canvas = new PixelBuffer(renderer, 650, 400);
canvas.clear(1, 1, 1, 255);

const data = canvas.data;
const width = canvas.width;
const height = canvas.height;
const tracker = new DirtyRegionTracker(canvas);

// random star noise
for (let i = 0; i < 2000; i++) {
    const x = Math.floor(Math.random() * width);
    const y = Math.floor(Math.random() * height);
    const brightness = 100 + Math.random() * 155;
    const idx = (y * width + x) * 4;

    data[idx]     = brightness;
    data[idx + 1] = brightness;
    data[idx + 2] = brightness;
    data[idx + 3] = 255;

    tracker.mark(x, y);
}

tracker.flush();
canvas.upload();

renderer.onRender(() => {
    renderer.clear({ r: 0, g: 0, b: 0, a: 50 });
    canvas.draw(0, 0);

    renderer.drawText(
        `FPS: ${renderer.FPS} | Buffer: ${canvas.width}x${canvas.height} | Memory: ${(canvas.width * canvas.height * 4 / 1024).toFixed(1)}KB`,
        { x: 20, y: 750 },
        16,
        { r: 1, g: 1, b: 1, a: 1 }
    );
});

function Loop() {
    renderer.input.GetInput();

    if (renderer.step()) {
        setImmediate(Loop);
    } else {
        renderer.shutdown();
    }
}

Loop();

process.on("SIGINT", () => {
    console.log("\nshutting down gracefully...");
    renderer.shutdown();
    process.exit(0);
});

Here's an optimized version that maintains your casual, direct tone:

tessera.js repo

Thanks for reading!

Find me here:

X/Twitter
Substack ← devlogs, deep dives, and long-form content.

The Only Practical Data Structure you'll ever need?

Sk — Thu, 09 Oct 2025 09:00:00 +0000

You know that one JavaScript meme? Yeah; this one:

That’s exactly how a queue feels the longer you code, especially when you go low-level.
The craziest part? It’s the simplest data structure ever.

You can simulate one with an array as easily as:

// NOTE: not recommended, O(n) for shift
const queue = []
queue.push() // enqueue 
queue.shift() // dequeue

And here’s why this is wild: if you’re like me and started coding back in the ancient year of 2018, you remember how terrifying algorithms seemed.
I can’t count how many interviews I failed because I had no idea what “find the contiguous subarray (Kadane’s algorithm)” meant.

Fast forward a few years, and now?
A queue is what I throw at everything.

Not just me, literally the whole industry runs on queues.
Node.js? Queue.
MySQL driver? Queue.
RabbitMQ? I’ll stop before this turns into a sermon.

Point is; you’ll use queues. A lot. Even in production.
Yes, you will.

Things I’ve Used a Queue For

1. Buffering Real-Time Data

When working with real-time data, there’s always a producer and a consumer:

producer (usually server) ---> consumer (frontend)

Classic problem? Back pressure.
The producer sends data too fast, the consumer can’t keep up; it lags.
You can’t pause real-time data, so what do you do?

Yep; queue the data on the frontend. Classic move. I’ve used it tons of times.

producer (server) ---> queue ---> consumer (frontend)

2. Synchronizing Threads

Once, I built an immediate mode GUI (imgui) for Node.js.
Quick context; Node.js is single-threaded (one lane). So I had to spawn a separate libuv thread to simulate and render the GUI.

If you’ve worked with ImGui, you know it’s like a game loop. The GUI runs separately; you inject data, it draws each frame:

for (imgui()) {
   inject_state()
   render_gui()
   repeat()
} // not real code, just for illustration

Meaning: state and GUI live in separate worlds.
Some of my state lived in the Node.js thread, while the GUI rendered in the libuv thread.

I couldn’t just stop the running loop to sync them; so when you create an image element, it got buffered in a queue.
On the next tick, the loop pulled it and uploaded it to the GPU, caching it in a sparse set resource manager.

That part looked like this:

{
  std::lock_guard<std::mutex> lock(globalIPCData.textureLoadQueueMutex);
  while (!globalIPCData.textureLoadQueue.empty()) {
    auto &[key, path] = globalIPCData.textureLoadQueue.front();
    gTextures.LoadTexture(key, path);
    globalIPCData.textureLoadQueue.pop();
  }
}

The wild part? It was blazingly fast.

3. BunniMQ Driver - Pure JavaScript Message Broker

Here’s another one.
Think of a driver as a wrapper over a low-level I/O system, like a MySQL driver.

I/O is async by nature. MySQL makes requests over the network; you never know when (or if) you’ll get a response.
Drivers solve that by buffering operations in a queue, making async code feel sync.

That’s why you can write:

const db = mysql.connect(creds)
db.insert(doc)
db.update(id, doc)

Behind the scenes, each operation is queued. When one finishes, the next runs.
Without that queue, your code would look like this mess:

mysql.connect(creds).then(() => {
   db.insert(doc).then(() => {
      db.update(id, doc)
   })
})

See? The queue saves your sanity.

That’s exactly how I built bunniMQ and its driver, a pure JavaScript message broker built entirely on queues.
You can check it out if you’re curious.

And honestly, that’s not even half the times I’ve reached for a queue.
Node.js cluster syncing? Queue.
Breadth-first file system traversal? Queue.
Real-time audio ring buffers? Definitely a queue.

So yeah; if you’re not convinced yet, just remember: Node.js itself is one giant queue for I/O and async.

Queue in C++

The Standard Template Library (STL) makes queues just as simple:

#include <iostream>
#include <queue> // <- here
using namespace std;

int main() {
    // Declare a queue that holds integers
    queue<int> my_queue;

    // enqueue
    my_queue.push(101); // Packet #1 arrives
    my_queue.push(202); // Packet #2 arrives
    my_queue.push(303); // Packet #3 arrives

    cout << "Three packets added to the queue." << endl;

    // peek
    cout << "Next packet to process: " << my_queue.front() << endl; // 101

    // dequeue
    my_queue.pop();
    cout << "Processed the front packet." << endl;

    // now who’s next?
    cout << "Next packet is now: " << my_queue.front() << endl; // 202
}

Dead simple.

When in doubt; pull out the old trusty queue.
After all, most of the world already does.

DEV Community: Sk

I Tried Vibe Coding an Audio Streaming System in C++: Here Are the Results

Letting the Vibes Drive

The Real Cost: Reading Code

Where I Actually Landed

That’s it.

Final Thought

Building a Smooth 60fps Video Player in Node.js.

But… how is this even possible?

The Renderer

The Decoder

The Hard Part: Synchronization

The Core Problem: Time Drift

Approach 1 (naïve)

Approach 2 (correct)

The Fix: Absolute Time

Final Result

I'm Building a Game Engine in Node.js (Yes, Really)

Camera

Physics Engine

I Tried to Beat WebAssembly With Node.js

Wasm Is Insanely Fast

Setup

125k JS Objects vs Wasm

Results

Data-Oriented Design

Results

Throwing Threads at It

Results

Final Thoughts

Building A Binary Compiler For Node.js.

Why a Binary Compiler?

Building the Compiler

Utils and Setup

Serializing Keys

Supported Types (For Now)

Strings

Numbers

The Compiler

Running It

Building Single-Executable Node.js Apps (Without the Pain)

Why SEA actually matters

Example 1: Simple Script

Folder structure

index.js

cross-build.js

Example 2: tessera.js

Common Build Profiles

Profile usage

Building Crash-Tolerant Node.js Apps with Clusters.

The Kernel

Booting an App Inside Another App

This Pattern Is Everywhere

Node.js Can Do This Too

Clusters in Node.js

Evolutionary Algorithms, Rendered Live in Node.js

Finding the Target Color

Parameters and the Genome (the “species”)

The Core Evolution Algorithm

Tie Everything Together

Render Everything

The Loop

Building A Distributed Video Transcoding System with Node.js.

A Distributed Video Transcoding Example

.auth

server.js

producer.js

consumer.js

Graphics Programming 101 in Node.js (Yes, It’s Actually Possible).

Installation

Polygons → UI

Mouse Interaction

Particle System Example

Bring Them to Life

How I Built a Graphics Renderer for Node.js

Thinking About Node.js

How Tessera Works

Demo

The Only Practical Data Structure you'll ever need?

Things I’ve Used a Queue For

`index.js`

`cross-build.js`

Example 2: `tessera.js`

`.auth`

`server.js`

`producer.js`

`consumer.js`