Bus GX And Bus UI

Modules behind the supported Go UI stack.

GX provides typed component authoring and generated Go rendering. Bus UI provides reusable node-first surfaces built on top of GX. The module set is designed for teams that want frontend code, backend code, tests, and agentic maintenance to share one Go-oriented production line.

Core product modules

  • bus-gx for .gx source parsing, formatting, linting, compilation, render trees, callback plumbing, runtime bridges, and tests.
  • bus-ui for reusable node-first components: shells, panels, forms, status, tables, lists, files, evidence, terminals, assistant controls, and portal integration surfaces.
  • bus-portal for host chrome, module launch, mounted app runtime handoff, runtime fixtures, and policy-free portal acceptance coverage.
  • bus-portal-ai, bus-portal-accounting, bus-portal-auth, and bus-portal-notes for module-owned adapters that consume shared Bus UI surfaces while keeping product behavior local.
  • Deterministic test harnesses for generated rendering, node-first adapters, mounted apps, callback dispatch, and component behavior.

Boundary model

Presentation components compile to Go. Shared components validate their public props and fail closed when required slots, hrefs, or trusted fragments are unsafe. Product modules still own data loading, provider calls, authorization, storage, upload policy, evidence access, redaction, and state transitions.

Adoption state

The Bus portal family now uses shared Bus UI surfaces for the common page, action, status, form, evidence, table/list, assistant, terminal, and mounted-app paths. Remaining behavior-heavy helpers are documented as Go-owned exclusions rather than missing presentation components.

Commercial adoption

Bus GX and Bus UI are commercial source-available products, not open-source public Git source releases.

Bus GX is the library foundation for teams that want to build their own component package. Bus UI includes GX and adds the complete supported component package used across Bus product screens.

The intended customer fit is a Go-first or agent-first product team that wants to avoid building a second TypeScript and React agent, build, test, and component stack. Browser-mounted apps still use normal web assets and Go/WASM loading where needed; the application UI model stays in Go.

See GX/UI pricing

Reference documentation

The product documentation covers the authoring model, component contracts, versioned feature pages, generated Go output, and runtime behavior.

Open documentation