DEV Community: iDev-Games

I Built a Full RPG with Zero JavaScript Logic - Here's What I Learned

iDev-Games — Thu, 11 Jun 2026 13:31:56 +0000

A deep dive into State.js by building Gutter Rat: a working SPA game with combat, shops, inventory, and level-ups — all in HTML and CSS.

Here's the CodePen. The JS panel is empty.

Take a minute to play it. Buy gear, pick a fight, grind XP, level up. Then come back and I'll explain exactly how it works and what building it taught me.

What is State.js?

State.js is a reactive state library that exposes application state as HTML data attributes and CSS custom properties. Instead of JavaScript managing the DOM, the DOM is the state — and CSS subscribes to it directly.

It's part of a broader browser-native stack built by @iDev_Games:

Trig.js — scroll position to CSS
Cursor.js — mouse/touch position to CSS
Keys.js — keyboard input to CSS
Motion.js — global animation clock for CSS
Gravity.js — DOM physics engine rendered in CSS
State.js — reactive application state layer

Each one independently useful. Together they form a complete declarative application engine that runs directly in the browser with no build step, no bundler, and no framework.

The philosophy: your HTML is your state graph, CSS is your rendering engine, and JavaScript is only for what JavaScript is genuinely good at.

The Project: Gutter Rat

I wanted to build a demo that pushed State.js hard — not a counter, not a toggle, but something with real game logic: an SPA with multiple panels, an economy, combat with health bars, a shop that modifies stats, dynamic inventory, conditional UI, and automatic level detection.

The result is Gutter Rat — a grimy street RPG in the spirit of old browser games like Hobo Wars. Scraps McBurly. The Rusty Alley. Big Vince. You know the vibe.

What it has:

4-panel SPA (Town, Fight, Gear, Stats) with animated transitions
HP/MP/XP bars driven by CSS custom properties
Gold economy with healing, drinks, scavenging, and gambling
Combat system with punch, haymaker, autofire victory/defeat detection
Shop that dynamically spawns items into an inventory grid
Attribute training (ATK, DEF, SPD)
Level-up toast that fires automatically when XP maxes out
Win/loss tracking

Zero lines of JavaScript logic. One <script> tag pointing at State.js.

How the SPA Routing Works

This is the most immediately useful pattern for anyone building with State.js.

The entire panel-switching system runs on a single numeric attribute:

<div id="app"
     data-state
     data-state-watch="panel"
     data-panel="1" data-panel-min="1" data-panel-max="4">

Nav buttons set it directly:

<button data-state data-state-trigger data-state-bind="app"
        data-state-attr="panel" data-state-value="1">
  🏚️ Town
</button>

CSS does the routing:

.panel { display: none; }
#app[data-panel="1"] .panel-town  { display: block; }
#app[data-panel="2"] .panel-fight { display: block; }

Active nav highlighting follows for free:

#app[data-panel="1"] .nav-btn[data-nav="1"] {
  color: var(--amber);
  border-bottom: 2px solid var(--amber);
}

Why this works better than a toggle-per-panel approach: data-state-attr + data-state-value sets a value directly — idempotent, no flipping. Clicking Town three times in a row stays on Town. Whereas data-state-toggle flips a boolean, which means clicking the same panel twice would close it. For routing, you want assignment, not toggle.

The HUD: CSS Variables as a Render Layer

Once you add an attribute to data-state-watch, State.js exposes it as a CSS custom property automatically. HP becomes --state-hp-percent. That's it.

<div class="bar-fill hp"></div>

.bar-fill.hp {
  width: var(--state-hp-percent);
  background: linear-gradient(90deg, #6b1010, #c84040);
  transition: width 0.3s ease;
}

The bar animates on every HP change with zero JavaScript. The browser's CSS engine handles the interpolation. This is the pattern that makes State.js genuinely fast — you're not triggering layout recalculations through JS, you're updating a CSS variable and letting the compositor handle the rest.

Trigger Chains: Your Game Logic Layer

This is where State.js gets powerful. A single button press can fire multiple sequential state changes via data-state-trigger-chain.

Buying a knife:

<button data-state data-state-trigger data-state-bind="app"
        data-state-instantiate="item-tpl"
        data-state-target="#inv-grid"
        data-state-set-icon="🔪"
        data-state-set-label="Knife"
        data-state-set-bonus="+3 ATK"
        data-state-condition="gold >= 15"
        data-state-trigger-chain="buyKnife,addKnifeAtk">
  Buy
</button>

<!-- Hidden trigger chain buttons -->
<button id="buyKnife"   ...  data-state-attr="gold" data-state-decrement="15"></button>
<button id="addKnifeAtk" ... data-state-attr="atk"  data-state-increment="3"></button>

One click: spawns an inventory card, deducts 15 gold, adds 3 ATK. Three side effects from pure HTML.

Important note about chains: each chain link fires independently. If a link has a data-state-condition that fails, that link is skipped — but the rest of the chain still fires. Design your chains with this in mind. Don't put required dependencies after conditional steps.

Dynamic Inventory with data-state-instantiate

This was the most satisfying feature to get working. The Gear panel starts empty:

<div id="inv-grid">
  <div class="inv-empty">No gear yet. Hit the Town market.</div>
</div>

There's a hidden template:

<div id="item-tpl" class="inv-slot" style="display:none"
     data-state data-state-watch="icon,label,bonus"
     data-icon="🎁" data-label="Item" data-bonus="">
  <span data-state-display="icon">🎁</span>
  <span class="slot-label" data-state-display="label">Item</span>
  <span class="slot-bonus" data-state-display="bonus"></span>
</div>

Each shop button uses data-state-instantiate with data-state-set-* overrides:

<button data-state-instantiate="item-tpl"
        data-state-target="#inv-grid"
        data-state-set-icon="🔪"
        data-state-set-label="Knife"
        data-state-set-bonus="+3 ATK">

State.js clones the template, applies the overrides as data-* attributes on the clone, auto-initialises State.js on the clone, strips display:none, and appends it to #inv-grid. The data-state-display elements inside each clone read from their own local scope, not the parent — so every spawned item correctly shows its own icon and stats.

Autofire: Reactive Logic Without Writing Logic

data-state-autofire="true" fires a trigger automatically the moment its condition flips from false to true. This is the closest thing State.js has to a computed reactive value, and it's how the level-up detection works:

<button id="autoLevelUp"
        data-state data-state-trigger data-state-bind="app"
        data-state-toggle="levelUp"
        data-state-condition="xp >= 100 and levelUp == false"
        data-state-autofire="true"
        data-state-trigger-chain="doLevelUp"
        style="display:none">
</button>

The moment XP hits 100, this fires — no click needed, no JS event listener, no polling. The level-up toast appears and the level increments. Then the "Keep Brawling" button resets XP to 0 and toggles levelUp back off.

Critical gotcha with autofire: if the condition is already true when the page loads, it fires immediately on init. In Gutter Rat, enemyHp starts at 0, which meant enemyHp <= 0 was true on load and the victory autofire was triggering before any fight began. The fix was a fightActive toggle that starts false and only flips true when you actually pick an enemy — gating the autofire with fightActive == true and enemyHp <= 0.

The Gotcha That Will Burn Everyone Once

Data attribute names must be lowercase in CSS selectors and State.js class names.

This is HTML's rule, not State.js's. The DOM normalises all attribute names to lowercase. But the consequence in State.js is specific: data-state-toggles="choosingEnemy" generates the CSS class state-choosingenemy — fully lowercase — not state-choosingEnemy.

If your CSS says:

#app.state-choosingEnemy .enemy-select { display: block; }

It will never match. The correct selector is:

#app.state-choosingenemy .enemy-select { display: block; }

This applies to every camelCase toggle name. levelUp becomes state-levelup. fightActive becomes state-fightactive. Write your CSS selectors in lowercase and you'll never hit this.

The same rule applies to data-state-watch attributes — keep them lowercase with hyphens. data-enemyHp will work for attribute reads, but the CSS variable will be --state-enemyhp-percent. Stick to lowercase throughout and it's consistent.

Setting vs Toggling Booleans

This one is subtle but important. data-state-toggle="victory" flips the boolean. If victory is false, it becomes true. If you call it again, it goes back to false.

That's the wrong tool when you need to set a specific value — like resetting combat state when starting a new fight. The right tool is data-state-attr + data-state-value:

<button id="resetVictory"
        data-state data-state-trigger data-state-bind="app"
        data-state-attr="victory"
        data-state-value="false"
        style="display:none">
</button>

Even though victory is in data-state-toggles, you can write its underlying attribute directly. State.js picks up the change through its MutationObserver and updates the CSS class accordingly. This gives you idempotent state assignment instead of a blind flip — essential for reset operations in game loops.

Debugging: Use the Tools

State.js has a console debug API that would have caught the lowercase CSS issue in seconds:

// See all reactive state at once
State.inspectAll()

// Check specific element
State.inspect('#app')

// Watch attribute changes in real time
State.trace('choosingEnemy', true)
// Logs every change to data-choosingEnemy as it happens

When something isn't working, State.trace('attributeName', true) is the first thing to run. It tells you immediately whether the attribute is changing (State.js working) vs. the CSS not responding (selector issue) vs. the condition not evaluating (logic issue). Those are three completely different problems with completely different fixes.

The Honest Assessment

State.js draws a clean line at the boundary of declarative and algorithmic. Everything reactive — state changes, conditional UI, event-driven side effects, dynamic DOM.

The hybrid approach is the optimal position for most projects: State.js handles the reactive layer, and you write the twenty lines of JS you actually need for the algorithm. You're not replacing JavaScript. You're eliminating the unnecessary JavaScript.

Why This Matters

React solves "how do I make the UI reflect state" by pulling everything into JavaScript and rendering down to the DOM. State.js solves the same problem by treating the DOM as the state store and CSS as the reactive subscriber.

React's approach is powerful but it requires buying into an entire mental model, a build pipeline, JSX, hooks, a component lifecycle. The payload for "show this element when this condition is true" is enormous.

With State.js the payload is one attribute. The CSS you already wrote does the rest.

There's also a real and underserved audience here: designers, WordPress developers, people who are genuinely good at HTML and CSS but hit a wall the moment interactivity requires JavaScript. State.js moves that wall dramatically.

The whole game state in Gutter Rat lives in one <div> opening tag. You can read the document and understand the entire data model without tracing through component trees or module imports. That inspectability is worth more than it sounds.

Try It

Play the game: CodePen
State.js on GitHub: iDev-Games/State-JS
State.js subreddit: r/Statejs
CDN: https://cdn.jsdelivr.net/npm/@idevgames/state-js/src/state.js

The full stack — Trig.js, Cursor.js, Keys.js, Motion.js, Gravity.js, State.js — is at iDev-Games on GitHub.

Tags: javascript css html gamedev webdev

The Architectural Pivot: JS-Reactive Frameworks vs. CSS-Reactive Ecosystems (with Strategic JS)

iDev-Games — Wed, 10 Jun 2026 09:33:57 +0000

For the past decade, frontend engineering has been locked inside a single, dogmatic assumption: if you want a reactive UI, JavaScript must control the screen.

This assumption birthed the Single Page Application (SPA) era. We gave full governance of our layouts over to heavy virtual DOM trees, reactive state proxies, and runtime JavaScript execution loops. To build a modern web app or high-fidelity game layout today, developers increasingly assemble stacks of frameworks, animation engines, state systems, and runtime tooling that collectively place growing pressure on bundle size and main-thread execution.

The result? Massive JavaScript bundles, main-thread layout blocking, brittle dependency chains, and a continuous battle against worsening Core Web Vitals.

But a paradigm shift is happening. By pairing native browser capabilities with a CSS-Reactive Framework like State.js and using JavaScript strategically rather than punitively, we can invert the traditional architecture. The goal isn't to ban JavaScript—it is to alter the Priority of Concerns to build the most performant, reactive, and premium web experiences possible.

The Core Structural Divide

To understand why the CSS-Reactive approach is fundamentally faster, we have to look at how data mutations translate into pixels on the user's screen.

The Old Way: Imperative JS Re-rendering

In a traditional JS-reactive framework, even a tiny state mutation triggers a massive computational sequence. When a value changes, the framework traps it via a proxy or setter, updates an abstract virtual DOM node, runs a diffing algorithm against the live DOM, and directly forces style recalculations by rewriting inline attributes at 60Hz or 120Hz.

JavaScript is forced to do two distinct jobs simultaneously: governing business logic and manually painting layout frames. When the main thread gets busy parsing data or handling asset downloads, the animation thread drops frames, creating visible micro-stutter and lag.

The New Way: The Decoupled Telemetry Layer

A CSS-Reactive ecosystem separates these concerns completely. Tools like State.js, Trig.js, and Cursor.js act as non-intrusive environmental sensors. They observe state triggers, layout boundaries, and user input variables passively, streaming those raw mathematical metrics directly into the DOM as native CSS Custom Properties (--state-hp, --trig-percent, --cursor-x).

Once the telemetry is saved to the CSS environment, JavaScript’s rendering job is completely finished. The framework goes back to sleep, leaving the browser’s native C++ compositing pipeline to handle frame-by-frame sub-pixel interpolation on the hardware-accelerated GPU thread.

Architectural Comparison: Building a Live Search & Scroll Reveal

Let's look at a real-world scenario: an interactive landing page that tracks user scroll progress and includes a real-time, debounced search counter.

1. The Monolithic SPA Stack (Next.js + GSAP + Lenis)

To implement input stabilization, smooth scroll tracking, and reactive UI updates, a traditional enterprise build pulls in a massive army of tools.

<div id="app"></div>

<script>
  // Splitting animation, state, and input normalization across multiple heavy libraries
  import { useState, useEffect } from 'react';
  import { gsap } from 'gsap';
  import { ScrollTrigger } from 'gsap/ScrollTrigger';
  import Lenis from '@studio-freight/lenis';

  gsap.registerPlugin(ScrollTrigger);

  export default function App() {
    const [searchQuery, setSearchQuery] = useState('');

    useEffect(() => {
      // 1. Initialize input scroll hijacking to force smooth mousewheel behavior
      const lenis = new Lenis();
      lenis.on('scroll', ScrollTrigger.update);

      function raf(time) {
        lenis.raf(time);
        requestAnimationFrame(raf);
      }
      requestAnimationFrame(raf);

      // 2. Heavy JS timeline parsing that thrashes getBoundingClientRect() at 60Hz
      gsap.to(".card", {
        scrollTrigger: {
          trigger: ".card-container",
          start: "top center",
          scrub: true
        },
        y: -100,
        opacity: 1
      });
    }, []);

    // 3. Debounce handling logic mixed inside component lifecycle state
    const handleInput = debounce((e) => setSearchQuery(e.target.value), 300);

    return (
      <main className="card-container">
        <input type="text" onChange={handleInput} />
        <div className="card">Interactive Element</div>
      </main>
    );
  }
</script>

2. The CSS-Reactive Stack (State.js + Trig.js)

Here is the exact same feature suite built using a priority-of-concerns architecture. There are no build tools, no compilation steps, and zero lines of structural JavaScript event listeners.

<main id="searchScene" 
      data-state 
      data-state-watch="queryCount"
      data-queryCount="0"
      data-trig-section>

  <input type="text" 
         placeholder="Search..."
         data-state-trigger
         data-state-trigger-on="input"
         data-state-debounce="300"
         data-state-bind="searchScene"
         data-state-attr="queryCount"
         data-state-increment="1">

  <div class="card">Interactive Element</div>
</main>

<style>
  /* 2. Style layer is the absolute authority on visual animations */
  .card {
    /* Trig.js provides passive, native viewport position data automatically */
    transform: translateY(calc(var(--trig-scroll-percent) * -1px));
    opacity: var(--trig-scroll-normalized);

    /* THE MAGIC: A native CSS transition acts as the visual shock absorber,
       eliminating desktop mouse-wheel jitter without any scroll hijacking. */
    transition: transform 0.2s ease-out, opacity 0.2s ease-out;
  }
</style>

The Strategic JS Blueprint: Extending the Playground

A common misconception is that a CSS-Reactive paradigm forces a "No JavaScript" limitation. In reality, it unlocks an infinitely flexible Hybrid Playground. Because the DOM serves as a unified data bus, your custom variables can be instantly ingested by advanced, specialized JS runtimes like GSAP or Three.js (WebGL).

Instead of forcing JavaScript to calculate mundane UI layouts, you dedicate its raw computational power exclusively to what it does best: heavy math orchestration.

Powering a High-Fidelity 3D WebGL Camera via Trig.js Variables

In this hybrid implementation, Trig.js automates the passive DOM-intersection tracking, leaving your custom JavaScript completely clear to manage 3D spatial vector matrices.

window.addEventListener("load", () => {
  const canvas = document.querySelector("#webgl-scene");
  const section = document.querySelector("#three-container");

  // Standard Three.js initialization boilerplate
  const renderer = new THREE.WebGLRenderer({ canvas, antialias: true });
  const scene = new THREE.Scene();
  const camera = new THREE.PerspectiveCamera(60, window.innerWidth / window.innerHeight, 0.1, 100);
  camera.position.set(0, 0, 10);

  // Hook directly into the high-frequency hardware GSAP ticker
  gsap.ticker.add(() => {
    // Read the static CSS variables pre-compiled by Trig.js
    const styles = getComputedStyle(section);
    const trigPercent = parseFloat(styles.getPropertyValue("--trig")) || 0; // 0 to 100
    const trigDeg = parseFloat(styles.getPropertyValue("--trig-deg")) || 0;     // 0 to 360

    const progress = trigPercent / 100; // Normalize 0–1

    // Smoothly glide the WebGL camera coordinates based on environmental data
    gsap.to(camera.position, {
      z: 10 - progress * 8,                     // Fly camera deep into the 3D grid on scroll
      x: Math.sin(trigDeg * Math.PI / 180) * 1.5, // Sway camera gently left/right
      duration: 0.2,
      ease: "power2.out"
    });
  });

  function animate() {
    requestAnimationFrame(animate);
    renderer.render(scene, camera);
  }
  animate();
});

Why Corporations and Premium Agencies are Transitioning

When technical leaders evaluate software architecture, they look past framework hype and calculate hard business metrics. The combination of State.js and native CSS primitives ticks every major corporate engineering box:

1. Hardened Supply Chain Security

Modern projects pull down thousands of nested, unvetted npm modules into their deployment pipelines, exposing corporations to catastrophic supply chain security vulnerabilities. State.js has zero framework dependencies. It is an isolated, auditable file with a secure-by-default architecture that explicitly avoids dangerous evaluation syntax like eval().

2. Massive Core Web Vitals Wins

Google's indexing algorithms directly punish slow-loading sites. By offloading rendering calculations entirely onto the browser's internal layout thread, sites built with a CSS-Reactive architecture achieve great performance scores out of the box, reducing bounce rates and directly driving down customer acquisition costs.

3. Infinite Maintainability

Framework standards change constantly; code written in React five years ago is often incompatible with the contemporary Next.js ecosystem. A CSS-Reactive stack leverages the permanent, everlasting standards of the web platform—HTML Data Attributes, MutationObservers, and CSS Custom Properties. The code you write today will run identically in browsers a decade from now without ever requiring an infrastructure overhaul.

Summary: A Reset of Balance

The modern web platform has evolved past the need for monolithic SPA wrappers.

By utilizing State.js as your data broker and letting native CSS Transitions and Keyframes handle the visual lifting, you reclaim the browser main thread. JavaScript is freed from the labor of layout tracking and restored to its most premium state: an extension layer for rich logic, 3D WebGL synthesis, and creative exploration.

Stop fighting the browser. Let HTML house your state, let CSS drive your motion, and let JavaScript power your imagination.

How the State.js Ecosystem Solves the Performance vs. Experience Paradox in Modern E‑Commerce

iDev-Games — Wed, 03 Jun 2026 19:33:10 +0000

Modern premium e‑commerce has a problem nobody talks about enough:

Luxury brands want fluid, tactile, high‑end interactions —

but the JS runtimes required to achieve them destroy performance.

Magnetic buttons.

Organic hover glows.

3D tilt cards.

Scroll‑reactive animations.

Cursor‑driven lighting.

These effects normally require:

GSAP
Framer Motion
Locomotive Scroll
RAF loops
heavy math
layout thrashing
hydration
virtual DOM diffing

All of which tank performance on mobile and mid‑range devices.

But there’s another way.

When you combine:

State.js (reactive UI state)
Motion.js (time‑based interpolation)
Trig.js (scroll + viewport reactivity)
Cursor.js (spatial tracking)

…you unlock a completely different architecture:

Premium, tactile interactions powered by the browser’s native rendering engine — not a JavaScript animation runtime.

This is the Performance vs. Experience Paradox, solved.

🟢 1. The Magnetic Checkout Button (Zero JS Animation)

Luxury brands love this effect:

A button that pulls toward your cursor like a magnet, then snaps back with a soft, premium feel.

With Cursor.js + CSS, it becomes trivial:

.checkout-btn {
  transition: transform 0.3s ease-out;
}

.checkout-btn.cursor {
  transform: translate(
    calc((var(--cursor-x) - 50%) * 0.3),
    calc((var(--cursor-y) - 50%) * 0.3)
  );
}

No RAF loops.

No JS math.

No animation engine.

Just native CSS transforms driven by Cursor.js variables.

The browser handles the easing.

The compositor handles the animation.

You get 120fps smoothness for free.

🟢 2. The Dynamic Angle Glow (Zero Runtime Math)

This is the “premium hover glow” effect you see on high‑end product cards.

Normally, you’d compute angles in JS every frame.

With Cursor.js:

.product-card.cursor {
  box-shadow: 0 0 30px hsl(var(--cursor-deg), 80%, 60%);
}

Cursor.js gives you:

--cursor-x
--cursor-y
--cursor-deg

…all computed natively, efficiently, and only when needed.

CSS does the rest.

This is how you get that “expensive” feel without a single JS animation loop.

🟢 3. Scroll‑Reactive Luxury Effects with Trig.js

This is where your ecosystem becomes unfairly powerful.

Trig.js gives you:

scroll progress
viewport entry/exit
element-relative percentages
direction
velocity
thresholds

All mapped directly to CSS variables.

This lets you build effects like:

Luxury product reveals

.product {
  opacity: calc(var(--trig-progress));
  transform: translateY(calc((1 - var(--trig-progress)) * 40px));
}

Parallax hero banners

.hero {
  background-position-y: calc(var(--trig-scroll) * 0.3);
}

Scroll‑driven color shifts

.section {
  background: hsl(calc(var(--trig-progress) * 360), 60%, 50%);
}

No scroll listeners.

No RAF loops.

No math in JS.

Just Trig.js feeding CSS.

🧠 Why This Works: The Performance Secret Under the Hood

Cursor.js, Motion.js, and Trig.js aren’t animation engines.

They’re input engines.

They feed the browser:

spatial data
time data
scroll data

…and let CSS handle the rendering.

Here’s why it’s so fast:

1. Passive Event Listeners

Cursor.js and Trig.js listen passively, never blocking scroll or input.

2. Attribute Caching

Element boundaries are cached.

No repeated layout reads.

No thrashing.

3. Selective Updates

CSS variables only update when values actually change.

4. IntersectionObserver Integration

If an element isn’t visible, Trig.js and Cursor.js stop tracking it entirely.

This is the opposite of GSAP/Framer, which run loops regardless of visibility.

🟢 4. Motion.js: The “Premium Feel” Layer

Motion.js gives you:

time
progress
easing
looping
interpolation

This lets you build:

floating product cards
soft hover springs
inertia‑based sliders
time‑driven transitions

…without writing a single RAF loop.

CSS handles the rendering.

Motion.js handles the timing.

The browser does the rest.

🟢 5. The Hybrid Model That Makes It All Work

This is the architecture that ties everything together:

JavaScript handles:

validation
pricing rules
async workflows
inventory checks
checkout logic

State.js handles:

UI state
layout state
toggles
transitions
reactive text
reactive CSS variables

Motion.js handles:

time
interpolation
easing

Cursor.js handles:

spatial input
angles
distances

Trig.js handles:

scroll
viewport
progress
direction

CSS handles:

rendering
transforms
transitions
shadows
filters

This is the browser-native animation engine the web should have had all along.

🟢 The E‑Commerce Payoff

With this ecosystem, you can build:

magnetic buttons
3D tilt cards
scroll‑reactive reveals
cursor‑reactive glows
inertia‑driven sliders
premium micro‑interactions

…with near-zero runtime overhead.

This is how you deliver:

luxury feel
instant responsiveness
perfect smoothness
minimal JS
maximum battery life
maximum accessibility

And you do it using the browser’s native rendering pipeline, not a JS animation engine.

🟢 Final Thought

The State.js ecosystem isn’t “another frontend framework.”

It’s a new way to build premium, tactile, high‑performance web experiences using:

declarative UI
native CSS
minimal JS
browser‑native rendering

This is how you break out of the Performance vs. Experience Paradox — and build e‑commerce that feels alive without sacrificing speed.

The Hybrid Architecture That Makes State.js Unstoppable

iDev-Games — Wed, 03 Jun 2026 18:32:19 +0000

(Declarative UI + Imperative Logic = The Sweet Spot)

Most HTML‑first frameworks hit a hard boundary the moment your UI logic becomes procedural, multi‑step, or algorithmic. Cross‑field validation, async inventory checks, dynamic pricing rules — these are not things you should try to express inside declarative attributes.

But here’s the part people miss:

State.js was never designed to replace JavaScript.

It was designed to replace DOM code.

And when you pair standard JavaScript for the heavy logic with State.js for the visual reactions, something magical happens:

No DOM manipulation
No class toggling
No template re-rendering
No hydration
No virtual DOM
No framework lifecycle overhead

Just pure logic → pure UI, with the browser doing the rendering work natively.

This hybrid model is not a workaround.

It’s the ideal architecture for State.js.

🟢 Why This Hybrid Model Works So Well

1. True Separation of Concerns

Your JavaScript does nothing but compute data.

No querySelector.

No classList.add.

No “toggle this element when that element changes.”

Your HTML/CSS does nothing but react to state.

This is the cleanest separation you can get on the web.

2. Zero Framework Lock‑In

If a developer knows JavaScript, they can write the logic.

If they know HTML/CSS, they can build the UI.

There are no lifecycle hooks, no component trees, no hydration rules, no custom syntax to learn.

3. Native Performance

When you do:

formEl.state.valid = true;

State.js updates:

attributes
CSS variables
text bindings

…all using the browser’s native rendering pipeline.

No diffing.

No reconciliation.

No memory churn.

Just instant paint.

🟢 A Real E‑Commerce Example (The Live Pattern)

Here’s what a real checkout validation flow looks like using the hybrid model.

1. The HTML (Clean & Semantic)

<div id="checkout-form" data-state data-shipping-cost="0" data-valid="false">

  <input type="text" id="zipcode" placeholder="Enter Zip Code">

  <div data-state-condition="valid == false" class="error-msg">
    Please enter a valid shipping address.
  </div>

  <div data-state-condition="valid == true" class="success-msg">
    Shipping calculated! Cost: £<span data-state-display="shipping-cost"></span>
  </div>
</div>

No JS logic.

No DOM manipulation.

Just declarative UI.

2. The JavaScript (Pure Logic)

const formEl = document.getElementById('checkout-form');
const zipInput = document.getElementById('zipcode');

zipInput.addEventListener('input', async (e) => {
  const zip = e.target.value;

  if (zip.length === 5) {
    const response = await fetch(`/api/shipping?zip=${zip}`);
    const data = await response.json();

    formEl.state.shippingCost = data.cost;
    formEl.state.valid = true;
  } else {
    formEl.state.valid = false;
  }
});

No DOM updates.

No class toggles.

No template re-renders.

Just data → state → UI.

🟢 Why This Matters for E‑Commerce

E‑commerce is 90% UI state:

cart drawer open/close
variant switching
“free shipping” progress bars
quantity selectors
error/success messages
loading states
stock indicators
modal popups
mobile menus

State.js handles all of this declaratively and instantly.

The remaining 10% — the business logic — belongs in JavaScript or the backend.

And that’s exactly how it should be.

🟢 The Final Architecture (The One That Actually Scales)

State.js handles:

UI state
visual state
layout state
animations
transitions
toggles
progress bars
variant switching
micro‑interactions

JavaScript handles:

validation
pricing rules
async workflows
inventory checks
checkout logic

Together:

You get a system that is:

simpler than React
cleaner than Alpine
more expressive than HTMX
more native than Stimulus
more flexible than Web Components

This is the architecture that makes State.js “unstoppable.”

🚀 State.js - Build Reactive, Interactive UIs Using Only HTML + CSS

iDev-Games — Wed, 03 Jun 2026 13:36:57 +0000

Most frontend tools make you learn a framework, write components, manage state, and fight a build pipeline… just to update a number on the screen.

State.js flips that model on its head.

It turns HTML data attributes into a fully reactive UI engine - exposing your element’s state as CSS variables, updating automatically, and letting you build dynamic interfaces without you writing any JavaScript logic yourself.

If you know HTML and CSS, you already know how to use State.js.

✨ What State.js Actually Does (In Plain English)

State.js watches your HTML elements and automatically exposes their state as CSS variables:

data-health="75" → --state-health: 75
data-health-max="100" → --state-health-percent: 75%

Then you use those variables in CSS:

.health-bar {
    width: var(--state-health-percent);
}

Change the attribute → UI updates instantly → CSS animates it.

No JS functions.

No components.

No re-renders.

No virtual DOM.

Just HTML + CSS.

🔥 Why Developers Love It

1. You don't need to write any JavaScript Logic

You can build:

dashboards
progress bars
form interactions
clicker games
idle games
RPG UIs
video players
reactive animations

…without writing a single line of JS.

2. Designers Can Work Directly in the Code

State.js exposes everything as:

CSS variables
data attributes
conditional classes

Designers don’t need to touch JS files or understand framework lifecycles.

3. Backend‑First Friendly

Works perfectly with:

Laravel
Rails
WordPress
Django
Phoenix
HTMX

No bundlers.

No hydration.

No client‑side routing.

Just reactive HTML.

4. Game‑Dev Ready

State.js includes:

timers
computed values
sound effects
persistence
event dispatch
interval triggers
auto‑fire logic
conditional classes

You can build a full idle game in pure HTML.

⚡ What You Can Build in 30 Seconds

A clicker game:

<div id="clicker" data-state data-score="0" data-state-watch="score">
    <h1>Score: <span data-state-display="score"></span></h1>

    <button data-state-trigger
            data-state-bind="clicker"
            data-state-attr="score"
            data-state-increment="1">
        Click Me!
    </button>
</div>

A health bar:

<div data-state data-hp="75" data-hp-max="100" data-state-var="true">
    <div class="bar" style="width: var(--state-hp-percent);"></div>
</div>

A form that tracks focus + changes:

<input data-state-trigger data-state-trigger-on="focus"
       data-state-bind="form" data-state-attr="focusCount" data-state-increment="1">

A video progress bar:

video::after {
    width: var(--state-progress);
}

A toggleable UI state:

<div data-state data-state-toggles="active" data-active="false"></div>

🧩 The Magic Primitives (The 80% You Need to Know)

Here are the core building blocks that let you build anything:

1. `data-state`

Turns an element into a reactive state container.

2. `data-state-watch="attr1,attr2"`

Watches attributes and exposes them as CSS variables.

3. `data-state-trigger`

Makes an element update state when interacted with.

4. `data-state-attr="health"`

Which attribute to update.

5. `data-state-increment="10"`

Add to a value.

6. `data-state-set="100"`

Set a value exactly.

7. `data-state-condition="gold >= 50"`

Only fire if condition is true.

8. `data-state-autofire="true"`

Fire automatically when condition becomes true.

9. `data-state-text="HP {hp}/{hpmax}"`

Template string interpolation.

10. `data-state-class="critical"`

Conditional CSS classes.

11. `data-state-interval="1000"`

Run triggers every N ms (timers, regen, idle loops).

12. `data-state-sound="coin"`

Play procedural sound effects.

13. `data-state-persist="true"`

Save + restore state from localStorage.

14. `data-state-trigger-on="input|scroll|mouseenter|submit"`

Event‑based triggers with debounce/throttle.

15. `data-state-include="component.html"`

HTML includes — reusable components with no build step.

🎮 Example: A Full Idle Game in Pure HTML

You can literally build this with no JS:

gold counter
click power
upgrades
level scaling
passive income
auto‑leveling
sound effects
persistence

All declarative.

This is why State.js is exploding in game‑dev circles.

🎨 Example: A Fully Reactive UI Component

<div id="player"
     data-state
     data-state-watch="health,mana,xp"
     data-state-var="true"
     data-health="100"
     data-mana="80"
     data-xp="450">

    <div class="health" style="width: var(--state-health-percent)"></div>
    <div class="mana" style="width: var(--state-mana-percent)"></div>
    <div class="xp" style="width: var(--state-xp-percent)"></div>
</div>

CSS handles the rest.

🧠 Why This Works: The Mental Model

State.js is built on one simple idea:

HTML holds the data.

CSS reacts to the data.

State.js keeps them in sync.

That’s it.

No components.

No framework.

No build step.

No hydration.

No virtual DOM.

Just declarative UI.

🚀 Want to Go Deeper?

The README is your full reference manual — every primitive, every example, every advanced feature.

But with what you’ve learned here, you can already:

build reactive dashboards
build interactive UI
build game interfaces
build idle games
build RPG UIs
build form logic
build video players
build reusable components

All with HTML + CSS only.

View the repo here

A New Stack for Turning HTML & CSS Into an Application Layer

iDev-Games — Tue, 02 Jun 2026 13:44:54 +0000

(State.js, Motion.js, Gravity.js, Cursor.js, Keys.js — a browser‑native ecosystem)

For years, frontend development has revolved around one assumption:

If you want interactivity, state, animation, or physics — you need a framework.

React, Vue, Svelte, Solid… all incredible tools, but they all share the same core idea:

JS owns the state
JS owns the rendering
JS owns the reactivity
JS owns the lifecycle

HTML and CSS are treated as passive output layers.

But what if that assumption is wrong?

What if the browser already has the primitives we need — and we just haven’t been using them as a unified system?

That’s the question that led me to build a small ecosystem of libraries that all share one philosophy:

Expose browser signals to CSS.

Let HTML declare behaviour.

Let CSS render it.

Use JS only as the glue.

This post introduces that ecosystem.

Why This Stack Exists

Modern frontend development is powerful — but also heavy.

Bundlers
Virtual DOMs
Component compilers
State libraries
Effect systems
Re-renders
Signals
Hooks
Stores

All to build things the browser can already do.

Meanwhile, CSS has quietly evolved into a reactive rendering engine:

CSS variables
calc()
transitions
animations
container queries
view transitions
scroll-driven animations
:has()
@property
custom easing

And HTML has evolved into a declarative configuration surface:

attributes
custom elements
dataset
templates
inert
popovers

So the question became:

What if we treat HTML + CSS as the application layer,

and JavaScript as the runtime that feeds them state?

That’s the foundation of this stack.

The Stack (Browser‑Native, Declarative, Modular)

Each library does one thing, exposes one set of signals, and stays tiny.

1. State.js — CSS‑Reactive State Engine

State.js exposes reactive state directly to CSS variables.

<div id="player"
     data-state
     data-state-watch="health,score"
     data-state-var="true"
     data-health="100"
     data-health-min="0"
     data-health-max="100"
     data-score="0">

    <div class="health-bar"></div>
</div>

No re-renders.

No virtual DOM.

No diffing.

Just state → CSS → rendering.

2. Motion.js — Scroll, Time & Viewport Signals

Motion.js exposes:

scroll progress
element visibility
time
easing
playback

…as CSS variables.

<div data-motion data-motion-var="true" data-motion-duration="2000">
  <!-- CSS animates based on scroll/time -->
</div>

3. Gravity.js — Physics Exposed to CSS

Gravity.js simulates:

gravity
velocity
friction
forces

…and uses CSS transform to simulate physics.

<div data-gravity data-gravity-type="static">
  <!-- CSS animates based on physics -->
</div>

This lets designers build physical-feeling interfaces without writing physics code.

4. Cursor.js — Cursor State as CSS Variables

Cursor.js exposes:

x/y position
velocity
direction
hover state

…to CSS.

<div data-cursor>
  <!-- CSS reacts to cursor movement -->
</div>

5. Keys.js — Keyboard State as CSS Variables

Keys.js exposes:

key pressed
key held
key released

…to CSS.

<div data-keys>
  <!-- CSS reacts to keyboard input -->
</div>

Why This Works

Because CSS is already a reactive rendering engine.

When you expose state to CSS variables:

CSS handles the rendering
CSS handles the animation
CSS handles the interpolation
CSS handles the transitions
CSS handles the layout

JavaScript becomes:

the state updater
the signal provider
the glue

Not the renderer.

This flips the traditional model:

Traditional	This Stack
JS renders	CSS renders
JS animates	CSS animates
JS manages state	JS exposes state
HTML is passive	HTML is declarative
CSS is styling	CSS is reactive

Why Not Just Use React?

React is incredible — but it’s a UI framework.

This stack is a browser-native runtime.

React owns:

rendering
state
components
lifecycle

This stack owns:

signals
state exposure
declarative behaviour
CSS-driven rendering

They’re not competitors.

They’re different layers.

You could even use them together.

What This Enables

This stack makes it trivial to build:

physical-feeling UI
scroll-reactive UI
cursor-reactive UI
keyboard-reactive UI
time-based UI
stateful UI
animated UI

…without writing application logic.

It also opens the door to something bigger:

A new authoring medium where designers can build interactive systems without touching JS.

Think:

Figma-like tools that export real interactions
CSS-driven physics
declarative behaviour graphs
HTML as the app layer
CSS as the rendering engine
JS as the runtime

This is the direction the web has been moving toward for years.

This stack just pushes it further.

Where This Goes Next

This isn’t a framework.

It’s not a React competitor.

It’s not a “React killer.”

It’s a new layer.

A browser-native layer.

A declarative layer.

A layer that asks:

How much interactivity can we get from HTML + CSS before we need application code?

And the answer so far is:

More than people think.

If You Want to Explore the Stack

Here are the individual libraries:

State.js — CSS-reactive state
Motion.js — scroll/time signals
Gravity.js — physics signals
Cursor.js — cursor signals
Keys.js — keyboard signals

Each one is tiny, focused, and works independently.

But together, they form something new.

A stack.

A philosophy.

A new way of thinking about the browser.

The Scale Misconception: Why State.js Scales Endlessly (Where Traditional SPAs Fail)

iDev-Games — Mon, 01 Jun 2026 14:22:07 +0000

For years, frontend developers have been told the same thing:

If you want to build a large-scale application, you need a large-scale JavaScript framework.

The assumption is everywhere. If your application is expected to grow, you're expected to adopt a complex client-side architecture built around React, Vue, Angular, or another framework that manages application state entirely within the browser.

The industry has largely accepted this as fact.

But what if we've misunderstood what "scaling" actually means?

Because in practice, many large Single Page Applications (SPAs) don't scale by becoming simpler, faster, or easier to maintain. They scale by accumulating more client-side state, larger JavaScript bundles, more hydration overhead, and increasingly complex frontend architectures.

State.js takes a fundamentally different approach.

Instead of treating the browser as an application server, State.js acts as a lightweight visual orchestration layer for the DOM. Business logic remains on the backend where it belongs, while State.js handles reactive visual state directly within HTML and CSS.

The result is an architecture that can scale from a simple landing page to a massive enterprise platform without requiring an ever-growing client-side application layer.

The Modern Misunderstanding of Frontend Scalability

When developers talk about scalability, they're often referring to frontend frameworks and state management solutions.

Questions usually sound like this:

Can React handle a million users?
Will Vue scale with a growing codebase?
Should enterprise applications use Angular?
Which frontend framework scales best?

The problem is that these questions focus on tooling instead of architecture.

A frontend framework doesn't determine whether an application scales.

Architectural boundaries do.

Most applications struggle to scale because responsibilities become blurred. Business logic, security concerns, application data, visual state, and rendering behavior become tightly coupled inside the browser.

As complexity increases, the frontend grows into a second application that mirrors the backend.

That's where scalability problems begin.

Proper Separation of Concerns: Security and Logic

To understand why State.js scales differently, it's important to separate two completely different categories of data.

Business-Critical Data

This includes:

User authentication
Financial transactions
Permission validation
Database operations
API integrations
Business rules

This data is sensitive, authoritative, and security-critical.

It belongs on the server.

Visual State

This includes:

Whether a menu is open
Which tab is active
Animation progress
Component visibility
Theme preferences
Interactive UI behavior

This state exists purely to control presentation.

It belongs in the frontend.

The distinction seems obvious, yet modern SPA architectures frequently blur these responsibilities.

The SPA Mistake

Traditional Single Page Applications often require developers to rebuild large portions of their backend architecture in JavaScript.

The process usually looks something like this:

Fetch raw JSON from APIs
Store it in a frontend state manager
Validate and transform the data
Synchronize state across components
Reconstruct UI from that state

The frontend effectively becomes a second application layer.

As systems grow, developers end up managing:

Large client-side state trees
Complex dependency chains
Hydration issues
State synchronization problems
Security considerations
Performance bottlenecks

The browser becomes responsible for work that the server is already capable of handling.

This duplication introduces complexity that often gets mistaken for scalability.

The State.js Approach

State.js follows a much simpler principle:

The backend remains the source of truth.

Whether you're using Laravel, WordPress, Ruby on Rails, Node.js, Django, or another backend framework, your server handles:

Authentication
Validation
Authorization
Business rules
Database interactions

The server renders the HTML.

State.js then operates directly at the DOM layer, managing visual behavior without attempting to duplicate backend responsibilities.

Instead of building and maintaining massive JavaScript object trees, State.js connects state directly to:

HTML attributes
CSS custom properties
DOM elements

This creates a clear separation between application logic and presentation logic.

Security stays on the server.

Interactivity stays in the browser.

Each layer performs the task it was designed to handle.

Why This Architecture Scales Better

The biggest scalability gains don't come from adding more frontend infrastructure.

They come from reducing unnecessary complexity.

State.js achieves this through architectural simplicity.

No Business Logic Duplication

The backend remains responsible for data and business rules.

You don't need to recreate validation systems, permission layers, or database structures inside the browser.

Smaller JavaScript Footprint

Because State.js focuses exclusively on visual state, applications avoid shipping unnecessary client-side infrastructure.

Smaller bundles mean:

Faster page loads
Better mobile performance
Lower memory consumption
Improved user experience

Reduced Cognitive Overhead

Developers can reason about systems more easily when responsibilities are clearly separated.

The backend handles business logic.

State.js handles presentation state.

There is no ambiguity about where functionality belongs.

Scaling Everywhere HTML Exists

One of the most overlooked benefits of State.js is its portability.

Because it operates directly on native HTML and the DOM, it works virtually anywhere HTML is generated.

That includes:

Laravel applications
WordPress websites
Ruby on Rails platforms
Node.js servers
PHP applications
Enterprise CMS systems
Static site generators

You don't need:

Complex build pipelines
Framework migrations
Hydration layers
Frontend rewrites

You simply integrate State.js into existing HTML output.

This makes it particularly attractive for organizations with large legacy systems that need modern interactivity without rebuilding their entire frontend stack.

A Scalable E-Commerce Example

Consider a shopping cart.

Many SPA architectures maintain the entire cart structure in browser memory, synchronizing changes between components and APIs.

With State.js, the server remains responsible for cart management.

The frontend simply reflects the current state.

<div id="cart-manager"
     data-state
     data-state-items="3"
     data-state-total="149.99"
     data-state-view="summary">

    <span class="cart-badge">
        var(--state-items)
    </span>

    <div class="cart-overlay">
    </div>
</div>

When a user adds an item:

A background request updates the server
The server calculates the new state
Updated attributes are returned
State.js updates the DOM
CSS handles the visual transition

The browser focuses on rendering.

The server focuses on business logic.

Each system performs the work it does best.

Why State.js Scales Endlessly

Zero Long-Term State Accumulation

Many frontend architectures maintain increasingly large state trees as applications grow.

State.js binds directly to DOM elements instead.

When elements are removed, browsers naturally garbage-collect associated state.

This minimizes long-term memory growth.

No Hydration Overhead

Hydration is one of the largest performance costs in modern frontend applications.

The browser must:

Download JavaScript
Parse JavaScript
Execute JavaScript
Reconstruct application state
Attach event handlers

State.js avoids this process by operating directly on rendered HTML.

Interactive behavior becomes available immediately.

Works with Monoliths and Micro-Frontends

Whether your architecture consists of:

One large backend
Multiple services
Distributed micro-frontends
Hybrid systems

State.js remains consistent.

Any HTML-producing service can emit compatible state attributes without interfering with others.

This flexibility allows organizations to evolve their architecture without rewriting frontend state management systems.

Security Benefits of Server-First Architecture

Security is rarely discussed in frontend scalability conversations.

It should be.

Every piece of business logic moved into the browser becomes more exposed and more difficult to control.

By keeping critical operations on the server:

Authentication remains protected
Authorization remains centralized
Validation remains consistent
Sensitive logic remains private

State.js doesn't attempt to solve security in the frontend.

Instead, it avoids creating the problem in the first place.

Stop Over-Engineering Frontend Scale

Many organizations assume frontend scalability requires more abstraction layers, more state managers, and larger frameworks.

Often the opposite is true.

Applications become difficult to scale because too much responsibility has been pushed into the browser.

State.js takes a different path.

By keeping business logic on the backend and limiting frontend responsibilities to visual state orchestration, it eliminates much of the complexity that causes large applications to become difficult to maintain.

The result is a simpler architecture, a smaller JavaScript footprint, better performance, stronger security boundaries, and a frontend that can grow without accumulating unnecessary complexity.

Conclusion

The biggest misconception in modern web development is that large applications require massive client-side frameworks to scale.

In reality, many SPA architectures introduce complexity by duplicating backend responsibilities in the browser.

State.js rejects that model.

Instead of acting as a client-side application platform, it serves as a lightweight visual orchestration layer that works directly with the DOM, CSS custom properties, and native HTML.

Business logic remains secure on the server.

Visual state remains fast in the browser.

And because those responsibilities remain clearly separated, State.js can scale from a simple marketing site to a large enterprise application without requiring the architectural overhead that often makes traditional SPAs difficult to maintain.

Sometimes the path to better scalability isn't adding more JavaScript.

It's using less of it.

⭐ State.js + Keys.js Tutorial - Build Interactive UI with Pure HTML & CSS

iDev-Games — Fri, 29 May 2026 20:30:10 +0000

State.js gives you reactive state.

Keys.js gives you reactive keyboard input.

Together, they let you build interactive UI, controls, and even simple games using only HTML attributes, with no JavaScript logic.

This tutorial teaches:

how Keys.js tracks keyboard state
how State.js reacts to it
how to bind keys to state
how to build interactive UI
how to animate with CSS
how to build a small “move the box” demo

Let’s go.

⭐ 1. What Keys.js Actually Does

Keys.js listens to keyboard events and exposes them as:

CSS variables
HTML attributes
classes

Example:

<div data-keys></div>

Keys.js automatically creates:

--keys-a: 1 or 0
--keys-space: 1 or 0
--keys-last: "a"

And adds classes like:

.keys-a
.keys-space

Learn more: Keys.js basics

⭐ 2. What State.js Does With That

State.js can react to:

CSS variables
attributes
events
conditions

So when Keys.js updates:

--keys-left: 1

State.js can use that to:

update state
change classes
animate with CSS
move elements

This is the reactive input pipeline:

Keyboard → Keys.js → CSS variables → State.js → UI

⭐ 3. Basic Setup

Include both libraries:

<script src="https://cdn.jsdelivr.net/npm/@idevgames/state-js/src/state.min.js"></script>
<script src="https://cdn.jsdelivr.net/npm/@idevgames/keys-js/src/keys.min.js"></script>

Add the Keys.js root:

<div data-keys></div>

Now the entire page reacts to keyboard input.

⭐ 4. Detecting Key Presses with CSS

Let’s show when the user presses the spacebar.

<div class="indicator"
     data-keys
     data-state
     data-state-class="active: keys.space">
  Press SPACE
</div>

Explanation:

data-keys → enable Keys.js
keys.space → true when space is pressed
data-state-class="active: keys.space" → add .active when pressed

CSS:

.indicator {
  padding: 20px;
  background: #444;
  color: white;
  transition: background 0.2s;
}

.indicator.active {
  background: #4caf50;
}

This is a reactive UI element driven by keyboard input.

⭐ 5. Using Keys to Change State

Let’s increment a counter when the user presses ArrowUp.

<div id="counter"
     data-state
     data-count="0"
     data-state-on="keys.arrowup => count += 1"
     data-state-text="Count: {count}">
</div>

What happens:

Keys.js fires a keys.arrowup event
State.js runs count += 1
UI updates automatically

This is the State.js event system in action.

Learn more: State.js event system

⭐ 6. Using Keys to Move an Element (No JS Logic)

Let’s build a simple “move the box” demo.

HTML

<div id="player"
     data-state
     data-x="100"
     data-y="100"
     data-state-on="
       keys.arrowleft => x -= 5;
       keys.arrowright => x += 5;
       keys.arrowup => y -= 5;
       keys.arrowdown => y += 5
     ">
</div>

CSS

#player {
  width: 50px;
  height: 50px;
  background: dodgerblue;
  position: fixed;
  transform: translate(var(--state-x), var(--state-y));
}

What’s happening:

Keys.js detects arrow keys
State.js updates data-x and data-y
CSS moves the element using transforms
No JavaScript logic
No game loop
No re-renders

This is DOM-native movement.

⭐ 7. Smooth Movement (Holding Keys)

Keys.js exposes “held down” state as CSS variables:

--keys-arrowleft: 1

We can use autofire to move continuously:

<div id="player"
     data-state
     data-x="100"
     data-y="100"
     data-state-autofire="
       if keys.arrowleft then x -= 3 every 16ms;
       if keys.arrowright then x += 3 every 16ms;
       if keys.arrowup then y -= 3 every 16ms;
       if keys.arrowdown then y += 3 every 16ms
     ">
</div>

This creates smooth WASD/arrow movement without JS.

Learn more: State.js intervals

⭐ 8. Using Keys to Trigger Animations

<div id="box"
     data-state
     data-state-class="jump: keys.space">
</div>

CSS:

#box.jump {
  animation: jump 0.3s ease;
}

Pressing space triggers a CSS animation.

⭐ 9. Using Keys to Toggle UI

<div id="menu"
     data-state
     data-open="false"
     data-state-on="keys.escape => open = !open"
     data-state-class="visible: open">
  Menu Content
</div>

Press ESC → open/close menu.

⭐ 10. Full Example — Move a Box + Change Color + Show Key

<div data-keys></div>

<div id="player"
     data-state
     data-x="100"
     data-y="100"
     data-color="blue"

     data-state-on="
       keys.arrowleft => x -= 5;
       keys.arrowright => x += 5;
       keys.arrowup => y -= 5;
       keys.arrowdown => y += 5;
       keys.space => color = 'red'
     "

     data-state-style="background: {color}">
</div>

<div id="info"
     data-state
     data-state-text="Last key: {keys.last}">
</div>

CSS:

#player {
  width: 50px;
  height: 50px;
  position: fixed;
  transform: translate(var(--state-x), var(--state-y));
}

This gives you:

movement
color change
last key display
all reactive
all declarative
zero JS logic

⭐ Why State.js + Keys.js Works So Well

Because they follow the same philosophy:

✔ HTML = structure

✔ CSS = behavior

✔ Attributes = API

✔ JS = engine, not authoring

✔ Zero build step

✔ Zero dependencies

✔ Browser-native

State.js Event System - The Complete Beginner’s Guide

iDev-Games — Fri, 29 May 2026 20:15:23 +0000

State.js introduces a new way to build reactive UI:

HTML holds the data.

CSS reacts to the data.

Events change the data.

This tutorial explains how State.js listens to events, how you trigger state changes, and how to build interactive UI without writing JavaScript logic.

⭐ 1. What Is a State.js Event?

A State.js event is simply:

a DOM event (click, input, mouseover, keydown, etc.)
connected to a state mutation
written declaratively in HTML

Example:

<div data-state
     data-count="0"
     data-state-on="click => count += 1"
     data-state-text="Count: {count}">
</div>

When you click the element:

count increases
State.js updates the attribute
CSS variables update
the text updates

All without JavaScript logic.

Learn more: State.js triggers

⭐ 2. The `data-state-on` Attribute

This is the core of the event system.

<div data-state
     data-active="false"
     data-state-on="click => active = !active">
</div>

This toggles the data-active attribute every time the element is clicked.

State.js then:

updates CSS variables
updates any bound text
updates any reactive classes

⭐ 3. Listening to Any DOM Event

You can listen to any event the browser supports.

Click

data-state-on="click => count += 1"

Input

data-state-on="input => value = event.target.value"

Mouseover

data-state-on="mouseover => hovered = true"

Mouseout

data-state-on="mouseout => hovered = false"

Keydown

data-state-on="keydown => key = event.key"

State.js doesn’t invent new events — it uses the browser’s native ones.

Learn more: Event expressions

⭐ 4. Using Event Data (`event`)

State.js exposes the event object as event.

Example: capture the clicked element’s text.

<div data-state
     data-last=""
     data-state-on="click => last = event.target.textContent"
     data-state-text="Last clicked: {last}">
</div>

Example: track mouse position.

<div data-state
     data-x="0"
     data-y="0"
     data-state-on="mousemove => x = event.clientX; y = event.clientY"
     data-state-text="X: {x}, Y: {y}">
</div>

⭐ 5. Updating Another Element’s State

Use data-state-target to update a different element.

<button
  data-state-trigger
  data-state-target="#box"
  data-state-on="click => color = 'red'">
  Make Red
</button>

<div id="box"
     data-state
     data-color="blue"
     data-state-class="red: color == 'red'">
</div>

This is the State.js equivalent of:

React props
Vue emits
Svelte dispatch

But simpler.

⭐ 6. Multiple Event Handlers

You can chain multiple events:

<div data-state
     data-state-on="
       click => count += 1;
       mouseover => hovered = true;
       mouseout => hovered = false
     ">
</div>

Each event runs its own expression.

⭐ 7. Using Events to Add/Remove Classes

<div data-state
     data-active="false"
     data-state-on="click => active = !active"
     data-state-class="active: active">
</div>

This toggles a class with no JavaScript.

⭐ 8. Using Events to Drive CSS Animations

<div data-state
     data-state-on="click => animate = true"
     data-state-class="pop: animate">
</div>

CSS:

.pop {
  animation: pop 0.3s ease;
}

This is how you build interactive UI without JS logic.

⭐ 9. Building a Mini App with Events

<div id="app"
     data-state
     data-count="0"
     data-state-on="click => count += 1"
     data-state-text="Clicked {count} times">
</div>

This is a complete app:

reactive state
reactive text
event-driven logic
no JavaScript

This is the State.js mental model.

⭐ 10. Why the Event System Matters

Because it replaces:

React’s onClick={() => setCount(count + 1)}
Vue’s @click="count++"
Svelte’s on:click={() => count++}

With:

data-state-on="click => count += 1"

No JS.

No framework.

No re-renders.

No hydration.

No build step.

This is the State.js philosophy.

Learn more: State.js architecture

⭐ State.js Basics — Learn CSS‑Driven Reactivity in 10 Minutes

iDev-Games — Fri, 29 May 2026 20:05:15 +0000

State.js looks simple — just HTML attributes — but it introduces a new mental model for building UI:

HTML holds the data.

CSS reacts to the data.

State.js keeps them in sync.

If you’re used to React, Vue, or Svelte, this feels strange at first.

If you’re used to CSS, this feels like “why didn’t CSS always work like this?”

This tutorial will teach you the core ideas behind State.js so you can build reactive UI without JavaScript logic, without a framework, and without a build step.

⭐ 1. What State.js Actually Does

State.js turns HTML attributes into live CSS variables.

Example:

<div data-state data-count="0"></div>

State.js automatically exposes:

--state-count: 0;

If data-count changes, the CSS variable updates instantly.

This is the foundation of everything.

Learn more: Reactive attributes

⭐ 2. Your First Reactive Element

Let’s make a simple counter.

HTML

<div id="counter"
     data-state
     data-count="0"
     data-state-text="Count: {count}">
</div>

What’s happening?

data-state → activates State.js
data-count="0" → creates --state-count: 0
data-state-text="Count: {count}" → binds text to the value

State.js replaces {count} with the live value.

⭐ 3. Updating State with Triggers

Add a button that increments the counter:

<button
  data-state-trigger
  data-state-target="#counter"
  data-state-attr="count"
  data-state-increment="1">
  +1
</button>

What this means:

data-state-trigger → this element performs an action
data-state-target="#counter" → update that element
data-state-attr="count" → update the data-count attribute
data-state-increment="1" → add 1

Clicking the button updates:

the attribute
the CSS variable
the text
all automatically

Learn more: Triggers

⭐ 4. Styling with CSS Variables

Because State.js exposes attributes as CSS variables, you can style reactively:

#counter {
  color: hsl(calc(var(--state-count) * 20), 80%, 50%);
}

As the count increases, the color changes.

No JS.

No re-renders.

Just CSS reacting to state.

Learn more: CSS variable projection

⭐ 5. Conditions (Reactive Logic in HTML)

Let’s change the background when the count reaches 5.

<div id="counter"
     data-state
     data-count="0"
     data-state-class="big: count >= 5"
     data-state-text="Count: {count}">
</div>

This adds the class .big when the condition is true.

CSS:

.big {
  background: gold;
}

Learn more: Conditions

⭐ 6. Autofire (State.js “Game Loop”)

State.js can update values on an interval:

<div data-state
     data-time="0"
     data-state-autofire="time += 1 every 100ms"
     data-state-text="Time: {time}">
</div>

This creates a reactive timer with no JavaScript.

Learn more: Intervals

⭐ 7. Two-Way Binding (Forms Without JS)

<input type="range"
       data-state
       data-value="50"
       data-state-bind="value">

<div data-state
     data-state-text="Value: {value}">
</div>

Moving the slider updates the text automatically.

Learn more: Binding

⭐ 8. Putting It All Together — A Mini App

<div id="app" data-state data-count="0">
  <h1 data-state-text="Count: {count}"></h1>

  <button
    data-state-trigger
    data-state-target="#app"
    data-state-attr="count"
    data-state-increment="1">
    +1
  </button>

  <button
    data-state-trigger
    data-state-target="#app"
    data-state-attr="count"
    data-state-increment="-1">
    -1
  </button>

  <div data-state-class="warning: count < 0">
    <p>Count is negative!</p>
  </div>
</div>

What you get:

reactive text
reactive classes
reactive styling
reactive state
no JavaScript logic

This is the State.js mental model.

⭐ 9. Why This Matters

State.js gives you:

✔ Reactivity without JavaScript

No functions.

No hooks.

No re-renders.

✔ Components without frameworks

Just templates + includes.

✔ State without state management libraries

Attributes are the state.

✔ UI logic without JS

CSS handles behavior.

✔ Zero build step

Works in plain HTML.

This is why people say:

“It feels like something CSS should have done.”

Because State.js makes the browser behave the way developers wish it behaved.

State.js Tutorial: Creating Reusable UI Components with Pure CSS Reactivity

iDev-Games — Wed, 27 May 2026 21:39:19 +0000

Modern frontend frameworks treat components as JavaScript functions, classes, or compiled files.

But what if components didn’t need JavaScript at all?

What if components were built from:

HTML templates
CSS for behavior and visuals
State.js attributes for reactivity

…with no JS logic, no virtual DOM, and no build step?

That’s exactly what State.js enables.

State.js turns HTML attributes into reactive CSS variables, letting you build fully reactive, reusable UI components using nothing but HTML + CSS.

In this article, you’ll learn how State.js components actually work.

⭐ What Is a Component in State.js?

In React, a component is a function.

In Vue, it’s an object.

In Svelte, it’s a compiled file.

In State.js, a component is:

A reusable HTML template that becomes reactive when included with data-state-include.

A component is:

defined once
cloned anywhere
customized via attributes
reactive automatically
fully encapsulated

No JavaScript logic.

No rendering engine.

No framework runtime.

Just HTML + CSS + State.js.

⭐ Example: A Reusable `<char-card>` Component

1. Define the component once

<template id="char-card">
  <div class="char-card" data-state data-hp="20" data-hp-max="20">
    <div class="name" data-state-display="name"></div>

    <div class="bar">
      <div class="fill" style="width: var(--state-hp-percent)"></div>
    </div>

    <button data-state-trigger data-state-attr="hp" data-state-increment="-5">
      Damage
    </button>
  </div>
</template>

This is the component definition.

State.js automatically exposes:

--state-hp
--state-hp-max
--state-hp-percent

These update reactively whenever attributes change.

⭐ 2. Use the component anywhere

<div data-state-include="#char-card"
     data-name="Warrior"
     data-hp="18"
     data-hp-max="20"></div>

<div data-state-include="#char-card"
     data-name="Mage"
     data-hp="9"
     data-hp-max="12"></div>

Each instance:

clones the template
merges your attributes
becomes a fully reactive component
auto-binds triggers to its own state

This is the State.js equivalent of props, but simpler.

⭐ CSS Drives the Component’s Behavior

.char-card .bar {
  height: 12px;
  background: #333;
  border-radius: 4px;
  overflow: hidden;
}

.char-card .fill {
  height: 100%;
  background: #4caf50;
  width: var(--state-hp-percent);
  transition: width 0.3s ease;
}

CSS handles:

animation
interpolation
transitions
layout

State.js handles:

state changes
variable updates
triggers
reactivity

This is CSS‑reactive architecture.

⭐ Updating the Component

Inside the component:

<button data-state-trigger data-state-attr="hp" data-state-increment="-5">
  Damage
</button>

When clicked:

data-hp decreases
State.js updates --state-hp
CSS recalculates --state-hp-percent
The bar animates automatically

This is reactivity without JavaScript logic.

⭐ Why This Works

State.js turns HTML attributes into live CSS variables.

CSS handles:

layout
animation
transitions
transforms

State.js handles:

state
triggers
conditions
intervals
reactivity

Together, they form a browser‑native component system.

⭐ Why This Is a Big Deal

✔ Zero JavaScript logic

Your component logic lives in HTML + CSS.

✔ Zero framework runtime

No virtual DOM.

No hydration.

No re-renders.

✔ Zero build step

Works in plain HTML files.

✔ Fully portable components

A <char-card> works anywhere HTML works.

✔ Native browser performance

CSS is GPU‑accelerated and instant.

✔ Auto‑binding triggers

Buttons inside the template automatically bind to the nearest [data-state] parent.

⭐ Component API Design

You can define your own “props” using attributes:

<div data-state-include="#char-card"
     data-name="Rogue"
     data-hp="12"
     data-hp-max="14"></div>

Or add more:

<div data-state-include="#char-card"
     data-name="Cleric"
     data-hp="14"
     data-hp-max="16"
     data-color="blue"
     data-low="red"></div>

State.js exposes them all as CSS variables.

⭐ Conclusion

State.js lets you build components using:

HTML for structure
CSS for behavior
State.js for reactivity

This creates a new category of UI architecture:

CSS‑Reactive Components

Components powered by HTML templates, CSS variables, and declarative reactivity — not JavaScript logic.

If you want lightweight, portable, framework‑free UI, this pattern is a game changer.

CSS Reactive Frameworks: Why the Future of UI Flows Through CSS Instead of JavaScript

iDev-Games — Wed, 27 May 2026 11:54:22 +0000

Modern frontend development has a contradiction at its core.

We tell developers that rich interactivity requires layers of abstraction:
virtual DOMs, hydration pipelines, reactive hooks, compiler stages, bundlers, state containers, and increasingly complex rendering architectures.

Then someone ships a fully interactive, real-time simulation from a single local HTML file with almost no custom JavaScript — and it runs flawlessly at 60 FPS.

That contradiction is the “No-JS” paradox.

And it exposes something the industry has slowly forgotten:

The browser is already a reactive engine.

Frameworks didn’t invent reactivity. Browsers had it from the beginning.

State.js simply stops fighting the browser’s architecture and starts working with it instead.

We Built an Entire Industry Around Re-Rendering

For the last decade, frontend engineering has been dominated by one assumption:

Application state belongs exclusively to JavaScript.

This belief shaped the modern web stack.

Need to update text? Trigger a render cycle.

Need to animate UI? Route it through component state.

Need interactivity? Build a synchronization layer between memory and the DOM.

The result is an ecosystem where developers routinely ship megabytes of tooling just to keep application data synchronized with elements the browser already knows how to update natively.

Modern frameworks treat the DOM as a dumb output target — something to be diffed, patched, reconciled, hydrated, and rebuilt.

But the DOM was never dumb.

The browser’s rendering engine is one of the most optimized reactive systems ever created.

It already performs:

dependency resolution
style recalculation
layout propagation
compositing
animation timing
GPU acceleration

The web platform solved reactivity years ago.

Most frameworks simply rebuilt it in JavaScript.

The Core Idea Behind CSS Reactive Frameworks

State.js introduces a different model.

Instead of routing UI updates through JavaScript rendering logic, it exposes application state directly to CSS through native browser variables.

Your markup becomes the source of truth.

<div id="colony"
  data-state
  data-state-watch="spores,bio,mut,haz"
  data-spores="10"
  data-bio="0"
  data-mut="0"
  data-haz="0">

When attributes change, State.js maps them directly into CSS custom properties:

--state-spores
--state-bio
--state-mut
--state-haz

At that point, JavaScript’s job is effectively finished.

The browser takes over.

CSS becomes:

the rendering layer
the calculation layer
the reactive layer

That’s the paradigm shift.

The DOM Is Already a Database

Traditional frameworks separate state from presentation:

JavaScript owns the data
The framework owns synchronization
The DOM becomes a visual projection

But in a CSS reactive architecture, the DOM is the state container.

That changes everything.

Instead of hidden memory trees buried inside framework internals, state becomes visible, inspectable, and native.

Open DevTools and the entire application state is sitting directly inside the markup.

You can literally edit gameplay values live in the Elements panel and watch the interface react instantly.

No React DevTools.

No framework inspectors.

No hidden proxy objects.

No hydration debugging.

The browser already gives you the tooling.

Why CSS Reactive Systems Feel Faster

One of the biggest performance gains comes from removing render bottlenecks entirely.

In traditional frontend frameworks, a state update typically triggers:

JavaScript execution
Dependency tracking
Component reconciliation
Virtual DOM diffing
DOM patching
Layout recalculation
Paint/composite

In a CSS reactive system, most of this disappears.

The state changes once.

The browser updates CSS variables.

Everything downstream becomes native browser work.

That matters because browsers optimize CSS and compositing at an extremely low level — often directly on GPU compositor threads.

Animations stay smooth because the browser is doing what it was originally designed to do instead of waiting for JavaScript reconciliation loops every frame.

CSS Is More Powerful Than We Pretend

Modern CSS is no longer just decorative styling.

It already contains:

variables
math
conditional logic
timelines
interpolation
transform pipelines
scroll-driven animation
responsive calculations
hardware acceleration

Yet most developers still treat CSS like a passive skin layered on top of JavaScript applications.

CSS reactive architecture flips that relationship.

Instead of JavaScript commanding the interface every frame, CSS passively responds to changing data.

A progress bar doesn’t need imperative width calculations:

.progress-fill {
  width: var(--state-spores-percent);
}

A camera shake effect doesn’t need animation libraries.

A HUD doesn’t need rerendering.

A dashboard doesn’t need component invalidation.

The browser already knows how to propagate visual dependencies.

The Modular Micro-Library Ecosystem

What makes this philosophy especially interesting is that it encourages modularity instead of ecosystem lock-in.

Instead of one massive framework controlling everything, browser behavior can be split into focused micro-libraries that extend native capabilities.

For example:

Trig.js feeds scroll positions directly into CSS variables for cinematic scroll-driven interfaces
Motion.js acts as a global timing engine for timeline-driven CSS animation systems
Keys.js maps keyboard input directly into declarative state mutations
Cursor.js introduces reactive pointer tracking without heavy event plumbing

Instead of adopting an all-or-nothing framework ecosystem, developers compose exactly the behavior layer they need.

That’s much closer to how the web was originally intended to work.

This Isn’t “Anti-JavaScript”

This is an important distinction.

CSS reactive architecture is not about eliminating JavaScript.

It’s about redefining JavaScript’s role.

JavaScript becomes a lightweight state mutator instead of a full rendering runtime.

In this model:

JavaScript changes data
CSS handles presentation
The browser manages propagation

The system becomes simpler because responsibilities become clearer.

Why This Matters Beyond Performance

The biggest advantage may not even be speed.

It may be accessibility.

Modern frontend development has become increasingly hostile to newcomers:

complex build chains
framework churn
hydration bugs
SSR edge cases
compiler-specific syntax
dependency fatigue

Building simple interactive websites now often requires knowledge of infrastructure that didn’t even exist a few years ago.

CSS reactive systems reduce that complexity dramatically because the application remains fundamentally HTML-first.

The app is the document.

That makes the platform easier to reason about, easier to debug, and significantly easier to teach.

Returning to the Browser Instead of Escaping It

For years, frontend engineering focused on abstracting developers away from the browser.

But the browser itself kept evolving.

Native CSS now supports features that previously required entire JavaScript ecosystems:

scroll timelines
container queries
view transitions
hardware compositing
declarative animation pipelines

The platform is catching up to the abstractions.

And in many cases, surpassing them.

CSS reactive frameworks like State.js represent a larger philosophical shift:

Instead of rebuilding the browser in JavaScript, what if we simply embraced the browser as the runtime?

Conclusion

The “No-JS” paradox feels impossible only because the industry spent years assuming that interactivity must flow through JavaScript rendering systems.

But the browser was reactive long before modern frameworks arrived.

State.js demonstrates that when state flows directly through CSS and the DOM becomes the source of truth, applications become simpler, faster, and dramatically more transparent.

It’s not about abandoning modern web development.

It’s about removing unnecessary layers between your data and the screen.

And perhaps more importantly:

It makes building for the web feel immediate, creative, and fun again.

DEV Community: iDev-Games

I Built a Full RPG with Zero JavaScript Logic - Here's What I Learned

What is State.js?

The Project: Gutter Rat

How the SPA Routing Works

The HUD: CSS Variables as a Render Layer

Trigger Chains: Your Game Logic Layer

Dynamic Inventory with data-state-instantiate

Autofire: Reactive Logic Without Writing Logic

The Gotcha That Will Burn Everyone Once

Setting vs Toggling Booleans

Debugging: Use the Tools

The Honest Assessment

Why This Matters

Try It

The Architectural Pivot: JS-Reactive Frameworks vs. CSS-Reactive Ecosystems (with Strategic JS)

The Core Structural Divide

The Old Way: Imperative JS Re-rendering

The New Way: The Decoupled Telemetry Layer

Architectural Comparison: Building a Live Search & Scroll Reveal

1. The Monolithic SPA Stack (Next.js + GSAP + Lenis)

2. The CSS-Reactive Stack (State.js + Trig.js)

The Strategic JS Blueprint: Extending the Playground

Powering a High-Fidelity 3D WebGL Camera via Trig.js Variables

Why Corporations and Premium Agencies are Transitioning

1. Hardened Supply Chain Security

2. Massive Core Web Vitals Wins

3. Infinite Maintainability

Summary: A Reset of Balance

How the State.js Ecosystem Solves the Performance vs. Experience Paradox in Modern E‑Commerce

🟢 1. The Magnetic Checkout Button (Zero JS Animation)

🟢 2. The Dynamic Angle Glow (Zero Runtime Math)

🟢 3. Scroll‑Reactive Luxury Effects with Trig.js

Luxury product reveals

Parallax hero banners

Scroll‑driven color shifts

🧠 Why This Works: The Performance Secret Under the Hood

1. Passive Event Listeners

2. Attribute Caching

3. Selective Updates

4. IntersectionObserver Integration

🟢 4. Motion.js: The “Premium Feel” Layer

🟢 5. The Hybrid Model That Makes It All Work

JavaScript handles:

State.js handles:

Motion.js handles:

Cursor.js handles:

Trig.js handles:

CSS handles:

🟢 The E‑Commerce Payoff

🟢 Final Thought

The Hybrid Architecture That Makes State.js Unstoppable

🟢 Why This Hybrid Model Works So Well

1. True Separation of Concerns

2. Zero Framework Lock‑In

3. Native Performance

🟢 A Real E‑Commerce Example (The Live Pattern)

1. The HTML (Clean & Semantic)

2. The JavaScript (Pure Logic)

🟢 Why This Matters for E‑Commerce

🟢 The Final Architecture (The One That Actually Scales)

State.js handles:

JavaScript handles:

Together:

🚀 State.js - Build Reactive, Interactive UIs Using Only HTML + CSS

✨ What State.js Actually Does (In Plain English)

🔥 Why Developers Love It

1. You don't need to write any JavaScript Logic

2. Designers Can Work Directly in the Code

3. Backend‑First Friendly

4. Game‑Dev Ready

⚡ What You Can Build in 30 Seconds

A clicker game:

A health bar:

A form that tracks focus + changes:

A video progress bar:

A toggleable UI state:

🧩 The Magic Primitives (The 80% You Need to Know)

1. data-state

2. data-state-watch="attr1,attr2"

1. `data-state`

2. `data-state-watch="attr1,attr2"`

3. `data-state-trigger`

4. `data-state-attr="health"`

5. `data-state-increment="10"`

6. `data-state-set="100"`

7. `data-state-condition="gold >= 50"`

8. `data-state-autofire="true"`

9. `data-state-text="HP {hp}/{hpmax}"`

10. `data-state-class="critical"`

11. `data-state-interval="1000"`

12. `data-state-sound="coin"`

13. `data-state-persist="true"`

14. `data-state-trigger-on="input|scroll|mouseenter|submit"`

15. `data-state-include="component.html"`