DEV Community: Antonio

I broke an Elementor site on purpose, then built a tool to find the bugs

Antonio — Tue, 20 Oct 2026 21:22:10 +0000

The night I broke my own site

I'm 53, I work in a factory, and in the evenings I build things in vanilla JavaScript.

Lately I've been looking at freelance WordPress jobs. Almost every one of them says the same thing: "Elementor site, layout is broken, fix it."

So I did something a bit crazy. I took an empty test site, installed Elementor, and asked an AI to break it for me — 5 hidden CSS bugs, packed into an encoded script so I couldn't just read the answer.

Then I tried to find them.

It was humbling. The page looked wrong, but the console said nothing. Of course: CSS doesn't throw errors. A bad rule is still a valid rule, so the browser applies it silently. That's exactly why clients say "everything moved and I don't know why."

I found the first bug the slow way — DevTools, Styles panel, unchecking rules one by one until I saw it:

.elementor-section, .e-con { margin-right: -60px !important; }

Twenty minutes for one line. I thought: there must be a faster way.

So I built one: CSS hunt

🐞 BeeLadybug is my zero-dependency debugging overlay. You paste one line in the console and it attaches to any page — WordPress dashboards, Elementor pages, mobile viewports. It already showed element size, classes, display type, FPS and memory.

Version 0.5 adds a new mode: CSS hunt (press F6).

When you hover an element, it tells you what's wrong with it:

!important rules that match the element, and where they come from (<style> inline or the stylesheet URL)
Overflow causes: which element actually leaves the viewport, plus negative margins
Invisible text: color: transparent, opacity: 0, or text the same color as its background
Click blockers: what sits on top of the element's center, including fixed ::before / ::after on html / body
Stretched images: natural ratio vs rendered ratio, when object-fit is fill

Press S to scan the whole page. Click a line and the element gets a red outline.

The hard part: telling the truth without noise

My first version was technically right and practically useless.

One card overflowing the screen produced ten red lines: the card, its article, its p, its h2… All "overflowing", because they inherited it. A fixed overlay blocking clicks? One warning per element underneath it.

A real developer doesn't want ten alarms. They want the culprit.

So the scan now:

Reports the cause, not the containers. An ancestor is skipped if a descendant overflows by the same amount (±2px).
Groups by cause. Instead of 12 lines you get:

▾ body::after blocks clicks on 12 elements
    div.elementor-element-629ef32
    img#1301
    summary.elementor-element-3925463
    …

Separates bugs from info. Red = bug. Grey = info, like unreadable sheet: fonts.googleapis.com (cross-origin stylesheets can't be read — that's a browser rule, not a problem on the page).
Keeps the log calm. Hover and DOM-mutation lines are hidden unless you turn on verbose mode (F3). Each issue is logged once per element every 5 seconds. Press P to pin the panel on an element and read it in peace.

The real test

The demo page bugs are easy — I wrote them. The real test was the broken Elementor page, with Elementor V4 "atomic" widgets, Google Fonts, Altervista ad scripts and all the usual mess.

Result: CSS hunt found the click blocker, the negative margin overflow, the invisible button text and the stretched image on a live page I didn't build the bugs for.

Try it

Open any page, press F12, paste this in the console:

import('https://cdn.jsdelivr.net/npm/bee-ladybug@0.5.3/src/index.js')
  .then(({ BeeLadybugCore, WebDOMAdapter, CSSAdapter }) => {
    const bee = new BeeLadybugCore();
    new WebDOMAdapter(bee, { root: document.body }).attach();
    new CSSAdapter(bee).attach();
    window.bee = bee;
  });

Then press F6, hover, and press S.

No build step, no framework, no dependencies. Just vanilla JavaScript.

What I learned

CSS bugs are silent. The console won't help you. You need to look at computed styles and geometry.
The right answer is not enough. A debugging tool must point to the cause, or it's just another wall of text.
Breaking things on purpose is the best teacher. I recommend it to anyone who wants to do WordPress fixes for clients.

I'm still learning. If you try CSS hunt on a broken page and it misses something, tell me in the comments — that's how the next version gets better.

🐞 npm: bee-ladybug

Nove classi per un pulsante: la mia piccola UI per canvas (e perché le voglio bene)

Antonio — Thu, 15 Oct 2026 21:13:44 +0000

Volevo un pulsante "Play" sul canvas del mio motore di gioco 2D.
Un pulsante. Uno.

Poi ho aperto il file e ho trovato questo:

import {
    BeeUI,
    BeeControl,
    BeePanel,
    BeeStack,
    BeeLabel,
    BeeUIButton,
    BEE_ANCHOR,
    BEE_UI_DEFAULTS,
    drawNineSlice
} from './src/ui/BeeUI.js';

Nove import per un menu di pausa. Ho riso anch'io. Poi ho capito che ognuno di quei nomi ha un motivo per esistere, e alla fine sono diventati la parte del motore che preferisco. Ve li presento uno per uno, con la serietà che si meritano (poca, ma sufficiente).

Il problema: il canvas non sa cos'è un pulsante

Il canvas HTML5 è un foglio bianco con i pixel. Non ha layout, non ha focus, non sa che il tuo menu dovrebbe restare centrato quando la finestra cambia dimensione. Tutto quello che il DOM ti regala gratis, sul canvas te lo devi costruire.

Quindi sì, servono un po' di classi.

BeeControl: il nonno di tutti

BeeControl è il nodo base. Non disegna niente (il suo draw() è letteralmente vuoto), ma sa fare le cose noiose e importanti:

tenere una lista di figli e un genitore (con campi privati #parent e #children, così nessuno li tocca a mano);
calcolare il proprio rettangolo a partire da ancore e offset;
capire se il mouse ci sta sopra con hit(x, y), partendo dall'ultimo figlio, cioè quello disegnato sopra.

Le ancore sono valori da 0 a 1 rispetto al genitore. Il conto è tutto qui:

const x = parentRect.x + parentRect.w * this.anchorLeft + this.offsetLeft;
const w = parentRect.w * (this.anchorRight - this.anchorLeft)
        + (this.offsetRight - this.offsetLeft);

Ancore uguali a sinistra e destra danno una larghezza fissa. Ancore diverse fanno allargare l'elemento insieme al genitore. Chi ha usato Godot riconoscerà il trucco, e non mi vergogno di averlo copiato.

BEE_ANCHOR: perché nessuno vuole scrivere `setAnchors(1, 1, 1, 1)`

Ricordarsi i numeri delle ancore è un incubo, quindi ci sono dei preset:

BEE_ANCHOR.TOP_LEFT, TOP, TOP_RIGHT,
LEFT, CENTER, RIGHT,
BOTTOM_LEFT, BOTTOM, BOTTOM_RIGHT,
FULL

Vuoi il punteggio in alto a destra con 16 pixel di margine?

new BeeLabel({ text: 'Score: 0', anchor: BEE_ANCHOR.TOP_RIGHT, x: 16, y: 16, width: 160 });

Ridimensioni la finestra e resta lì. Magia? No, sottrazioni.

BEE_UI_DEFAULTS: le decisioni che non voglio prendere ogni volta

{ gap: 8, padding: 12, buttonWidth: 220, buttonHeight: 44 }

È un oggetto congelato con Object.freeze. Quattro numeri, zero discussioni. 44 pixel di altezza perché è una misura comoda da toccare col dito.

BeePanel: un rettangolo con ambizioni

BeePanel è un controllo che finalmente disegna qualcosa: colore di sfondo, bordo, angoli arrotondati (se il browser supporta roundRect) oppure un'immagine. E se gli passi anche slice, usa…

drawNineSlice: l'eroe silenzioso

Hai una cornice da 48×48 pixel e vuoi un pannello da 400×300 senza che gli angoli si deformino. La tecnica nine-slice taglia l'immagine in 9 pezzi: i 4 angoli restano fissi, i bordi si allungano in una sola direzione e il centro si allunga in tutte e due.

new BeePanel({
    anchor: BEE_ANCHOR.CENTER,
    width: 400, height: 300,
    image: frameImage,
    slice: { left: 12, top: 12, right: 12, bottom: 12 }
});

Nove chiamate a drawImage e il tuo menu sembra uscito da un gioco vero.

BeeStack: il flexbox dei poveri (e mi basta)

Mettere i pulsanti uno sotto l'altro calcolando le y a mano è il modo migliore per odiare la gamedev. BeeStack lo fa per te, in verticale ('v') o in orizzontale ('h'):

measure() somma le dimensioni dei figli visibili, più spazi e margini interni;
layout() li posiziona uno dopo l'altro;
se è ancorato al centro, si ricentra da solo in base alla dimensione calcolata.

BeeLabel e BeeUIButton: finalmente quello che volevo

BeeLabel scrive del testo. Fine. BeeUIButton è il pulsante vero: ha stati diversi per mouse sopra, premuto, disabilitato e focus, e si attiva al rilascio del mouse solo se sei ancora sopra al pulsante, esattamente come un pulsante del browser. Se ti penti a metà click, trascini fuori e non succede niente.

BeeUI: il capo

BeeUI è la radice dell'albero. Occupa tutto il canvas e a ogni frame:

ricalcola il layout solo se qualcosa è cambiato (c'è un flag #dirty);
gestisce hover e click del mouse;
gestisce la tastiera: Tab e Shift+Tab, frecce o WASD, Invio e Spazio;
gestisce il gamepad: croce direzionale e tasto A.

La parte che mi piace di più è focusToward(dx, dy). Quando premi "giù", non va semplicemente al pulsante successivo nella lista: cerca il controllo più vicino in quella direzione, penalizzando quelli troppo spostati di lato. Funziona anche con griglie di pulsanti, non solo con le liste.

Inoltre blocca il comportamento normale del Tab sul canvas, così il focus non scappa nella barra degli indirizzi a metà partita.

Un menu di pausa completo

const ui = new BeeUI({ canvas });

const menu = ui.add(new BeeStack({ anchor: BEE_ANCHOR.CENTER, background: '#0f172acc', radius: 12 }));
menu.add(new BeeLabel({ text: 'PAUSA', align: 'center', font: 'bold 24px monospace' }));
menu.add(new BeeUIButton({ text: 'Riprendi', onClick: () => game.resume() }));
menu.add(new BeeUIButton({ text: 'Opzioni',  onClick: () => openOptions() }));
menu.add(new BeeUIButton({ text: 'Esci',     onClick: () => game.quit() }));
ui.focusAt(0);

// nel game loop
ui.update(input);
ui.draw(ctx);

Centrato, navigabile con mouse, tastiera e gamepad, e resta al suo posto quando ridimensioni la finestra. Il tutto in circa 700 righe senza dipendenze.

Quindi, nove classi erano troppe?

Probabilmente sì, per un pulsante.
Per un pulsante che si centra da solo, si allarga, si naviga col joystick e non si rompe quando giri il telefono, no.

E la prossima volta che qualcuno mi chiede "perché non usi semplicemente un <button> sopra il canvas?", gli mando questo articolo e vado a giocare.

I'm 53, I build a JS game engine, and the bots think I'm fresh meat

Antonio — Mon, 12 Oct 2026 18:12:55 +0000

Someone told me that if bots keep landing on my articles, it means I'm "fresh content" for them.

I'm 53. I've spent my life working in a warehouse and on machines. The only fresh thing around here is my patience, and it's leaving fast.

In my part of Italy we have a saying for situations like this: "Le mazzate ci vo!" Roughly: what this needs is a good beating. Here's why I've been saying it a lot lately.

The illusion of numbers

I build BeeEngine, a zero-dependency 2D game engine in vanilla JavaScript, and I write docs and posts about it.

So I open my analytics and think: wow, 100 visits from California, 50 from New York!

Then I dig a little. Zero-second sessions. Datacenter cities like Ashburn and Mountain View. Not a single human being. Just machines talking to machines.

Then came the comments

This week two comments showed up under my posts. Long, polite, full of words like "double-buffered draw lists", "GPU batching", "ECS queries".

Sounds smart. Except my engine is single-threaded Canvas 2D: there is no GPU batch and no ECS to query. The comments were answering a post I didn't write.

The pattern was always the same:

a random username, like ywnigcsmku2m
an account created a few days earlier, with a bio that says "404 bio not found"
comments on a dozen unrelated articles on the same day, in several languages
and, at the very end, a small "(site: ...)" with a link

That last line is the whole point. Everything else is packaging.

A few hours later I found my own article copied on an aggregator site, wrapped in a "create an account" popup.

Not all bots are the same

To be fair, a bot is just a script doing a repetitive job faster than any human. They come in different flavors:

The useful ones. Googlebot, Bingbot. They read your HTML, follow links and tell search engines your page exists. Without them nobody finds you.

The collectors. AI crawlers and scrapers. They harvest code, docs and tutorials to train models or to build mirror sites that catch traffic on the side.

The spammers. Fake profiles that use AI to write plausible technical comments and plant a link, hoping someone clicks or that search engines pass them some authority.

Why us?

At first I thought: they're targeting me, maybe because I'm small and not "authoritative".

No. They don't pick anyone. They follow fresh, well-indexed content with technical tags: javascript, gamedev, canvas, webdev. A post about sprite sheets or particle pools is exactly what they're looking for.

So, strangely, bots showing up is a side effect of being visible. It doesn't feel like a compliment, though.

What I actually want

I don't need 500 fake sessions. I need:

people who actually try the library
a star or a real issue on GitHub
honest feedback from someone building an HTML5 game

Ghost traffic just dirties the stats and makes it harder to know if things are going well.

What I do now

Don't click the links in suspicious comments.
Check the profile: brand-new account, random name, comments everywhere on the same day.
Report it on DEV (the three dots on the comment, then "Report abuse") and hide the comment on your own post.
Don't reply to bots. Do reply to real people, they're the reason you write.
Filter analytics by excluding datacenter traffic and zero-second sessions before celebrating any spike.
Set a canonical URL on cross-posted articles, so search engines know which copy is the original.

Conclusion

As long as we publish openly on the web, bots will be around. We can't give them the beating they deserve, so we unmask them one comment at a time and keep writing real code for real humans.

Le mazzate ci vo!

Have you had fake comments or ghost traffic on your posts? How do you deal with them? Real humans only in the comments, please. 😄

An inventory plugin that never lies: transactional add, equip and use in a vanilla JS 2D engine

Antonio — Sat, 10 Oct 2026 16:50:02 +0000

Every 2D game ends up with an inventory. And almost every first inventory looks the same: an items[] array living in the scene, a few push calls, and a growing pile of if statements around it.

It works, until it doesn't. The bag is full and the potion silently disappears. An equip fails halfway and the sword is now in neither the slot nor the hand. A use callback throws and you've already removed the item.

I maintain a small vanilla JavaScript 2D engine for HTML5 Canvas (BeeEngine JS), and for version 2.10.0 I added an inventory. Here's how I designed it so it can't end up in those states.

Rule zero: plugins don't own the loop

Before the inventory, I built a tiny plugin registry (2.9.0). The engine does not import plugins. A plugin has attach / detach, and the engine exposes registerPlugin / unregisterPlugin. If a plugin really needs a frame, it uses engine.onTick(fn). It never calls loop() and never overrides update.

The first plugin was a localization helper, BeeLocale: read-only, with a fallback language, and missing keys return the key itself instead of an empty string. The inventory is the second plugin, built on the same pattern:

it registers itself as inventory
it has no onTick
it doesn't draw anything

The scene decides how to show it. The inventory only keeps state honest.

The API in one snippet

import { BeeEngine } from 'beeengine';
import { BeeInventory } from 'beeengine/plugins';

const game = new BeeEngine('testCanvas', 800, 600);

const inventory = new BeeInventory({
  slots: 1,
  equipSlots: ['hand'],
  engine: game
});

inventory.defineItem('potion', {
  name: 'Potion',
  maxStack: 5,
  consumable: true,
  onUse: () => true
});

const drop = inventory.add('potion', 8); // { added: 5, left: 3 }
inventory.use(0, null);

One slot, a stack limit of 5, and we try to add 8. The result isn't true or false: it's { added: 5, left: 3 }.

`add` always tells you what didn't fit

add fills existing stacks first, then empty slots. If there's no room left, it doesn't throw the extra items away. It returns them as left.

This sounds small, but it moves the decision to where it belongs. The inventory doesn't know whether the leftover potions should stay on the ground, go to a chest, or show a "Bag full" message. The game does. So the inventory just reports the truth and lets the scene decide.

remove works the other way around, from the last slot back to the first, so the stacks you filled first stay intact.

All or nothing: `move`, `equip`, `unequip`

These three either succeed completely or leave the state exactly as it was. No half-moved stacks, no item that vanished between the bag and the hand.

The idea is simple: check everything first, change things only when you know the whole operation can finish.

`use` with a rollback

use is the tricky one, because it runs user code: the item's onUse.

The rules:

a piece is removed only if onUse doesn't throw and doesn't return false
if onUse returns false, nothing is consumed (for example "you're already at full health")
if onUse throws, the error is not swallowed: it propagates to the caller, and the inventory is restored to a snapshot taken before the call

I didn't want to hide bugs in game code with a silent try/catch. But I also didn't want a broken callback to leave the inventory corrupted. The snapshot gives you both: the error is loud, and the state stays clean.

Copies out, plain data in

get, list and equipped return copies. Code outside can't mutate the inventory by accident by editing an object it got back.

toJSON saves only slots and equipment. Item definitions (names, stack limits, onUse functions) stay in code, where they belong. A save file never contains functions, and changing an item's behaviour in an update doesn't require migrating old saves.

Two plugins, zero coupling

The demo drops coins and gems from the top of the screen. When the collector catches one, onCollect calls inventory.add. The counters on screen use locale.t(), and pressing L switches language.

The interesting part is what's not there: BeeInventory and BeeLocale don't import each other. The only thing that connects them is the scene. When the bag is full, the scene can read left and decide what to show, like a "Bag full" message.

Tests

A plain Node script:

node scripts/test-beeinventory.mjs
# BeeInventory tests ok

TypeScript types (BeeItemDef, BeeInventoryOptions, BeeInventory implements BeePlugin) ship in index.d.ts, and npm run typecheck passes.

And the engine core (BeeEngine.js) wasn't touched at all. That was the whole point of the plugin contract.

Why 2.10.0 and not 2.9.7

It's a new export, not a fix. Semver minor bump, even if it's "just" a plugin.

What's next

One plugin at a time: post-processing effects (fade, flash, shake) are next, then dialogue, which can reuse BeeLocale for its strings.

If you've built inventories before, I'm curious: do you return leftovers, or do you reject the whole add when it doesn't fit?

npm: beeengine
Docs: beeenginejs.com
GitHub: BeeEngine

I replaced our warehouse paper inventory with one HTML file

Antonio — Thu, 08 Oct 2026 19:17:53 +0000

At work, inventory day looks the same every time. We walk around the warehouse with printed sheets and pens: wood panels, aluminium profiles, glass and laminates, hundreds of entries. We write numbers in the margins and cross things out. A few weeks later at least one sheet has gone missing.

I'm not a professional app developer. I build a 2D game engine in JavaScript as a hobby. One evening I thought: I can't build an inventory system for the company, but I can build one for myself.

This post covers what I built, how it works, and what I'd do differently. Spoiler: there are better tools out there. This one exists because it solved my problem in one evening.

The goal

It opens on my phone, even with no signal in the warehouse.
Finding an item takes two letters, not scrolling through 300 rows.
Big + and − buttons I can use with one hand.
Nothing to install, no server, no database, no login.
At the end I can export everything to Excel.
It's private: nobody needs to know it exists.

The architecture

It's one index.html file with inline CSS and JavaScript. That's the whole thing.

The catalogue (item codes and descriptions) is a JavaScript array embedded in the file.
The quantities are saved in localStorage on the phone.
Hosting is a folder with a random name on a site I already had, with a noindex meta tag.

<meta name="robots" content="noindex, nofollow">

Even if someone found the URL, they would only see an empty app. The counts live on my phone, not on the server.

Getting the data in

The most boring part was the catalogue itself: several pages of printed tables, some photographed upside down, plus a scanned PDF. I gave the photos to an AI assistant, which transcribed them into plain text, one line per item:

2|Line A|AL-001|White Matt
2|Line A|AL-002|Light Grey
3|Line B|AL-101|Bronze Brushed

A tiny script turns that into the array that goes inside the HTML:

const CATALOGUE = [
  { c: 2, l: 'Line A', k: 'AL-001', d: 'White Matt' },
  { c: 2, l: 'Line A', k: 'AL-002', d: 'Light Grey' },
  // ...
];

(The codes above are made up. The real ones belong to our suppliers.)

The core: search plus counters

Search matches every word you type against the code, description and line, ignoring accents:

const norm = (s) => String(s).toLowerCase()
  .normalize('NFD').replace(/[\u0300-\u036f]/g, '');

const words = norm(query).split(/\s+/).filter(Boolean);
const visible = items.filter((i) =>
  words.every((w) => norm(`${i.k} ${i.d} ${i.l}`).includes(w))
);

Typing grey matt finds "Light Grey Matt" whatever order the words are in.

Each row has a minus button, a number field and a plus button. One click listener on the list handles all of them:

list.addEventListener('click', (e) => {
  const btn = e.target.closest('[data-a]');
  if (!btn) return;
  const key = btn.closest('.card').dataset.k;
  qty[key] = Math.max(0, (qty[key] || 0) + Number(btn.dataset.a));
  localStorage.setItem('inv-qty', JSON.stringify(qty));
  navigator.vibrate?.(15); // a tiny buzz so you know it counted
});

Tapping the number lets you type a value directly, which is useful when you count 40 panels in one go.

Panels have sizes, and they're never the same

Aluminium is easy: one code, one count. Wood and laminate panels aren't. The same "Oak Natural" might be in stock as 200×200 and as a leftover 270×120, and the sizes are different every time.

So every panel can have its own list of sizes, each with its own counter:

// sizes['P|Laminate|Oak Natural'] = [{ m: '200×200 sp.18', n: 3 }, { m: '270×120', n: 1 }]
const total = (k) => (qty[k] || 0) + (sizes[k] || []).reduce((s, x) => s + x.n, 0);

I type the size once (200x200 becomes 200×200), and after that it's just + and −.

Export and backup

localStorage has one big weakness: lose the phone or clear the browser data, and everything is gone. So there are two buttons.

CSV for Excel. I use a semicolon separator and a UTF-8 BOM, otherwise Excel set to Italian puts everything in one column and mangles the accents:

const csv = '\ufeff' + rows
  .map((r) => r.map((v) => `"${String(v).replace(/"/g, '""')}"`).join(';'))
  .join('\r\n');

JSON backup. It saves the quantities and sizes to a file, and the same file can be restored on another phone. I send it to myself on WhatsApp after every count.

Installing it like an app

There's no app store involved. I open the page and choose Add to Home screen. With apple-mobile-web-app-capable and a theme-color, it opens full screen like a native app.

What I'd do better

I know this isn't how you'd build a real inventory system:

No sync. The data lives on one phone, so two people can't count at the same time.
The catalogue is hardcoded. Adding items from the UI works, but those extras stay on that phone.
No service worker. It works offline once loaded, but a proper PWA would cache it properly.
No history. It records the current count, not who changed what and when.

A small backend (or even a shared Google Sheet) would fix most of this. But that would be a project. This was an evening.

Takeaway

You don't need permission, a budget or a framework to fix a small, real problem at work. One HTML file, localStorage and a phone took us from "where's sheet number 3?" to typing two letters and tapping +.

If you've built a tiny tool like this for your own job, I'd love to hear about it in the comments.

The child that vanished: an order-dependent bug in my 2D render pipeline

Antonio — Wed, 07 Oct 2026 21:39:24 +0000

I'm building BeeEngine, a 2D HTML5 Canvas game engine in plain JavaScript. One of its core pieces is BeeLayer, the draw pipeline. Every frame it walks the entities, decides which pass each one belongs to, and hands them to the renderer in the right order.

It looked solid, and the tests were green. Then a child entity simply stopped showing up on screen, and it only happened when the entity list was in a certain order.

This post covers what was wrong, the first fix, the two bugs that fix still had, and the version that ships in 2.9.6.

How the pipeline works

There are four default passes:

Pass	order	Space	Sort
`background`	0	world	stable
`world`	10	world	stable
`ysort`	20	world	by feet (`y + height`, or `sortY`)
`ui`	100	screen	stable

Entities can have children (a hat on a hero, an HP label above an enemy). The renderer, engine.drawEntity, draws a node and then recurses into its children, skipping any child whose drawLayer differs from the current pass:

for (const child of entity.children) {
  if (child && child.drawLayer && child.drawLayer !== pass) continue;
  this.drawEntity(ctx, child, { space, pass });
}

So the job of BeeLayer is narrow. It only puts two kinds of entity in the buckets:

roots (no parent), and
split children, whose explicit drawLayer differs from the one they inherit.

A child on the same layer as its parent gets drawn inside the parent's draw call. A child on a different layer gets its own slot. No entity is ever drawn twice.

The bug

Collection walked currentScene.entities, then engine.entities, calling #visit on each item:

#visit(entity, engine, inherited) {
  if (!entity || entity.destroyed || this.#seen.has(entity)) return;
  this.#seen.add(entity);              // marked immediately
  if (entity.visible === false) return;

  const explicit = typeof entity.drawLayer === 'string' && entity.drawLayer;
  const isRoot = !entity.parent;
  const split = !!(explicit && inherited && explicit !== inherited);

  if (isRoot || split) { /* push into the bucket */ }

  // recurse into children with the inherited layer...
}

Now picture a hero with a gun on ysort and a hud on ui, and a list in this order:

[hud, gun, hero]

hud is visited first, straight from the list, so inherited is null.
It isn't a root (it has a parent), and split needs inherited, so it's false.
It doesn't go in any bucket, but it's already in #seen.
Then hero is visited and recurses into hud, which is already seen, so it returns.

The hud never gets drawn. With the list in the order [hero, gun, hud] everything works. That's a bug that depends on the order of an array, which is the worst kind to chase.

First fix: two passes

The idea is to stop letting children be visited before their parents:

Roots pass: visit only entities with no parent, recursing into children as before.
Orphans pass: anything still not in #seen has a parent that was never reached (the parent isn't in a list, or is hidden). Work out its inherited layer by climbing the parent chain, and treat it as an orphan root.

collect(engine) {
  // ...reset buckets, #seen.clear()
  this.#walkRoots(sceneList, engine);
  this.#walkRoots(engineList, engine);
  this.#walkOrphans(sceneList, engine);
  this.#walkOrphans(engineList, engine);
}

The tests passed, including [hud, gun, hero] against [hero, gun, hud]. I almost published.

Review: two more bugs

Reading the new code line by line turned up two cases the tests didn't cover.

1. A double draw, order-dependent again

Take a grandparent G that is not in any list, a parent P and a child C that are, with no drawLayer anywhere. The list is [C, P].

The orphans pass reaches C first. Its parent was never seen, so C goes in the bucket as an orphan root.
Then it reaches P, which also goes in the bucket as an orphan root.
At draw time, drawEntity(P) recurses into its children and draws C again.

With [P, C] it's fine. The bug I had just fixed was back in a new form.

2. The child of a destroyed parent

#visit returns on destroyed before adding the node to #seen, so the children of a destroyed parent are never marked. The orphan check only looked at visible === false, so those children became orphans and got drawn. Before the fix that never happened, because drawEntity on a destroyed parent draws nothing.

Final fix

Enter each branch from the top. Each frame I fill a reused Set with everything in both lists. For each orphan, I climb to the highest ancestor that is listed and not yet seen, and visit that one instead:

#listedRoot(entity) {
  let top = entity;
  let node = entity.parent;
  while (node) {
    if (this.#listed.has(node) && !this.#seen.has(node)) top = node;
    node = node.parent;
  }
  return top;
}

Destroyed hides a branch, the same as invisible:

#hiddenAncestor(entity) {
  let node = entity.parent;
  while (node) {
    if (node.visible === false || node.destroyed === true) return true;
    node = node.parent;
  }
  return false;
}

The orphan walk now looks like this:

#walkOrphans(list, engine) {
  for (const entity of list) {
    if (!entity || this.#seen.has(entity)) continue;
    if (this.#hiddenAncestor(entity)) continue;
    const root = this.#listedRoot(entity);
    if (!root || this.#seen.has(root)) continue;
    this.#visit(root, engine, this.#inheritedLayer(root), true);
  }
}

Both Sets are cleared and reused every frame, and the buckets keep their rows, so the hot path doesn't allocate anything new.

The tests that matter

The most useful test didn't check the buckets. It simulated drawEntity and counted how many times each entity was actually drawn:

[hero, gun, hud] and [hud, gun, hero] give the same result.
With G missing, [C, P] and [P, C] give the same result: only P is in a bucket, and C is drawn once.
A parent in the scene with a child in engine.entities: the child doesn't vanish.
The same entity in both lists is collected once.
An invisible or destroyed parent turns off its whole branch, even a ui child that is in a list.
Regressions: default passes, sortY = 0 used as a key, stable ties, add('') and duplicates throw.

Takeaways

A "seen" set marked too early means the first visit wins. If the first visit has the least context, you lose information you can't get back.
If the result depends on array order, test with the array reversed. Then test with a missing middle node.
Assert on the output, not on internal state. Checking the buckets looked fine. Counting the actual draws is what exposed the double draw.
Read your fix as if somebody else wrote it. Green tests only prove the cases you thought of.

The fix ships in BeeEngine 2.9.6. If you've handled parent/child draw ordering differently in your own engine, I'd love to hear how in the comments.

I almost edited 25 documentation pages by hand. Then one WordPress plugin did it in 1 second.

Antonio — Sun, 04 Oct 2026 16:46:40 +0000

I'm building BeeEngine JS, a lightweight 2D game engine for the browser, and I'm writing its documentation on WordPress, one page per module.

Every doc page has the same sidebar listing all the modules. While a guide isn't written yet, its link is just an anchor:

<li><a href="#BeeAnimatedSprite">BeeAnimatedSprite.js</a></li>

When I publish the real guide, that link has to point to the new page... on every single page.

The painful way

Open page → Edit → find the line → paste the URL → Save. Repeat 25 times. Then again for the next module. And I still have ~50 pages of docs to write. 😩

The 1-second way: Better Search Replace

Better Search Replace searches and replaces text directly in the database. Yes, many WordPress devs already know it (it's a classic for site migrations), but if you write docs in WordPress and you've never used it, this is for you.

Search for:

href="#BeeAnimatedSprite"

Replace with:

href="https://beeenginejs.com/animazione-spritesheet-in-javascript-play-update-e-draw/"

Table: wp_posts (your prefix may differ, mine wasn't wp_).

The dry run said 444 cells. I panicked for a second, then realized: 25 pages + all their revisions. Totally normal.

I ran it. 1,144 ms. Done. Every page updated. I almost cried. 😂

My checklist so you don't break anything

Back up the database first. The change is permanent.
Always do the dry run and check the count makes sense.
Search something unique, like the full href="#Module", not just Module.
Clear your cache (LiteSpeed, etc.) or you'll still see the old links.
Open a page and click the link to verify.

The trick I'm keeping for the next 50 pages

I write every not-yet-published link as href="#ModuleName". When the guide goes live, one search & replace and the whole documentation is linked. No more opening pages one by one.

If you know an even better workflow for multi-page docs in WordPress, tell me in the comments. And if you like tiny 2D JS engines, come say hi at beeenginejs.com 🐝

BeeEngine 2.9: plugins are here, starting with BeeLocale 🌍

Antonio — Sat, 03 Oct 2026 09:22:58 +0000

title: "BeeEngine 2.9: plugins are here, starting with BeeLocale 🌍"
published: true

tags: javascript, gamedev, opensource, webdev

Starting with v2.9.0, BeeEngine supports plugins. The engine stays "blind": it doesn't import or know anything about any plugin. Each plugin hooks itself in with attach(engine) and removes itself with detach().

The first official plugin is BeeLocale: a tiny helper to make your canvas games multilingual.

npm install beeengine@2.9.0

1. The problem: hardcoded text

// ❌ Before: to translate the game you have to hunt every string in your code
ctx.fillText('Score: ' + score, 20, 30);
ctx.fillText('Game Over', 300, 200);
ctx.fillText('Press SPACE to restart', 260, 240);

2. The solution: BeeLocale

import { BeeEngine } from 'beeengine';
import { BeeLocale } from 'beeengine/plugins';

const canvas = document.getElementById('game');
const engine = new BeeEngine(canvas, 800, 600);

// All translations in one place
const locale = new BeeLocale({
    language: 'it',   // active language
    fallback: 'en',   // backup language
    strings: {
        en: {
            score: 'Score',
            gameover: 'Game Over',
            restart: 'Press SPACE to restart'
        },
        it: {
            score: 'Punteggio',
            gameover: 'Hai perso!',
            restart: 'Premi SPAZIO per ricominciare'
        }
    }
});

// The plugin registers itself in the engine as 'locale'
locale.attach(engine);

3. Use it wherever you draw text

// ✅ After: only keys in your code
ctx.fillText(locale.t('score') + ': ' + score, 20, 30);
ctx.fillText(locale.t('gameover'), 300, 200);
ctx.fillText(locale.t('restart'), 260, 240);

get(key) does exactly the same as t(key), if you prefer that name:

locale.get('gameover'); // "Hai perso!"

You can also grab it from the engine, anywhere in your game:

const loc = engine.plugin('locale');
loc.t('score'); // "Punteggio"

4. Switch language on the fly

document.getElementById('btn-en').onclick = () => locale.setLanguage('en');
document.getElementById('btn-it').onclick = () => locale.setLanguage('it');

// Or automatically, from the browser language
locale.setLanguage(navigator.language.slice(0, 2)); // "it", "en", "fr"...

The next frame already draws the text in the new language.

5. Fallback: never an empty string

BeeLocale looks up a key in this order:

active language (it)
fallback language (en)
the key itself, left visible

const locale = new BeeLocale({
    language: 'fr',
    fallback: 'en',
    strings: {
        en: { score: 'Score', lives: 'Lives' },
        fr: { score: 'Score' }          // "lives" is missing in French
    }
});

locale.t('score');   // "Score"  → found in French
locale.t('lives');   // "Lives"  → missing in French, falls back to English
locale.t('bonus');   // "bonus"  → missing everywhere, shows the key

A missing translation shows up on screen right away instead of silently disappearing. Empty strings ('') count as missing too.

6. Detaching the plugin

locale.detach();
engine.plugin('locale'); // null

Under the hood: the plugin contract

Every plugin needs just two methods: attach(engine) and detach().

class MyPlugin {
    attach(engine) {
        this.engine = engine;
        engine.registerPlugin('my-plugin', this);
        return this;
    }

    detach() {
        if (this.engine) this.engine.unregisterPlugin('my-plugin');
        this.engine = null;
        return this;
    }
}

A plugin can't call engine.loop(), override update/render, or patch the main loop.

If it needs to run something every frame, it uses onTick, which returns a function to turn the hook off:

class FrameCounter {
    attach(engine) {
        this.engine = engine;
        this.frames = 0;
        engine.registerPlugin('frames', this);
        this.off = engine.onTick(() => { this.frames++; });
        return this;
    }

    detach() {
        if (this.off) this.off();   // always turn the hook off
        if (this.engine) this.engine.unregisterPlugin('frames');
        this.engine = null;
        return this;
    }
}

BeeLocale doesn't use onTick at all: it only works when you call t(), so it costs nothing per frame.

What's next

More plugins are coming, one at a time. Which one would you like to see next? Let me know in the comments! 🐝

npm: beeengine
GitHub: BeeEngine

A tiny deep-link trick so my Instagram stories open the exact game (3,000 games, 25 lines of JS)

Antonio — Fri, 02 Oct 2026 17:56:39 +0000

This is not rocket science, and many of you have probably done it a hundred times. But it solved a real, annoying problem for me in 10 minutes, so I'm sharing it in case it helps someone else. 🙂

The problem

I run PlayCombo, a small site with around 3,000 free HTML5 games split into 13 category pages. The games are loaded from a JSON list and rendered with plain JavaScript inside WordPress.

Every day I post a story or a short video on Instagram, Facebook and YouTube showing one game. Then I add the link... and the user lands on a category page with hundreds of games. The game they just saw? Somewhere in there. Good luck. 😅

People suggested sorting by date, but I didn't want to change the order of the whole catalog every evening, or move things around by hand.

The idea

Put the game in the URL:

https://playcombo.it/?gioco=pinch-bubbles

When the page loads, a small script reads ?gioco=, finds the matching game in the list that's already in the page, and opens its preview. If the parameter isn't there, the script does nothing.

No backend, no database, no changes to the JSON.

The code

My game engine already exposes two things on window: the game list (listaGiochi) and the function that opens a game preview (apriAnteprima). (Yes, the names are Italian: gioco = game, titolo = title.) The snippet just uses them:

(function () {
  // 1. Read ?gioco=... from the URL. No parameter? Stop right here.
  var richiesto = new URLSearchParams(location.search).get('gioco');
  if (!richiesto) return;

  // 2. Turn any title into a URL-friendly slug:
  //    "Pinch Bubbles" -> "pinch-bubbles", "Città Café" -> "citta-cafe"
  function slug(t) {
    return String(t || '').toLowerCase()
      .normalize('NFD').replace(/[\u0300-\u036f]/g, '') // strip accents
      .replace(/[^a-z0-9]+/g, '-')                      // anything else -> "-"
      .replace(/^-+|-+$/g, '');                         // trim dashes
  }

  var cercato = slug(richiesto);
  var tentativi = 0;

  // 3. The engine loads asynchronously, so wait until the list
  //    and the open function are ready (check every 100 ms).
  var attesa = setInterval(function () {
    tentativi++;
    var lista = window.listaGiochi;

    if (typeof window.apriAnteprima === 'function' && Array.isArray(lista) && lista.length) {
      clearInterval(attesa);

      // 4. Exact match first, then a partial match as a fallback.
      var gioco = lista.find(function (g) { return slug(g.titolo) === cercato; }) ||
                  lista.find(function (g) { return slug(g.titolo).indexOf(cercato) !== -1; });

      if (gioco) window.apriAnteprima(gioco);
    }

    // 5. Give up after ~10 seconds so it never runs forever.
    if (tentativi > 100) clearInterval(attesa);
  }, 100);
})();

Why I like it

Zero impact on normal visits. Without ?gioco=, the script exits on the first line.
Separate from the engine. I added it with a "custom JS/CSS/HTML" plugin in WordPress, not inside the engine file. If something goes wrong, the worst case is that the game just doesn't open by itself.
Works for every game. No per-game setup: the slug is generated from the title, so ?gioco=air-zero works out of the box.
Forgiving links. Accents and capital letters don't matter, and partial names still work.

Possible improvements

Use a stable id or slug field instead of the title, so renaming a game doesn't break old links.
Update the URL with history.replaceState when a game is opened, so people can share it directly.
Add og: meta tags per game for nicer previews on social media (that one needs server-side help).

That's it: a small trick, but now every story link opens exactly the game people just saw. If you've solved this differently, I'd love to hear how in the comments! 👇

I built a lightweight 2D Web Game Engine in Pure Vanilla JS (BeeEngine v2.8.4)

Antonio — Wed, 30 Sep 2026 20:42:52 +0000

Hi DEV community! 👋

Over the past few months, I've been working on BeeEngine, a lightweight 2D game engine built with pure Vanilla JavaScript and HTML5 Canvas.

My main goal was to create a clean, modular engine without relying on heavy external frameworks or complex build setups. It features a custom built-in visual inspector (BeeLadybug), a State-Graph Animator, and a robust Audio Mixer.

🛠️ Project Structure

Here is how BeeEngine is structured under the hood:

BeeEngine-V2.8/
├── index.html                 # Entry point & Canvas config
├── index.js                   # ESM Barrel (re-exporting BeeEngine.js)
├── main.js                    # Visual Demo (BeeUI: anchor, stack, focus, HUD)
├── BeeEngine.js               # CORE (Core Loop & System Coordinator)
├── index.d.ts                 # Global TypeScript definitions & IntelliSense
└── src/
    ├── audio/                 # BeeAudioMixer (bus, fade, duck, pan 2D)
    ├── core/                  # Entities, Prefabs, Tweens, Timelines, Pooling, Scene Manager
    ├── gameplay/              # Player, Enemy, Platform, Collectibles, Menus
    ├── graphics/              # Layers, Animator, Camera, Tilemaps, Particles
    ├── input/                 # Keyboard, Mouse, Touch & Virtual Joysticks
    ├── ui/                    # BeeUI (Panels, Stacks, Labels, Buttons, Nine-slice)
    ├── physics/               # Spatial Hashing, RigidBody & AABB Collisions
    └── debug/                 # BeeLadybug (Visual Inspector & Hitbox Overlay)

✨ Key Features

Zero External Dependencies: Built with 100% pure Vanilla JS.
Physics & Collision: Integrated Spatial Hash grid for efficient AABB collision detection.
Input System: Built-in support for Keyboard, Mouse, Touch, and Virtual Joysticks.
UI Engine (BeeUI): Flex-like layouts, anchors, focus management, and nine-slice UI rendering.
Visual Debugger (BeeLadybug): Built-in tool for real-time inspection, data tracking, and hitbox rendering.

🎬 Deep Dive: BeeAnimator (State Graph, Not Just Clips)

Most simple engines just play an animation clip. BeeAnimator is a proper State Graph Coordinator. While BeeAnimatedSprite renders the frames, the Animator decides which clip to play and when, handling priorities, hit-locks, and automatic transitions.

The entity.animator ticks inside the entity loop using the simulation's delta time (dt), meaning if the game pauses, the animation lifecycle freezes correctly.

// 1. Create the base animated sprite (The Renderer)
const sprite = gioco.createAnimatedSprite(sheet, {
    animations: {
        idle: { frames:, fps: 4, loop: true },
        run: { frames:, fps: 10, loop: true },
        attack: { frames:, fps: 12, loop: false }
    }
});

// 2. Wrap it in the State Graph Animator
const animator = gioco.createAnimator(sprite);
animator
    .add('idle', { clip: 'idle', initial: true })
    .add('run', { clip: 'run', priority: 1 })
    .add('attack', { clip: 'attack', loop: false, lock: true, priority: 10, exitTo: 'idle' })
    // State Transitions via Predicates
    .when('idle', 'run', (actor) => Math.abs(actor.vx) > 1)
    .when('run', 'idle', (actor) => Math.abs(actor.vx) <= 1)
    .when('*', 'attack', (actor) => actor.wantsAttack)
    .start();

actor.sprite = sprite;
actor.animator = animator;

Core Concepts:

Feature	Mechanics
lock	As long as the clip isn't finished, states with `priority` (\le) current cannot interrupt it (they get queued).
exitTo	Defines where to transition automatically once a one-shot/locked clip finishes.
*when('', to, pred)**	Defines a global transition predicate checkable from any active state.
play(name, { force })	Manual override request; `force: true` breaks active animation locks.

Note: BeeAnimatedSprite.play(name, { restart: true }) and sprite.finished are exposed so the animator knows precisely when an action (like an attack) ends.

🔊 Deep Dive: BeeAudioMixer (Audio Nodes & Bus Hierarchy)

Instead of poorly cloning HTML5 audio nodes (cloneNode), BeeEngine uses a proper audio graph node system via BeeAudioMixer. It handles a full hierarchy: master (\rightarrow) music / sfx / ui / voice. It supports volume control, muting per channel, smooth fading, 2D panning relative to the camera listener, and automatic audio ducking.

The mixer ticks every frame using real-time execution independent of the game simulation pause state.

// Unlock Audio Graph (requires user gesture interaction)
gioco.audio.unlock();

// Play background music with crossfade and custom volume
gioco.audio.music(track, { fade: 0.6, volume: 0.5 });

// Play a 2D localized sound effect spatialized vs the camera listener
gioco.audio.play('hit', { bus: 'sfx', x: 120, y: 300 });

// Procedural beep generation (perfect for web demos without downloading MP3s)
// Triggers automatic music ducking because it runs on the 'voice' bus
gioco.audio.tone({ frequency: 180, duration: 1.1, bus: 'voice' }); 

// Global Bus Controls
gioco.audio.setVolume('sfx', 0.8);
gioco.audio.fade('music', 0.2, 0.4);

Core Concepts:

Feature	Mechanics
bus	Hierarchy chain controller. Muting a parent bus automatically silences all child streams.
duck	Default behavior: Active signals on the `voice` bus automatically duck the `music` bus volume down to `0.35`.
x, y	Automatic distance attenuation and left/right stereo panning relative to the listener position.
tone()	Low-overhead procedural beep generator for quick sound design prototyping.

📦 Try It Out

jsDelivr CDN:

<script type="module">
  import * as BeeEngine from 'https://cdn.jsdelivr.net/npm/beeengine@latest/BeeEngine.js';
</script>

npm:

npm install beeengine

📊 CDN Stats & Package: [BeeEngine on jsDelivr](https://www.jsdelivr.com/package/npm/beeengine

I'd love to hear your thoughts, feedback, or suggestions from fellow web developers and gamedevs! What features would you like to see next?

BeeLadybug — un overlay per il debug DOM in tempo reale

Antonio — Sat, 26 Sep 2026 16:08:34 +0000

Un piccolo overlay in azione per il debug in tempo reale.

Invece di riempire il codice di console.log o stare sempre a smanettare con gli DevTools, ho creato questa piccola utility per tracciare e illuminare gli elementi del DOM e i nodi in tempo reale mentre ci si passa sopra.

Molto comoda per fare controlli al volo mentre si sviluppa, senza appesantire nulla.

Che ne pensate? Vi capita mai di impazzire per tracciare gli elementi a schermo?
Provatelo e fatemi sapere se puo' essere utile."(testato su Chrome/Edge)"

import('https://cdn.jsdelivr.net/npm/bee-ladybug@0.4.0/src/index.js')
  .then(({ BeeLadybugCore, WebDOMAdapter }) => {
    const bee = new BeeLadybugCore();
    new WebDOMAdapter(bee, { root: document.body }).attach();
    window.bee = bee;
  });

🔗 https://www.npmjs.com/package/bee-ladybug

BeeLadybug Ironic: Code Inspection meets Self-Inspection

Antonio — Mon, 21 Sep 2026 18:49:39 +0000

🐞 BeeLadybug Ironic: A Small End-of-Day Ritual for Devs

What if we applied the rubber-duck debugging concept to our end-of-day workflow?

The Core Idea

When you close your code editor after hours of problem-solving, refactoring, or hunting down subtle layout bugs, you don't always need another complex dashboard or analytical tool.

Sometimes, a simple circuit breaker helps you transition out of "dev mode" and step away from the desk.

BeeLadybug Ironic is an experimental project separate from the main bee-ladybug debug tool, combining two main concepts:

Visual Debugging: Inspecting Canvas elements and DOM boundaries under the hood.
Self-Inspection & Irony: A lightweight interactive canvas where you can write down thoughts, log simple notes, or reflect on a session before shutting down the system.

How It Works

Mascot Interface: A small 2D bee-ladybug mascot welcomes you to the canvas session.
Reflection Prompts: Quick interaction nodes to evaluate where you stand:
- "Is this a logic issue or just time for a break?"
- "What's the main blocker left for tomorrow?"
- "Ready to call it a day?"
Canvas Transition: Selecting an option transitions the interface into a clean workspace.
The Dissolve Effect: You type your temporary notes, hit the action button, and watch the text dissolve into a pixel field on screen. Once cleared, it's gone.

Technical Details

Runs Locally: Everything executes inside the browser's RAM during the session. No backend API calls, no databases, no tracking.
JavaScript & Canvas: Built on a minimal 2D rendering loop to keep performance fast and dependency-free.

Feedback & Ideas

This prototype is evolving, and I'd love to hear your thoughts:

Do you use any specific routine or visual break when wrapping up a long coding session?
What kind of canvas particle effect would feel best for clearing text (e.g., pixel dissolve, 8-bit blast, or terminal sweep)?

Feel free to leave a comment below!

DEV Community: Antonio

I broke an Elementor site on purpose, then built a tool to find the bugs

The night I broke my own site

So I built one: CSS hunt

The hard part: telling the truth without noise

The real test

Try it

What I learned

Nove classi per un pulsante: la mia piccola UI per canvas (e perché le voglio bene)

Il problema: il canvas non sa cos'è un pulsante

BeeControl: il nonno di tutti

BEE_ANCHOR: perché nessuno vuole scrivere setAnchors(1, 1, 1, 1)

BEE_UI_DEFAULTS: le decisioni che non voglio prendere ogni volta

BeePanel: un rettangolo con ambizioni

drawNineSlice: l'eroe silenzioso

BeeStack: il flexbox dei poveri (e mi basta)

BeeLabel e BeeUIButton: finalmente quello che volevo

BeeUI: il capo

Un menu di pausa completo

Quindi, nove classi erano troppe?

I'm 53, I build a JS game engine, and the bots think I'm fresh meat

The illusion of numbers

Then came the comments

Not all bots are the same

Why us?

What I actually want

What I do now

Conclusion

An inventory plugin that never lies: transactional add, equip and use in a vanilla JS 2D engine

Rule zero: plugins don't own the loop

The API in one snippet

add always tells you what didn't fit

All or nothing: move, equip, unequip

use with a rollback

Copies out, plain data in

Two plugins, zero coupling

Tests

Why 2.10.0 and not 2.9.7

What's next

I replaced our warehouse paper inventory with one HTML file

The goal

The architecture

Getting the data in

The core: search plus counters

Panels have sizes, and they're never the same

Export and backup

Installing it like an app

What I'd do better

Takeaway

The child that vanished: an order-dependent bug in my 2D render pipeline

How the pipeline works

The bug

First fix: two passes

Review: two more bugs

1. A double draw, order-dependent again

2. The child of a destroyed parent

Final fix

The tests that matter

Takeaways

I almost edited 25 documentation pages by hand. Then one WordPress plugin did it in 1 second.

The painful way

The 1-second way: Better Search Replace

My checklist so you don't break anything

The trick I'm keeping for the next 50 pages

BeeEngine 2.9: plugins are here, starting with BeeLocale 🌍

tags: javascript, gamedev, opensource, webdev

1. The problem: hardcoded text

2. The solution: BeeLocale

3. Use it wherever you draw text

4. Switch language on the fly

5. Fallback: never an empty string

6. Detaching the plugin

Under the hood: the plugin contract

What's next

A tiny deep-link trick so my Instagram stories open the exact game (3,000 games, 25 lines of JS)

The problem

The idea

The code

Why I like it

Possible improvements

BEE_ANCHOR: perché nessuno vuole scrivere `setAnchors(1, 1, 1, 1)`

`add` always tells you what didn't fit

All or nothing: `move`, `equip`, `unequip`

`use` with a rollback