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...
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).
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).
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?
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).
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!
Thanks romshark for publishing my post here :) I'm the original writer so I'll try to answer this question from my perspective.
Agree, price and cost do come apart, and chat and API are quite different products with different dynamics. That's why the piece also uses a serving-cost estimate rather than raw API list price - the real number sits somewhere between the SemiAnalysis figure and hosting-cost estimates, and it's still 10x-plus what we pay for a subscription, depending on usage of course.
Usage is where it gets more concrete, margins reportedly go underwater past roughly 11% of the plan limit, and around 5.7% on the top tier. So it's only a subsidy for the people actually hammering it.
I’ve 12 years of official experience and it took me 8 months to find a job. I’ve been also writing about huge problems in the western Europe IT job market - hiring has almost plateaued here. So the trick was to search for a job in the eastern Europe, moving soon.
Quality of generated code is honestly trash, Claude can build you a thing that will work somehow, but under the hood is unmaintainable, entangled, dirty, full of workarounds code :) You need to spend a lot of time controlling every its move to achieve decent code quality.
Hmm, interesting, maybe I should look into the UK market then... Because I often see open positions in the UK segment on the company job boards, just didn't know if it's mostly fake ones as in NL and FR.
The ones I see coming up repeatedly on LinkedIn are real jobs, but for places with high staff churn - Bet365 in Stoke for instance have a voracious appetite for recruiting System Development Managers, mainly because they can't get anyone to stay in the role more than a month.
Yes, I have such thoughts. I'm building something constantly, have a history of attempting different projects, some of them got into startups fueled purely by passion and lasted for years, but didn't attract investments. Currently I'm working on MASS - Modular AI Scheduling System, basically it's a scheduler and package manager for AI-native applications/services. As I see a huge part of future AI as dedicated small fine-tuned models, local to user and on-site programs and services. But it's another story :)
Yeah, by all signs this is how hiring works (or actually doesn't work) right now. I have info from Datadog (France) that they don't hire anybody right now despite lots of openings on their career board. And yeah, originally I'm from Russia, though in EU for almost 8 years by now...
reply