datapages on GitHub (romshark/datapages)

datapages README

Datapages

[!NOTE] Beta: Datapages is ready for production use. APIs are close to stable but can still change.

A Templ + Go + Datastar web framework and toolset for building GUI apps and web application in pure Go - no matter whether it's a real-time collaborative dynamic web app, a simple HTMX-style website, or an installable local-first GUI app.

See FAQ.md for frequently asked questions.

Utilize AI agents more efficiently

Datapages will provide your coding agents with the skills and CLI tools they need to generate well performing, resource-efficient apps and keep the code base coherent and maintainable, lowering token-usage, reducing potential for bugs and vulnerabilities as well as slowing the accumulation of technical debt.

Focus on your business logic

Datapages parses your app source packages, lints them, reports errors, and generates all the wiring and boilerplate. Routing, sessions and authentication, SSE streams, per-tab server-side state, CSRF protection, type-safe URL and action helpers, Prometheus metrics, JavaScript service workers etc. - so your application code stays clean and takes full advantage of Go's strong static typing and high performance.

Examples

counter: Real-time counter built twice in one module, bare bones as app/simple and polished as app/fancy. Bare bones starting point, and the example of a module that builds more than one application.
todolist: Real-time collaborative todo list with per-tab server-side state (Most Tao conform example).
calculator: Hybrid calculator app that runs both as a multi-client server and single-client Desktop app.
classifieds: Full-featured classifieds marketplace with sessions, auth, Prometheus metrics, Grafana dashboards and load testing.
tailwindcss: Minimal static page demonstrating Tailwind CSS integration.
webcomponents: Landing page with vanilla and Lit-based Web Components bundled via esbuild through a custom watcher.
sqlitesessions: Custom sessions.Manager implementation backed by SQLite via sqinn-go (no cgo).
fast-shim: A cached placeholder shown immediately and replaced with the live response.
offline-cache: Service worker support with handler-cached pages, a PageOffline fallback, and tickets available without a connection.
file-upload: Chunked file uploads to disk that can be paused, resumed and continued after a reload or a server restart, with server-enforced transfer limits.

Getting Started

See the Guide.

Specification

See SPECIFICATION.md for the full source package specification, including handler signatures, parameters, return values, events, sessions, and modules.

Modules

Datapages ships pluggable modules with swappable implementations:

Manager[Data]
- natskv - NATS KV store with AES-128-GCM encrypted cookies
- inmem - In-memory sessions (lost on restart; single-instance only)
Broker
- natscore - Core NATS backed message broker
- inmem - In-memory fan-out message broker (single-instance only)
TokenWriter, TokenValidator
- Tokens - the built-in default: HMAC-SHA256 over the session token under a fixed domain-separator key, BREACH-resistant masking, nothing to configure
TokenGenerator

Motivation

The reason I built Datapages is that the combination of Datastar + Go + Templ is my preferred way of writing server-centric web applications. But in every project I used this tech stack for I kept repeating the same code patterns and solving the same problems over and over again. I realized many developers are repeating the same patterns too and struggle with the common pitfalls:

How to handle SSE streams correctly?
How to use NATS effectively?
How to approach security and authentication?
How to configure a convenient hot-reload for development?
How to keep the code maintainable over time, especially when you add more developers and/or AI assistants?
How to keep AI coding assistants from drifting too much?
How to achieve optimal performance and a good UX for endusers?

Your Datastar frontends are your rocket to extraterrestrial worlds of the internet. The further you want to go, the heavier a rocket you'll require. Hence, you need powerful boosters to get it off the ground and overcome Earth's gravity. Such boosters exist in the form of awesome templates like zangster300/northstar, which will quickly get your rocket to the stratosphere and beyond. But power alone is not enough — you also need good stabilizing fins and thrust vectoring to keep your rocket steady as it flies. I felt like this part was lacking in the Go ecosystem of Datastar. By enforcing a common structure of types, methods and other conventions with tooling, Datapages provides not only the power but also the stability your rocket needs to stay in flight for long and consume as little brain fuel as possible.

Not only does Datapages allow you to start quickly with datapages init and jump straight into building your application, but it also continuously supports you keeping accidental complexity low by:

Providing a Datastar Tao oriented architecture as a good default while preserving enough flexibility to go beyond if you need to.
Providing datapages gen to generate all boilerplate code consistently and guide you and your AI coding agents.
Providing datapages lint that can be used in CI/CD workflows for extensive static code analysis.
Providing datapages watch to give you an interactive hot-reload environment for a fast feedback loop with error reporting directly in the browser preview.

Agentic coding is a big topic right now and likely here to stay. But LLMs tend to drift over time and introduce accidental complexity. So for AI to be used more effectively I wanted to provide the skills and instructions necessary for agents to know how to deal with this tech stack and call into Datapages CLI help them when they drift by providing them with useful feedback.

Cost comparison: doing it all yourself, using AI assistance, and Datapages plus AI assistance

Who This Is For

Datapages is a good fit if you:

Already write your backend in Go and want to build your web frontend in the same language and toolchain.
Are building a server-rendered application, where the server owns the data; not a local-first offline-capable SPA.
Already use Datastar and want a Go framework to help you ship faster with less code while preserving maintainability.
Already use Templ and want a full framework built around it.
Use HTMX, idiomorph and Alpine.js, and instead want a single cohesive stack with a smaller bundle size and less spaghetti-code.
Don't want to maintain a separate REST/GraphQL API just to feed your frontend.
Want to deploy as a single, statically compiled binary that makes the most of your hardware.
Want to develop hybrid desktop apps in Go and HTML5 (see Calculator example)

Contributing

See CONTRIBUTING.md for development setup and commands, and AGENTS.md for code style, testing conventions, commit message format and project structure.

114 ·GitHub

Datapages

What is this?

Datapages is a web framework and toolset for building GUI and web apps in pure Go on a Templ + Go + Datastar stack — real-time collaborative web apps, simple server-rendered sites, or installable local-first GUI apps.

How is it different from wiring up Datastar with Go by myself?

It parses your source packages and generates the wiring you'd otherwise hand-roll in every project: routing, SSE streams, per-tab server-side state, CSRF protection, Prometheus metrics and service workers — so your code stays clean and takes full advantage of Go's static typing.

What's the first command I run to try it out?

Scaffold an app with datapages init; during development datapages gen generates the boilerplate and datapages watch gives you hot-reload with errors shown right in the browser preview.

Do I need NATS or other infrastructure to run it?

No — the pieces are pluggable: in-memory sessions and broker work for single-instance apps, and you can swap in NATS-backed implementations (KV sessions with AES-128-GCM encrypted cookies) when you scale out.

The README calls it beta — how safe is it for production?

It explicitly says Datapages is ready for production use, but APIs are close to stable and can still change — expect some upgrade churn while it matures.

So it's not for building an offline SPA with a REST API?

Correct — it targets server-rendered apps where the server owns the data, not a local-first offline-capable SPA, and it removes the need to maintain a separate REST/GraphQL API just to feed the frontend.

Can it build real desktop apps, or only web apps?

Hybrid ones: the calculator example runs both as a multi-client server and as a single-client desktop app, and apps deploy as a single, statically compiled binary.

Why did the author build this instead of using Datastar with Go directly?

Datastar + Go + Templ is his preferred stack, but he kept repeating the same patterns — SSE handling, NATS usage, auth, hot-reload setup — in every project. Datapages packages those solutions and adds the structural stability he found missing in the Go Datastar ecosystem.

What is the Tao architecture it enforces?

A Datastar Tao-oriented app structure provided as a sensible default — common conventions for types and methods that the tooling checks — while still leaving room to go beyond it. The todolist example is the most Tao-conform one.

Can I use Tailwind CSS or Web Components with it?

Yes — there are examples for both: a minimal static page showing Tailwind CSS integration, and a landing page with vanilla and Lit-based Web Components bundled via esbuild through a custom watcher.

What are similar projects?

gin-vue-admin, casbin-gateway, wasp, agentsview, plandex, ontology-driven-dev, okf-agent-memory, open-swe

Which topics is it in?

csrf, sse, agentic-coding, full-stack, code-generation, ai-coding, static-analysis, web-framework, coding-agents, authentication, real-time, golang

Creator: romshark
Size: 7.3 MB
Stars: 114
Updated: CommitOct 15 Releasev0.10.1Sep 26
Age: 9mo
Commits · 90 Days