04 — In development
OmniJS
A custom front-end framework with `.rlm` (Realm) components, zero-build runtime interpretation and AOT compilation.
A lightweight front-end framework and CLI compiler built from first principles. `.rlm` components run directly in the browser with no build step, reactivity is signal-based, and the same source can be compiled ahead of time for production.
- Role
- Creator & maintainer
- Year
- 2025
- Status
- In development
Links for this project are not public yet.
Problem
Modern front-end tooling assumes a build step before anything runs. That is a reasonable default, but it hides what a framework actually does and puts distance between a file and a rendered node. I wanted both paths available: interpret now, compile when it matters.
Approach
OmniJS treats `.rlm` components as the source of truth. The runtime parses and mounts them directly, so a component can be authored and shipped without a bundler. The same input can be compiled ahead of time by the CLI, producing static output for deployments that want it.
Key features
- 01`.rlm` component format (Realm) interpreted at runtime
- 02Zero-build workflow: ship components the browser can read
- 03Signal-based reactivity with fine-grained updates
- 04Ahead-of-time static compilation for production output
- 05CLI compiler for building and inspecting projects
Architecture & decisions
Runtime first, compiler second
The interpreter is the reference implementation and the AOT compiler targets the same semantics, so there is one behaviour to reason about.
Signals for updates
State is a signal, derived values are computed, and effects run only when their inputs change — no virtual DOM diff.
A deliberately small surface
The API stays small so the component format remains readable and the compiler remains auditable.
Outcome
OmniJS is where the trade-off between interpretation and compilation stopped being abstract. It continues alongside Studio Framer.