Native Custom Elements
Shadow DOM, slots, part, CSS custom properties, form association. One tag that works wherever HTML works.
v0.1 prerelease — Rust/OXC compiler
React-like TSX in.
Native elements out.
Naos compiles typed component functions into platform-native Web Components — Shadow DOM, slots, events, and static HTML when you prerender. No virtual DOM. A small shared runtime kernel, not a framework runtime.
pnpm add @naos-ui/core @naos-ui/runtime- ≈6 kB
- gzip for the complete shared runtime kernel
- 1×
- authored — runs in every stack, or none
- 100%
- platform output: real Custom Elements
import { event, state } from "@naos-ui/core"
export function Counter({ label = "Count" } = {}) {
const count = state(0)
const change = event<number>("change")
return (
<button
part="button"
onClick={() => {
count.update((value) => value + 1)
change.emit(count())
}}
>
{label}: {count()}
</button>
)
}
<!-- any framework — or no framework at all -->
<app-counter label="Clicks"></app-counter>
<script type="module" src="/counter.js"></script>
How it works
From typed functions to platform code.
Author
Write typed PascalCase component functions with state(), computed(), and typed events — a strict, React-like TSX subset.
Compile
The Rust/OXC compiler analyzes your TSX and generates native Custom Element modules. No virtual DOM anywhere in the output.
Ship
Deliver real Custom Elements with Shadow DOM, slots, and Declarative Shadow DOM prerendering. Consumers share a small runtime kernel, not a framework.
Why Naos
The platform is the framework.
Everything Naos generates is standard browser technology. Your components do not depend on Naos being fashionable in five years — only on the web platform still existing.
Small shared runtime
A tree-shakeable kernel handles lifecycle, updates, styles, and DOM spreads. The complete internal kernel is about 6 kB gzip — not a framework runtime.
Signals reactivity
state(), computed(), and effect() update exactly what changed. No re-render cycles, no reconciliation passes.
Rust-powered compiler
A Rust/OXC core behind a thin TypeScript surface: fast parses, precise diagnostics, and a typed N-API boundary.
Prerender & DSD
Static HTML with <template shadowrootmode> by default — markup that renders before JavaScript and hydrates on upgrade.
Every stack welcome
React, Vue, Angular, CMS pages, plain HTML. Build a component once, consume it as a native element everywhere.
Where Naos fits
Familiar words, a different core bet.
Naos shares the "compiler-first, no virtual DOM" vocabulary of today's tools — but it compiles to native Custom Elements, ships a small shared runtime rather than a framework runtime, and updates with signals. Here is how that lands next to the tools you already know.
vs. StencilThe closest neighbor — but Naos drops the virtual DOM entirely and authors with functions and signals instead of classes and decorators.vs. LitSame native-element output, with a small shared kernel instead of a template runtime: JSX and signals instead of tagged templates and reactive properties.vs. SolidThe same signals you would reach for in Solid — except the Custom Element is the primary output, not an app rendered into a page.vs. GeaNearly the same pitch, opposite core: Gea patches plain DOM as an app framework; Naos compiles to real Custom Elements.vs. ReactNot a rival — a complement. Build components in Naos, consume them in React (and everything else), with a small shared kernel instead of a framework runtime.All comparisonsSide-by-side tables and sourced claims — every statement backed by the other tool's own documentation.
Build components that outlive the framework.
If a component should outlive the framework that renders it, author it once in Naos and ship it as a native element — instead of rebuilding it for React, Vue, and Angular in turn.