Today, Fission does not ship a live in-browser editor for trying widgets from a text box in your browser. The practical playground is local and target-aware: run a small example or your own app on the host that best matches the product question you are exploring, change one reducer or one widget branch, and immediately see the result in the real runtime you will keep using later.
That may sound less glamorous than a toy sandbox, but it is more honest and more useful. You are experimenting against the real layout engine, the real input pipeline, the real rendering path, and the real platform hosts. When something works in this loop, you are learning something that carries directly into product code.
Choose the smallest host that can answer your question. On many machines, desktop is the easiest general loop for shared-runtime questions because rebuilds are fast and packaging friction is low. But if your product question is really about browser hosting, Android packaging, iOS simulator flow, viewport behavior, or another target-specific concern, start on that host instead. The point of the playground is not to define a primary platform. It is to give you a truthful experiment loop.
Recommended loops
Different loops are useful for different kinds of work. If you only need to understand a reducer or a layout branch, keep the loop small. If you need to verify overlays, semantics, screenshots, packaging, or a target launcher, widen the loop deliberately and choose the host that can actually prove that behavior.
Start with a local app or checked-in example, change one reducer or widget branch, and verify one visible result before moving on.
On many machines this loop is easiest through the desktop host because rebuilds are fast and packaging is minimal, but the real goal is to answer shared-runtime questions that apply across every target.
cargo run -p countercargo run -p widget-gallerycargo run -p text-labRun a real shell with the test-control server enabled and script it with `LiveTestClient` when overlays, semantics, or screenshots matter.
Use this when you want to verify behavior in a real window, not just in a headless harness.
FISSION_TEST_CONTROL_PORT=48711 cargo run -p text-labcargo test -p widget-gallery --test live_e2e -- --ignoredUse the checked-in or generated host scripts when browser, Android, or iOS behavior is part of the experiment and you need the real target host to answer the question.
Keep the target READMEs close. They contain the real prerequisites, current caveats, and target-specific environment variables for the host you are validating.
./examples/web-smoke/platforms/web/run-browser.sh./examples/mobile-smoke/platforms/ios/run-sim.sh./examples/mobile-smoke/platforms/android/run-emulator.shGood scratchpads
Each example below is small enough to edit safely and focused enough that one change usually teaches one idea. That makes them better playgrounds than jumping straight into the largest product-like crate. If your question lives on a browser or mobile host, the target examples belong in that first group too.
The smallest complete Fission app loop, plus a modal, checkbox, text input, selector, animation requests, and a small custom canvas example.
Use this when you want to practice typed actions and reducers, selector-backed view model, and modal overlay and animation wiring.
cargo run -p counterA broad survey of the built-in widget surface, useful when you want to see how common controls, overlays, and data widgets already behave.
Use this when you want to practice layout, input, navigation, and feedback widgets, and semantic tree and screenshot checks.
cargo run -p widget-galleryThe focused proving ground for text input, comboboxes, menus, modal focus, and input method editor-sensitive flows.
Use this when you want to practice single-line and multiline editing, combobox overlay teardown, and modal text flow and focus handling.
cargo run -p text-labThe checked-in host path for Android emulator and iOS simulator packaging and launch around shared app code.
Use this when you want to practice shared mobile runtime host, test control port forwarding on Android, and generated host-folder reference.
cargo run -p mobile-smoke./examples/mobile-smoke/platforms/ios/run-sim.sh./examples/mobile-smoke/platforms/android/run-emulator.shThe checked-in WebAssembly and browser host path, plus the clearest reference for generated web launcher folders.
Use this when you want to practice wasm-pack build script, and browser host bootstrap.
cargo run -p web-smoke./examples/web-smoke/platforms/web/run-browser.shLater
A future browser playground would make sharing snippets and trying small layout ideas easier. That would be useful, especially for teaching and quick experiments.
Until that exists, the honest path is still to experiment in the real hosts you plan to learn or ship on. That keeps you close to the checked-in examples, teaches the actual runtime and host boundary, and avoids a split between a toy sandbox and the architecture you actually ship.