Datapages, the Datastar-powered Go frontend meta-framework and toolchain has reached beta
This is the first release of Datapages I consider production ready.
P.S. Please read the release notes, I've carefully hand-written them for you Otherwise - happy to answer any question!
TL;DR: Datastar is awesome, but in each Go code base with Datastar I just kept repeating the same code patterns over and over again, and coding agents kept messing up too. Hence, I thought that this code should not be owned and maintained by the author of the business logic, instead it should be owned by a code generator that calls into your business logic.
It keeps the code base more maintainable, especially with agentic coding and should also reduce your token usage (you give the agents less freedom of choice to maneuver within which makes them more efficient).
Read the full motivation here: https://github.com/romshark/datapages#motivation
> Also Go is not very framework oriented...
True. But Datastar is a framework :) it does define how your Go code is going to look and function; and I believe to have found the best approach to Datastar in Go, which doesn't compromise on performance and DX and remains flexible enough to cover practically any sort of use case, except SSG (static site generation).
A very simple example is a stale link to a page that no longer exists. Datapages will not allow `<a href="/account">Account</a>` in your Templ templates, `datapages gen` or `datapages lint` will error. It will give you a hint, that you should be using a URL builder from the generated package instead: `<a href={ href.PageAccount() }>Account</a>`. And if that page is ever changed/removed - that will produce an actual compiler error.
But this is obviously just one of the smallest of mistakes.
A production ready application requires a lot of moving parts: - SSE stream subscription, teardown, per-tab state, panic recovery, and graceful shutdown. - Auth, sessions, CSRF, input validation, cross-origin, CSP, etc. - AI skills (I created and tested them for you so you don't have to). - Logging, metrics. - All the NATS boilerplate for doing proper CQRS. - Service workers, browser-local caches, static assets. - Live reload in dev mode (https://github.com/romshark/templier is built in) - etc.
Basically, I'm trying to move a lot of the "plumbing/infrastructure" code out of your and/or your agents ownership into the ownership of a well tested code generator to make it super cheap and easy to ship production grade Datastar apps in Go. You can literally wipe 2/3 of the code base and recreate it idempotently and deterministically, so you really only own and maintain 1/3 of the code (fewer bugs, fewer AI tokens).