Overview

What makes gjsify different

Three worlds, one runtime

GNOME, Node.js, and the Web have lived in separate runtimes for a decade. gjsify dissolves the boundary — every API lands inside one SpiderMonkey process and shares the same memory, the same event loop, the same GTK main context.

GNOME

• Gtk 4 widgets
• libadwaita
• GIO file / network / DBus
• GStreamer pipelines
• WebKit, libsoup, Cairo

Node.js

• fs · net · http(s)
• stream · events · process
• crypto · worker_threads
• util · buffer · url
• 44 of the 50 stdlib modules

Web

• fetch · WebSocket · SSE
• Canvas 2D · WebGL · WebGPU bridge
• WebRTC · WebAudio · Gamepad
• FormData · Streams · Crypto
• DOM events, Mutation/Resize observers

gjsify

One SpiderMonkey process. One TypeScript codebase. Zero glue between worlds.

For example

Ship a browser game engine — without shipping a browser.

Excalibur.js renders directly into a Gtk.GLArea through gjsify's WebGL bridge. Pointer, keyboard, and gamepad input flows through GTK4 event controllers, dispatched as W3C DOM events. Audio runs on GStreamer through the Web Audio API. The whole game lives in one process — the same one that draws the Adwaita window around it. No WebKit.WebView, no IPC bridge, no embedded Chromium.

Electron app ~150 MB Chromium runtime · separate renderer process · webContents bridge · X11/Wayland double-buffered

gjsify app Stock GJS · single process · native GTK4 widgets · uses the GNOME runtime the user already has installed

Where to go next

• How It Works — the build pipeline: auto-aliasing, --globals auto, native prebuilds
• Coverage — how complete the Node, Web and bridge surfaces already are
• Showcases — end-to-end apps that run unchanged on GJS and in the browser
• Getting Started — scaffold and run your first app