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">
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>
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)"
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>
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:
- State changes
- Components re-render
- Diffing happens
- The DOM updates
With State.js:
- State attributes update
- CSS variables change
- 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%);
}
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);
}
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
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
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)