BEARER Docs
Capy pages, Bearer runtime

Make dynamic websites like it is 2006.

BEARER is a direct web runtime. Files are pages. Templates live next to control flow. nginx fronts the site. A request can compile into a WebAssembly module on first hit.

Files are routes A Capy page is the thing you edit and the thing nginx serves.
Compile on demand First request builds a WebAssembly module. Later requests reuse it.
WebSockets included The same runtime owns page handlers and socket handlers.
Why BEARER

The old web had the right instincts.

Put code where the page lives. Let runtime state die with the request. Keep deployment boring.

templating

Inline markup

Capy keeps rendering local to the request logic that owns it.

composition

Components and units

Components are Capy units. Props cross boundaries as copied dynamic values.

transport

FastCGI and sockets

Normal pages use FastCGI. WebSocket routes use the built-in HTTP listener.

operations

nginx and systemd

Static files stay static. The runtime handles compilation and request execution.

Examples

Small programs first.

Capy

A page

function RENDER(request : dval) {
    var name := string(request.query.name, "guest")
    <><h1>Hello, <?= name ?>.</h1></>
}
Capy

A component

function COMPONENT(request : dval) {
    <><article><h3><?= string(request.props.title, "") ?></h3></article></>
}
Capy

Markdown

function RENDER(request : dval) {
    print(markdown_to_html("# Release notes"))
}
Deploy

Keep the edge boring.

nginx serves static files and forwards Capy units to Bearer over FastCGI.

Explore

Open the running examples.