A stateful UI runtime for reactive web apps in Go

Doors: Server-driven UI framework + runtime for building stateful, reactive web applications in Go.

Some highlights:

* Front-end framework capabilities in server-side Go. Reactive state primitives, dynamic routing, composable components. * No public API layer. No endpoint design needed, private temporal transport is handled under the hood. * Unified control flow. No context switch between back-end/front-end. * Integrated web stack. Bundle assets, build scripts, serve private files, automate CSP, and ship in one binary.

How it works: Go server is UI runtime: web application runs on a stateful server, while the browser acts as a remote renderer and input layer.

Security model: Every user can interact only with what you render to them. Means you check permissions when your render the button and that's is enough to be sure that related action wont be triggered by anyone else.

Mental model: Link DOM to the data it depends on.

Limitations:

* Does not make sense for static non-iteractive sites, client-first apps with simple routing, and is not suitable for offline PWAs. * Load balancing and roll-outs without user interruption require different strategies with stateful server (mechanics to make it simpler is included).

Where it fits best: Apps with heavy user flows and complex business logic. Single execution context and no API/endpoint permission management burden makes it easier.

Peculiarities:

* Purposely build [Go language extension](https://github.com/doors-dev/gox) with its own LSP, parser, and editor plugins. Adds HTML as Go expressions and \`elem\` primitives. * Custom concurrency engine that enables non-blocking event processing, parallel rendering, and tree-aware state propagation * HTTP/3-ready synchronization protocol (rolling-request + streaming, events via regular post, no WebSockets/SSE)

From the author (me): It took me 1 year and 9 month to get to this stage. I rewrote the framework 6 or 7 times until every part is coherent, every decision feels right or is a reasonable compromise. I am very critical to my own work and I see flaws, but overall it turned out solid, I like developer experience as a user. Mental model requires a bit of thinking upfront, but pays off with explicit code and predictable outcome.

Code Example: ``` type Search struct { input doors.Source[string] // reactive state }

elem (s Search) Main() { <input (doors.AInput{ On: func(ctx context.Context, r doors.RequestInput) bool { s.input.Update(ctx, r.Event().Value) // mutate state return false }, }) type="text" placeholder="search">

~// subscribe results to state changes ~(doors.Sub(s.input, s.results))

}

elem (s Search) results(input string) { ~(for _, user := range Users.Search(input) { <card> ~(user.Name) </card> }) } ```