Web framework

Status and roadmap

What exists, what is being built, and the path to a complete framework. As of v0.8.0, 19 October 2026.

In development · v0.8

The libraries today

Every library in the workspace is implemented and tested; there are no stubs. The workspace carries one version, and each library’s changelog lists only its own entries under it.

Library	Since	Does
`webglue_spec`	0.1	The request/response contract and the words for reading it
`webglue_router`	0.1	Route tables as data, groups, HEAD and OPTIONS, `prx routes`
`webglue_test`	0.1	Requests, responses and stand-in handlers for tests, no server needed
`webglue_server`	0.1	The adapter contract, the parity suite, `prx webglue bench`
`webglue_bandit`	0.1	Adapter over Bandit: HTTP/1.1, HTTP/2, WebSockets
`webglue_wrangler`	0.2	WebGlue’s own HTTP/1.1 server; no HTTP/2 or TLS yet
`webglue_session`	0.2	Session middleware over a pluggable store; an in-memory store
`webglue_static`	0.2	Files from a directory, traversal-safe
`webglue_pubsub`	0.3	Topic broadcast on `pg`, with an adapter seam
`webglue_socket`	0.3	Persistent connections as responses; RFC 6455 both ways
`webglue_presence`	0.3	Who is connected on a topic, across nodes
`webglue_cluster`	0.3	Node discovery: static lists, DNS
`webglue_pubsub_redis`	0.3	A shared Redis client and a Redis pub/sub adapter
`webglue_fragment`	0.4	Server push of data and markup fragments
`webglue_db`	0.4	A repository on the request, explicit rollback
`webglue_validation`	0.4	Checks and coerces parameters, headers and bodies
`webglue_view`	0.5	A project’s templates compiled into functions; a tree answered as a page
`webglue_content_negotiation`	0.7	A response’s media type chosen from `Accept` and what a handler offers
`webglue_params`	0.8	Query strings and urlencoded form bodies read into maps
`webglue_server_csrf`	0.8	The synchronizer token: kept in the session, required on unsafe requests
`webglue_tailwind`	0.8	A stylesheet built by Tailwind’s standalone CLI, pinned and checksummed; `prx tailwind`
`webglue_demo`	0.1	The companion ticket system

Two general Praxis libraries arrived with templates in 0.5 and sit outside WebGlue, because nothing about them is web-shaped: quire reads markup text into a tree, and stencil compiles a template into a function. webglue_redis was renamed webglue_pubsub_redis on 30 September.

Releases

Donev0.1.0 (27 August) — the core pattern and minimal HTTP: contract, router, test helpers, server contract, Bandit adapter, demo.
Donev0.2.0 (24 September) — static files, sessions, Wrangler and the parity suite, benchmarking.
Donev0.3.0 (25 September) — the realtime foundation: pub/sub, sockets, presence, clustering, Redis.
Donev0.4.0 (29 September) — server push; the data layer and validation libraries arrived in the same release.
Donev0.5.0 (9 October) — templates and views: quire, stencil and webglue_view, and a page in the demo whose ticket row is the same template the socket pushes. Inserted before the data layer, so every later release shifted by one.
Donev0.6.0 (9 October) — the data layer released with its demo: search by text and status, and an audit trail.
Donev0.7.0 (12 October) — content negotiation; the demo answers a ticket, a list and a trail as text, DXN or JSON.
Donev0.8.0 (19 October) — what Lictor’s registration pulled: form bodies, CSRF protection with the synchronizer token, and the Tailwind build; a session that keeps the handler’s own cookies.
In progressNext, for Lictor’s login: the OAuth2 server roles — authorization code with PKCE, and a token server with opaque, hashed tokens, refresh-token rotation that revokes a reused token’s family, revocation and introspection. webglue_server_oauth2_token is built and merged, not yet released; the authorization server, the client side Lictor needs and login rate limiting are to come.

What is planned

Since 12 October there is one roadmap for everything in the Praxis repository. What WebGlue has not built is a backlog, not a sequence: Lictor pulls from it journey by journey, and what is left becomes WebGlue’s own completion after Lictor. The version numbers of the old plan no longer apply; a version is assigned when a phase ends.

PlannedBackend — REST resources with OpenAPI from the same definitions, and Accept-Language; GraphQL over Absinthe; CORS, security headers, compression and Basic Auth; OAuth2 and OpenID Connect in every role, session identity and authorization; HTTP caching and idempotency; tracing and metrics; jobs, scheduling and queues; mail and file storage. Then a checkpoint: backend complete.
PlannedFrontend — reactive cells, rendering and hydration, the browser build and the first island, fragment morphing and live pages, client pages that run as a process in the browser, client routing from the server’s route table, data clients, forms whose rules run on both sides, templates compiled for the browser, live reload. Then: frontend complete.
PlannedFull stack — OAuth2 from the browser as a public client, and generators such as prx webglue new. Stretch goals: HTTP/3, gRPC. Then: framework complete.

Proposed: live views

The templates proposal of September described three libraries, and all three are built. Its fourth part is not: a live view, in which a server process holds a page’s state, renders it with the same templates and pushes the changes, which are morphed into the page. It is planned with the frontend, beside client pages that keep the same callbacks, so a screen can move between the two.

Known gaps

Nothing on the browser side yet: pages are server-rendered, and pushed fragments are not applied to them.
Wrangler has no HTTP/2, no TLS, and refuses chunked request bodies with 501.
Static files have no caching headers, ranges or ETag yet.
Sessions have only the in-memory store, without server-side expiry.
Only urlencoded form bodies are read; a repeated field keeps its last value. CSRF has the synchronizer token, not yet the double-submit cookie for stateless applications.
Tailwind is fetched for macOS and Linux on x64 and arm64; musl and Windows builds need an explicit :binary.
No authentication or authorization library released yet; the OAuth2 work for Lictor’s login is under way.

Trying it

Not yet. WebGlue is not published, and it needs the Praxis toolchain, which is not published either. When both are, the demo session is the place to start.