@ramonda/server

The plumbing a Ramonda server render needs — a DOM for the render, and the document it goes into — so an app does not hand-roll it.


Keywords
ramonda, ssr, server, prerender, linkedom, dom
License
MIT
Install
npm install @ramonda/server@0.2.2

Documentation

Ramonda 🌸

A UI framework. Explicit. Predictable. Readable.

CI Coverage npm types license

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.0 is 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 these 0.x months 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.230.24 may ask you to change something and 0.23.10.23.2 never will. Upgrading is the whole of it.

📖 Documentation: ramonda.dev

What it is

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 @compute recomputes 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 RMD0xx codes) and say what to do instead.

Packages

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

Developing

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         # biome

The documentation site lives in apps/docs and runs its own documented features — it is server-rendered with Ramonda, hydrated on the client, and searchable.

License

MIT © Nikola Blagojević