Bus GX And Bus UI

Go-native UI for agentic product teams.

GX and Bus UI let Go-first teams build product frontends in the same Go production line as backend code, tests, and agentic maintenance. Instead of standing up a separate TypeScript and React stack, teams can keep UI logic, generated rendering, and reviewable changes inside the Go toolchain they already operate.

Learn GX Browse Bus UI Open Reference

GX/UI pricing

The pricing page shows the current Bus GX and Bus UI purchase options. Choose GX when you need the library foundation and will build your own components; choose Bus UI when you want the complete supported component package.

View GX/UI pricing

One language, one delivery model

GX gives you .gx source files, typed component functions, generated Go rendering, event callbacks, runtime bridges, and tests.

Bus UI uses GX to provide shared shells, forms, data display, evidence, assistant, terminal, and portal surfaces for Bus products. Together they keep frontend work close to the same static analysis, formatting, testing, and agent workflows used for the rest of the product.

notice.gx

func Notice(props NoticeProps) gx.Node {
  return <section class={"notice " + props.Tone}>
    <h2>{props.Title}</h2>
    {props.Children}
  </section>
}

What this changes for a business

GX is not a universal React replacement. It is a supported UI stack for products where Go is already the main engineering and automation language.

Less stack to operate

Use one Go-oriented build, test, review, and agent workflow instead of a separate frontend production line.

More useful automation

Existing Go-specialized agents can change backend, UI, rendering, and tests without switching language ecosystems.

Lower maintenance drag

Supported components can be fixed in the same codebase instead of waiting for an upstream dependency timeline.

Easier human review

Go types, formatting, static checks, and focused tests make generated UI changes easier to inspect.

Start with the layer you need

The framework pages explain how components are written and rendered. The library pages explain the reusable components Bus products already share.

GX Framework

Author markup in Go packages, compile it into Go, render HTML, mount state, and test the output.

Bus UI Library

Use validated components for forms, shells, status, data, evidence, assistant, terminal, and portal pages.

Reference

Find focused pages and primary Go names for GX framework APIs and Bus UI components.

GX: write the component language

A .gx file stays in a Go package. Props, children, callbacks, control flow, and reviewable generated Go stay close to the product presenter.

Learn source files

component.go

type NoticeProps struct {
  Title    string
  Tone     string `gx:",optional"`
  Children []gx.Node
}

Bus UI: use the public package

Shared components validate public props, keep stable CSS and data hooks, and return explicit errors when a component cannot render safely. Use the public pkg/ui facade first, composing typed nodes and rendering them at the application boundary.

Browse component families

result-panel.go

import (
  gx "github.com/busdk/bus-gx/pkg/gx"
  ui "github.com/busdk/bus-ui/pkg/ui"
)

node := ui.ResultPanel(ui.ResultPanelProps{
  Title:   "Evidence pack ready",
  Status:  ui.StatusSuccess,
  Summary: "3 files prepared for review.",
})

html, err := gx.RenderHTML(node)

GX concepts at the page level

The framework docs split nodes, component functions, props and children, source files, generated Go, events, rendering, runtime mounting, effects, and testing into separate programmer-facing pages.

Nodes and render tree

Work with gx.Node, fragments, text, and composed child trees.

Component functions

Return nodes from Go functions and keep composition explicit.

Props and children

Pass data through Go structs and nested content through child slots.

Source files

Author .gx files, format them, and compile them into Go.

Generated Go

Inspect the compiled roots that the package and tests actually execute.

Events

Use typed callbacks and payloads for click, form, input, and drop handling.

Rendering

Turn nodes into stable HTML and a normalized render tree.

Runtime bridges

Mount stateful trees and separate host interaction from pure rendering.

Effects

Route actions and resource requests through the host.

Testing

Assert snapshots, generated output, and mounted behavior from Go tests.

Use it across frontend hosts

Render stable HTML on the server, mount stateful Go components where a host needs interaction, bridge through Go/WASM for browser-specific behavior, and embed shared shells inside Bus portal modules. Browser hosts still use normal web assets to load WASM; the application UI logic stays in Go.

Server-rendered pages

Use deterministic HTML for documents, pages, snapshots, and tests.

Mounted apps

Keep state across renders with explicit runtime diagnostics.

Portal modules

Pass host context, public config, assets, and provider origins safely.

Browser bridges

Use Go/WASM helpers for host behavior that requires browser APIs.

Reference documentation

The reference index maps the framework concepts and component families to their primary Go names and tutorial pages.

Open Reference