DEV Community: Sara Loera

HTML-in-Canvas Feels Fake Until You Try to Build With It

Sara Loera — Wed, 13 May 2026 19:49:44 +0000

HTML-in-Canvas feels fake the first time it works.

Real DOM.

Real CSS.

Real layout.

Inside canvas.

You write a tiny canvas.onpaint, call drawElementImage(), and the browser just… does it. Your styled HTML is suddenly part of a canvas frame.

Beautiful.

Then you try to build an actual app.

Now you have multiple surfaces, resize logic, export timing, React unmounts, cleanup, invalidation, and the classic:

wait, is this number CSS pixels or canvas pixels?

That's the part where the cool browser primitive turns into lifecycle work.

So I built Prism.

First: what is HTML-in-Canvas?

The WICG HTML-in-Canvas proposal lets a canvas render real HTML elements directly.

Not screenshots.

Not html2canvas.

Not SVG foreignObject.

Actual DOM, painted into a canvas frame by the browser.

A tiny example looks like this:

<canvas id="canvas" layoutsubtree>
  <div id="panel" style="width: 400px; height: 200px">
    <h2>Real HTML</h2>
    <p>Real CSS. Real fonts. Real layout.</p>
  </div>
</canvas>

const canvas = document.getElementById("canvas");
const panel = document.getElementById("panel");
const ctx = canvas.getContext("2d");
if (!ctx) throw new Error("2d context unavailable");

canvas.onpaint = () => {
  ctx.drawElementImage(panel, 0, 0);
};

canvas.requestPaint();

The rough shape is:

layoutsubtree opts canvas children into layout.
drawElementImage() draws a child element into the canvas.
onpaint fires when the browser says the canvas subtree needs painting.

For one surface, it is almost suspiciously nice.

But apps are never one surface.

The part that gets messy

With the raw API, your app has to answer a bunch of boring-but-important questions:

Which DOM elements are canvas surfaces?
Who updates their bounds?
Who asks the browser for a new paint?
What happens when a component unmounts?
What happens when the runtime is destroyed?
How do you wait for a paint-ready frame before export?
How do you keep CSS pixels and backing-store pixels straight?

A single React component can already start to look like this:

useEffect(() => {
  const canvas = canvasRef.current;
  const scene = sceneRef.current; // the DOM element to draw
  const ctx = canvas?.getContext("2d");
  if (!canvas || !ctx || !scene) return;

  canvas.onpaint = () => {
    ctx.reset();
    ctx.drawElementImage(scene, 0, 0);
  };

  // Simplified: uses CSS pixels for backing-store size.
  // In production, use DPR-aware sizing via devicePixelContentBoxSize
  // or multiply contentRect dimensions by devicePixelRatio.
  const resizeObserver = new ResizeObserver(([entry]) => {
    canvas.width = Math.round(entry.contentRect.width);
    canvas.height = Math.round(entry.contentRect.height);
    canvas.requestPaint();
  });

  resizeObserver.observe(canvas);
  canvas.requestPaint();

  return () => {
    resizeObserver.disconnect();
    canvas.onpaint = null;
  };
}, []);

That is not terrible.

It is also not the app I wanted to write.

Now add export. Add multiple DOM surfaces. Add transform sync. Add pointer interaction. Add route changes. Add a framework. Add "why is this blank PNG happening only sometimes?"

That is where Prism comes in.

What Prism is

Prism is a native-first HTML-in-Canvas runtime for managed DOM surfaces in canvas applications.

It does not replace your renderer.

Your app still owns the scene, drawing model, animation loop, state, data, interactions, and visual decisions.

Prism owns the DOM-surface lifecycle:

your app owns:
  scene, rendering, animation, state, interaction

Prism owns:
  surface registration, bounds, invalidation,
  paint readiness, coordinate helpers, cleanup

Install it:

pnpm add @synthesisengineering/prism

Use it like this:

import { CanvasRuntime } from "@synthesisengineering/prism";

const runtime = new CanvasRuntime(canvas, { backend: "auto" });

const surface = runtime.registerSurface(element, {
  bounds: { x: 0, y: 0, width: 320, height: 180 }
});

runtime.onPaint(({ drawSurface }) => {
  drawSurface(surface);
});

runtime.start();

That is the core idea.

The DOM stays DOM.

The canvas stays canvas.

Prism manages the boundary.

The shift: DOM as source material

The important part is not that Prism makes prettier pixels than hand-written canvas.

You can make beautiful things with Canvas 2D, SVG, WebGL, shaders, and all the usual tricks.

The important part is that the source material can stay DOM.

Your labels can be real HTML.

Your typography can stay CSS.

Your icons can stay SVG.

Your React components can stay React components.

Prism lets the canvas treat those DOM-authored pieces as managed surfaces.

So instead of rewriting every styled element as canvas drawing code, you can author the visual source with the browser's layout engine and compose it inside canvas.

The browser gives us the primitive.

Prism provides an app lifecycle.

Use case 1: data visualization

One example is Prism Atlantic.

It uses real NOAA/NHC HURDAT2 Atlantic storm-track data from 2000–2025. The canvas draws the storm paths. Prism manages the HTML/CSS surfaces: title, overview, legend, tooltip, detail panel, caption, and export button.

Open Prism Atlantic →

The app owns the data visualization. Prism owns the surface lifecycle.

import { CanvasRuntime } from "@synthesisengineering/prism";

const runtime = new CanvasRuntime(canvas, { backend: "auto" });

const tooltip = runtime.registerSurface(tooltipEl, {
  bounds: { x: 0, y: 0, width: 280, height: 120 }
});

const legend = runtime.registerSurface(legendEl, {
  bounds: { x: 20, y: 20, width: 200, height: 400 }
});

runtime.onPaint(({ ctx, drawSurface }) => {
  ctx.save();
  ctx.scale(runtime.pixelRatio, runtime.pixelRatio);
  drawStormTracks(ctx);
  ctx.restore();
  drawSurface(tooltip);
  drawSurface(legend);
});

runtime.start();

The export path is the part I really wanted to get right.

With Prism, you wait for fonts, then wait for one Prism-owned paint pass, then use the normal canvas API:

await document.fonts.ready;
await runtime.paintOnce();

const blob = await new Promise<Blob>((resolve, reject) => {
  canvas.toBlob((value) => {
    if (!value) {
      reject(new Error("Canvas export failed."));
      return;
    }
    resolve(value);
  }, "image/png");
});

paintOnce() does not export anything by itself.

It just answers: has Prism completed a paint-ready frame?

Then canvas.toBlob() does the export.

No screenshot library. No html2canvas. No foreignObject export path.

Use case 2: React components as canvas surfaces

Another example is React Composer Lite.

It shows React-authored HTML/CSS components as movable, transformable, exportable canvas surfaces.

The trick is not to let React and Prism fight over ownership.

React owns component state.

Prism owns surface registration and cleanup.

The pattern is:

Create the runtime once.
Register the DOM node once for a runtime/element pair.
Update bounds through surface.setBounds().
Destroy and dispose on unmount.

import { useEffect, useRef, useState } from "react";
import type { RefObject } from "react";
import { CanvasRuntime } from "@synthesisengineering/prism";
import type { CanvasSurface } from "@synthesisengineering/prism";

type SurfaceBounds = {
  x: number;
  y: number;
  width: number;
  height: number;
};

export function usePrismRuntime(
  canvas: HTMLCanvasElement | null
): CanvasRuntime | null {
  const [runtime, setRuntime] = useState<CanvasRuntime | null>(null);

  useEffect(() => {
    if (!canvas) {
      setRuntime(null);
      return;
    }

    const nextRuntime = new CanvasRuntime(canvas, { backend: "auto" });
    nextRuntime.start();
    setRuntime(nextRuntime);

    return () => {
      setRuntime(null);
      nextRuntime.destroy();
    };
  }, [canvas]);

  return runtime;
}

export function usePrismSurface(
  runtime: CanvasRuntime | null,
  elementRef: RefObject<HTMLElement | null>,
  bounds: SurfaceBounds
) {
  const surfaceRef = useRef<CanvasSurface | null>(null);

  useEffect(() => {
    const element = elementRef.current;
    if (!runtime || !element) return;

    const surface = runtime.registerSurface(element, { bounds });
    surfaceRef.current = surface;

    return () => {
      surface.dispose();
      surfaceRef.current = null;
    };
    // Register once for this runtime/element pair.
    // Bounds updates are handled by the effect below.
  }, [runtime, elementRef]);

  useEffect(() => {
    surfaceRef.current?.setBounds(bounds);
  }, [bounds.x, bounds.y, bounds.width, bounds.height]);

  return surfaceRef;
}

The important detail: usePrismRuntime returns state, not a ref, so downstream usePrismSurface re-runs correctly when the runtime is ready. Bounds updates do not require re-registering the surface — register once, then update through surface.setBounds().

The boundary is clean:

React renders normal components.
Prism registers those DOM nodes as surfaces on mount.
Canvas composes them into a frame.
Cleanup happens when components unmount.

Your React components do not need to become canvas drawing code.

They can stay React components.

Use case 3: DOM as creative material

The third example is Prism Atelier.

This one is less practical and more fun.

It uses DOM-authored HTML/CSS/SVG as visual material. A real DOM surface is registered once, then drawn repeatedly inside the canvas paint pass with transforms, opacity, shadows, blend modes, and pointer-driven motion.

Open Prism Atelier →

The source can be a normal element:

<div id="type-surface" class="type-surface">PRISM</div>

Then Prism turns it into a reusable canvas surface:

const surface = runtime.registerSurface(typeEl, {
  bounds: { x: -380, y: -105, width: 760, height: 210 }
});

And the app can compose it:

runtime.onPaint(({ ctx, drawSurface }) => {
  // runtime.canvas.width/height are backing-store pixels (CSS pixels × devicePixelRatio).
  // Surface bounds passed to registerSurface/setBounds are CSS pixels — keep them separate.
  ctx.fillStyle = "#07070a";
  ctx.fillRect(0, 0, runtime.canvas.width, runtime.canvas.height);

  const count = 35;
  const radius = 220 * runtime.pixelRatio;
  const cx = runtime.canvas.width / 2;
  const cy = runtime.canvas.height / 2;

  for (let i = 0; i < count; i += 1) {
    const t = i / count;
    const angle = t * Math.PI * 2 + rotation;

    ctx.save();
    ctx.translate(
      cx + Math.cos(angle) * radius,
      cy + Math.sin(angle) * radius
    );
    ctx.rotate(angle);
    ctx.globalAlpha = 1 - t * 0.65;
    drawSurface(surface);
    ctx.restore();
  }
});

You could hand-roll something like this with the raw API.

But then you own the browser paint hooks, bounds, invalidation, readiness, and cleanup yourself.

Prism makes the DOM surface reusable as canvas material without making your app coordinate raw onpaint, requestPaint(), and drawElementImage() directly.

The coordinate-space footgun

One thing Prism makes explicit is coordinate space.

Surface bounds are CSS pixels:

surface.setBounds({
  x: 24,
  y: 32,
  width: 360,
  height: 220
});

Direct canvas drawing uses backing-store pixels.

So Prism exposes helpers:

const point = runtime.cssPointToCanvasPixels({ x: 24, y: 32 });
const size = runtime.cssLengthToCanvasPixels(12);

This sounds boring until it saves you from the classic "everything is offset and blurry on my display" bug.

Boring runtime helpers are good, actually.

An agent skill is included

One thing I care about: Prism should be hard to misuse, even when an AI coding agent is writing the first draft.

So Prism ships with an agent skill:

npx skills add synthesiseng/prism --skill prism-runtime

The skill teaches agents the Prism runtime contract:

import from @synthesisengineering/prism
register DOM nodes as surfaces
draw surfaces inside onPaint()
wait for document.fonts.ready and runtime.paintOnce() before export
avoid html2canvas, dom-to-image, raw drawElementImage(), and deep imports

That last part matters.

Without guidance, agents tend to reach for screenshot libraries or raw platform APIs. The skill keeps them on the Prism path.

The renderer boundary

Prism can sit alongside renderers like Three.js because it does not try to own the scene. Today, the documented API remains 2D-first; renderer-specific integrations are future-facing.

That boundary is the design:

the renderer owns the scene
the app owns state and interaction
Prism owns DOM-surface lifecycle

The point is not to turn Prism into a renderer.

The point is to let renderers use real DOM surfaces without every app rebuilding the same lifecycle layer.

The honest caveats

Prism is still early.

Native fidelity currently requires Chromium with:

chrome://flags/#canvas-draw-element

Prism detects native support and can fall back to a compatibility path, but fallback is lower fidelity. It is not equivalent to native HTML rendering.

This is alpha software: 0.1.0-alpha.8.

The current public API is 2D-first. WebGL, WebGPU, Three.js, Pixi, and Phaser integrations are future-facing, not the current public API center.

Prism is not a renderer, UI kit, design tool, app framework, charting library, or game engine.

It is a runtime for managed DOM surfaces in canvas applications.

That is the whole point.

Try it

Docs and examples: runprism.dev

Source: github.com/synthesiseng/prism

Live examples:

Install:

pnpm add @synthesisengineering/prism

Agent skill:

npx skills add synthesiseng/prism --skill prism-runtime

Feedback welcome from people building canvas-heavy apps, visual tools, data viz, editors, and creative systems.

I built Earth's Year Wrapped with real climate data. 2025 was rough.

Sara Loera — Sun, 19 Apr 2026 21:53:49 +0000

This is a submission for Weekend Challenge: Earth Day Edition

What I Built

Earth Wrapped · MMXXVI

Earth is the narrator.
The year is the subject.
The reader is asked to answer back.

thisyear.earth is an immersive climate year-in-review told across eleven full screen chapters. It borrows the emotional shape of a wrapped recap, then turns the perspective inside out: the account belongs to Earth, the receipts are climate data, and the final action is not to share a playlist, it is to leave a pledge.

The experience moves through:

Preface · The Record
Coordinates
The Fever
The Atmosphere
The Melt
The Canopy
The Ledger
The Roll Call
The Residue
The Turn
Epilogue · Sincerely

At the end, Earth asks for one small thing.

You write a pledge for the year ahead.
You can sign it.
You can leave it anonymous.
And if you want it to remain, you can mint it to the ledger.

That pledge becomes part of thisyear.earth/ledger — a public record with on-chain proof behind it.

Why I made it

Climate data is everywhere, and somehow still easy to ignore.

The numbers exist. They are published. They are updated. They are cited. But a spreadsheet does not stop you in the middle of your day. A PDF does not follow you into Monday morning. A chart rarely makes you feel the weight of what it represents.

I wanted to build something that made the data land. Something that could turn 429 ppm into a condition, 1.17 trillion tonnes of ice lost into memory, and renewables up 32% into relief that had to be earned.

So I gave Earth a Wrapped.

Demo

🌍 thisyear.earth

🗒️ thisyear.earth/ledger — the permanent pledge record

Why Solana mattered

The ledger is the part I care about most.

Not because it is “web3.”

Because it turns a passing interaction into a record.

When someone mints a pledge, the app creates a real memo transaction on Solana Devnet for the challenge build. The transaction hash and mint metadata are stored in the app’s database, and the public ledger page renders those sealed pledges in a readable, shareable, and verifiable format.

The ledger is not a crypto dashboard.

It is a book of names and promises.

A reader can follow the Explorer link and verify that the pledge exists on-chain. For the challenge build, that proof currently lives on Devnet rather than Mainnet.

What mattered to me was the split:

Neon serves the ledger and app data quickly
Solana acts as the proof layer underneath

How I built it

The site uses separate shells for mobile and desktop:

Mobile: swipeable full-screen sequence
Desktop: scroll-driven atmospheric narrative

The stack:

Next.js 16 — App Router, Turbopack, React 19
TypeScript — strict mode
Tailwind CSS + Framer Motion — layout, motion, transitions
Neon — pledge and location persistence
Solana — memo-based Devnet pledge minting
globe.gl — final globe visualization
Lenis — desktop scroll behavior

The data

The climate data is real.

The CO₂ card fetches daily live readings from the NOAA GML CSV at the Mauna Loa Observatory. The other cards use annual or authoritative reported figures, cited in the experience itself.

Card	Source
CO₂ · 429 ppm	NOAA GML — Mauna Loa Observatory
Temperature · +1.55°C	NASA GISS + NOAA Climate.gov
Ice · 1.17T tonnes	NSIDC + NASA GRACE-FO
Forest · 14.9M hectares	Global Forest Watch + WRI
Species · 41,046	IUCN Red List
Plastic · 413 Mt	OECD + UNEP
Wildfires	NASA FIRMS
Renewables · +32%	IEA + IRENA

The design

This project could have gone in a loud, celebratory direction. I tried that path at first. It felt wrong. The subject matter did not want confetti. It wanted gravity.

So the final direction became typographic, atmospheric, and editorial, not because it was trendy, but because it was the only version that felt honest.

Prize category

Best Use of Solana

Every minted pledge creates a real Solana Devnet memo transaction.

The app keeps the ledger readable and fast by serving it from Neon, while each sealed pledge links to its on-chain proof on Solana. That gave me the best of both worlds: a public record people can actually read, and a proof layer underneath it that is real and verifiable.

Special thanks

Special thanks to the scientists and researchers who maintain these datasets year after year — NOAA GML at Mauna Loa Observatory, NASA GISS, NSIDC, Global Forest Watch, the IUCN Red List, and the IEA.

Cover image uses Earth imagery courtesy of NASA.

Try It

🌍 thisyear.earth
Code: github.com/saraeloop/thisyearearth

Read the year.
Leave a pledge.
Add your line to the record.

Managing Multiple Git Identities Was a Mess, So I Built gitrole

Sara Loera — Tue, 14 Apr 2026 22:13:56 +0000

Multiple accounts were annoying. Multiple machines made it worse. Then came the agents.

I was supposed to be on vacation.

Not fully offline. Just the kind of trip where you bring an old laptop, keep a loose eye on things, and tell yourself that if something urgent comes up, you can handle it.

I had my dotfiles. I had the usual setup scripts for bootstrapping a machine and juggling Git accounts. I even had a shell wrapper and GIT_SSH_COMMAND to force the right key per repo. I thought that would be enough. It wasn’t.

Halfway through the trip, a client messaged me. The project they had been sitting on for weeks suddenly became urgent.

So there I was, on an old laptop, trying to jump back into work mode.

I needed to pull private files from one GitHub account, set up a client repo on another, and keep my personal GitHub config intact on the same laptop. Three identities. One machine. As if that weren’t enough chaos, I also wanted an agent running overnight, and none of them were playing nicely together.

I tried to make gh behave across multiple accounts.

Wrong account authenticating. Wrong identity on commits. Private repos inaccessible because the wrong SSH key was being used. Everything was tangled together.

I got it working eventually. But it took way longer than it should have. And the worst part was knowing this was not a one time problem. It was going to happen again on the next machine, the next repo, the next account, the next agent.

That was the moment I stopped patching the workflow and decided to build the missing tool.

That tool is gitrole.

Why separate identities at all?

For me, this is not just cleanup. It is discipline.

Work is employer-owned code. Wrong identity on a commit is not just awkward; it's a problem. It is an accountability and IP problem.

Freelance is client-owned code. I also keep private client templates and tools there that I do not want mixed into anything else.

Personal is my own work. I do not want employer email on side projects or personal experiments bleeding into client repos.

Agents make this even more important. If an agent commits as me and pushes something broken, was that me or the agent? There needs to be a clean boundary.

Each identity has a different owner, audience, and level of accountability. Mixing them is not just messy. It creates real problems.

The actual problem

Git identity is split across two systems.

Commit identity is your user.name and user.email — what your commit says it is from.

Push identity is your SSH setup — which key gets used, which GitHub account that key maps to, which host alias the repo remote points at.

Those two things are related, but they are not the same. You can easily end up with commits that look right, but pushes that go through the wrong account. Git does not warn you when those two drift apart. Most people only notice after the damage is already in history.

gh helps with GitHub authentication. It does not manage your Git commit identity. You can gh auth switch all day and still commit as the wrong person.

That is the hole gitrole fills.

What gitrole gives you

gitrole gives you one place to check the two things Git keeps separate:

who the next commit will say it is from
which GitHub account will actually push it

Instead of editing config by hand and hoping you remembered everything, you save your identities once, switch to the one you want, and check the repo before you commit or push.

The three-command loop

gitrole use work --local
gitrole status
gitrole doctor

use switches the identity for this repo only
status tells you whether commit and push identity are aligned
doctor explains what is wrong if they are not

You save a role once per identity:

gitrole add work \
  --name "Your Name" \
  --email "you@company.com" \
  --ssh ~/.ssh/id_work \
  --github-user your-work-github-username \
  --github-host github.com-work

Then use it and check it:

gitrole use work --local
gitrole status

work  aligned
  commit Your Name <you@company.com>
  push  your-work-github-username via github.com-work
  scope local override

If status shows aligned, you are done. If something looks off, gitrole doctor tells you exactly what and why:

gitrole doctor

checks
  ok role   commit identity matches saved role work
  ok scope  selected role work is applied via local config
  ok commit effective commit identity matches selected role work
  ok auth   SSH auth matches role githubUser your-work-github-username

And if the push path is still wrong:

gitrole remote set work

That rewrites origin to use the SSH host alias configured for that role.

Remote was still pointing at the personal account after switching to work. Doctor caught it. One command fixed it.

The fresh-machine moment

On a clean machine, the problem becomes obvious fast. You install gitrole, run status, and see this:

no matching role  warning
  commit Ada <ada@example.com>
  push  Ada via github.com
  scope global

Git is configured. gitrole just does not know that identity yet. So you capture it:

gitrole import current --name personal

imported current identity as personal
  commit Ada <ada@example.com>
  scope global

Now gitrole knows that identity by name. No retyping.

Agents made this more important, not less

Humans are bad at remembering which identity belongs where.

Agents are worse. They do not carry ambient context unless you make it explicit.

That is why gitrole has gitrole status --short, gitrole doctor --json, and repo-local .gitrole policy files. Not because I wanted to build an AI tool, but because explicit identity state matters a lot more once software is committing on your behalf.

The point

I built gitrole because I was tired of that moment before every push:

wait — am I the right person right now?

Save your identities once. Switch with one command. Check before you push.

It already works; I use it myself, and I'm still refining it as I pressure test it across machines and repos. If you try it, I'd love to hear what works and what still feels rough.

Install: npm install -g gitrole

Docs: docs.gitrole.dev — repo pinning, agent identity setup, and machine-readable output for automation.

GitHub: github.com/synsoftworks/gitrole

I "accidentally" built an awesome-useless ecosystem. There is an owl. The Tamagotchi is dying. 1997 portfolio devcities.lol

Sara Loera — Thu, 09 Apr 2026 03:29:45 +0000

This is a submission for the DEV April Fools Challenge

What I Built

Hello, my name is Sara, and I'm a software engineer. I build observable AI infrastructure. I make complex systems legible, auditable, and safe.

Today, in full yolo mode, I used those skills to build awesome-useless — a real awesome-* list for useless software. Like awesome-python but for things that should not exist.

It is a russian doll. Open it and find something weirder inside.

🪆 awesome-useless — the repo. A curated list. Real badges. Real CI. Contributions welcome. Useful PRs will be rejected.

🪆 oh-my-silly-me — a shell framework that makes your terminal measurably worse. Has a Tamagotchi that always dies.

🪆 .spells — a hidden grimoire. ls -la and you'll see things. We cannot be held responsible.

🪆 devCities.lol — the innermost doll. You describe yourself. A tired government owl named Agent Hoot builds you a personal 1997 Devcities homepage. You get a shareable URL. Your portfolio is now safe from modern web design. Forever. In 1997.

I have no regrets. My git log tells a different story.

Demo

→ Try devCities.lol— yeah, I went there.

How it works:

Land on devcities.lol — a Windows 98 portal
Describe yourself in the prompt box:

"I'm ___, frontend dev with strong feelings about border-radius. My stack is TypeScript and regret. My cat, Mr. Whiskers, reviews all my PRs. He has never approved one."
Hit 🦉 ENTER O.W.L.S PROTECTION
Behind the scenes, the Gemini API wakes up Agent Hoot.
He reads your description. He built your 1997 homepage.
He does not ask questions. This also concerns us.
Watch the terminal go...
Your personal 1997 devCities homepage appears. It is not pretty. It was never going to be pretty. Your name is in rainbow Comic Sans. Your stack has been renamed to chaos. Your hot take is marked CLASSIFIED. The guestbook has one entry — Agent Hoot. Also classified. You made this. You cannot unmake this. This is yours now.

--> Hit "🔗 SHARE YOUR PAGE" — the entire Devcities nightmare
gets compressed into a URL. No backend. No database. Just pure 1997 chaos encoded into a link. Send it to your friends. Send it to your enemies. Send it to your tech lead, who keeps saying "we should rewrite this in Rust."

oh-my-silly-me in action:

source oh-my-silly-me/silly.sh

ksshhhhh...bing bing bing...CONNECTED AT 28.8 KBPS
MEMORANDUM: Please report any unauthorized use of the 'Tab' key to Agent Hoot.
🐣 [TAMAGOTCHI] is currently 0 minutes old. It is 1799 seconds from its inevitable doom.
🦉 [CLASSIFIED] ~/your-directory $

You can also cast spells:

cast ghostbuster

Gemini identified 3 ghosts, 7 personality enhancements, and 13 anomalies in total. It was recommended to leave offerings in the node_modules folder at midnight. Agent Hoot will collect them.

Code

saraeloop / awesome-useless

An awesome list for software that solves nothing. Contributions welcome.

awesome-useless ✨

A curated list of awesome useless code, tools, and resources.
Contributions welcome. Useful PRs will be rejected.

🏆 An entry in the DEV.to April Fools Challenge · #418challenge · #devchallenge

🛠️ Tools

oh-my-silly-me — A shell framework for the unproductive. Like oh-my-zsh but worse in every measurable way. On purpose.

🏛️ Projects

devCities — Your dev portfolio. In 1997. A government owl builds your Devcities homepage from a prompt.

🧠 Prompts

unhinged-prompts — AI prompts that should not exist. Curated by someone who regrets all of them.

🧙 Spells

.spells — A hidden grimoire. ls -la and you'll see things. Cast them on any AI: Gemini, Claude, Codex, or other. We cannot be held responsible.

⚰️ Graveyard

graveyard — Where projects go to die. Even AI projects. Especially AI projects. Submit yours. Be proud.

🖥️ Useless Downloads

418 I Am A Teapot Wallpaper…

View on GitHub

The repo is a russian doll. Each layer contains something weirder.

ls -la when you get there.

How I Built It

The stack:

TypeScript + Vite (the app that hides websites in 1997 has strict mode enabled)
98.css (Windows 98 government portal aesthetic)
Gemini API / gemini-3.1-pro-preview (Agent Hoot, the Identity Reassignment Officer)
lz-string (compress entire Geocities pages into shareable URLs)
Vanilla chaos (CSS, HTML, the spirit of 1997)
Bash/zsh (oh-my-silly-me shell framework)

The Gemini API does the actual work:

When you describe yourself, the prompt tells Gemini:

"You are Agent Hoot, O.W.L.S. Identity Reassignment Officer. This page was made by a developer in 1997 who was EXTREMELY proud of it. It should look intentional. Chaotic but lovingly crafted. It looks like someone spent their whole weekend on this. Useless ≠ ugly. Charming chaos ≠ visual disaster."

That last instruction went through 5 iterations. The first 4 produced visual disasters. The 5th produced Sara's CyberDomain. Sara's CyberDomain is beautiful. In 1997.

Gemini CLI built oh-my-silly-me:

I prompted Gemini CLI to build a shell framework that makes your terminal worse. It built Tamagotchis, Enya error handlers, dial-up simulators, and a cast command for AI spells. It did not object once. This concerns me deeply.

Google Imagen created Agent Hoot:

He did not consent.

Total cost of all Gemini API calls: approximately $0.83

⚠️ The Incident Report

Every mission has casualties.

O.W.L.S. INCIDENT LOG
======================
Classification: EYES ONLY

INCIDENT #001: THE MODEL THAT DID NOT EXIST
gemini-3.0-flash is not found for API version v1beta.
We asked for the future. The future was not available.
We settled for 2.5. for a bit, then 3.0 flasharoooo!

INCIDENT #002: THE TYPING THAT WOULD NOT STOP
> Agent Hoot is still typing.
> Agent Hoot is still typing..
> Agent Hoot is still typing...
[× 87]
Agent Hoot typed for 4 minutes.
Agent Hoot was very thorough.
We could not stop him.

INCIDENT #003: THE LINTER THAT HAD OPINIONS
The CI markdown linter told us:
"This repo is a joke —
let's not fight the linter on every creative choice."
We disabled the rules.
The linter was right.
We were also right.

INCIDENT #004: THE TAMAGOTCHI
It died.
We could not save it.
Nobody can save it.
This is by design.
This is fine.

TOTAL CASUALTIES: 4 incidents, 1 Tamagotchi
STATUS: Operational. Mostly. It is 1997.

The repo is real. The contributions are welcome.
The useless PRs will be merged with great pride.
The useful PRs will be rejected with great sorrow.

Star the repo. Submit your useless thing.
The grimoire is open. ls -la and you'll see.

Prize Category

Best Google AI Usage — Gemini CLI built the shell framework. Gemini API powers the identity reassignment. Google Imagen created Agent Hoot. Total Google AI involvement: everything except the existential crisis, which was my own.

Best Ode to Larry Masinter — Our servers are teapots. HTTP 418. This is not an error. This is a lifestyle. The HTCPCP/1.0 certification appears in the footer of every page. Agent Hoot has been a teapot since 1997. Agent Hoot did not choose this. Free pocket computer skins ship with every generated page. Larry Masinter has not been informed.

Community Favorite — devCities gives every developer their own shareable 1997 homepage. The repo accepts PRs for new useless projects. The tamagotchi dies for everyone equally. This is community.

The visitor counter is at 000312.
It will reach 000313 eventually.
Agent Hoot is still watching.
It is 1997.
It is always 1997.

🦉

DEV Community: Sara Loera

HTML-in-Canvas Feels Fake Until You Try to Build With It

First: what is HTML-in-Canvas?

The part that gets messy

What Prism is

The shift: DOM as source material

Use case 1: data visualization

Use case 2: React components as canvas surfaces

Use case 3: DOM as creative material

The coordinate-space footgun

An agent skill is included

The renderer boundary

The honest caveats

Try it

I built Earth's Year Wrapped with real climate data. 2025 was rough.

What I Built

Why I made it

Demo

Why Solana mattered

How I built it

The data

The design

Prize category

Best Use of Solana

Special thanks

Try It

Managing Multiple Git Identities Was a Mess, So I Built gitrole

Why separate identities at all?

The actual problem

What gitrole gives you

The three-command loop

The fresh-machine moment

Agents made this more important, not less

The point

I "accidentally" built an awesome-useless ecosystem. There is an owl. The Tamagotchi is dying. 1997 portfolio devcities.lol

What I Built

Demo

Code

saraeloop / awesome-useless

An awesome list for software that solves nothing. Contributions welcome.

awesome-useless ✨

Contents

🛠️ Tools

🏛️ Projects

🧠 Prompts

🧙 Spells

⚰️ Graveyard

🖥️ Useless Downloads

How I Built It

⚠️ The Incident Report

Prize Category