Part 1 of a 3 part series

Why I Built a Game Without React

When the “right tool for the job” means no tool at all

Rock-Paper-Scissors-Lizard-Spock desktop reveal phase showing player and house choices with winner glow animation.

Rock-Paper-Scissors-Lizard-Spock desktop reveal phase with winner glow animation.

I recently built a Rock-Paper-Scissors game with a bonus Rock-Paper-Scissors-Lizard-Spock mode. It has animated winner glows, keyboard navigation, screen reader support, and a responsive layout that scales from a 375px phone to an ultrawide monitor.

I used exactly zero frameworks. No React, no Vue, no Svelte. No build step, no bundler, no node_modules folder in sight.

This is the story of why I made that choice — and the surprising things I learned by saying no.

The reflex to reach for React

When I started the project, my first instinct was the same as every other frontend developer’s: scaffold it with Vite, install React, set up a component tree. That’s what we do. It’s comfortable. It’s what every job posting asks for.

But I stopped and asked myself a question I rarely take seriously enough:

What problem would React solve here?

The game has three screens:

1. A pick phase where you choose rock, paper, or scissors

2. A reveal phase that shows your choice, the house’s choice, and the result

3. A rules modal

It has exactly one piece of state: the score. It has no API calls, no routing, no forms, no real-time updates, no multi-user interactions.

I couldn’t name a single problem React would solve that vanilla JS wouldn’t solve just as well — with less complexity.

What a framework would have cost

Let me be concrete about what React would have added to this project.

Bundle size

React + ReactDOM is about 40KB gzipped. My entire JavaScript file is 5KB. That’s eight times the payload for effectively zero benefit to the user.

A build step

React means Vite (or Webpack). Vite means npm create vite@latest. That means node_modules (1,572 packages last time I checked a fresh Vite install). That means a build script, a dev server, a config file. It means asking “why is my build failing?” instead of just opening index.html in a browser.

Cognitive overhead

A React component for this game would look something like:

function GameBoard({ mode, onChoice, result }) {
  return (
    <div className="game-board">
      {result ? (
        <RevealPhase result={result} mode={mode} />
      ) : (
        <Choices mode={mode} onChoice={onChoice} />
      )}
    </div>
  );
}

That’s fine. But it’s also unnecessary. The same logic in vanilla JS is:

function showReveal(playerChoice, houseChoice, result) {
  choicesEl.classList.add('hidden');
  revealEl.classList.remove('hidden');
  // populate the DOM...
}

No virtual DOM, no reconciliation, no hooks. Just direct DOM manipulation. It’s faster to write, faster to run, and easier to debug.

What I gained by going vanilla

1. Deployment is copying files

I deploy this project to Vercel. There’s no build step — just point it at the repo. Any static host works. This is the simplest deployment model that exists, and I got it by choosing the simplest technology.

2. Zero dependencies, zero vulnerability audits

The project has exactly zero entries in package.json. That means zero npm audit warnings, zero supply chain risk, zero “my project broke because a dependency changed its API.” Every line of code is code I wrote and understand.

3. I had to actually understand the DOM

This was the biggest win. Without React’s declarative abstractions, I had to think about:

• When does the DOM actually update? (requestAnimationFrame, layout thrashing)

• How do you manage focus on dynamically appearing elements? (focus trapping, aria-live regions)

• How do you structure CSS so that changing one value scales the entire UI? (custom properties, clamp())

These are real skills that React abstracts away. I’m a better developer for having wrestled with them directly.

Where I would use a framework

I’m not anti-framework. Here’s where I’d reach for one:

• Multiple developers on the same codebase: React’s component boundaries and data flow conventions help teams stay coordinated.

• Complex state management: If the app had multiplayer, real-time scores, or undo/redo, I’d want reactive state.

• Server-side rendering: For an SEO-critical content site, Next.js makes sense.

• Long-lived product: If this were a codebase I’d maintain for years, React’s ecosystem and hiring pool matter.

But a portfolio project with 300 lines of logic and one user? Vanilla JS was the right call.

What I didn’t expect

The hardest part wasn’t the JavaScript — it was the CSS. Responsive circles that scale at every viewport, proportional gradient rings, desktop reveal alignment without JavaScript measurements, a pentagon layout for the bonus mode buttons. These were real engineering problems that a framework wouldn’t have helped with.

If I had reached for React reflexively, I might have stopped thinking about the CSS architecture and leaned on component libraries instead. Going vanilla forced me to confront the browser’s actual capabilities.

The takeaway

The best tool isn’t the one everyone’s hiring for. It’s the one that solves your problem with the least unnecessary complexity.

Ask yourself: ”Am I reaching for this framework because it’s the right tool, or because it’s what I’m used to?”

The answer might surprise you.

This is Part 1 of a 3-part series on building a production-quality game without a framework.

Part 2: One Render Pipeline, Two Games — How I built a dual-mode game engine with zero duplicated code

Part 3: The Art of Responsive CSS — How one CSS variable controls an entire responsive system