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…
In plain words
Doors is a server-driven UI framework for building stateful, reactive web applications in Go. It brings front-end capabilities like reactive state and composable components to the server side, eliminating the need for separate API layer design. The framework unifies back-end and front-end control flow, removing context switching between layers. Applications run on a stateful Go server while the browser serves as a remote renderer, and the entire stack—assets, build scripts, and files—ships as a single binary with automated security policies.
written from the facts on this page · September 2026
From the sources
In the maker’s words, at launch
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) // reactive 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> }) }
More dev tools this month
the category →
Open-source GTM skills for technical founders
Dev tools · 29d ago · gtmcofounder.com
OpenTrailPaper is open-source bike computer firmware for the LilyGO T5S3 4.7" E-Paper PRO. It supports offline maps, GPX routes, FIT recording and Bluetooth sensors.
Dev tools · 1d ago · opentrailpaper.com
Launched alongside, April 2026
the whole month →
- AG
Thought the resources for GPU arch were lacking, so here we are
Life & fun · Apr 2026 · jaso1024.com
- IB
Built a ~9M param LLM from scratch to understand how they actually work. Vanilla transformer, 60K synthetic conversations, ~130 lines of PyTorch. Trains in 5 min on a free Colab T4. The fish thinks the meaning of life is food. Fork it and swap the personality for your own character.
AI · Apr 2026 · github.com
- BC
Life & fun · Apr 2026 · sam-burns.com
- IB
With social media and now AI, its important to keep the indie web alive. There are many people who write frequently. Blogosphere tries to highlight them by fetching the recent posts from personal blogs across many categories. There are two versions: Minimal (HN-inspired, fast, static): https://text.blogosphere.app/ Non-minimal: https://blogosphere.app/ If you don't find your blog (or your favorite ones), please add them. I will review and approve it.
AI · Apr 2026 · text.blogosphere.app