Declarative views

{}

If you’ve written SwiftUI, Jetpack Compose, or Flutter, BESPA’s programming model will feel familiar. All four belong to the same family — declarative typed view-trees — where:

Views/widgets are typed value structures, not strings or templates.
You compose them in trees with chained builder methods.
State changes drive rebuilds; you don’t imperatively mutate the UI.
The framework owns the diff and decides what to repaint.

BESPA is the same shape, applied to the server. The renderer is your net/http handler instead of Apple’s graphics pipeline, and the diff travels over HTTP as HTML fragments instead of being applied locally — but the programming model is the same.

Side-by-side

A greeting that updates as the user types — in SwiftUI:

// SwiftUI
struct GreetingView: View {
    @State var name: String = ""
    var body: some View {
        VStack {
            TextField("Your name", text: $name)
            Text("Hello, \(name)!")
                .font(.headline)
        }
    }
}

And in BESPA:

// BESPA
func handleHome(w http.ResponseWriter, r *http.Request) {
    state := wf.StateOf(r)
    wf.Page().Add(
        wf.Form().Add(
            wf.InputText("name", "").
                WithPlaceholder("Your name").
                WithAutoSubmit(true),
        ),
        wf.HeadlineMedium("Hello, ", state.Get("name"), "!").
            HideIfEmpty(r, "name").
            RedrawIfChanged(r, "name"),
    ).Draw(w, r)
}

Different language, different runtime, same shape: a function that returns a tree of typed view nodes, where each node opts in to the state it cares about. The framework figures out the rest.

The mental-model map

SwiftUI / Compose / Flutter	BESPA
`struct ContentView: View` / `@Composable fun X()` / `Widget build()`	A Go handler that returns a widget tree
`var body: some View { ... }`	`wf.Page().Add(...)`
`Text("Hi").font(.title)`	`wf.HeadlineMedium("Hi")`
`VStack { ... }`, `HStack { ... }`, `Row { ... }`	`wf.Toolbar().AddLeft(...)`, `wf.Splitter(...).AddLeft(...)`
`@State var x: String` triggers rebuild	URL state `?x=...` triggers rebuild
`@Binding`, `@ObservedObject`, `@EnvironmentObject`	`wf.StateOf(r).Get("x")` everywhere
The framework diffs the view tree and repaints	The framework diffs which widgets opted in, swaps fragments by `data-id`
Hot reload via Xcode preview	Hot reload via `go run .`
Strongly typed: refactor a `.font()` rename and the compiler catches it	Strongly typed: refactor a `WithColorPrimary()` and the compiler catches it

The generic-self-typing trick

SwiftUI’s some View keeps .font(.title) returning the concrete view type, so the chain doesn’t lose its identity. BESPA does the same thing with Go generics: every widget embeds *WidgetBase[T] where T is the widget’s own pointer type, so the WithFoo methods on the base return *T, not *WidgetBase. The chain stays typed all the way to the end:

// SwiftUI — opaque return type, fluent chain stays on the concrete type
Text("Hi").font(.title).foregroundColor(.blue)

// BESPA — generic WidgetBase[T] returns the concrete pointer, so chains
// stay typed all the way through.
wf.HeadlineMedium("Hi").
    WithColorPrimary().
    RedrawIfChanged(r, "name")

Where it diverges

The model is the same; the runtime isn’t. Things to recalibrate:

Where the rebuild happens. SwiftUI rebuilds locally on @State change. BESPA rebuilds on the server after a round-trip — a fetch posts the state delta, the server re-renders the affected widgets, and the client swaps fragments by data-id.
Where state lives. SwiftUI: a typed reactive graph rooted in the view (@State, @Binding, @EnvironmentObject). BESPA: the URL query string. Less expressive, but persistent, bookmarkable, and trivially debuggable.
Children syntax. SwiftUI’s @ViewBuilder lets you write VStack { Text("a"); Text("b") } without a separator. Go variadic functions get the same effect with .Add(a, b, c).
No declarative animations (yet). SwiftUI’s .animation() and withAnimation { } have no direct analog — animations in BESPA are CSS transitions on the rendered HTML.
No previews / instant rebuild loop. Xcode preview, Compose preview, and Flutter hot-reload are tighter feedback loops than go run .. The Go side is still fast (sub-second compiles for a typical app) — just not interactive.

What transfers immediately

If you came from one of those frameworks, the following habits work on day one:

Compose, don’t inherit. Wrap existing widgets to make new ones — see Composing existing widgets.
Push state up, pass it down. Keep state at the page level and let widgets read it via wf.StateOf(r).Get(...). Same idea as lifting @State to a parent view.
Small focused widgets. Lots of small widget functions beats one big page handler. Same as SwiftUI’s body discipline.
The framework owns identity. Don’t try to hold onto references to live widgets; treat each render as a fresh tree. Same as SwiftUI’s value-type View.

Related frameworks

BESPA isn’t a new idea — it applies a well-established programming model to Go. Other frameworks in the same architectural family:

Blazor Server (C#) — the closest match. Typed Razor components, server-side render, automatic DOM sync over SignalR. If you’ve used it, BESPA will feel immediately familiar. The main difference is BESPA emits all-Go (no Razor template syntax) and patches over plain HTTP.
Vaadin Flow (Java) — typed Java component trees, server-rendered HTML, DOM kept in sync via WebSocket. Mature, enterprise-grade. The Java analog of BESPA.
Wt (C++) — pre-dates most of this list (2005). Pure-code widget trees in C++ that render as HTML, with reactive updates. Architecturally identical to BESPA; C++ ergonomics held wider adoption back.
Phoenix LiveView (Elixir) — adjacent cousin. Server-authoritative, surgical DOM patches over WebSocket. Closer to template-first than view-tree-first, but the philosophy (server owns rendering, client is a thin patch applier) is the same.

Adjacent but different — these solve the same end-goal (server-rendered HTML with partial updates) without the typed view-tree:

HTMX — HTML-with-attributes rather than widgets-that-emit-HTML. Backend-agnostic, smaller surface area, zero opinion on your component model.
Hotwire / Turbo (Rails) — partial updates via <turbo-frame> and <turbo-stream>. Template-first.
Datastar — reactive signals + SSE patches. New (2024), template-first, backend-agnostic.

Client-side cousins — same view-tree shape, but they render in the browser rather than the server:

SwiftUI / Jetpack Compose / Flutter — the family BESPA borrows from. Native rendering, not HTML.
Lit — typed Web Components with template literals. Same chained-builder feel, client-side.
Solid.js, Mithril, hyperapp — JSX or builder-style view trees, client-rendered.

The four-cell positioning: typed-view-tree × server-rendered. Blazor Server is the C# cell, Vaadin Flow the Java cell, Wt the C++ cell, and BESPA the Go cell. Of those four, the only one that emits HTML in pure handler-returns-tree form (no template language alongside) is BESPA.