Skip to main content

Showcase

This page is intentionally narrow. It is not a gallery of aspirational mockups. It is a short list of checked-in examples that prove meaningful parts of the framework already work in code you can run today.

Each story here answers a skeptical question. Can Fission handle a real app shell instead of a counter? Can it host custom rendering? Can it survive text-input edge cases? Can it actually launch through browser and mobile hosts instead of only claiming target support in theory?

The point of showcase examples is not only that they look substantial. The point is that each one exercises architecture that matters in production: explicit state, deterministic flow, runtime-managed resources, portals, rendering boundaries, and platform hosts.

Repo-backed stories

What these examples prove

The strongest showcase examples are not just larger. They isolate different architectural claims and make those claims inspectable through source, tests, and host launch paths.

repo-backedexamples/inbox

Inbox proves a full app shell with theme, locale, routing, and host actions

Theme mode, locale switching, portals, responsive navigation, and capability-backed host work all show up in one coherent product shell.

This matters because it shows the shared runtime solving a real class of product problem instead of only rendering isolated widgets. The example is useful when you need a concrete proof, but the related guide explains the design choices in a slower and more beginner-friendly way.

  • locale bundles and `Env` sync
  • portal-heavy app chrome and drawers
  • typed external-link capability flows
Open repo pathRelated guide
repo-backedexamples/editor

Fission Editor proves custom rendering can stay inside the same runtime model

The editor mixes custom surfaces, timers, menus, hover interactions, tabs, and a terminal panel without opting out of reducers, resources, or the pipeline.

This matters because it shows the shared runtime solving a real class of product problem instead of only rendering isolated widgets. The example is useful when you need a concrete proof, but the related guide explains the design choices in a slower and more beginner-friendly way.

  • custom render node path
  • resource-driven background work
  • large live test coverage
Open repo pathRelated guide
repo-backedexamples/text-lab

Text Lab proves the hard text-input cases before they disappear into a larger app

Comboboxes, modal text flows, focus handling, and input method editor-sensitive behavior are isolated so you can verify them directly.

This matters because it shows the shared runtime solving a real class of product problem instead of only rendering isolated widgets. The example is useful when you need a concrete proof, but the related guide explains the design choices in a slower and more beginner-friendly way.

  • combobox popup teardown
  • modal focus reachability
  • text input live tests
Open repo pathRelated guide
repo-backedexamples/mobile-smoke

Target smoke paths keep web and mobile claims grounded in checked-in code

The repo includes browser, Android emulator, and iOS simulator launch paths instead of treating target support as a vague promise.

This matters because it shows the shared runtime solving a real class of product problem instead of only rendering isolated widgets. The example is useful when you need a concrete proof, but the related guide explains the design choices in a slower and more beginner-friendly way.

  • checked-in host scripts
  • generated target parity
  • documented prerequisites and caveats
Open repo pathRelated guide
repo-backedexamples/web-smoke

Web Smoke proves the current browser host path around the shared runtime

The same app model can be compiled to WebAssembly, launched through a generated browser folder, and validated as a concrete host path.

This matters because it shows the shared runtime solving a real class of product problem instead of only rendering isolated widgets. The example is useful when you need a concrete proof, but the related guide explains the design choices in a slower and more beginner-friendly way.

  • wasm-pack driven browser build
  • generated web host shape
  • shared app code with desktop preview
Open repo pathRelated guide