I’m building templUI – a UI kit for templ, styled with TailwindCSS.
It includes a CLI installer to add and manage components (like: templui add button modal) – inspired by shadcn/ui.
templUI – The UI Kit for templ
Goals:
- Help Go devs build UIs faster with well-structured, minimal components
- No JS frameworks – just Vanilla JS
- HTMX-friendly, but optional
- CSP-compliant by default
- Built for enterprise use and long-term scaling
Currently at v0.7x, with 1000+ commits and 500+ GitHub stars. It's already used in production projects and evolving fast.
* Website: https://templui.io
* GitHub: https://github.com/axzilla/templui
Happy to hear feedback or ideas!
I could've just Googled it sooner, but I was just surprised I couldn't find any reference to the thing it's actually building on/for.
"Templ - Type-safe templating for Go" with a link to templ.guide.
Thanks for the feedback!
It's a language that compiles down to Go and lets you mix HTML-like syntax into your Go code for HTML templating.
You really just paste these 2 lines in your html and that's it:
<link href="https://cdn.jsdelivr.net/npm/daisyui@5" rel="stylesheet" type="text/css" />
<script src="https://cdn.jsdelivr.net/npm/@tailwindcss/browser@4" />
it's a bit more than 100kb of js, but for prototyping it is very nice.I wish more UI libraries where in the same style. You can always optimize the bundle later.
With TemplUI, I’m aiming for a more minimal, dependency-free setup – no extra Tailwind plugins or runtime JS unless absolutely needed. The idea is to stay as close to the metal as possible and let devs build their own design system on top, rather than fight against a pre-styled one.
It's less “drop-in UI kit” and more “starter kit to build your own.” That makes it more customizable and hopefully a better fit for projects that want full control.
But Datastar tries to do both, AlpineJS stuff like show/hide dropdow options, as well as HTMX stuff like talk to backend and merge/replace parts of the DOM.
I came across TemplUI a few times while working on this app so far. But always felt the Vanilla JS plus HTMX approach of TemplUI conflicts with Datastar. Too much overlap in different components doing the same stuff for my taste. While at the same time, I spent way too much time converting Tailwind UI components into Tempo. Time I could spend better.
Datastar is quite on the experimental/unstable side of things. And its concept of signals doesn't quite work for my Kubernetes style API resources. So maybe I need to revisit this decision at some point.
What I really like about Datastar and what made me choose it in the first place is how easy it makes using server sent events.
So yeah, exciting times. Still some rough edges I would say. But for me personally I already prefer hypermedia over the predominant React frontends approach.
Not a fan of that.
It helps keep things consistent as the library evolves.
But yeah, I get that some folks prefer manual imports – all good!
Originally, I had templUI components available via Go module imports, but there were a few real issues:
- Tailwind v4+ with CSS-only config needs hardcoded paths to `.templ` files. That clashed in teams where Go paths differed (e.g. `~/dev`, `~/code`, etc.).
- It made Git diffs messy – you had `.templ` and `.go` files being imported per component.
- Updating components via module versions often led to unwanted breaking changes – not easy to "just use one component" from a newer version.
- Workarounds like Makefile tricks for Tailwind `src` path felt too hacky.
The CLI avoids all that. It copies clean files into your codebase, so it's portable, version-safe, and no import path magic needed.
That said – I’m open to feedback. If there's a solid reason to bring back module imports (optionally), I’m listening!
By “HTMX support” I just mean: the JS logic in components (e.g. tooltips, modals) auto-reinitializes after HTMX swaps.
So you can use components inside HTMX-driven UIs without worrying about broken behavior.
It definitely doesn’t feel like JSX or any other modern/exciting thing to me.
templ’s more for folks who want to stay in Go but need a smoother frontend experience for modern UI needs.