Showcases

The showcases are end-to-end runnable applications that double as proof of the @gjsify/* pillar set’s coverage. Every showcase runs in two places from the same source:

• In a GTK4 window via gjsify showcase <name> — Cairo / WebGL / WebKit / GStreamer backing the standard DOM APIs the showcase code reaches for.
• In a regular browser via import { mount } from '@gjsify/example-dom-<name>/browser' — same module, native browser implementations.

If something runs on GJS through GJSify, it also runs in the browser unmodified (and vice versa). That cross-platform contract is the point.

Browse the catalog

Showcase	Pillar focus	Browser demo
adwaita-storybook	Adwaita + @gjsify/adwaita-web + @gjsify/storybook	Interactive Libadwaita component browser (native GTK + browser, one shared story)
canvas2d-fireworks	DOM + @gjsify/canvas2d	Particle fireworks on a Canvas2DBridge / <canvas>
excalibur-jelly-jumper	DOM + @gjsify/webgl + @gjsify/xmlhttprequest	Excalibur.js 2D platformer with Tiled tilemaps
three-geometry-teapot	DOM + @gjsify/webgl	Three.js Utah teapot with parameter controls
three-postprocessing-pixel	DOM + @gjsify/webgl + post FX	Three.js pixel-art post-processing pipeline
minimalist-browser	DOM + @gjsify/iframe	URL bar + <iframe> (WebKit on GJS, real <iframe> in browser)
webrtc-loopback	@gjsify/webrtc	Two local peers exchange offer/answer + RTCDataChannel
webrtc-video	@gjsify/webrtc + @gjsify/video	Webcam preview — getUserMedia stream rendered through VideoBridge / native <video>
express-webserver	Node — @gjsify/http + express	Express HTTP server running unmodified on GJS

Running a showcase locally

Terminal

gjsify showcase                          # list all
gjsify showcase canvas2d-fireworks       # run on GJS (opens a GTK4 window)

The CLI resolves the showcase’s npm package (every showcase is published as @gjsify/example-<category>-<name>) and launches its GJS bundle via gjs -m. Native dependencies (Vala typelibs) are auto-discovered from node_modules’s prebuild directories.

Pick the runtime — --runtime

Add --runtime to run a showcase on Node.js, Bun or Deno instead of GJS, through the @gjsify/node-gi reverse bridge — same GTK4 window, same source, a different JS engine underneath:

Terminal

gjsify showcase canvas2d-fireworks --runtime gjs    # gjs -m
gjsify showcase canvas2d-fireworks --runtime node
gjsify showcase canvas2d-fireworks --runtime bun
gjsify showcase canvas2d-fireworks --runtime deno

--runtime defaults to whichever runtime the CLI itself is running on (gjs for a global GJS install, node/bun/deno when invoked via npx/bunx/deno run). A showcase can restrict which runtimes it supports via package.json#gjsify.example.runtimes; requesting an unsupported one fails with a clear error instead of a bundle crash. Details: Runtimes · CLI Reference.

Running the browser version

Every showcase ships a ./browser export pointing at a TS module you can mount into any DOM container:

TypeScript

import { mount } from '@gjsify/example-dom-canvas2d-fireworks/browser';

const container = document.getElementById('app')!;
mount(container);

The website’s <ShowcaseEmbed> component handles the loading and lifecycle for the live demos linked above. Source for each showcase lives under showcases/ in the GJSify repo — see the per-showcase pages for the deep dive on how each one exercises the pillar set.

Why two targets matter

Showcases are how we prove the cross-platform contract: code written against standard DOM / Web APIs runs unmodified on both. Every gap surfaced by a showcase (a missing event, an unhandled Canvas method, a Web API stub) becomes a bug-fix in the underlying @gjsify/* package — never patched at the consumer level. The browser entry is the ground truth, the GJS entry validates we match it.

When the matrix grows (new pillars, new bridges, new Vala extensions), showcases grow with it.