~/
rust-munich
·
crux + gpui
# Where to go next You have a crux core and a gpui shell talking to each other over HTTP. From here, a lot of directions open up. --- ## Easy wins - Add a `Reset` button. One new variant, two lines in `update`. - Show a history of fetched weather snapshots. The core changes; the shell barely does. - Try the theming. gpui-component gives you light/dark out of the box. - Surface errors. Right now we eat them silently; turn them into a red tag. --- ## Tests are cheap — go wild The crux model makes unit tests almost free. Try: - "Decrement from 1 to 0 fetches weather." - "WeatherLoaded(Err) keeps the previous snapshot." - "Hammering `+` only fires one in-flight request at a time." No mocks. No fixtures. Just `update(event, &mut model)` and assertions. --- ## Bring it to the web Look at this again:
The same widgets we use natively, running in a **browser tab**. The Longbridge team appears to compile the `story` showcase to **WebAssembly** and render it on `
` via WebGPU/WebGL. What stops us from doing the same to our counter app? - Our **core** is pure Rust → already WASM-ready. - The **shell**'s HTTP path uses `ureq` (blocking) → in the browser we'd swap that for `fetch` via `web-sys` or `gloo-net`. - The gpui side would need the same WASM treatment Longbridge applied to `story`. That last step is the homework. Start by reading the `gallery/` and `wasm/` folders of
. --- ## A different shell entirely Because the core does not know about gpui, you can wrap it in: - A **ratatui** TUI shell (terminal UI). - A **leptos** web app (no gpui at all — pure DOM). - A **mobile** shell via crux's typegen → Swift / Kotlin bindings. The Red Badger examples repo has working versions of each:
--- ## Where to keep reading - The **crux book**:
- **gpui-component story crate**:
- **Tailwind docs** (yes, really):
--- ## That's it Now go break things.