A new stack for turning HTML and CSS into an application layer
▲ 53 r/Frontend+1 crossposts

A new stack for turning HTML and CSS into an application layer

Hi all,

About three years ago I built a small library called Trig.js to expose scroll data to CSS via data‑attributes. It recently got highlighted as one of the “Enterprise Heavyweights” of scroll animation libraries by CSSAuthor, which made me revisit the idea.

I’d always planned to make a Cursor.js, so I built it and then I started wondering, what else could be exposed to CSS variables? That question spiralled into something bigger, and I’ve now ended up creating a full stack of small, browser‑native libraries that all share the same philosophy:

>Use the DOM as the application layer, keep JavaScript minimal, and let CSS be the rendering engine.

Once I reached Keys.js, something clicked. Keys aren’t animation, they’re input.
That led to the bigger question, could you build full applications or even games this way?
The answer turned out to be yes, and that’s when I came up with State.js.

For the first time, here’s the full stack together:

Trig-js - exposes scroll data to CSS

Cursor.js - exposes mouse/touch position

Motion.js - a global clock for CSS‑driven animation

Keys.js - exposes keyboard input

State.js - a reactive state layer for HTML

Gravity.js - a DOM‑element physics engine rendered in CSS

Together, these for a declarative application/game engine using the native browser without webGL, webGPU or canvas. Your HTML is your state graph, the CSS is your rendering engine and JS becomes the wiring that connects everything up.

These libraries all work independently or together. As every one of these open up capabilities that wasn't possible before that's why they are all individual so you can pick or choose or use them altogether for a complete stack.

A few months ago I wouldn’t have believed half of this was possible in the browser without heavy abstractions. It’s made me realise how much capability we’ve historically hidden behind frameworks instead of exposing directly.

I’m excited to share this approach and would love to hear your thoughts, ideas, or critiques.
If you’re curious about browser‑native reactivity or CSS‑driven rendering, I’m happy to dive deeper.

Thanks

Edit: I also have a subreddit for State.js here https://www.reddit.com/r/Statejs/ come and checkout demos, examples and articles to learn more about State.js or come and talk about the complete stack.

u/iDev_Games — 4 days ago
▲ 11 r/css+2 crossposts

A frontend framework with no build step, no re-renders, and no virtual DOM.

Most frontend frameworks solve the same problems with the same tools:
virtual DOM, re-renders, hydration, build steps, bundlers, JSX, components, effects, hooks, signals, etc.

State.js takes a different approach.

It exposes DOM state as CSS variables and lets CSS handle the rendering.
No re-renders. No virtual DOM. No build step. No server.

GitHub: https://github.com/iDev-Games/State-JS

Key differences from traditional frameworks:

  • No re-renders — CSS updates instantly when state changes
  • No virtual DOM — the DOM is the source of truth
  • No build step — works from a local file
  • No server — double‑click the HTML file and it runs
  • No JSX or templates — everything is HTML attributes
  • No hydration — nothing to hydrate
  • No JS logic — state, triggers, and loops are declarative
  • 19kb — tiny footprint

Live demos (HTML + CSS only):

This is not a React/Vue/Svelte clone.
It’s a different model: CSS as the renderer, HTML attributes as the logic.

Would love feedback

github.com
u/iDev_Games — 15 days ago