DEV Community

Cover image for I Built a Real-Time Simulation Game in a Single HTML File (Without React or Custom JavaScript)
iDev-Games
iDev-Games

Posted on

I Built a Real-Time Simulation Game in a Single HTML File (Without React or Custom JavaScript)

Modern frontend development has normalized an absurd amount of complexity.

Want to build a real-time app or simulation game?

Apparently you now need:

  • React or Vue
  • Virtual DOM rendering
  • State management libraries
  • Bundlers like Vite/Webpack
  • Hydration pipelines
  • Component trees
  • Build steps
  • Thousands of lines of JavaScript

But what if you could build a fully autonomous real-time simulation game using:

  • HTML
  • CSS
  • Declarative attributes

…and almost no custom JavaScript at all?

That’s exactly what I did with Spore Colony, a real-time autonomous simulation game powered entirely by State.js.

The entire application runs from a single HTML file.

No React.
No re-rendering.
No framework overhead.
No build tools.

Just native browser technology pushed to its limits.


🚀 Live Demo

Check out the live CodePen demo here:

👉 Spore Colony — Autonomous Simulation
Codepen URL

And the framework powering it:

📦 GitHub: State-JS by iDev-Games


The Big Idea: The DOM Is Already a Database

Most frontend frameworks treat the DOM like a disposable rendering target.

The actual application state lives somewhere else:

  • JavaScript objects
  • stores
  • reducers
  • proxies
  • signals
  • virtual DOM trees

The framework continuously syncs those structures back into the browser.

But browsers already ship with a fully reactive document system:

The DOM itself.

State.js flips the model completely:

Your HTML becomes the application state layer.

Instead of managing state in JavaScript, state lives directly on elements using native data-* attributes.

Example:

<div id="colony"
  data-state
  data-state-watch="spores,bio,mut,haz,cycle,nodes,boosted,collapsed"
  data-state-var="true"
  data-state-persist="true"
  data-state-toggles="ticking,danger,mutating,thriving"

  data-spores="10"
  data-spores-min="0"
  data-spores-max="100"

  data-bio="0"
  data-bio-min="0"
  data-bio-max="200"

  data-mut="0"
  data-mut-min="0"
  data-mut-max="30"

  data-haz="0"
  data-haz-min="0"
  data-haz-max="20"

  data-cycle="0"

  data-nodes="1"
  data-nodes-min="1"
  data-nodes-max="10"

  data-boosted="0"
  data-collapsed="0">
Enter fullscreen mode Exit fullscreen mode

That single block becomes:

  • the game database
  • the reactive state store
  • the UI binding system
  • the persistence layer

State.js automatically maps those attributes into live CSS custom properties.

Which means the browser itself becomes the rendering engine.


⚡ Building Autonomous Game Loops Without setInterval()

Traditional JavaScript games rely heavily on:

  • loops
  • timers
  • state mutation functions
  • imperative event pipelines

State.js turns all of that into declarative markup.

Here’s an autonomous resource growth loop:

<button id="t-grow"
  data-state
  data-state-trigger
  data-state-bind="colony"
  data-state-attr="spores"
  data-state-increment="calc(var(--state-nodes))"
  data-state-condition="spores < 95 and collapsed < 1"
  data-state-interval="2000"
  style="display:none">
</button>
Enter fullscreen mode Exit fullscreen mode

That single hidden element:

  • runs on an interval
  • evaluates conditions
  • updates state
  • scales dynamically
  • binds to another element
  • triggers autonomously

No manual timer code required.


🧮 Dynamic Game Math Using Native CSS Variables

Because State.js exposes state directly as CSS custom properties, you can use native browser math for game logic.

Example:

data-state-attr="bio"
data-state-increment="calc(10 + var(--state-nodes) * 2)"
Enter fullscreen mode Exit fullscreen mode

That means:

  • infrastructure scaling
  • economy balancing
  • production pipelines
  • progression systems

…can all be expressed declaratively.

Without custom calculation functions.

Without reducers.

Without giant state trees.


🔗 DOM-Based Chain Reactions

One of the most interesting parts of the project was replacing procedural reset logic with pure DOM chaining.

Normally a game reset requires a giant JavaScript function.

With State.js:

<button id="t-r-spores"
  data-state-attr="spores"
  data-state-set="10"
  data-state-trigger-chain="t-r-bio"
  style="display:none">
</button>

<button id="t-r-bio"
  data-state-attr="bio"
  data-state-set="0"
  data-state-trigger-chain="t-r-mut"
  style="display:none">
</button>
Enter fullscreen mode Exit fullscreen mode

Each state mutation triggers the next one like falling dominoes.

The DOM itself becomes an event orchestration system.


🎨 Zero-JS Rendering With Pure CSS

This is where the architecture gets really interesting.

In React:

  1. State changes
  2. Components re-render
  3. Diffing happens
  4. The DOM updates

With State.js:

  1. State attributes update
  2. CSS variables change
  3. The browser handles rendering natively

No component lifecycle.

No reconciliation.

No virtual DOM.


Example: Dynamic Resource Bars

.bf-s {
  background: linear-gradient(
    90deg,
    var(--spore3),
    var(--spore)
  );

  width: var(--state-spores-percent, 10%);
}
Enter fullscreen mode Exit fullscreen mode

The UI updates automatically because the CSS variable itself changes.

No rendering glue code exists.


Example: Reactive Petri Dish Simulation

One of my favorite systems was the colony density visualization.

Instead of looping through cells in JavaScript, I used native CSS selectors tied directly to state attributes.

#colony[data-state-spores="40"]
.cell:nth-child(-n+22) {

  background: var(--spore2);

  box-shadow:
    0 0 5px rgba(57,255,106,0.5);
}
Enter fullscreen mode Exit fullscreen mode

When the spore count changes:

  • the DOM attribute updates
  • the selector matches instantly
  • the browser paints the new cells

The browser’s internal rendering engine does all the work.

No JavaScript loops required.


📉 Why This Approach Is Surprisingly Fast

Modern frameworks often spend enormous resources managing abstraction layers.

State.js removes most of them.

Benefits include:

✅ No Virtual DOM

No diffing.
No reconciliation.
No component tree overhead.


✅ Hardware-Accelerated CSS Rendering

Updates route directly into CSS variables, allowing browsers to optimize transitions on the compositor thread.


✅ Tiny Runtime Footprint

The entire game architecture remains extremely lightweight.

No framework bundle bloat.


✅ Single File Portability

The game can run locally by simply opening:

index.html
Enter fullscreen mode Exit fullscreen mode

No servers required.

No npm install.

No bundling pipeline.


🧠 The Bigger Philosophy

This project started as an experiment.

But it evolved into something much larger:

What if modern frontend development has massively overcomplicated interactivity?

Browsers already provide:

  • reactive styling
  • event systems
  • rendering engines
  • selectors
  • animations
  • variables
  • stateful attributes

Frameworks often rebuild systems browsers already solved years ago.

State.js explores the opposite direction:

  • fewer abstractions
  • more native browser capabilities
  • declarative architecture
  • DOM-first state management

It’s the same philosophy that inspired my earlier project, Trig.js, which reimagined scroll animations using HTML attributes and CSS instead of heavy JavaScript animation frameworks.


🔮 Could HTML Become Reactive Again?

There’s something powerful about opening a single HTML file and immediately understanding:

  • the application state
  • the game rules
  • the rendering logic
  • the UI bindings
  • the behavior system

All in one place.

No build process required.

No hidden architecture.

No framework magic.

Just the web platform itself.


📦 Project Links

State.js

State-JS GitHub Repository

Demo

👉 Spore Colony — Autonomous Simulation
Codepen URL


💬 Final Thoughts

I genuinely think we’re entering a phase where developers are re-evaluating how much tooling is actually necessary.

Not every application needs:

  • a virtual DOM
  • hydration
  • client/server rendering pipelines
  • giant dependency trees

Sometimes the fastest solution is simply leaning harder into the browser itself.

Would you build apps this way?

Could declarative HTML state management become viable for indie games, dashboards, or interactive tools?

Curious to hear what other developers think.

Top comments (0)