Skip to content

UI framework review — Argus /ui polish (ARGUS-120)

Where we are

  • Stack: Go html/template (server-rendered) + HTMX (vendored, no CDN) + a PWA (manifest, service worker, theme-color #11161d). Deployed as a single Go binary/container. No Node, no build step.
  • CSS today: one hand-written style.css (~264 lines) with a GitHub-ish custom-property token system (light + dark via prefers-color-scheme), system fonts, mobile-first. Plus a little per-page inline <style>. Clean bones, but no cohesive component layer — it reads "functional," not "designed."
  • 11 nav sections (Runs, Memory, Episodes, Injections, Feed, Projects, Review, Parked, Lint, Tasks, Jobs).

Constraints that drive the choice

  1. No-build is a feature. A Go service that ships as one binary is simple to deploy; adding a Node/PostCSS pipeline is real, permanent friction (CI stage, tooling, version drift).
  2. Aaron knows Tailwind — YACT (Phoenix + Tailwind), personal-site (Astro + Tailwind). Consistency across projects has value.
  3. Aesthetic target: app-like, dark-first, rounded cards, considered color — the Bubble Card / navbar-card vibe, "The Way of Color."
  4. HTMX-friendly: fragments swap in; the styling layer must work on server-rendered semantic HTML, not assume a SPA.
  5. "Simple but effective."

Options

1. Tailwind (standalone CLI) + daisyUI

  • Tailwind ships a standalone binary — no Node needed; one compile step in CI/build produces style.css.
  • daisyUI (a Tailwind plugin) adds semantic, app-like components — card, navbar, badge, btn, table, built-in dark themes — closest to the Bubble Card look with the least custom CSS.
  • Matches Aaron's muscle memory; fastest path to "nice."
  • Cost: a build step (the no-build property is gone), utility-class verbosity in templates, CI gains a compile stage. Theming is daisyUI's, not fully bespoke.

2. Pico CSS

  • Classless/semantic, dark-by-default, ~10 KB, single file, zero build. Drop it in and the semantic HTML Argus already writes (header/nav/main, article, table) looks polished immediately.
  • Best HTMX pairing; near-zero template churn.
  • Cost: generic out of the box — getting a distinctive app identity means overrides; component vocabulary is thinner than daisyUI.

3. Open Props (+ evolve the existing hand-CSS)

  • A design-token layer (colors, shadows, sizes, fonts, easings) as a single import — no build. You keep authoring components, but on a professional token foundation. Argus already has half a token system, so this is a natural level-up.
  • Maximum control, keeps the bespoke look, no utility-class noise, no build.
  • Cost: you write the components (cards/badges/tables) yourself — more manual than daisyUI, though the current CSS is a head start.

4. Formalize the hand-CSS into a design system

  • Evolve style.css into proper tokens + a component layer, no new dependency.
  • Most control, zero deps; most manual effort and least "free" polish.

Recommendation

The real fork is one question: is a single CSS build step acceptable in the Argus pipeline?

  • Yes → Tailwind standalone + daisyUI. Fastest to the app-like-dark aesthetic, matches your other projects, components for free. Best if you want it to look designed quickly.
  • No (keep Argus build-free) → Open Props on top of the existing tokens. You already have the palette + dark mode; Open Props adds the rest of the system, and you build a small component layer (card, badge, btn, table, nav) once. Keeps full control and the single-binary simplicity.

My lean: Open Props + a hand-built component layer. Reasons — it preserves the no-build simplicity that suits a Go control-plane, it builds directly on the token system you already have (so it's evolution not rewrite), and a focused component pass gets you 90% of the daisyUI look without the pipeline. If you'd rather move fast and don't mind the build stage, Tailwind+daisyUI is the pragmatic call and keeps you consistent with YACT/personal-site.

Proposed epic shape (ARGUS-120)

  1. Foundation — pick the approach; establish tokens (color ramps, spacing, radius, shadow, type scale), dark-first; refit the shell (header/nav → app-like top bar or sidebar; the 11 links want grouping).
  2. Component layer — card, badge/pill (lifecycle + verified states), button, table, form controls, banner/toast — one consistent set used everywhere.
  3. Per-page polish — Tasks (the tree + the new collapse carets), Memory/Notes, Runs, Review, Feed — applied page by page, each its own task.

Inspiration to pull from

  • YACT — its Tailwind component patterns + the judge-card / status-pill language (we can mirror the lifecycle/verified badges).
  • Bubble Card / navbar-card — rounded, elevated, dark cards; a compact app-like nav.
  • The Way of Color — deliberate accent + state colors (ok/warn/fail) rather than ad-hoc hex; we already have --ok/--fail, extend into a proper ramp.