DEV Community: Alex Kolovskiy

Fire. Flour. Amore. — a Neapolitan pizzeria landing page with a chef who judges your toppings

Alex Kolovskiy — Tue, 11 Aug 2026 19:48:15 +0000

This is a submission for Frontend Challenge - Comfort Food Edition, Perfect Landing

What I Built

Pizza Mania — a landing page for a fictional Neapolitan pizzeria where the comfort food is pizza, and the comfort is aggressively defended by a chef named Giovanni.

The centerpiece is a build-your-own-pizza workshop: toppings composite as layered SVGs on a live pizza, the price ticks up in real time, and every ingredient lands with a little "thud" on the placemat. Add pineapple, and Giovanni scooters in to protest. Add it again in the same session and he comes back angrier. The third time he just… stops reacting. His disappointment is persisted in sessionStorage, because emotional continuity matters.

Around the workshop there's a full landing page: five house pizzas with a hand-drawn poster art direction, a cart with a real checkout flow (delivery to 11 countries, including Ukraine 🇺🇦), customer reviews — one of which honestly withholds a star — a love letter to Neapolitan dough, and the whole thing in three languages: English, Italian, and Ukrainian, with real pluralization rules for each.

Also: if your cart contains pineapple, the "Place order" button dodges your mouse. Twice. Then it gives up and mutters "va bene." It never dodges keyboard users — Giovanni has opinions, not accessibility violations.

Demo

🍕 Live: https://pizzamania.kolovsky.dev/

📦 Code: https://github.com/alexkolovsky/pizzamania

Try this path: hero → "Build your pizza" → add pineapple → apologize → remove pineapple (Giovanni visibly forgives you) → "Surprise me" → order. Then switch the language to Italian and do it again, because Giovanni is funnier in Italian.

Journey

The stack is deliberately boring in the right places. Astro 7 with fully static output, and exactly one Svelte 5 island for the builder + cart. Everything else ships zero JS. The nav's cart badge lives outside the island — a plain <script> and the island talk to the same nanostores atoms, which turned out to be a lovely way to prove state can cross the island boundary in both directions. GSAP only loads via dynamic import() at the moment a gag actually plays, so Giovanni never touches the initial bundle. No UI framework for styles — hand-written CSS with custom properties and clamp() type.

The real work was making the jokes accessible. Every gag has an accessibility-equivalent path, not just an escape hatch:

One shared aria-live region for the whole page. Toasts are aria-hidden; the same text goes through the live region exactly once, and same-tick announcements get queued and joined instead of overwriting each other (adding a 10th topping says both "topping added" and "maybe you want a lasagna?").
Under prefers-reduced-motion, Giovanni's scene doesn't even mount — his lines arrive as a static toast instead. Same joke, no motion.
The cart panel is a real dialog: focus trap, inert + scroll-lock on everything behind it, focus re-anchoring when the cart/checkout/success stages swap the DOM out from under you, and focus restore to the trigger on close.
The composite pizza is one role="img" whose label reads the current recipe and price out loud.

The thing I'm most proud of is a color: #b07708. The mustard stars looked great and measured 2.05:1 against the cream cards — decorative to a contrast checker, meaningless to an actual human squinting at them. Finding a gold that still reads as gold but clears 3:1 on every background took longer than some features. That's frontend.

What I learned: hreflang links must be absolute URLs (Lighthouse will politely dock you until you believe it); Safari needs tabindex="-1" on the skip-link target; and a marquee needs a pause mechanism even when it already respects reduced motion — WCAG 2.2.2 doesn't care that it looks cool.

Final Lighthouse on the production build: 99 / 100 / 100 / 100 (perf / a11y / best practices / SEO).

Next: sound design (a faint wood-fire crackle on the hero is right there), more Giovanni lore, and possibly a prefers-reduced-judgment media query for pineapple lovers.

No pizzas were harmed. One chef was mildly inconvenienced.

I built a Korean fire-noodle stall in pure CSS — and you can eat it

Alex Kolovskiy — Sat, 08 Aug 2026 18:30:40 +0000

This is a submission for Frontend Challenge - Comfort Food Edition, CSS Art.

Inspiration

Hello all, I want to share my favorite dish — Buldak (Korean fire noodles). I don't eat it that often lately since it's pretty spicy, but I recommend trying it if you've never had Korean food before. Cheers.

Instead of just drawing a bowl, I built a whole Korean street stall (포차 / pocha) where you assemble your own pot: toss in toppings from a side-dish tray, pick your heat level with chili peppers, and — when it's ready — eat it.

Demo

Things to try:

Tap the side dishes — each topping gets tossed into the pot with a little arc and a squash landing, and the dish gets a red 담김 ("added") stamp
Crank the heat to 핵불닭 (nuclear) — the sauce saturates, bubbles boil faster, flames erupt under the pot, the pot starts trembling, and the stall lights flicker
Hit 먹자 EAT! — the chopsticks dive in, the noodles disappear in bites, and you're left with a sauce-smeared pot and a "잘 먹었습니다" note
Watch the receipt — it counts your toppings and totals the price live ## Journey

The gimmick: the entire builder is a CSS state machine. Every topping is a checkbox, the heat level is a radio group, and even "eat" is just one more checkbox — the whole scene reacts through :has() selectors. The challenge allows a sprinkle of JavaScript, and I spent my entire JS budget on one thing: a ~6-line "chef's pick" randomizer button. Everything else — the toss animations, the heat states, the eating sequence — is pure CSS.

Favorite tricks in there:

Noodles from border arcs. Each strand is an ellipse with border: 7px solid transparent and only border-top-color set — you get a clean curved noodle for one element. A pile of them at different sizes and rotations, plus a red radial overlay with mix-blend-mode: multiply for the sauce coating.
The receipt is CSS counters. counter-reset: tops 0 price 350 on the root, then every checked dish does counter-increment: tops 1 price 50, and the bill renders counter(tops) " added · ₩" counter(price) "0". The base pot is ₩3500, each topping adds ₩500 — computed and displayed with zero JavaScript.
Eating in bites, not a wipe. The eat sequence animates clip-path: inset() through stepped keyframes — chomp to 31%, settle back to 28%, chomp to 64%, settle, gone — synced with the chopsticks' dive animation. The little settle-backs between bites sold the effect more than anything else.
Toss physics with one keyframe. Toppings fly in from the tray's direction, overshoot, squash on landing (scale: 1.08 .9), rebound, and settle. Each ingredient keeps its own final rotation because the keyframes end on rotate: var(--r).
Sesame is one element. A single 5px dot with a dozen box-shadow offsets, mixing golden and black toasted seeds. What I learned: :has() has quietly turned CSS into a real state-management tool. Once I stopped thinking "how do I fake interactivity" and started thinking "what is my state and what observes it," the whole thing became a set of declarative rules — honestly cleaner than some JS state code I've written.

I also learned to put transition delays in the checked-state rules, not the base rules. My first eat sequence took three seconds to reset because the delays applied in both directions.

Honest limitation: real drag-and-drop is impossible in pure CSS (nothing can track pointer position), so instead of faking it badly, I made the tap feel physical — the tray dish empties, gets stamped, and the ingredient arcs into the pot. There's a genuine pure-CSS drag primitive (resize handles + container queries) I considered for a "pull to pour sauce" mechanic, but it's clunky on touch, so it didn't make the cut.

Small things I'm proud of: the dented brass 양은냄비 pot (the pot every Korean instant noodle deserves) instead of a generic bowl, the celadon-glazed side dishes, and that prefers-reduced-motion users still get a fully working builder — the eat still works, just without the theatrics.

Next: maybe a slurp. If anyone knows how to make sound in pure CSS, my DMs are open.

Code is MIT — fork it, add your own toppings.

nvm loses your global CLIs every time you switch. So I fixed it.

Alex Kolovskiy — Tue, 14 Jul 2026 23:51:10 +0000

Every nvm user knows this loop. You install a CLI globally, it works, then a week later nvm use 18 for some legacy project and the command is gone. Not broken — gone. command not found. Because nvm doesn't have global packages; each node version has its own lib/node_modules, and switching versions swaps the entire world out from under you.

The standard answers are all bad. nvm reinstall-packages copies everything between versions, which is a sledgehammer and reinstalls things into versions where they don't belong. --default-packages only helps at install time. And "just use npx" means cold-starting your tools through the network.

So I built nvmpin: pin each global package to a specific node version, and it keeps working no matter which version your shell is on.

$ nvm use 16
Now using node v16.20.2

$ which cowsay
/Users/alex/.nvmpin/bin/cowsay

$ cowsay ok
 ____
< ok >
 ----

That's a real transcript from the pre-release smoke test — cowsay is pinned to node 22, the shell is on 16, nothing breaks.

"Isn't this just Volta?"

Mostly, yes — and if you're choosing a version manager from scratch, look at Volta first. It shims everything transparently and it's more complete than this will ever be.

nvmpin exists for one population: people already on nvm who aren't leaving. Volta and nvm fight over your PATH; migrating means unwinding years of muscle memory, dotfiles, CI scripts, and team conventions. nvmpin sits on top of an existing nvm install and changes nothing about how you use nvm. That's the whole pitch. If that's not you, close the tab.

How it works

No daemon, no wrapper around nvm, no PATH interception magic. Three parts:

A registry at ~/.nvmpin/pins.json mapping package → node version.
A shim directory ~/.nvmpin/bin, prepended to PATH after nvm's init.
Generated shims — three-line bash scripts with absolute paths baked in:

#!/usr/bin/env bash
# nvmpin shim for cowsay -> v22.21.1 (do not edit)
exec "/Users/alex/.nvm/versions/node/v22.21.1/bin/node" \
  "/Users/alex/.nvm/versions/node/v22.21.1/lib/node_modules/cowsay/cli.js" "$@"

nvmpin add cowsay --node 22 installs it into node 22's tree and writes the shim. nvmpin move pkg --node 18 reinstalls into 18 — a real reinstall, never a re-point, because native modules are compiled per node ABI. nvmpin scan shows which globals live in which versions. nvmpin doctor tells you when something's broken. Zero dependencies, POSIX only for now.

Simple idea. The interesting part is everything npm did to sabotage it.

Sabotage #1: lifecycle scripts compile against the wrong node

First naive version of the installer: run the target version's npm with the target version's node.

<target>/bin/node <target>/bin/npm i -g node-sass

Looks airtight. It isn't. On npm 10, lifecycle scripts — postinstall, node-gyp — resolve node from the ambient PATH, not from the node that's running npm. So installing node-sass "into node 18" from a shell where node 22 was active produced a binding compiled for ABI 127 — node 22's ABI — sitting inside node 18's tree. Loading it:

Error: The module was compiled against a different Node.js version using
NODE_MODULE_VERSION 127. This version of Node.js requires NODE_MODULE_VERSION 108.

The fix: the installer prepends the target version's bin dir to the spawned PATH, so gyp finds the right node. There's now a regression test that asserts exactly this, because it's the kind of bug that comes back.

Sabotage #2: one stray prefix setting redirects every install

If you have NPM_CONFIG_PREFIX exported — or prefix= sitting in ~/.npmrc from some tutorial five years ago — npm ignores the version tree entirely and installs into that prefix. Your shims then point at paths that don't exist. nvm users are exactly the people likely to have this half-configured; nvm itself refuses to run when it's set.

First instinct: strip the bad env vars. Wrong, twice. Stripping doesn't touch the npmrc form, and over-stripping npm_config_* would eat registry URLs, proxies, and auth tokens — breaking everyone behind a corporate proxy.

The actual fix is one line, and it's better than stripping: assert the correct value. npm's config precedence is env > userconfig > defaults, so setting npm_config_prefix=<versionDir> in the spawned env defeats every npmrc layer and every ambient variable at once.

Almost. While verifying this on npm 10.9, I found a behavior I haven't seen documented anywhere: npm matches the npm_config_ env prefix case-insensitively, and on casing conflicts, last in env order wins. Try it:

$ npm_config_prefix=/tmp/lower NPM_CONFIG_PREFIX=/tmp/upper npm prefix -g
/tmp/upper

Which means a bare assignment can silently lose to a stale uppercase variable that happens to sit later in the environment. So the installer deletes every casing of the key first, then sets its own last. Deterministic, and yes, there's a test.

Sabotage #3: my own doctor called my healthy system broken

nvmpin doctor originally checked that the shim dir precedes every nvm bin dir in PATH — reasonable, since rc misordering means shims permanently lose. Then, during the real-machine smoke test, doctor exited 2 on a system where everything demonstrably worked.

The cause: nvm use prepends the selected version's bin dir to PATH in the live shell. Every time. It's inherent nvm behavior — which means the "shims must be first" invariant is violated in any shell where you've ever switched versions, while the shims keep resolving fine as long as no same-named bin exists in the prepended dir.

A diagnostic that fires in every normal shell trains you to ignore it right before the one time it matters. So the check is now collision-aware: it only errors when an earlier nvm dir actually contains a bin that shadows one of your pins (and even then, not if it's the pin's own target version — identical resolution either way). Bare ordering after nvm use is a note, exit 0.

The part nobody asked about: tests

79 tests, zero dependencies, all node:test. The unit suite runs against fixture nvm trees and a stub npm. But sabotages #1 and #2 are claims about npm's behavior, not mine — a stub that simulates npm honoring $npm_config_prefix proves nothing if npm 11 changes the rules. So there's a gated integration test (NVMPIN_INTEGRATION=1) that runs real npm against a sandbox under a three-way prefix conflict, and it's wired into prepublishOnly — publishing without re-verifying the npm contract is impossible by default. It already paid for itself once: the claims were derived on npm 10.8.2 and the test confirmed they hold on 10.9.4.

Every non-obvious call — all eighteen of them — is written down in DECISIONS.md with the reasoning and, where it exists, the terminal receipt. Four real bugs got caught before a single user existed. I'd rather ship the bug list myself than read it in the issues.

Try it

npm i -g nvmpin
nvmpin setup
nvmpin add <your-most-missed-cli> --node 22

POSIX only (macOS/Linux), node ≥ 18, MIT. If you're on an npm version I haven't verified, run NVMPIN_INTEGRATION=1 npm test in the repo and tell me what the diagnostic line says — that's free contract verification for everyone.

GitHub: github.com/alexkolovsky/nvmpin · npm: npmjs.com/package/nvmpin

I Built an 8-bit RPG With Zero Image or Audio Files. Here's How.

Alex Kolovskiy — Fri, 10 Jul 2026 20:42:58 +0000

A game with no assets folder

Open the source of most browser games and you will find a public/ directory sagging under the weight of PNGs, sprite sheets, and .mp3 files. Open the source of Pixel Quest and you will find… fonts. Two of them. That's it.

No sprite sheets. No music files. No sound effects. And yet the game hums with chiptune battle themes, splashes damage numbers off a lunging hero, and renders four hand-drawn 16×16 heroes marching across a CRT-scanlined landing page.

Everything you see and hear is computed. This is the story of how that came together — a month-long build (74 commits, June to July) of a bilingual, choice-driven, permadeath-optional RPG that lives entirely inside <canvas> and a text editor's worth of arithmetic.

The pitch: pick a class, brave five cursed lands, pass d20 skill checks, out-think telegraphed boss attacks, and choose an ending. In English or Ukrainian. On your phone or your desktop. With nothing downloaded but code.

The stack, briefly

Nothing exotic — the trick is what we don't add:

Next.js 16 (App Router, TypeScript) — the app shell, landing page, and SEO layer.
Phaser 3 — the game engine: scenes, rendering, tweens, input.
Drizzle ORM + Neon serverless Postgres + Auth.js — optional cloud saves.
Vitest + Playwright — unit tests for the combat math and story graph, smoke tests for real gameplay.
Zero runtime art or audio dependencies. Custom i18n, a seeded RNG, a pixel-sprite texture generator, and a WebAudio synth do the rest.

That last bullet is the whole personality of the project. Let's pull it apart.

Sprites are just strings

Every character, enemy, and prop is a 16×16 grid described as an array of strings. Each character is a key into a palette; . is transparent. Here is the warrior, in full:

export const SPRITES: Record<string, PixelSprite> = {
  warrior: {
    colors: { X: "#10101e", S: "#c8d0e0", D: "#8890a8", F: "#f0c090", A: "#4868b0", B: "#283878", G: "#ffd040" },
    rows: [
      "................",
      ".....XXXXXX.....",
      "....XSSSSSSX....",
      "....XSDDDDSX....",
      "....XSFFFFSX..X.",
      "....XXFXXFX..XS.",
      // ...the rest of the knight...
    ],
  },
};

At boot, a generator walks these grids and paints them into Phaser textures pixel-by-pixel. No image decoding, no network round-trips, no onload races — the art is already there the moment the JavaScript parses. It also means a sprite is a diff-able, reviewable, version-controlled artifact. Want to give the mage a bigger hat? Edit two rows of a string and the pull request shows you exactly what changed.

The same sprites pull double duty on the marketing site: a small helper re-renders these grids as inline SVG data URIs so the four classes can parade across the landing page — server-rendered, no client JS required.

Music is arithmetic, not audio

There is no soundtrack file to stream. Instead, a tiny WebAudio synth schedules oscillators against the audio clock — persistent lead and bass "voices" playing note sequences defined per campaign and per scene. Chapters get a wandering theme; boss fights get something with more teeth.

type SfxName = "click" | "hit" | "crit" | "heal" | "hurt" | "death" | "victory" | "levelup" | "phase";

Each effect is a shaped blip — a crit is just a hit with more attitude. Because it's synthesized on demand, the entire audio layer costs zero kilobytes to download and respects independent Sound and Music toggles. Flip music back on mid-battle and it resumes the track the current scene last asked for, because the synth remembers the desired track even while muted. Little touches like that are cheap when your audio engine is a hundred lines of code instead of a media pipeline.

Determinism, so the dice can be trusted

An RPG lives and dies by its randomness, and randomness is notoriously hard to test. The fix is a seeded PRNG — mulberry32 — injected everywhere a die is rolled:

export type Rng = () => number;

export function mulberry32(seed: number): Rng {
  let a = seed >>> 0;
  return () => {
    a |= 0;
    a = (a + 0x6d2b79f5) | 0;
    let t = Math.imul(a ^ (a >>> 15), 1 | a);
    t = (t + Math.imul(t ^ (t >>> 7), 61 | t)) ^ t;
    return ((t ^ (t >>> 14)) >>> 0) / 4294967296;
  };
}

/** Classic d20 roll: integer in [1, 20]. */
export function d20(rng: Rng = defaultRng): number {
  return rollInt(1, 20, rng);
}

In production, defaultRng is Math.random. In tests, you hand the combat engine a fixed seed and assert that a level-3 rogue with a lucky charm passes a DC-14 lockpick exactly when it should. The dice ceremony players see on screen — the d20 tumbling to a verdict — is the same function the test suite pins down to the integer.

The balance sim that caught a lie

Here's my favorite part, because it's where the game caught me in a mistake.

Pixel Quest ships three difficulties, and the top one — Nightmare — promises permadeath and pain. I thought it was brutal. Then I wrote a Monte-Carlo balance simulator (scripts/balance-sim.ts) that plays thousands of full runs with a "competent player" policy: it guards against telegraphed heavy attacks, uses AGI to dodge, ticks status effects on both sides, charges and spends ultimate meters, and has the cleric hold its heal-cleanse until it actually needs it.

The verdict was humbling. Old Nightmare was, statistically, Adventurer difficulty plus permadeath. Its boss attack multiplier (1.025) was actually below Adventurer's (1.07) — Nightmare bosses hit softer. The scary label was a placebo.

So Nightmare got a real identity: a new heavyMul field that makes telegraphed "!!" attacks land at 1.8× if you ignore the warning.

nightmare: {
  enemyHpMul: 1.0,
  enemyAtkMul: 1.05,
  bossHpMul: 1.1,
  bossAtkMul: 1.1,
  dcShift: 2,
  // Heavies land at 1.5 x 1.2 = 1.8x: telegraphs demand an answer.
  heavyMul: 1.2,
  startPotions: 0,
  potionHeal: 12,
  permadeath: true,
},

Now Nightmare's turn-to-turn identity is guard play as survival, not optimization. Miss a telegraph and you feel it. The sim confirmed the new tiers: Nightmare survival lands around 0.25–0.4× the Adventurer rate. The lesson: your intuition about difficulty is a hypothesis; a simulator is the experiment.

A story graph the tests refuse to let me break

The narrative is data: branching scenes, requirements, effects, skill checks, riddles, secret paths, and a moral choice that forks the ending three ways — roughly 4,000 lines of it across four campaigns, every word mirrored in English and Ukrainian.

Prose that large will rot. Links break. A translation goes missing. A chapter forgets to end in a boss. So the story is validated by the unit suite as a graph:

Every scene must be reachable — no orphans.
Every choice must point somewhere real — no dangling links.
Every line must exist in both locales.
Every chapter must terminate in a boss fight.

If I fat-finger a scene id, npm test goes red before a player ever hits a dead end. Content becomes as safe to refactor as code, which is the only way a solo dev keeps four campaigns coherent.

Saving without losing anyone

Progress auto-saves to localStorage after every scene, and — if you sign in — mirrors to Postgres for cross-device play. But saves are where players get hurt, so the code is paranoid on their behalf.

The write itself is best-effort: Safari private mode and quota limits can throw mid-combat, and a crash there would eat the run, so writes are wrapped and failures are swallowed silently — you keep playing, just without persistence. Schema changes run through an explicit migration ladder so a v1 save from launch week upgrades cleanly to v4 today. And if a save blob is ever unreadable — corrupt JSON, a version from the future — it isn't discarded:

// Unknown/future version: park the blob before reporting "no save" so the
// run isn't silently lost when a New Game overwrites the main key.
if (!migrated) safeWrite(BACKUP_KEY, raw);

The bad save gets parked in a backup key so a future fixed client — or a hand recovery — can still bring the run back. Nobody's dragon-slaying afternoon gets thrown away by a schema bump.

Made in Ukraine

One more thing that isn't a technical decision but is the truest part of the project: Pixel Quest is made in Ukraine, ships in Ukrainian as a first-class language (not an afterthought bolted onto English), and the landing page carries a banner for uanimals.org — a hand-drawn pixel cat bobbing beside floating hearts, linking to help for animals caught in the war. It's a small pixel gesture. It felt like the right one.

Where to try it

Pixel Quest runs entirely in the browser — nothing to install, nothing to download. Pick a class, pick a difficulty, and press START.

Play it now: pixelquestgame.com

A few things worth trying on your first run:

Read the telegraphs. When an enemy winds up a !! heavy, guarding isn't optimal play — on Nightmare it's survival.
Turn the sound on. Every note is synthesized on the fly — there isn't a single audio file in the build.

Pixel Quest is a small game, but it's proof that "no assets" is a feature, not a limitation — and that the most interesting parts of a game are often the systems the player never directly sees.

Let me know what you think; I'll continue to improve this project.