Real HTML templates
Author ordinary .html files with Go template
expressions. Markup remains readable to frontend developers
and does not become a Go DSL.
Purpose
Presentation structure without application bloat.
GoConga sits between your Go application and the documents it renders. It handles view discovery, layouts, reusable components, fragments, assets, validation, diagnostics, and rendering while leaving routing, persistence, authentication, sessions, queues, business logic, and deployment choices under your control.
The result is a clean MVC-style boundary without importing a large MVC framework. Handlers become easier to audit because SQL, authorization, state transitions, and request logic are no longer buried between hundreds of lines of HTML and CSS.
Install
Use GoConga as a normal Go module.
GoConga requires Go 1.26.9 or newer. Add the module to an existing Go project with:
go get goconga.com/goconga
Add GoConga to your application.
go install goconga.com/goconga/cmd/goconga@latest
Install the GoConga command-line tools.
The canonical module path is
goconga.com/goconga. Source code, releases,
development history, and issue tracking are available in the
public repository.
Browse the GoConga source repository
git clone https://github.com/GoConga/goconga.gitCore model
Go
business rules, data access, authorization, HTTP
GoConga
views, layouts, components, assets, fragments, validation
HTML
document structure and server-rendered state
CSS
presentation and responsive behavior
JavaScript
optional browser interaction, independently chosen
Capabilities
Layouts, blocks, partials, and components
Build pages from reusable presentation pieces without repeating parse trees, registrations, wrapper templates, or handler boilerplate.
Go-native rendering and contextual escaping
GoConga builds on the standard html/template
package rather than replacing it. Go retains responsibility
for security-sensitive contextual escaping while GoConga adds
layouts, components, fragments, typed validation, dependency
analysis, diagnostics, asset integration, and production view
management around it.
No custom HTML rendering engine
GoConga's generation and compilation tools create deterministic resource metadata, manifests, and Go resource inventories. They do not generate a second HTML renderer or duplicate the contextual escaping logic maintained by Go.
Strict startup validation
Invalid templates, missing layouts, unresolved helpers, duplicate names, circular dependencies, bad asset references, and broken view graphs fail before traffic reaches them.
Embedded production views
Use embed.FS and fs.FS directly so
templates and assets can ship inside one Go binary with no
production filesystem dependency.
Parse once, render many
Production views are discovered, resolved, parsed, validated, and cached before requests. Request-time rendering does not walk the template filesystem.
Direct io.Writer rendering
Render directly to HTTP writers or any other writer without framework-specific response objects or forced intermediate strings.
Fragment rendering
Render a complete page or a named fragment from the same view. Partial responses work with standard fetch, StrideJS, HTMX, or any browser code that consumes HTML.
Typed view-model analysis
GoConga tooling can inspect templates against Go view-model types so invalid field paths and misspelled names are caught before deployment while markup remains external.
Detailed render diagnostics
Errors identify the file, line, expression, dependency chain, component, and failing value path rather than collapsing everything into an opaque template error.
Asset fingerprints and manifests
Version CSS, JavaScript, images, and other static files by content hash and resolve stable source names into immutable production URLs.
SRI, compression, transformation, and CDN support
GoConga provides fingerprints, integrity metadata, cache metadata, built-in gzip precompression, and optional CDN prefixes. Startup-time transformer and precompressor hooks let applications add their preferred CSS or JavaScript minifier, Brotli encoder, or other processor without putting those dependencies into GoConga or onto the request path.
CSP-aware rendering
Security helpers support strict Content Security Policy, nonces, external scripts, and external styles without encouraging inline application code.
Router-independent URL helpers
Applications can provide a small URL resolver interface without surrendering routing to GoConga.
CSRF integration without session ownership
Supply your own token provider and render fields safely. GoConga integrates with existing security controls rather than replacing them.
Development reload
Development mode watches views and assets, reloads safely, and surfaces validation errors immediately while production code keeps watchers out of the request path.
Deterministic resource generation
Generate exact Go resource inventories and deterministic source
and build manifests from validated views and assets. GoConga
deliberately keeps Go's html/template as the
rendering engine rather than generating a separate renderer.
View testing and benchmarking
Render pages and fragments directly in tests, validate the complete graph, assert output, and measure render cost without starting a full HTTP application.
Security
Security and efficiency are architectural requirements.
Contextual escaping remains native.
GoConga preserves Go's established
html/template security behavior instead of
inventing another escaping language.
Production failures move to startup and CI. Invalid view graphs are rejected before they can become request-time surprises.
No hidden database or privilege layer exists. GoConga never needs direct authority over your data model, ACLs, or authentication system.
No browser framework is injected behind your back. Server rendering remains server rendering. Client behavior is explicit and independently selected.
Request overhead stays small. Production rendering avoids filesystem discovery and template reparsing while keeping concurrency safe.
Go toolchain security still matters. GoConga does not replace or vendor the Go standard library. Applications should build with a supported, patched Go release and audit their own complete dependency graph.
Tooling
A small runtime with serious development tools.
goconga init
Create a clean project/view structure without generating an application framework.
goconga dev
Run view and asset validation with development reload.
goconga check
Validate templates, dependencies, helper arity, assets, and literal route/translation references.
goconga lint
Analyze views for structural, dependency, and template problems.
goconga audit
Produce a combined source, build, view, asset, and analysis audit.
goconga manifest
Inspect fingerprinted production assets and resource metadata.
goconga source / build / verify
Create and verify deterministic source and build manifests.
goconga inspect
Inspect the resolved view graph and project resources.
goconga generate / compile
Generate deterministic Go resource inventories without replacing html/template.
goconga benchmark
Benchmark representative views and fragments using standard Go benchmarks.
Application shape
Go stays readable because presentation leaves the Go file.
Go handler
func (h *Handler) Profile(w http.ResponseWriter, r *http.Request) {
page, err := h.service.Profile(r.Context(), r.PathValue("id"))
if err != nil {
h.fail(w, r, err)
return
}
h.views.Render(w, "profiles/detail", page)
}views/profiles/detail.html
{{extends "layouts/app.html"}}
{{define "title"}}Profile · {{.Profile.DisplayName}}{{end}}
{{define "content"}}
<section class="profile">
<h2>{{.Profile.DisplayName}}</h2>
{{template "components/user-badge.html" .Profile}}
</section>
{{end}}Browser layer
JavaScript stays optional and independent.
GoConga does not require StrideJS or any other browser library. This site uses StrideJS for its own lightweight client behavior because the projects share the same preference for standard platform features and low overhead.
StrideJS can enhance GoConga-rendered HTML with reactive state, forms, events, includes, routing, transitions, and lifecycle behavior while GoConga remains entirely usable without it.
Read the GoConga + StrideJS integration guideDesign rule
Go handles the application. HTML handles the document. CSS handles
presentation. JavaScript handles interaction. GoConga keeps those
boundaries useful instead of mixing them together.