Thanks for your feedback. I cannot reproduce it. If the problem persists, I would be happy if you create a detailed issue on GH, thanks!
31 karma · joined April 10, 2025
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!
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.
"Templ - Type-safe templating for Go" with a link to templ.guide.
Thanks for the feedback!
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 helps keep things consistent as the library evolves.
But yeah, I get that some folks prefer manual imports – all good!
templ’s more for folks who want to stay in Go but need a smoother frontend experience for modern UI needs.