DEV Community: Olu Desire

🕹️ The Reinvention Tax: Why We Ditched Pure Scratch for Epic.js (and You Should Too)

Olu Desire — Tue, 25 Aug 2026 00:31:39 +0000

How we tried to build a whole game engine out of stubbornness, and what the browser had to say about that.

📖 Introduction: The "We Can Build It" Syndrome

Every developer starts a project with a dangerous amount of confidence. The day we decided to build a custom HTML5 canvas arcade shooter, we walked into the room like champions — "no shaking, we go handle am." No pre-built modules, no shortcut libraries, no dependencies. Just us, a blank browser tab, and a keyboard doing overtime past midnight.

We genuinely thought hand-coding the physics, the enemy spawn logic, and the bullet arrays would be a calm weekend job. Instead, the CPU started shouting the moment two enemies appeared on screen at once. Frame rate dropped to single digits like it was on strike. Our code turned into spaghetti — and not the good kind you enjoy on a Sunday. It showed us pepper.

We were busy reinventing the wheel from zero, completely blind to the fact that a solid core engine — epic.js — was sitting right there, fully able to carry the heavy part of the matter for us.

This isn't just a "we failed, then we won" story, though. We're going to show you exactly why the naive version fell apart, line by line, and exactly what replaced it — so you can skip the three days we spent finding this out the hard way.

The one-line summary: We tried to build an arcade shooter entirely by hand, our browser humbled us in public, and switching to a pooled, delta-time-driven architecture on epic.js is the thing that actually saved the project.

🪤 Sector 1: Falling Into the "Pure Scratch" Trap

Every developer passes through that phase where using an existing framework feels like cheating. We want total control. We want to write every variable ourselves so we can beat our chest later and say "I built this from the ground, nobody helped me."

Our early object-tracking system was pure chaos. Instead of a clean entity manager, bullets went straight into a raw, unmanaged array that looped endlessly on the main thread:

// Our painful, hand-coded bullet loop
function updateBullets() {
  for (let i = 0; i < playerBullets.length; i++) {
    playerBullets[i].y -= 10; // manual coordinate tracking
    if (playerBullets[i].y < 0) {
      playerBullets.splice(i, 1);
      i--;
    }
  }
}

This loop worked fine when there was one lonely bullet on screen, moving like a snail with nowhere to be. But scale that up to a real arcade wave — lasers, particle sparks, three enemy formations descending at once — and the browser will very quickly show you pepper.

🧯 Sector 2: Why Our Hand-Coded Architecture Packed Up (The Actual Technical Reason)

It didn't take long for the DIY masterpiece to scatter completely. On a web canvas, performance is not a bonus feature — it's the entire difference between a smooth arcade game and a slideshow with extra steps.

Here's the part most devlogs skip: why exactly that loop was the problem, not just that it was slow.

Reason 1 — splice() inside a loop is quietly expensive. Every time splice(i, 1) removes a bullet, JavaScript has to shift every element after it one position to the left to close the gap. That's an O(n) operation, happening potentially dozens of times per frame, inside a loop that's already O(n). With 5 bullets on screen, you'd never notice. With 200 bullets, particles, and enemies all doing this every frame, you're paying that shifting cost constantly — this alone was a big chunk of our frame drop.

Reason 2 — we were creating and destroying objects every frame. Every new bullet was { x, y, ... } freshly allocated with push(), then thrown away with splice() a second later. JavaScript's garbage collector has to clean up after all that churn, and garbage collection pauses are exactly the kind of thing that shows up as a stutter, not a steady slowdown — which is why our frame rate wasn't just low, it was inconsistent.

Reason 3 — collision checks were brute-force. Every bullet was checked against every enemy, every frame — an O(n × m) comparison with no shortcuts. Ten bullets and ten enemies is 100 checks. Fine. Fifty bullets and thirty enemies is 1,500 checks, every single frame, on the main thread, alongside rendering.

Stacked together, here's roughly what that did to us on a mid-range laptop:

Scenario	Active bullets/particles	Frame rate
One bullet on screen	~1	60 FPS, smooth
A real wave (lasers + enemies + sparks)	~180	6–9 FPS
Same wave, boss fight	~350	Effectively frozen

Our custom approach failed for three structural reasons on top of the raw math:

Reason	What it actually looked like
CPU overload	Every bullet trajectory, boundary check, and collision box was computed manually on the main thread — the browser choked under the weight
Tightly coupled code	Game logic, rendering, and input listeners were tangled like cheap earphone wires — touch one variable, three unrelated features scatter
The "reinventing the wheel" tax	Three full days spent hand-writing collision logic that solid engine frameworks had already solved years ago

We were so busy trying to prove a point that we forgot the first rule of smart engineering: don't carry heavy load when a trailer is passing free of charge. Ego writes the first draft. Engineering rewrites it.

🚦 When to walk away from pure-scratch: if your frame rate dips below 30 FPS with fewer than 100 objects on screen, stop optimizing your hand-rolled version and start integrating an engine. That's the reinvention tax ceiling — past that point, you're paying in days what a framework already solved in years.

To be fair to our stubborn selves, though — building it wrong first wasn't pure waste. If your goal is learning how canvas internals actually work, keep going by hand, that struggle is the whole point. Just don't ship the hand-rolled version to production. Know which one you're doing before you start.

🔧 Sector 3: The Actual Fix — Object Pooling and Delta Time

Before we get to epic.js itself, we want to show the two changes that mattered most — because you can apply both of these in any canvas game, engine or no engine.

Fix 1 — Object pooling (stop creating and destroying bullets)

Instead of constantly allocating new bullet objects and throwing them away, we pre-allocate a fixed pool once, and just recycle inactive ones:

// A simple bullet pool — allocate once, reuse forever
const BULLET_POOL_SIZE = 200;
const bulletPool = Array.from({ length: BULLET_POOL_SIZE }, () => ({
  x: 0, y: 0, active: false
}));

function spawnBullet(x, y) {
  const bullet = bulletPool.find(b => !b.active);
  if (!bullet) return; // pool exhausted, skip spawn this frame
  bullet.x = x;
  bullet.y = y;
  bullet.active = true;
}

function updateBullets(deltaTime) {
  for (const bullet of bulletPool) {
    if (!bullet.active) continue;
    bullet.y -= 600 * deltaTime; // speed in px/sec, not px/frame
    if (bullet.y < 0) bullet.active = false; // recycle, don't destroy
  }
}

No splice(). No push(). No garbage collector chasing after us. We just flip a boolean. This one change took our bullet-heavy scenes from stuttering to steady on the same laptop.

Fix 2 — Delta time instead of fixed pixel steps

Our original loop moved bullets by a flat 10 pixels every frame — which means speed was secretly tied to frame rate. Drop to 30 FPS, and every bullet moves at half the speed it should, which makes a slow machine feel even more broken than it is.

let lastTime = performance.now();

function gameLoop(currentTime) {
  const deltaTime = (currentTime - lastTime) / 1000; // seconds since last frame
  lastTime = currentTime;

  updateBullets(deltaTime);
  render();

  requestAnimationFrame(gameLoop);
}

requestAnimationFrame(gameLoop);

With delta time, updateBullets always knows how much real time passed, so movement stays consistent whether the game is running at 60 FPS on a good laptop or 25 FPS on a tired one. Speed becomes pixels per second, not pixels per frame — a small change with a big effect on how "broken" a slow device feels.

Where epic.js comes in (and where it honestly doesn't)

Let's be precise here, because we don't want to overclaim what the engine hands you for free. Once our engine version was routed correctly:

if (versionDropdown) {
  let selectedVersion = versionDropdown.value.toLowerCase();
  if (selectedVersion.includes('v4')) {
    engineScriptFile = "https://limn-engine-doc.vercel.app/asset/epic.js";
  }
}

...here's what epic.js actually gave us, straight from the source:

A component system with built-in collision, so we stopped hand-writing AABB math. Every game object is a Component — you give it a width, height, position, and it comes with .crashWith(otherObject) for rectangle collision (with rotation support baked in) and .enableCircleCollision() / .crashWithCircle() if you'd rather check circles:

const bullet = new Component(4, 12, "yellow", playerX, playerY);
bullet.speedY = -10;
display.add(bullet);

// later, in your own update loop:
if (bullet.crashWith(enemy)) {
  bullet.destroy(); // removes it from the engine's render list for you
  enemy.destroy();
}

We didn't have to write crashWith() ourselves — that was three of our "reinvented the wheel" days, gone.

Automatic viewport culling, which is the real reason the frame rate recovered. Here's the part we didn't expect: the engine checks each component's Rect-like x property — which holds x, y, width, and height — against the game area bounds before doing any work on it:

if (TCJSgameGameArea.crashWith(component.x)) {
  component.x.update(display.context);
}

Off-screen bullets, particles, and enemies still exist in memory, but they stop costing us render and update time the moment they leave the visible area. That single check quietly did more for our frame rate than anything we'd hand-rolled ourselves — it wasn't pooling that saved us, it was the engine simply refusing to do work on things nobody could see.

What it does not give you for free: object pooling. This is the honest part. Objects go into a global list via display.add() and come back out via .destroy(), which does a findIndex + splice() under the hood — the exact same pattern we were trying to escape in Sector 1. Even the engine's own particle system creates and destroys particles this way. If you want true pooling — pre-allocating and recycling — that's still on you to build on top of Component, the same way we showed in the manual fix above.

Speed is still per-frame, not per-second, by default. move() applies this.x += this.speedX directly — no delta-time scaling built in. display.deltaTime is exposed for you to use in your own update() function, but the engine won't apply it for you automatically. So the delta-time discipline from the fix above still matters, even once you're on epic.js — the engine gives you the tools, not the guarantee.

Being honest about it: this wasn't instant magic. Wiring epic.js into a codebase that had spent three days being hand-rolled and tightly coupled meant untangling our own mess first — pulling rendering logic out of the input listeners it had no business living inside. The framework didn't fix our architecture. It gave us collision handling and free culling. Pooling and delta time discipline were still ours to get right.

So when do you actually switch?

We were three days in when we switched. That's not a universal number — here's a rougher rule of thumb than "just use an engine":

Your situation	What to do
Object count under ~50, frame rate is fine	Stay pure. You don't have a performance problem yet.
Object count over ~50, frame rate holds but you're hand-writing AABB/circle collision	Grab a collision-only library or a `crashWith()`-style utility — you don't need a full engine yet.
Object count over ~50 and frame rate is dropping and you're hand-writing collision	Grab the engine. You've hit both problems at once — that's the actual signal, not a fixed day count.
You're doing this specifically to learn canvas internals	Keep going by hand, on purpose — just don't ship that version.

The difference, in numbers

Version	Active bullets/particles	Frame rate
Original — `splice()`, no delta time, checking everything on-screen or not	~180	6–9 FPS
Manual fix — pooling + delta time, still checking everything	~180	48–55 FPS
On `epic.js` — built-in `crashWith()` + automatic viewport culling, our own pooling on top	~350	Steady 60 FPS

Same laptop, same scene, three different architectures. The lesson wasn't "epic.js is magic" — it's that pooling and delta time recovered most of the performance ourselves, and the engine's free viewport culling plus not having to hand-write collision math is what let us push the object count even higher on top of that.

🎓 Sector 4: Hard-Earned Lessons From the Trenches

Some lessons don't come from documentation. They come from watching your frame rate crawl at 1 AM and asking yourself hard questions.

Under-the-hood mechanics still matter. Writing those messy loops by hand taught us why canvas rendering contexts and coordinate grids behave the way they do. You genuinely have to break something manually at least once to understand how it ticks — the pain wasn't wasted, even if the code was.

Frameworks aren't cheating. Leaning on a solid core asset like epic.js isn't cutting corners — it's smart architecture. It frees up your mental bandwidth for the part that actually moves the needle: game design and how it feels to play.

Knowing when to pivot is a skill, not a defeat. Admitting your hand-coded system has become the bottleneck isn't failure — it's a checkpoint in engineering maturity. The stubborn version of us needed to hear that first.

📊 What You've Learned

Concept	How It Applies
`splice()` cost	Removing from the middle of an array shifts every element after it — expensive when it happens every frame
Object pooling	Recycle objects instead of creating/destroying them — cuts garbage collection stutter dramatically
Delta time	Move objects by `speed × secondsElapsed`, not a flat number per frame, so speed stays consistent across devices
Viewport culling	Skipping update/render work on objects outside the visible area can matter more than clever collision math
Read your dependency's source	We assumed `epic.js` did pooling for us — it doesn't. Checking the actual code saved us from shipping on a wrong assumption
The reinvention tax	Solving a problem a mature framework already solved costs days you don't get back

🚀 Conclusion & What's Next

Building an arcade shooter from scratch taught us humility, patience, and the real value of proper tool selection. Dropping the ego, ending the "pure scratch" marathon, and integrating epic.js is what saved this project from a very avoidable disaster.

Here's the receipts — the editor running the real V4 build, and the actual arcade wave rendering steady instead of crawling:

If you're currently hand-coding every single piece of your own engine, take a breath. Step back, look at your tools honestly, and let clean architecture carry some of the weight for you. And if you take nothing else from this, at least go add object pooling and delta time to whatever you're building right now.

🔗 Come Say Hi

🌐 Docs & assets: Limn Engine Vercel Assets
💬 Community & support: Join our Discord
📂 Source code: GitHub

Your turn: what's the thing you rebuilt from scratch before finally admitting a library already did it better? Drop it below. 🎮

Limn Engine — draw your game into existence. No shaking, no scattering, just clean architecture doing the heavy lifting for you. 🎨✨

🛠️ How We Upgraded the Limn Engine Playground Editor for Version 4

Olu Desire — Mon, 24 Aug 2026 23:09:40 +0000

One dropdown, one bug, and the afternoon we almost shipped it broken.

📖 Introduction

The Version 4 launch of Limn Engine had everything — a new particle system, audio management, a slick preview. What it didn't have was a way for the playground to actually find the damn file.

We'd already built epic.js — the new core script with particle systems and audio management baked in. That part felt great. That part felt like progress, like something to post about. But none of it mattered if the playground editor couldn't even find it. A developer could select "Version 4" from the menu, hit run, cross their fingers... and the preview would just keep loading the old engine. No error. No warning. Just the wrong file, running like nothing happened. Very smooth criminal behaviour from our own code.

That's the kind of bug that scares us more than any crash — the one where nothing looks broken, so you almost sign off on it and go rest.

This is the story of how we fixed it, what we got wrong the first time, and what's still genuinely unfinished about it — because pretending otherwise would defeat the point of writing this at all.

The one-line summary: We upgraded the Limn Engine playground editor to detect and load Version 4 — and learned the hard way that "it works for us" and "it works" are not the same thing.

🔍 The Problem Nobody Would Notice Until It Was Too Late

The playground editor doesn't ask any server which engine version you want — no config file, no manifest, no backend deciding for you. It simply looks at the page, finds a <select> element, reads whatever text is sitting inside it, and tries to match that text to a script. That's the whole idea. Fast, simple, zero dependencies.

But that convenience comes with a price. If the scanner doesn't recognize a version string, it doesn't shout — it doesn't crash. It just quietly keeps whatever it last loaded, which is exactly how we almost shipped V4 broken. We selected it, hit run, saw the canvas render... and only after staring longer than we'd like to admit did we realize it was the old engine playing dress-up as the new one. Nobody would've known unless they checked very carefully.

What this taught us: the bugs that don't announce themselves are the ones that reach production. We started treating a suspiciously calm preview as a warning, not a relief.

🧵 Teaching the Scanner to See V4

Here's the loop that walks the dropdowns on the page — the actual fix, straight from the runn() function that powers the "Run" button:

let engineScriptFile = "epic.js";
let allDropdowns = document.querySelectorAll('select');
let versionDropdown = null;

for (let select of allDropdowns) {
    let text = select.textContent.toUpperCase();

    // Updated search check to recognize V2, V3, and V4
    if (text.includes('V2') || text.includes('V3') || text.includes('V4') || select.value.toUpperCase().includes('V')) {
        versionDropdown = select;
        break;
    }
}

Before we touched it, that condition stopped politely at V3, like V4 never existed. Every dropdown labeled "Version 4" was invisible to the scanner — not broken, not flagged, just completely skipped.

Adding V4 to that condition was one line. Finding out it was missing took an entire evening, because our first assumption was that the routing was wrong — not that the dropdown was never being found in the first place.

Future-proofing note we haven't shipped yet: hardcoding each version string like this means every new release needs another || clause. A cleaner version — worth doing before V5 — is a simple array:

const VERSIONS = ['V2', 'V3', 'V4', 'V5'];
if (VERSIONS.some(v => text.includes(v)) ||
    select.value.toUpperCase().includes('V')) {
  versionDropdown = select;
}

Still on the todo list. Mentioning it here so future-us can't pretend we didn't know.

🎯 Routing the Version to the Right File

Once the scanner can actually see the dropdown, something decides which script file to load:

if (versionDropdown) {
    let selectedVersion = versionDropdown.value.toLowerCase();

    if (selectedVersion.includes('v2')) {
        engineScriptFile = "tcjsgame-v2.js";
    } else if (selectedVersion.includes('v3')) {
        engineScriptFile = "tcjsgame-v3.js";
    } else if (selectedVersion.includes('v4')) {
        engineScriptFile = "epic.js";
    }
}

Notice engineScriptFile starts life as "epic.js" before this block even runs — so if no dropdown is found at all, or nothing matches, the playground defaults to V4 anyway rather than falling back to an older version. That's not fallback logic. That's a variable we forgot to reset, quietly doing the right thing by pure accident — the coding equivalent of surviving a disaster because you happened to fall asleep in the safest corner of the room.

What this taught us: sometimes your "fallback behavior" isn't something you designed — it's whatever your default variable happens to be. Worth checking that it's the safe default, not just a default, before you accidentally get credit for engineering discipline you didn't actually apply.

🖼️ The Part the Article Almost Skipped: What Actually Happens on "Run"

Once the right script file is picked, here's what the rest of runn() actually does — and it's more interesting than just "load a script tag":

It checks if you're not even using the engine at all. Before any of the version-routing logic runs, the function checks whether your editor code looks like raw HTML:

let hasHtmlTags = /<[a-z][\s\S]*>/i.test(userEditorCode) || userEditorCode.includes('<!DOCTYPE');

if (hasHtmlTags && iframe) {
    iframe.srcdoc = userEditorCode;
    return;
}

If you paste a full HTML document into the editor, the playground doesn't fight you about it. It just shrugs, decides "ah, you don craft your own thing," and runs your raw HTML straight through — like a landlord who stops asking questions the moment rent shows up on time. No engine, no version dropdown, no opinions. We hadn't thought to mention this branch in earlier drafts, but it's real, and a reader who hits it without knowing it's there will absolutely think something is broken.

Console output gets piped from the sandboxed iframe back to the editor UI. The generated preview document overrides console.log so that anything the user's game code logs shows up in a console panel in the parent editor, not just buried in the iframe's own devtools:

const _customLog = console.log;
console.log = function(...args) {
    _customLog.apply(console, args);
    const joinedArgs = args.map(arg =>
        typeof arg === 'object' ? JSON.stringify(arg) : arg
    ).join(' ');

    if (window.parent && window.parent.document) {
        const consoleDisplay = window.parent.document.getElementById('editor-console-logs');
        if (consoleDisplay) {
            const line = window.parent.document.createElement('div');
            line.textContent = joinedArgs;
            consoleDisplay.appendChild(line);
            consoleDisplay.scrollTop = consoleDisplay.scrollHeight;
        }
    }
};

That's genuinely a nice touch for a browser playground. Your console.log doesn't stay trapped in iframe jail — it climbs the fence, walks over to the parent window, and reports what it saw like a very well-behaved snitch.

Runtime errors get caught and reported automatically. If the user's code throws, the playground catches it and posts the error message to a webhook so we can see what's breaking for real users without waiting for a bug report:

try {
    ${userEditorCode}
} catch(err) {
    console.log("Engine Runtime Error: " + err.message);
    // error message dispatched to an internal alerts channel
}

We're intentionally not showing the actual webhook wiring here — it's a plain fetch call with a URL baked in, and an earlier draft of this article almost pasted that URL straight into the code block. We caught it before publishing, but only just. Publishing your own alert webhook URL in a public tutorial is the developer equivalent of posting a photo of your house key on Twitter with the caption "come design my kitchen." So: fixing that properly (move it behind a real backend endpoint instead of calling a webhook straight from client-side code) is next on the list, and until it's done, the URL stays out of anything we publish. Worth remembering if you're building something similar: a "just post to Discord" error reporter is fine for a personal project, but the moment the code that contains the URL is public — like, say, in a blog post — the URL is public too.

✅ The One We Actually Went Back and Fixed

Talk is cheap, so before publishing this version, we went and closed the loudest gap: the missing timeout. Here's what actually shipped.

First, the script tag inside the generated iframe gets an id and real onload/onerror handlers, plus a timeout in case the browser never fires either event:

<script id="engineScript" src="./${engineScriptFile}"></script>
<script>
    const ENGINE_LOAD_TIMEOUT_MS = 5000;

    const engineTimeout = setTimeout(() => {
        reportEngineLoadFailure('Engine timed out after 5s — check your connection or the script URL.');
    }, ENGINE_LOAD_TIMEOUT_MS);

    const engineScriptTag = document.getElementById('engineScript');

    engineScriptTag.onload = () => {
        clearTimeout(engineTimeout);
    };

    engineScriptTag.onerror = () => {
        clearTimeout(engineTimeout);
        reportEngineLoadFailure('Engine script failed to load — 404, CDN issue, or bad URL.');
    };

    function reportEngineLoadFailure(message) {
        if (window.parent && window.parent.document) {
            const banner = window.parent.document.getElementById('engine-error-banner');
            if (banner) {
                banner.textContent = "⚠️ " + message;
                banner.style.display = 'block';
            }
        }
    }
</script>

Second, runn() itself resets the banner at the start of every run, so a stale error from three runs ago doesn't sit there haunting someone who already fixed the problem:

let errorBanner = document.getElementById('engine-error-banner');
if (errorBanner) {
    errorBanner.style.display = 'none';
    errorBanner.textContent = '';
}

Same trick as the console piping from earlier — the sandboxed iframe reaches out to window.parent.document to update a banner that lives in the actual editor UI, not buried where nobody will see it.

Is this everything? No — the dropdown-renaming gap and the "which engine actually loaded" confirmation are both still open, and we're not going to pretend otherwise twice in one post. But this is the difference between a paragraph promising a fix and a code block that is the fix. One down.

🩹 What's Still Actually Missing

Here's the part we got wrong last time we wrote about this: we described hardening we hadn't actually built yet — a load timeout, an error banner, a fallback config object. Only the first two of those existed only as a paragraph back then. We fixed the timeout and banner for real, above. The rest still doesn't exist, and we're not going to pretend it does.

What the current runn() function still does not handle, as far as we can tell from the code itself:

Gap	Current reality
Dropdown label gets renamed without updating the matching logic	Still pure string matching, no fallback config object. If someone changes "Version 4" to something the scanner doesn't recognize, we're back to square one.
Confirming which engine actually loaded	The console piping shows game output, not engine version. There's no `console.log` confirming "epic.js (v4) loaded" anywhere in the real code — the new banner only fires on failure, not on success.

One honest caveat: we're describing the script-loading path specifically, not every corner of the editor — there's still some iframe styling elsewhere in runn() we haven't traced all the way through. If something down that path already touches error handling in a way we missed, consider this table mostly right instead of fully right. We'd rather flag the uncertainty than state it with false confidence.

Two down from three. All of them are still worth naming, which is a more honest place to leave this post than claiming they're all done.

🔁 What If V4 Just... Doesn't Work?

If epic.js fails to load or throws early, there's currently no automatic fallback to V3 — the developer has to manually reselect it from the dropdown. Combined with the missing timeout above, a broken V4 load can currently look identical to "the playground is just loading forever," with no clear signal to the user about what's actually wrong.

🗣️ Honesty About the Trade-offs

String-matching a dropdown label is not how a "serious" IDE would do this. Bigger tools use config manifests, package registries, versioned APIs — systems that don't fall apart just because someone renamed a label without checking the routing logic.

We know. We built it this way anyway, because Limn Engine is still small enough that a full config system would be more machinery than the actual problem deserves — for now. But we won't pretend the trade-off isn't there. If this editor grows past what it is today, string-matching is the first thing on the list to retire — right alongside the webhook that needs to move server-side.

What this taught us: "good enough for now" is a real engineering decision, not laziness in disguise — as long as you say it out loud instead of hiding it in the commit message. And "we fixed it" should mean the code changed, not just that we wrote a paragraph saying it did.

📊 What You've Learned

Concept	How It Applies
Silent failure	A missing condition doesn't crash — it quietly does the wrong thing
Default values as accidental fallbacks	Check whether your variable's default is actually the safe choice, not just a choice
Secrets in client-side code	Anything a browser can fetch, a reader can copy — webhook URLs and API keys don't belong in code that ships to the client
Write down what's still broken	A devlog that only shows the fix and skips the gaps isn't more impressive, it's just less useful

🚀 Final Thoughts

The routing fix that shipped was one line of code. Writing honestly about everything around that line — the parts that still don't work — took a lot longer, and mattered more.

If you're building anything that reads the DOM to make a decision — a dropdown, a data attribute, a class name — assume it will fail quietly before it ever fails loudly. And if you're going to write about your own fix, resist describing the version of it you meant to build instead of the one that's actually running.

Draw your game into existence — and make sure your dropdown knows which version to use. We're still working on the rest.

🔗 Come Say Hi

🌐 Try Limn Engine live (Version 4): limn-engine-doc.vercel.app
💻 Source & issues: GitHub
💬 Join the community: Discord

Your turn: what's your most embarrassing version-mismatch bug? Drop it in the comments — we promise ours isn't the worst one out there. 🎮