Less translation. More of the page.

The website is part of the workbench.

This page, the documentation, and our tutorials are written in .sando. Shared headers, footers, and page components compile into Go. The website links only the small Apache-2.0 sando runtime; the compiler and development supervisor are not in its production binary.

• Sandwich Hime: the project site exercises reusable layouts, canonical and mounted routes, strict CSP, documentation tables, and a request-rendered tutorial.
• Gamertan: our public home uses Hime for its pages and application interfaces. It gives us ongoing feedback about templates used beyond a demonstration.
• EQL Helper: a live reference service migrated its presentation to Hime. The migration account explains the scope; application behaviour and data remain the application's responsibility.

Dogfooding exposes integration friction. It is useful evidence, but it is not an independent audit or proof that every application will behave like ours.

Templates and foundations, with separate jobs.

Web Foundations is our collection of composable Go packages for application boundaries, including request identity, browser security, authentication, organizations, and access policy. Hime handles the presentation side: typed components and contextual output.

1. Your handler authenticates the request, authorizes the operation, and loads the data.
2. It builds a small typed view and passes that view to a Hime component.
3. The application controls response status, headers, buffering, errors, and caching.

No hidden router or mandatory framework joins them together. Use the Foundations packages you need, or your existing Go stack. Hime's runtime does not depend on Web Foundations, and escaping output is not a substitute for authorization.

Small renderer. Specific measurements.

Our August 24, 2026 RC1 benchmark compared an output-equivalent synthetic view against a pre-parsed html/template. Each result is the median of ten two-second samples. Timed output goes to io.Discard; equivalence is checked separately using buffers.

In those runs, Hime used 17.6–23.9% of the baseline renderer time, with 21 allocations and 688 bytes per operation versus 58 allocations and 1,600 bytes. A September 9 repeat on M1 with Go 1.27.0 measured 1,034.5 versus 4,044.0 ns/op—25.6% of baseline time—with the same allocation counts. Hardware and run conditions matter.

These are renderer measurements, not whole-website speedups. They exclude compilation, HTTP, network latency, database queries, and deployment. The synthetic Hime function mirrors generated writer calls; this is not a benchmark of every generated template or every template engine.

Read the samples, resource limits, source identity, and reproduction command. Measure your own pages before choosing an architecture on performance alone.

A good fit when you want to own the application.

Hime fits Go applications that value HTML-first templates, explicit data contracts, reusable components, and inspectable build output. It does not require a frontend framework or prevent you from using JavaScript where interaction calls for it.

It is not a CMS, a visual page builder, or a sandbox for templates submitted by strangers. Template authors can write Go and must be trusted like application developers. If your current templating stack is doing its job, a migration needs a concrete benefit—not a benchmark alone.

Start with a small working page, then use the security model and technical guide to understand the boundaries.