romshark
Joined 10 years ago
Joined 10 years ago
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).
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!
it's a CLI toolchain with a code generator and linter.
I invested time into this because:
1. Go is a much less wasteful SSR solution than JavaScript.
2. Datastar + Templ + Go is a highly effective combination.
3. I wanted a set of tools that not only helps getting started with a project fast, but also allows me to make it easier to maintain, especially with coding agents.
v0.10.0 should soon move it out of alpha into the beta stage.
Yes, as stated in the article, it probably could have been cheaper. But this setup is supposed to:
1. Run simulations and benchmarks of/on entire SCION topologies with multiple ASes.
2. Potentially grow beyond 25 Gbit/s into the 200 Gbit/s ranges (and more?).
3. Be available to me ASAP (can't wait months for it to arrive from China).
4. Potentially be used for CI/CD performance regression testing in the future.
The budget allowed a bit of headroom for the future.
SCION also offers more protection against DDoS attacks and other outages thanks to its multi-path routing capabilities and ability to failover quicker than BGP as it builds and stores its path knowledge in advance.
> How do I peer with the big corps in a SCION world?
You do so by joining an ISD (Isolation Domain) and inheriting TRC (Trust Root Configuration).
> so SCION doesn't really enable a more secure internet, it enables more (largely corporate) control
Much critical infrastructure is still reliant on leased lines or MPLS which is expensive and reliant on a single ISP which often reduces resilience. It often also requires assurances about where its traffic is being forwarded (e.g. through particular countries or regions) which is difficult or impossible with BGP. SCION can instead provide these assurances over the commodity Internet provided by multiple ISPs, by being able to verify paths and allowing packet senders to control how packets should be routed given the available path options.
ISDs are typically for specific use cases (e.g. Swiss Secure Finance Network) where strong assurances are needed for where traffic is sent, but ISDs can decide admission criteria for themselves and how they wish to communicate with other ISDs and the rest of the Internet.
Think of the power grid for example. Putting power plants on the internet is probably a bad idea. A better idea is to interconnect power plants through multiple ISPs over a SCION ISD. Less expensive than leased lines or MPLS, and more flexible.
I'm trying to make i18n easier, integrate it better with CI/CD and automate it more with LLMs (for now in Go, second priority is TypeScript and other languages later).
For this I had to develop a completely new approach and subsequently a specification for the "textual internationalization key" (TIK) which are programmatically translatable to ICU MF.
Toki is the first TIK processor implementation for Go.
I've held a talk about this, unfortunately wasn't recorded. I've tried to squeeze as much out of Go as I could and I've went crazy doing that :D
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).