惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

博客园_首页
量子位
D
DataBreaches.Net
博客园 - 司徒正美
J
Java Code Geeks
博客园 - 【当耐特】
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
aimingoo的专栏
aimingoo的专栏
B
Blog
The Cloudflare Blog
D
Docker
I
InfoQ
爱范儿
爱范儿
MongoDB | Blog
MongoDB | Blog
腾讯CDC
月光博客
月光博客
Hugging Face - Blog
Hugging Face - Blog
Microsoft Azure Blog
Microsoft Azure Blog
Vercel News
Vercel News
阮一峰的网络日志
阮一峰的网络日志
小众软件
小众软件
S
SegmentFault 最新的问题
GbyAI
GbyAI
有赞技术团队
有赞技术团队

DEV Community

Authentication Security Deep Dive: From Brute Force to Salted Hashing (With Java Examples) Why AI Systems Don’t Fail — They Drift Spilling beans for how i learn for exam😁"Reinforcement Learning Cheat Sheet" I Replaced Chrome with Safari for AI Browser Automation. Here's What Broke (and What Finally Worked) How Python Borrows Other People's Work The $40 Architecture: Processing 1 Billion API Requests with 99.99% Uptime Vibe Coding: A Workflow Guide (From Zero to SaaS) Most webhook security guides protect the wrong side. The scary part is delivery. Headless CMS for TanStack Start: Build a Blog with Cosmic EU Age Verification App "Hacked in 2 Minutes" — What Actually Happened Comfy Cloud’s delete function does not actually remove files Running AI Models on GPU Cloud Servers: A Beginner Guide Event-driven media intelligence with AWS Step Functions and Bedrock I scored 500 AI prompts across 8 quality dimensions — here's what broke How to Call Google Gemini API from Next.js (Free Tier, No Backend Needed) The Portal Protocol: Reclaiming Human Connection in the Age of AI How to Fix Your Team's Scattered Knowledge Problem With a Self-Hosted Forum Intro to tc Cloud Functors: A Graph-First Mental Model for the Modern Cloud Designing Multi-Tenant Backends With Both Ownership and Team Access I Built a Neumorphic CSS Library with 77+ Components — Here's What I Learned PostgreSQL Performance Optimization: Why Connection Pooling Is Critical at Scale Cómo construí un SaaS multi-rubro para gestionar expensas en Argentina con FastAPI + Vue 3 🚀 I Built an Ethical Hacking Scanner Tool – Open Source Project I Replaced /usage and /context in Claude Code With a Single Statusline A Pythonic Way to Handle Emails (IMAP/SMTP) with Auto-Discovery and AI-Ready Design I Collected 8.9 Million Polymarket Price Points — Here's What I Found About How Markets Really Move EcoTrack AI — Carbon Footprint Tracker & Dashboard Everyone's Using AI. No One Agrees How. 5 self-hosted ebook managers worth trying in 2026 Building Your First AI Agent with LangChain: From Chatbot to Autonomous Assistant
I Built a Real-Time Simulation Game in a Single HTML File...
iDev-Games · 2026-05-27 · via DEV Community

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:

  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%);
}

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

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.