11 hours ago
After 7 long months of lots of work and rumination, it finally happened!
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!
11 hours ago
I've been using Datastar a bit and I really liked it. How is this better than the vanilla Datastar? Like can you name a couple core features that can make me use it? Also Go is not very framework oriented...
11 hours ago
The core feature is the toolchain :) the linter & code generator.
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).
11 hours ago
I see, thanks, but how exactly can it help agents to use Datastar better? If it's a superset on Datastar, isn't it just another set of rules an agent needs to learn?
10 hours ago
Having rules is good, but having rules that you can statically enforce is better (partly why Rust is so popular, right?). Think of golangci-lint. Datapages can prevent drifting agents (and humans) from making mistakes using static code analysis.
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).
10 hours ago
I like that - "You can literally wipe 2/3 of the code base and recreate it idempotently and deterministically...", I like the idea of having an easily recyclable code, especially nowadays. Okay, so I see how it can contribute to more efficient agentic workflows. I'll give it a try. Thanks for the answers!