Put State in the Right Place

TL;DR: Placing state in the wrong place is the root cause of most real-world problems, especially in web development. The solution is to use a dedicated engine plus declarative data — the browser itself is already a hypermedia client, HTML/CSS are declarative, we just need to add declarative attributes to the JavaScript parts. Data Star does this in 4KB, making the web UI honest. ## Core Axiom: State in the Wrong Place Every good talk has an axiom — a fundamental statement universally accepted as true without proof. My axiom is simple: **Placing state in the wrong place is the cause of most real-world problems**, and it's entirely avoidable. This applies to all sorts of scenarios, but it's been a huge problem in the web domain. I'm Delaney, with a weird career: started out making video games, worked on slot machines (doing both art and internal network messaging), participated in real-time military systems (getting the right information to the right people, frame-accurate), and dealt with large-scale distributed problems at Cenadia. The web is inherently a distributed problem, but many people don't realize it, thinking there's a happy little path on the client side and a separate one on the server side. That's not the case. ## Browsers Are Powerful, but the Web Feels Heavy Modern browsers have never been so powerful and efficient — they can do many really great things for you. But the web has never felt so heavy: huge, bloated, hard to use. The main reason is that most projects today are all-in on full-stack JavaScript. I tested it: a Next.js "Hello World" (just displaying text on screen) before doing anything is 500 MB — just a Hello World page. We're still living in a post-leftpad world: a website goes down because of a missing function in ESX. More bizarrely, under this massive dependency, developers become Next.js or SvelteKit developers, no longer JavaScript developers. The ecosystems barely communicate with each other. The end result is a ton of CVEs, and these problems have nothing to do with the web; they're about this slowly accumulated ecosystem. ## How Did We Get Here? Back when SPAs became popular, servers were always one thread per request (Apache, Glassfish, etc.), incapable of async scaling. Meanwhile, interesting content like maps and spreadsheets could only be implemented in the client browser. Servers didn't support these things at the time, so clients started doing heavy lifting, and the path went astray. Once progress was made, everyone said, "Why aren't you doing this? Everyone's doing it." I don't think of myself as a JavaScript developer, but I like the sandboxed deployment of the web. In the military, getting an executable approved is extremely difficult, whereas the browser can immediately deliver content and sandbox it. But now frameworks have become "a new JavaScript framework every week," and all these synthetic benchmarks never test the full path from server to client; they're all competing to be the best at being the worst option. ## Three Failure Modes and Their Fixes We can try to fix three failure modes today — this isn't idle talk, it's actionable: 1. **Optimistic updates are a lie** — The user's intent is not "I am buying this thing" but "I want to try to buy this thing." Don't lie to the user. 2. **Custom code is often imperative** — Should shift to a declarative style. 3. **Polling leads to stale state** — Data needs real-time sync. ## Core Philosophy: Dedicated Engine + Declarative Data The core philosophy I've learned from game development and various interesting experiences: **Dedicated engine plus declarative data is the direction you should pursue**. For example, SQLite: you say "create unique index," you don't tell it how to invalidate caches or how to balance B-trees. The user expresses high-level intent, leaving flexibility to the engine. The browser is already a dedicated engine that sends hypermedia to the client — a hypermedia client. HTML and CSS are already declarative: you don't need to tell it which pixel to put on screen, you don't need to tell it how to handle flexbox. You say "here's my intent, please render it." The problem is the JavaScript part is still imperative. Carson Gross said: JavaScript has an incredible property — it's in the browser, but we seem to only be able to deal with it. We can't throw away that duck, so we need to make the JavaScript part more declarative. ## Data Star: Making JavaScript Declarative I built Data Star (formerly data-star), with only two core things: - **Easily parse attributes**: Use the browser's native `data-*` custom data attributes. - **Add reactive expressions**: Fix the missing declarative reactivity in JavaScript. That's it. It's currently about 4KB (not 500MB), because this shouldn't be that hard. TC39 is working on bringing signals into the browser, and then the size will halve again. I built it the way I build ECS game engine systems, and from there everything is a plugin. Once the declarative part is in place, you can freely choose how to build your system. ## Data Engine and the Honesty Principle I'm building a "data engine" that integrates an event bus, data sets, and open ontology. The goal is to make the web UI honest — strip away the framework's red tape, no longer be a Next.js or Data Star developer, just use the web as a target, the way you use WebGL. I handle streaming, compression, and many other problems in the data engine — the same problems that exist on the web. If I solve them for Data Star and help others, I also solve my own problems. **Three key principles**: - **Truth near authority**: Every piece of data in the system has a single source of truth, and you know where it is. - **Render near perception**: Delay creating pixels or data until the last moment, let the engine do it. - **Intent near user**: Don't lie, and don't lie to others. When a user clicks a button, they mean "I want to try to buy," not "I bought." ## Current State and Future It's been about 3 years since the first commit of Data Star. v1 is complete, released, and working. Unless the browser stops backward compatibility, no changes are needed. We've established a 501(c)(3) organization; all code lives under the org, we are stewards but don't own any code, so it won't disappear, and no one can take it away. For me, this is a solved problem. I can go back to working on the truly interesting problems. Developing for the web is no longer a problem for us or for users. --- Source: YouTube video (https://www.youtube.com/watch?v=W7Ki3aXgmZU) (Lobste.rs discussion link)