A UI framework. Explicit. Predictable. Readable.
Status:
0.x— still being explored. The API changes freely between releases while the design is being worked out. It is real and tested, and it is on npm so it can be installed and tried, but it is not asking to be adopted yet.
1.0is the line. From there the interfaces hold: backward compatibility becomes a rule rather than a courtesy, and the work turns to performance and bugs. The point of these0.xmonths is to arrive at an API worth keeping, because the way it works then is the way it goes on working.Until then a breaking change ships as a minor, so
0.23→0.24may ask you to change something and0.23.1→0.23.2never will. Upgrading is the whole of it.
📖 Documentation: ramonda.dev
import { Component, state } from "@ramonda/core";
export class Counter extends Component {
@state count = 0;
bump() {
this.count++;
}
render() {
return <button onclick={this.bump}>Clicked {this.count} times</button>;
}
}A few ideas set Ramonda apart:
-
One JSX tag, one DOM node. A component's markup is what its
render()returns and nothing else — one element, several, or none — so the JSX maps straight to the DOM you inspect. There is no wrapper element, no fragment tag to write, and two<td>from one component sit inside the<tr>. -
Decorators, not conventions.
@state,@compute,@mounted,@destroyed,@updated,@interval… behavior is declared on ordinary methods and fields. -
Signals under the hood. Reactivity tracks reads, so a
@computerecomputes only when something it actually read changed — no dependency arrays. - Region-aware diffing. Lists get identity from their items, not from hand-written keys, and state never lands on the wrong row.
- SSR is not bolted on. The server render and the client render are the same code; hydration adopts the server's DOM, and mismatches report themselves.
-
Diagnostics that teach. Development builds catch the mistakes the design is
meant to prevent (the
RMD0xxcodes) and say what to do instead.
| Package | What it is |
|---|---|
@ramonda/core |
The framework: components, reactivity, VDOM, SSR/hydration |
@ramonda/router |
State-first client-side router with nested outlets |
@ramonda/query |
Async state: cached, deduped, race-free queries and mutations |
@ramonda/form |
Forms: typed field paths, Standard Schema validation, stable array rows |
@ramonda/lens |
Immutable deep updates by path, via structural sharing |
@ramonda/server |
The DOM and request plumbing an SSR server needs |
@ramonda/build |
The three bundler settings an app needs, as a Vite and an esbuild plugin |
@ramonda/check |
Static checks over your source, and over what your build emitted |
@ramonda/devtools |
The in-page inspector panel |
@ramonda/testing-library |
Testing utilities, built on @testing-library/dom
|
create-ramonda |
The scaffolder — npm create ramonda
|
A pnpm + Turborepo monorepo.
pnpm install
pnpm build # build every package and app
pnpm test # run every test suite (turbo)
pnpm check-types # type-check
pnpm lint # oxlint
pnpm format # biomeThe documentation site lives in apps/docs and runs its own
documented features — it is server-rendered with Ramonda, hydrated on the client,
and searchable.
MIT © Nikola Blagojević