DEV Community: Martin Palopoli

Forms, payloads, and live inputs in Fitz LiveViews

Martin Palopoli — Tue, 11 Aug 2026 09:51:12 +0000

TL;DR — Events in Fitz LiveViews carry data three ways: a click payload (data-flv-value-*) tags a button with the value it should send; a form submit (data-flv-submit) reads the form's named inputs; and a live value (@input / @change) delivers a control's current value in payload["value"]. All three land in the same place — a payload map your handler reads. This post builds a live name list (add / remove / count) that runs both server-rendered and as WebAssembly. (Part 3 of the FitzLiveViews series.)

Parts 1 and 2 covered the pitch and the counter. A counter only reads +1/-1 — no data flows in. Real UIs take input: text, selections, form fields. Here's how that data reaches your handlers.

The `payload`

Every event handler has a payload in scope — a Map<Str, Str>. The three mechanisms below all fill it; your handler reads it with payload["key"] (guard with payload.has("key")):

1. Click payload — a button that carries a value

Tag any element with data-flv-value-<key>="{expr}", and when a data-flv-click on it (or an ancestor) fires, that value rides along:

<button data-flv-click="remove" data-flv-value-item="{it}">×</button>

event remove() {
  if (payload.has("item")) {
    let target = payload["item"]
    names = names.filter(fn(it) => it != target)
  }
}

The delete button knows which row it is because the row's value is stamped on it. No IDs threaded through a callback, no closure capture.

2. Form submit — the whole form at once

data-flv-submit="handler" on a <form> reads each named input into the payload on submit; data-flv-clear resets a field afterward:

<form data-flv-submit="add">
  <input name="item" placeholder="Add a name" data-flv-clear />
  <button type="submit">Add</button>
</form>

event add() {
  if (payload.has("item")) {
    let n = payload["item"]
    if (n != "") { names.push(n) }
  }
}

payload["item"] is the input's value at submit time. No preventDefault, no FormData, no fetch.

3. Live value — `@input` / `@change`

For a control that reports as you type or on selection, @input (every keystroke) and @change (on blur/selection) deliver the current value in payload["value"]:

<input @input="on_name" value="{name}" />
<select @change="on_color"> … </select>

event on_name() { name = payload["value"] }

The same payload["value"] covers <input>, <select>, and <textarea>. On the server-rendered target this is the classic data-flv-change attribute; on the client-WASM target it's the @input / @change decorator — same payload, same handler, so one .fitzv serves both.

Putting it together — a live name list

component NameList {
  state {
    names: List<Str> = ["Ada", "Grace", "Margaret"]
  }

  event add() {
    if (payload.has("item")) {
      let n = payload["item"]
      if (n != "") { names.push(n) }
    }
  }

  event remove() {
    if (payload.has("item")) {
      let target = payload["item"]
      names = names.filter(fn(it) => it != target)
    }
  }

  <template>
    <div class="names">
      <form data-flv-submit="add">
        <input name="item" placeholder="Add a name" data-flv-clear />
        <button type="submit">Add</button>
      </form>
      <ul>
        {#for it in names}
          <li>{it} <button data-flv-click="remove" data-flv-value-item="{it}">×</button></li>
        {/for}
      </ul>
      <p>{names.len()} total</p>
    </div>
  </template>
}

{#for it in names} iterates; {it} interpolates each item; the remove button stamps its own value. Add a name, remove a row, watch the count — no client code, no API.

Wire it into a main.fitz (the same shape as the counter in part 2) and it runs:

from fitz_liveviews import Html, html, live_layout, html_response,
  LiveFrame, diff_html, component, dispatch_component_events, flv_register
from NameList import NameList, NameList_render, NameList_add, NameList_remove

@get("/")
fn page() -> Response {
  return html_response(live_layout("/live/names", "names-app",
    component("NameList", "root")))
}

@ws("/live/names")
async fn socket(ws: WsConn<LiveFrame>) {
  let last = component("NameList", "root").raw
  loop {
    let frame = ws.recv()?
    let _ = dispatch_component_events(frame)
    let new_html = component("NameList", "root").raw
    ws.send(LiveFrame { html: new_html, patches: diff_html(last, new_html) })?
    last = new_html
  }
}

@server(3000) fn main() => 0

fitz run, open http://localhost:3000, add and remove names. (I ran exactly this — the page renders the seeded list, the count, and the wired form/buttons.) The client-WASM build of the same list is running in the live gallery — add/remove/count entirely in your browser, offline.

Two honest caveats

Live text inputs re-mount. The current rendering model is dirty-flag + naive re-render: a state change rebuilds the component's DOM. For a <select> @change that's invisible; for a live text <input> @input, the field re-mounts each keystroke — the value re-binds via value="{name}", but the caret jumps to the end. Fine-grained reactivity (patch in place) is the next rendering-model step, and it's what fixes this. The value always reaches the handler reliably; that's what @input guarantees today.
String methods on WASM — now supported. A case-insensitive filter (names.filter(fn(x) => q == "" or x.lower().contains(q.lower()))) used to be server-rendered only; as of Fitz core v0.29.8 the string methods (.lower / .contains / …) and logical and/or compile on the client-WASM target too, so the filter runs offline. The only remaining wrinkle is the caret caveat above for the filter box itself while you type.

What's next in this series

#4+ — Building the flagship. A complete admin panel in Fitz + Fitz LiveViews: cookie-based auth (Argon2id + JWT), live DataGrids querying Postgres over WebSockets, the packaged UI library, i18n, and a one-command Docker setup.

If typed events without a client framework sound good, star the repo. Next: a real app.

Forms, payloads e inputs en vivo en Fitz LiveViews

Martin Palopoli — Tue, 11 Aug 2026 09:49:07 +0000

TL;DR — Los eventos en Fitz LiveViews llevan data de tres formas: un click payload (data-flv-value-*) marca un botón con el valor que tiene que mandar; un form submit (data-flv-submit) lee los inputs con nombre del form; y un valor en vivo (@input / @change) entrega el valor actual de un control en payload["value"]. Las tres caen en el mismo lado — un mapa payload que tu handler lee. Este post construye una lista de nombres en vivo (agregar / quitar / contar) que corre server-rendered y como WebAssembly. (Parte 3 de la serie FitzLiveViews.)

Las partes 1 y 2 cubrieron el pitch y el counter. Un counter solo lee +1/-1 — no entra data. Las UIs reales toman input: texto, selecciones, campos de formulario. Acá está cómo esa data llega a tus handlers.

El `payload`

Cada handler de evento tiene un payload en scope — un Map<Str, Str>. Los tres mecanismos de abajo lo llenan; tu handler lo lee con payload["clave"] (guardá con payload.has("clave")):

1. Click payload — un botón que lleva un valor

Marcá cualquier elemento con data-flv-value-<clave>="{expr}", y cuando un data-flv-click sobre él (o un ancestro) dispara, ese valor viaja:

<button data-flv-click="remove" data-flv-value-item="{it}">×</button>

event remove() {
  if (payload.has("item")) {
    let target = payload["item"]
    names = names.filter(fn(it) => it != target)
  }
}

El botón de borrar sabe qué fila es porque el valor de la fila está estampado en él. Sin IDs pasados por un callback, sin captura de closure.

2. Form submit — el form entero de una

data-flv-submit="handler" en un <form> lee cada input con nombre al payload en el submit; data-flv-clear limpia el campo después:

<form data-flv-submit="add">
  <input name="item" placeholder="Agregar un nombre" data-flv-clear />
  <button type="submit">Agregar</button>
</form>

event add() {
  if (payload.has("item")) {
    let n = payload["item"]
    if (n != "") { names.push(n) }
  }
}

payload["item"] es el valor del input al momento del submit. Sin preventDefault, sin FormData, sin fetch.

3. Valor en vivo — `@input` / `@change`

Para un control que reporta mientras tipeás o al seleccionar, @input (cada tecla) y @change (al blur/selección) entregan el valor actual en payload["value"]:

<input @input="on_name" value="{name}" />
<select @change="on_color"> … </select>

event on_name() { name = payload["value"] }

El mismo payload["value"] cubre <input>, <select> y <textarea>. En el target server-rendered esto es el atributo clásico data-flv-change; en el target client-WASM es el decorador @input / @change — mismo payload, mismo handler, así que un .fitzv sirve a los dos.

Todo junto — una lista de nombres en vivo

component NameList {
  state {
    names: List<Str> = ["Ada", "Grace", "Margaret"]
  }

  event add() {
    if (payload.has("item")) {
      let n = payload["item"]
      if (n != "") { names.push(n) }
    }
  }

  event remove() {
    if (payload.has("item")) {
      let target = payload["item"]
      names = names.filter(fn(it) => it != target)
    }
  }

  <template>
    <div class="names">
      <form data-flv-submit="add">
        <input name="item" placeholder="Agregar un nombre" data-flv-clear />
        <button type="submit">Agregar</button>
      </form>
      <ul>
        {#for it in names}
          <li>{it} <button data-flv-click="remove" data-flv-value-item="{it}">×</button></li>
        {/for}
      </ul>
      <p>{names.len()} total</p>
    </div>
  </template>
}

{#for it in names} itera; {it} interpola cada ítem; el botón de borrar estampa su propio valor. Agregá un nombre, quitá una fila, mirá el contador — sin código de cliente, sin API.

Cablealo a un main.fitz (la misma forma que el counter de la parte 2) y corre:

from fitz_liveviews import Html, html, live_layout, html_response,
  LiveFrame, diff_html, component, dispatch_component_events, flv_register
from NameList import NameList, NameList_render, NameList_add, NameList_remove

@get("/")
fn page() -> Response {
  return html_response(live_layout("/live/names", "names-app",
    component("NameList", "root")))
}

@ws("/live/names")
async fn socket(ws: WsConn<LiveFrame>) {
  let last = component("NameList", "root").raw
  loop {
    let frame = ws.recv()?
    let _ = dispatch_component_events(frame)
    let new_html = component("NameList", "root").raw
    ws.send(LiveFrame { html: new_html, patches: diff_html(last, new_html) })?
    last = new_html
  }
}

@server(3000) fn main() => 0

fitz run, abrís http://localhost:3000, agregás y quitás nombres. (Corrí exactamente esto — la página renderiza la lista sembrada, el contador, y el form/botones cableados.) El build client-WASM de la misma lista está corriendo en la galería en vivo — agregar/quitar/contar entero en tu browser, offline.

Dos caveats honestos

Los inputs de texto en vivo se re-montan. El modelo de render actual es dirty-flag + naive re-render: un cambio de estado reconstruye el DOM del componente. Para un <select> @change es invisible; para un <input> @input en vivo, el campo se re-monta en cada tecla — el valor se re-bindea con value="{name}", pero el caret salta al final. La reactividad fine-grained (patch in-place) es el próximo paso del modelo de render, y es lo que arregla esto. El valor siempre llega al handler de forma confiable; eso es lo que @input garantiza hoy.
Métodos de string en WASM — ahora sí. Un filtro case-insensitive (names.filter(fn(x) => q == "" or x.lower().contains(q.lower()))) antes era solo server-rendered; desde Fitz core v0.29.8 los métodos de string (.lower / .contains / …) y el and/or lógico compilan también en el target client-WASM, así que el filtro corre offline. Lo único que queda es el caret caveat de arriba para la caja del filtro mientras tipeás.

Qué viene en la serie

#4+ — Construyendo el flagship. Un panel de administración completo en Fitz + Fitz LiveViews: auth por cookie (Argon2id + JWT), DataGrids en vivo consultando Postgres por WebSockets, la librería de UI empaquetada, i18n, y un setup Docker de un comando.

Si eventos tipados sin framework de cliente te suena bien, dale una estrella al repo. Lo próximo: una app real.

A native frontend for a compiled language: .fitzv components that compile to WebAssembly

Martin Palopoli — Tue, 11 Aug 2026 09:47:12 +0000

Part 14 of the Fitz series. Part 13 showed the dev loop for .fitzv → WASM; this part is what a .fitzv component actually is, and how a language that emits native binaries also emits a frontend — to WebAssembly, without adopting a JavaScript framework.

The problem: a server language needs a frontend, without importing an ecosystem

Fitz compiles to a native binary and has HTTP/async/Postgres/JWT in the syntax. But a backend eventually needs a UI, and the usual answer is: bolt on the JavaScript ecosystem — a framework (React/Vue/Svelte), a bundler, a node_modules, a second toolchain, and a second definition of every type that crosses the wire.

Fitz's answer is a component format the same compiler understands, that compiles to WebAssembly — no JS framework, no npm.

A component

A .fitzv is a single file: state, events, a <template>, optional scoped styles — the Vue/Svelte shape, but it's Fitz all the way down:

component Counter {
  state {
    count: Int = 0
  }

  event inc() { count = count + 1 }
  event dec() { count = count - 1 }

  <template>
    <div class="counter">
      <button @click="dec">-</button>
      <span class="n">{count}</span>
      <button @click="inc">+</button>
    </div>
  </template>

  <style scoped>
    .counter { display: flex; gap: 12px; }
    .n { font-variant-numeric: tabular-nums; }
  </style>
}

{count} interpolates state. @click wires an event. <style scoped> is scoped to this component (via a hash on the class names). Build it:

fitz build --bin web --target wasm-client   # → target/wasm/web/{web.js, web_bg.wasm}

That's the whole toolchain. No package.json, no bundler config.

What the compiler emits

There's no framework runtime in the bundle. The emitter lowers the component directly to Rust over wasm-bindgen + web-sys: a struct with the state fields, a mount() that builds the DOM with create_element/append_child, event closures that mutate state, and a render() that re-paints the component's subtree on a state change. It's a self-contained WASM module — the counter above is 26 KB raw / 11.4 KB gzipped.

The template is a real DSL: interpolation ({user.name.upper()} — arbitrary Fitz expressions over state), directives ({#if} / {#for}), events (@click / @input), and composition:

<template>
  <ul>
    {#for todo in todos}
      <TodoRow label="{todo.title}" @remove="drop" />
    {/for}
  </ul>
</template>

<Child prop="v" /> passes props down; @remove="drop" bubbles an event up with its payload; <slot> lets a parent inject content. Composition works across files, so a component library is just imports.

The type is the same type

This is the part a bolted-on framework can't give you. The type your server defines is the exact one your component uses — imported from the same .fitz module:

// models.fitz
type Todo {
  id: Int
  title: Str
  done: Bool
}

// App.fitzv
from models import Todo
// ... a List<Todo> in state, {todo.title} in the template

The server compiles Todo into a native struct; the component compiles it into a WASM struct; there's one definition. No types.ts that drifts from the backend, no codegen step to keep them in sync — by construction they can't diverge.

Why this is different

Component models aren't new — the point is what compiles them:

React / Vue / Svelte are excellent, but they're JavaScript: a framework runtime shipped to the browser, a bundler, an npm tree, and a separate type story for the API boundary. .fitzv compiles to WASM with none of that.
Elm is a lovely own-language frontend, but it compiles to JavaScript and lives only in the browser — it isn't the same language as your compiled backend.
Rust WASM frameworks (Dioxus, Leptos) compile to WASM too, but you're adopting a framework, its macro DSL, and its toolchain on top of Rust. In Fitz the component is the language, and the same fitz binary builds it.

One language, one compiler, one type definition — emitting a native binary for the server and a WASM bundle for the browser.

The honest edges (MVP)

Re-render is naive: a state change re-paints the component's subtree, not a fine-grained signal graph. It's fast enough for the common case; fine-grained reactivity is a future slice.
The template supports a growing envelope of constructs (interpolation, {#if}/{#for}, events, composition, slots, scoped styles); genuinely exotic patterns fall outside it for now and the compiler tells you where.
The client is WASM-first; there's no JS-vanilla target — a deliberate choice recorded when the counter came in under the 40 KB bundle gate.

That's the frontend as a first-class part of the language: components you write in Fitz, compiled to WebAssembly, sharing types with a backend compiled to native code. Next up: how a function on that backend becomes callable from the component as if it were local — @rpc.

Fitz is a compiled language with gradual typing and HTTP/async/DB as first-class citizens, compiling to native binary via Rust. Its frontend is .fitzv single-file components compiled to WebAssembly — no framework, no npm. Open source.

Un frontend nativo para un lenguaje compilado: componentes .fitzv que compilan a WebAssembly

Martin Palopoli — Tue, 11 Aug 2026 09:46:26 +0000

Parte 14 de la serie Fitz. La Parte 13 mostró el dev loop para .fitzv → WASM; esta parte es qué es realmente un componente .fitzv, y cómo un lenguaje que emite binarios nativos también emite un frontend — a WebAssembly, sin adoptar un framework de JavaScript.

El problema: un lenguaje de servidor necesita frontend, sin importar un ecosistema

Fitz compila a binario nativo y tiene HTTP/async/Postgres/JWT en la sintaxis. Pero un backend tarde o temprano necesita una UI, y la respuesta habitual es: pegar el ecosistema JavaScript — un framework (React/Vue/Svelte), un bundler, un node_modules, un segundo toolchain, y una segunda definición de cada tipo que cruza el cable.

La respuesta de Fitz es un formato de componentes que el mismo compilador entiende, que compila a WebAssembly — sin framework JS, sin npm.

Un componente

Un .fitzv es un solo archivo: state, events, un <template>, estilos scoped opcionales — la forma Vue/Svelte, pero es Fitz de punta a punta:

component Counter {
  state {
    count: Int = 0
  }

  event inc() { count = count + 1 }
  event dec() { count = count - 1 }

  <template>
    <div class="counter">
      <button @click="dec">-</button>
      <span class="n">{count}</span>
      <button @click="inc">+</button>
    </div>
  </template>

  <style scoped>
    .counter { display: flex; gap: 12px; }
    .n { font-variant-numeric: tabular-nums; }
  </style>
}

{count} interpola el state. @click cablea un evento. <style scoped> queda scopeado a este componente (vía un hash en los nombres de clase). Buildealo:

fitz build --bin web --target wasm-client   # → target/wasm/web/{web.js, web_bg.wasm}

Ese es el toolchain entero. Sin package.json, sin config de bundler.

Qué emite el compilador

No hay runtime de framework en el bundle. El emisor baja el componente directo a Rust sobre wasm-bindgen + web-sys: un struct con los campos de state, un mount() que construye el DOM con create_element/append_child, closures de evento que mutan el state, y un render() que re-pinta el subtree del componente ante un cambio de state. Es un módulo WASM autocontenido — el contador de arriba pesa 26 KB raw / 11.4 KB gzipped.

El template es un DSL de verdad: interpolación ({user.name.upper()} — expresiones Fitz arbitrarias sobre el state), directivas ({#if} / {#for}), eventos (@click / @input), y composición:

<template>
  <ul>
    {#for todo in todos}
      <TodoRow label="{todo.title}" @remove="drop" />
    {/for}
  </ul>
</template>

<Child prop="v" /> pasa props hacia abajo; @remove="drop" burbujea un evento hacia arriba con su payload; <slot> deja que un padre inyecte contenido. La composición funciona entre archivos, así que una librería de componentes es solo imports.

El tipo es el mismo tipo

Esta es la parte que un framework pegado por encima no te puede dar. El type que define tu server es exactamente el que usa tu componente — importado del mismo módulo .fitz:

// models.fitz
type Todo {
  id: Int
  title: Str
  done: Bool
}

// App.fitzv
from models import Todo
// ... un List<Todo> en el state, {todo.title} en el template

El server compila Todo a un struct nativo; el componente lo compila a un struct WASM; hay una sola definición. Sin un types.ts que se desincroniza del backend, sin un paso de codegen para mantenerlos en sync — por construcción no pueden divergir.

Por qué es distinto

Los modelos de componentes no son nuevos — la cuestión es qué los compila:

React / Vue / Svelte son excelentes, pero son JavaScript: un runtime de framework mandado al browser, un bundler, un árbol npm, y una historia de tipos aparte para el borde de la API. .fitzv compila a WASM sin nada de eso.
Elm es un hermoso frontend de lenguaje propio, pero compila a JavaScript y vive solo en el browser — no es el mismo lenguaje que tu backend compilado.
Frameworks WASM de Rust (Dioxus, Leptos) compilan a WASM también, pero estás adoptando un framework, su DSL de macros, y su toolchain sobre Rust. En Fitz el componente es el lenguaje, y el mismo binario fitz lo buildea.

Un lenguaje, un compilador, una definición de tipo — emitiendo un binario nativo para el server y un bundle WASM para el browser.

Los bordes honestos (MVP)

El re-render es naive: un cambio de state re-pinta el subtree del componente, no un grafo de señales fine-grained. Alcanza para el caso común; la reactividad fine-grained es un slice futuro.
El template soporta un envelope creciente de constructos (interpolación, {#if}/{#for}, eventos, composición, slots, estilos scoped); los patrones genuinamente exóticos quedan afuera por ahora y el compilador te dice dónde.
El cliente es WASM-first; no hay target JS-vanilla — una decisión deliberada registrada cuando el contador entró bajo el gate de bundle de 40 KB.

Ese es el frontend como parte de primera clase del lenguaje: componentes que escribís en Fitz, compilados a WebAssembly, compartiendo tipos con un backend compilado a código nativo. Lo que sigue: cómo una función de ese backend se vuelve llamable desde el componente como si fuera local — @rpc.

Fitz es un lenguaje compilado con tipado gradual, HTTP/async/DB como ciudadanos de primera clase, que compila a binario nativo vía Rust. Su frontend son componentes single-file .fitzv compilados a WebAssembly — sin framework, sin npm. Código abierto.

A Vite-class dev loop for a compiled language: hot reload + state preservation + a live manifest

Martin Palopoli — Thu, 06 Aug 2026 10:02:16 +0000

Part 13 of the Fitz series. The frontend chapter opens: Fitz compiles .fitzv components to WebAssembly, and this is the dev loop that makes editing them feel instant — the same "save and see it" experience you get from Vite, on a language that compiles to a native binary.

The setup: a compiled language with a frontend

Fitz is a compiled language — HTTP, async, Postgres, JWT all live in the syntax and it emits a native binary via Rust. The frontend story is a single-file component format, .fitzv (state + events + <template>, à la Vue/Svelte), that compiles to WebAssembly:

fitz build --bin web --target wasm-client   # → target/wasm/web/{web.js, web_bg.wasm}

No npm install, no bundler config, no external framework — the component becomes a self-contained WASM bundle (the counter demo is 11.4 KB gzipped).

Here's the reflex objection: compiled means slow feedback. Edit, wait for a full compile, refresh the browser by hand. That's the opposite of what a frontend loop should feel like. So Fitz has fitz dev.

The loop

Point fitz dev at a wasm-client bin and it stops being a compiler and starts being a dev server:

fitz dev              # serves on http://127.0.0.1:1234/

What it does:

Incremental rebuild with wasm-pack --dev (no wasm-opt), reusing a stable crate so cargo's cache stays warm — the first build compiles the deps, every save after that is ~1-2 seconds.
A dev server that serves your project root like python -m http.server: your index.html, your CSS, the bundle in target/wasm/<bin>/. No index.html? It generates a minimal one at the mount point.
Browser auto-refresh over a WebSocket: save a .fitzv/.fitz/fitz.toml and the page reloads itself. No manual F5.

Save, and ~2 seconds later the browser shows the change. On a compiled language.

The detail that matters: state survives the reload

Most hot-reload stories lose your state on a full reload — you were three clicks into a counter, you edit the template, and you're back at zero. fitz dev snapshots the component's live state before the reload and restores it after:

component App {
  state {
    count: Int = 0
    items: List<Str> = []
  }
  ...
}

Bump count to 7, type two items into the list, then edit the <h1> above them. The reload lands and count is still 7, the list still has its two items. Primitives, lists, maps, nullables, custom nominal types — all survive (serialized to JSON into sessionStorage, restored on boot). You keep editing against the exact state you were testing.

(Honest caveat: a preserved state field wins over a changed default in the template — the state is what's preserved. Change a default and reset to see it.)

The manifest re-resolves live too

This is the piece that just shipped. Editing a .fitzv was always picked up (the entry is re-read every build) — but the manifest wasn't. Now it is: save fitz.toml and fitz dev re-resolves it without restarting.

Repoint [bin].main to a different component → next rebuild uses the new entry.
Add a [dependencies] — pull in a companion-UI component (from fitz_liveviews.ui.Badge import Badge) — → resolved and available on the next build.
Edit [flags] → picked up live.

And a fitz.toml you broke mid-edit doesn't kill the loop: it prints the parse error and keeps serving the previous bundle, recovering on your next valid save.

↻ change in fitz.toml — rebuilding ...
↻ fitz.toml re-resolved
✓ reloaded browser

Fullstack: two bins, two terminals

A real app is a backend plus a frontend. In Fitz that's two bins in one manifest — a native server and a wasm-client web — wired with @rpc (server functions callable from the component as if they were local). You dev each half in its own terminal:

# Terminal 1 — the backend
fitz run --bin server

# Terminal 2 — the frontend, hot reload
fitz dev --bin web

--bin <name> selects the bin in a multi-bin project; it lands on fitz run and fitz build too.

Why this is different

Live-reload loops aren't new — the point is what it takes to get one:

Vite / webpack HMR give a great loop, but they're the JavaScript ecosystem: a bundler, a node_modules, a framework runtime. Fitz's loop is one CLI over a language that compiles to WASM — no npm at all.
cargo watch rebuilds and restarts, but there's no browser reload and no state preservation — you refresh by hand and start over.
Rust WASM frameworks (Dioxus, Leptos) have hot-reload stories, but you're adopting a framework + its macro DSL + its toolchain. Here the component is the language, and fitz dev ships with the compiler.

The combination — a compiled-to-WASM language, incremental rebuilds, browser auto-refresh, state that survives the reload, and a manifest that re-resolves live — is the part no single tool in the neighborhood gives you out of one binary.

The honest edges (MVP)

It recompiles the crate (incrementally — "Approach C"). It is not yet a data-driven template runtime that diffs without recompiling; sub-second-without-a-rebuild is a bigger future north. For the 90% visual loop, ~2s feels the same.
The classic native/SSR mode of fitz dev is kill+respawn without browser reload (there's no page to refresh) — the wasm-client mode above is where the browser loop lives.
Running both bins in one fitz dev (dual-process orchestration) is a follow-up; today it's two terminals.

That's the frontend dev loop closed: a compiled language whose components you edit and see in the browser in a couple of seconds, without losing your state, without an npm ecosystem underneath. Next up: how the same .fitzv renders on the server for first paint, and the WASM runtime then adopts that DOM instead of re-creating it.

Un dev loop tipo Vite para un lenguaje compilado: hot reload + preservación de state + manifest en vivo

Martin Palopoli — Thu, 06 Aug 2026 10:00:50 +0000

Parte 13 de la serie Fitz. Se abre el capítulo del frontend: Fitz compila componentes .fitzv a WebAssembly, y este es el dev loop que hace que editarlos se sienta instantáneo — la misma experiencia "guardar y verlo" que te da Vite, sobre un lenguaje que compila a binario nativo.

El setup: un lenguaje compilado con frontend

Fitz es un lenguaje compilado — HTTP, async, Postgres, JWT viven en la sintaxis y emite un binario nativo vía Rust. La historia del frontend es un formato de componentes single-file, .fitzv (state + events + <template>, al estilo Vue/Svelte), que compila a WebAssembly:

fitz build --bin web --target wasm-client   # → target/wasm/web/{web.js, web_bg.wasm}

Sin npm install, sin config de bundler, sin framework externo — el componente se vuelve un bundle WASM autocontenido (el demo del contador pesa 11.4 KB gzipped).

Acá viene la objeción refleja: compilado = feedback lento. Editás, esperás una compilación entera, refrescás el browser a mano. Es lo opuesto a lo que un loop de frontend debería sentirse. Por eso Fitz tiene fitz dev.

El loop

Apuntá fitz dev a un bin wasm-client y deja de ser un compilador para ser un dev server:

fitz dev              # sirve en http://127.0.0.1:1234/

Qué hace:

Rebuild incremental con wasm-pack --dev (sin wasm-opt), reusando un crate estable así la cache de cargo queda caliente — el primer build compila las deps, cada save siguiente es de ~1-2 segundos.
Un dev server que sirve el root de tu proyecto como python -m http.server: tu index.html, tu CSS, el bundle en target/wasm/<bin>/. ¿Sin index.html? Genera uno mínimo en el punto de mount.
Auto-refresh del browser por WebSocket: guardás un .fitzv/.fitz/fitz.toml y la página se recarga sola. Sin F5 a mano.

Guardás, y ~2 segundos después el browser muestra el cambio. En un lenguaje compilado.

El detalle que importa: el state sobrevive el reload

La mayoría de los hot-reload pierden tu estado en un reload completo — ibas tres clicks adentro de un contador, editás el template, y volvés a cero. fitz dev snapshotea el estado vivo del componente antes del reload y lo restaura después:

component App {
  state {
    count: Int = 0
    items: List<Str> = []
  }
  ...
}

Subí count a 7, escribí dos items en la lista, después editá el <h1> de arriba. El reload aterriza y count sigue en 7, la lista sigue con sus dos items. Primitivos, listas, mapas, nullables, tipos nominales custom — todos sobreviven (serializados a JSON en sessionStorage, restaurados al boot). Seguís editando contra el estado exacto con el que estabas probando.

(Caveat honesto: un campo de state preservado gana ante un default cambiado en el template — lo que se preserva es el estado. Cambiá un default y reseteá para verlo.)

El manifest también se re-resuelve en vivo

Esta es la pieza que acaba de salir. Editar un .fitzv siempre se tomaba (el entry se re-lee en cada build) — pero el manifest no. Ahora sí: guardás fitz.toml y fitz dev lo re-resuelve sin reiniciar.

Repuntá [bin].main a otro componente → el próximo rebuild usa el nuevo entry.
Agregá una [dependencies] — traé un componente de la companion UI (from fitz_liveviews.ui.Badge import Badge) — → resuelto y disponible en el próximo build.
Editá [flags] → se toma en vivo.

Y un fitz.toml que rompiste a mitad de edición no mata el loop: imprime el error de parse y sigue sirviendo el bundle anterior, recuperándose en tu próximo save válido.

↻ change in fitz.toml — rebuilding ...
↻ fitz.toml re-resolved
✓ reloaded browser

Fullstack: dos bins, dos terminales

Una app real es un backend más un frontend. En Fitz eso son dos bins en un manifest — un server nativo y un web wasm-client — cableados con @rpc (funciones de servidor llamables desde el componente como si fueran locales). Dev-eás cada mitad en su propia terminal:

# Terminal 1 — el backend
fitz run --bin server

# Terminal 2 — el frontend, hot reload
fitz dev --bin web

--bin <nombre> elige el bin en un proyecto multi-bin; existe igual en fitz run y fitz build.

Por qué es distinto

Los loops de live-reload no son nuevos — la cuestión es qué hace falta para tener uno:

Vite / webpack HMR dan un loop excelente, pero son el ecosistema JavaScript: un bundler, un node_modules, un runtime de framework. El loop de Fitz es un CLI sobre un lenguaje que compila a WASM — sin npm en absoluto.
cargo watch rebuildea y reinicia, pero no hay reload del browser ni preservación de state — refrescás a mano y arrancás de nuevo.
Frameworks WASM de Rust (Dioxus, Leptos) tienen hot-reload, pero estás adoptando un framework + su DSL de macros + su toolchain. Acá el componente es el lenguaje, y fitz dev viene con el compilador.

La combinación — un lenguaje compilado a WASM, rebuilds incrementales, auto-refresh del browser, state que sobrevive el reload, y un manifest que se re-resuelve en vivo — es la parte que ninguna herramienta sola del vecindario te da desde un solo binario.

Los bordes honestos (MVP)

Recompila el crate (incremental — "Approach C"). No es todavía un runtime de template data-driven que aplique diffs sin recompilar; sub-segundo-sin-rebuild es un norte futuro más grande. Para el 90% del loop visual, ~2s se siente igual.
El modo clásico native/SSR de fitz dev es kill+respawn sin reload del browser (no hay página que refrescar) — el modo wasm-client de arriba es donde vive el loop del browser.
Correr ambos bins en UN fitz dev (orquestación dual-process) es un follow-up; hoy son dos terminales.

Ese es el dev loop del frontend cerrado: un lenguaje compilado cuyos componentes editás y ves en el browser en un par de segundos, sin perder tu estado, sin un ecosistema npm abajo. Lo que sigue: cómo el mismo .fitzv se renderiza en el server para el first paint, y el runtime WASM después adopta ese DOM en vez de recrearlo.

Your first Fitz LiveViews component, twice: SSR and WASM from one source

Martin Palopoli — Thu, 06 Aug 2026 09:59:23 +0000

TL;DR — A Fitz LiveViews component is a single .fitzv file. The interesting part: the same file compiles to two different targets with no rewrite. Server-rendered (SSR) — the server holds the state, renders HTML, and patches the browser over a WebSocket; best for shared, DB-driven, multi-user state. Client-WASM — the same component compiles to WebAssembly and runs entirely in the browser; best for offline, zero-round-trip widgets. This post builds a counter and ships it both ways. (Part 2 of the FitzLiveViews series — start here if you missed part 1.)

In part 1 I made the pitch: real-time UI in one language, no JavaScript build. Now let's build something and ship it two ways from the same source.

The component

Here's a counter as a single-file component (.fitzv) — state, events, template, style:

component Counter {
  state { count: Int = 0 }

  event increment() { count = count + 1 }
  event decrement() { count = count - 1 }
  event reset() { count = 0 }

  <template>
    <div id="counter-app">
      <p>Count: {count}</p>
      <button @click="increment">+1</button>
      <button @click="decrement">-1</button>
      <button @click="reset">Reset</button>
    </div>
  </template>

  <style scoped>
    #counter-app { padding: 1.5rem; font-family: system-ui; }
    button { padding: 0.5rem 1rem; margin: 0 0.25rem; }
  </style>
}

state is the reactive data. Each event handler mutates it directly — no setState, no reducers. <template> is real markup; {count} interpolates and auto-escapes. @click="increment" binds a DOM event to a handler. <style scoped> is CSS namespaced to this component. If you've written Vue or Svelte, this is familiar — the difference is what happens next.

Target 1 — server-rendered (over a WebSocket)

The SSR target is the default. The component runs on the server; a tiny main.fitz wires it into an HTTP route (first paint) and a WebSocket route (the live layer):

from fitz_liveviews import html_response, live_layout, LiveFrame,
  diff_html, component, dispatch_component_events
from Counter import Counter, Counter_render,
  Counter_increment, Counter_decrement, Counter_reset

@get("/")
fn page() -> Response {
  return html_response(live_layout("/live/counter", "counter-app",
    component("Counter", "root")))
}

@ws("/live/counter")
async fn socket(ws: WsConn<LiveFrame>) {
  let last = component("Counter", "root").raw
  loop {
    let frame = ws.recv()?
    let _ = dispatch_component_events(frame)   // route the event to the component
    let new_html = component("Counter", "root").raw
    ws.send(LiveFrame { html: new_html, patches: diff_html(last, new_html) })?
    last = new_html
  }
}

@server(3000) fn main() => 0

What happens on a click: the browser sends the event over the WebSocket → dispatch_component_events routes it to the handler → the handler mutates state → the server recomputes the HTML, diffs it against the previous render, and sends only the patches. The browser applies them. You never wrote client JavaScript, never defined an API, never serialized a payload. The state lives on the server, so it survives reloads and can be shared or DB-backed.

fitz run, open http://localhost:3000, click. That's the whole app — three files (Counter.fitzv, main.fitz, fitz.toml), and it's exactly what you see above. The complete, ready-to-run version is in the repo at examples/counter/ — git clone, cd examples/counter, fitz run.

Target 2 — client-WASM (offline, no server)

Now the same Counter.fitzv — no changes — compiled to WebAssembly. Declare it as a wasm bin in fitz.toml:

[[bin]]
name = "counter"
main = "Counter.fitzv"
target = "wasm-client"
mount = "#app"       # required: where the component mounts in the page

Build it:

fitz build --bin counter --target wasm-client
# → emits a wasm-bindgen + web-sys crate, runs wasm-pack,
#   produces counter.js + counter_bg.wasm

Drop the two files into a page with <div id="app"></div> and a <script type="module">import init from './counter.js'; init()</script>, and the counter runs entirely in the browser — no server, no WebSocket. The state lives in Rc<RefCell<T>> cells; @click handlers mutate the DOM directly.

It's running right now in the live component gallery — that counter is this exact file compiled to WASM. The bundle is 11.4 KB gzipped for the whole thing (no separate framework runtime to load first).

Same source — so which target?

	Server-rendered	Client-WASM
State lives	on the server	in the browser
Multi-user / shared / DB-backed	✅ natural	❌ (per-tab)
Works offline	❌ (needs the socket)	✅
Round-trip per interaction	one WS message	none
Best for	dashboards, CRUD, chat, anything shared	widgets, calculators, offline tools

The point isn't "pick one forever." It's that a presentational component — a badge, a card, a stepper — can serve both, and you decide per component. Shared state? SSR. Local, offline, zero-latency? WASM. Same .fitzv.

What's next in this series

#3 — Forms, payloads, and live inputs. How events carry data: click payloads, form submits, and the @input / @change value binding.
#4+ — Building the flagship. A real admin panel: cookie auth, live DataGrids over Postgres, i18n, and Docker.

Star the repo if the one-source-two-targets idea clicks. Next: forms and payloads.

Tu primer componente de Fitz LiveViews, dos veces: SSR y WASM del mismo source

Martin Palopoli — Thu, 06 Aug 2026 09:58:16 +0000

TL;DR — Un componente de Fitz LiveViews es un solo archivo .fitzv. Lo interesante: el mismo archivo compila a dos targets distintos sin reescribir nada. Server-rendered (SSR) — el servidor guarda el estado, renderiza HTML, y parchea el browser por WebSocket; ideal para estado compartido, DB-driven, multi-usuario. Client-WASM — el mismo componente compila a WebAssembly y corre entero en el browser; ideal para widgets offline sin round-trip. Este post construye un counter y lo shipea de las dos formas. (Parte 2 de la serie FitzLiveViews — empezá acá si te perdiste la parte 1.)

En la parte 1 hice el pitch: UI en tiempo real en un solo lenguaje, sin build de JavaScript. Ahora construyamos algo y shipeémoslo de dos formas desde el mismo source.

El componente

Un counter como componente de un solo archivo (.fitzv) — state, events, template, style:

component Counter {
  state { count: Int = 0 }

  event increment() { count = count + 1 }
  event decrement() { count = count - 1 }
  event reset() { count = 0 }

  <template>
    <div id="counter-app">
      <p>Count: {count}</p>
      <button @click="increment">+1</button>
      <button @click="decrement">-1</button>
      <button @click="reset">Reset</button>
    </div>
  </template>

  <style scoped>
    #counter-app { padding: 1.5rem; font-family: system-ui; }
    button { padding: 0.5rem 1rem; margin: 0 0.25rem; }
  </style>
}

state es la data reactiva. Cada handler de event la muta directo — sin setState, sin reducers. <template> es markup real; {count} interpola y auto-escapa. @click="increment" bindea un evento del DOM a un handler. <style scoped> es CSS namespaceado a este componente. Si escribiste Vue o Svelte, esto te suena — la diferencia es lo que pasa después.

Target 1 — server-rendered (por WebSocket)

El target SSR es el default. El componente corre en el servidor; un main.fitz chiquito lo cablea a una ruta HTTP (primer paint) y una ruta WebSocket (la capa en vivo):

from fitz_liveviews import html_response, live_layout, LiveFrame,
  diff_html, component, dispatch_component_events
from Counter import Counter, Counter_render,
  Counter_increment, Counter_decrement, Counter_reset

@get("/")
fn page() -> Response {
  return html_response(live_layout("/live/counter", "counter-app",
    component("Counter", "root")))
}

@ws("/live/counter")
async fn socket(ws: WsConn<LiveFrame>) {
  let last = component("Counter", "root").raw
  loop {
    let frame = ws.recv()?
    let _ = dispatch_component_events(frame)   // rutea el evento al componente
    let new_html = component("Counter", "root").raw
    ws.send(LiveFrame { html: new_html, patches: diff_html(last, new_html) })?
    last = new_html
  }
}

@server(3000) fn main() => 0

Qué pasa en un click: el browser manda el evento por el WebSocket → dispatch_component_events lo rutea al handler → el handler muta el estado → el servidor recomputa el HTML, lo diffea contra el render anterior, y manda solo los parches. El browser los aplica. Nunca escribiste JavaScript de cliente, nunca definiste una API, nunca serializaste un payload. El estado vive en el servidor, así que sobrevive reloads y puede ser compartido o respaldado por DB.

fitz run, abrís http://localhost:3000, clickeás. Esa es toda la app — tres archivos (Counter.fitzv, main.fitz, fitz.toml), y es exactamente lo que ves arriba. La versión completa y lista para correr está en el repo en examples/counter/ — git clone, cd examples/counter, fitz run.

Target 2 — client-WASM (offline, sin servidor)

Ahora el mismo Counter.fitzv — sin cambios — compilado a WebAssembly. Declaralo como un bin wasm en fitz.toml:

[[bin]]
name = "counter"
main = "Counter.fitzv"
target = "wasm-client"
mount = "#app"       # requerido: dónde monta el componente en la página

Buildealo:

fitz build --bin counter --target wasm-client
# → emite un crate wasm-bindgen + web-sys, corre wasm-pack,
#   produce counter.js + counter_bg.wasm

Metés los dos archivos en una página con <div id="app"></div> y un <script type="module">import init from './counter.js'; init()</script>, y el counter corre entero en el browser — sin servidor, sin WebSocket. El estado vive en celdas Rc<RefCell<T>>; los handlers de @click mutan el DOM directo.

Está corriendo ahora mismo en la galería de componentes en vivo — ese counter es este archivo exacto compilado a WASM. El bundle son 11.4 KB gzipped por todo (sin runtime de framework aparte que bajar primero).

Mismo source — ¿entonces qué target?

	Server-rendered	Client-WASM
Dónde vive el estado	en el servidor	en el browser
Multi-usuario / compartido / DB	✅ natural	❌ (por pestaña)
Funciona offline	❌ (necesita el socket)	✅
Round-trip por interacción	un mensaje WS	ninguno
Ideal para	dashboards, CRUD, chat, cualquier cosa compartida	widgets, calculadoras, herramientas offline

El punto no es "elegí uno para siempre". Es que un componente presentacional — un badge, una card, un stepper — puede servir a los dos, y decidís por componente. ¿Estado compartido? SSR. ¿Local, offline, cero latencia? WASM. El mismo .fitzv.

Qué viene en la serie

#3 — Forms, payloads e inputs en vivo. Cómo los eventos llevan data: click payloads, form submits, y el binding de valores con @input / @change.
#4+ — Construyendo el flagship. Un panel de administración real: auth por cookie, DataGrids en vivo sobre Postgres, i18n, y Docker.

Dale una estrella al repo si te cierra la idea de un-source-dos-targets. Lo próximo: forms y payloads.

Introducing Fitz LiveViews: real-time UI in one language, zero JS build

Martin Palopoli — Sat, 01 Aug 2026 12:09:55 +0000

TL;DR — Fitz LiveViews is a real-time UI framework for Fitz, a compiled, gradually-typed language where HTTP, WebSockets, auth, and an ORM are part of the syntax. You write single-file components (.fitzv) with state / event / <template>, and the server renders HTML, diffs it, and patches the browser over a WebSocket — no JavaScript build step, no client framework. The same .fitzv can also compile to WebAssembly for offline, zero-round-trip widgets. There's a live component gallery, a course, and a full flagship app (an admin panel with auth + Postgres + Docker) already built with it. Repo: github.com/Thegreekman76/fitz-liveviews · Docs: thegreekman76.github.io/fitz-liveviews

This is the first post in the FitzLiveViews series. I'll start with the pitch and the setup; the following posts build things.

The problem

Building a modern web UI usually means two languages, two type systems, and a build pipeline: a backend (Python / Node / Go) plus a frontend framework (React / Vue / Svelte) plus its toolchain (Vite / Webpack / Babel). You duplicate your types across the wire, you keep two mental models in sync, and node_modules grows a personality of its own.

Phoenix LiveView (Elixir) showed there's another way: render on the server, push diffs over a WebSocket, and let the browser stay dumb. No client framework, no API to hand-write, no JSON serialization dance. Fitz LiveViews brings that model to Fitz — and adds a twist: the same component can also compile to WebAssembly when you want purely client-side, offline interactivity.

What Fitz LiveViews looks like

A component is a single .fitzv file — state, event handlers, and a template, like Vue or Svelte:

component Counter {
  state { count: Int = 0 }

  event increment() { count = count + 1 }
  event decrement() { count = count - 1 }
  event reset() { count = 0 }

  <template>
    <div id="counter-app">
      <p>Count: {count}</p>
      <button @click="increment">+1</button>
      <button @click="decrement">-1</button>
      <button @click="reset">Reset</button>
    </div>
  </template>
}

On the server-rendered target, the framework registers this component, sends the initial HTML, and — on every event — recomputes the HTML, diffs it, and sends only the patches over a WebSocket. The browser applies them. You never write client JavaScript, never define an API, never serialize a payload by hand.

On the client-WASM target (fitz build --target wasm-client), the same file compiles to a wasm-bindgen + web-sys bundle that mounts and mutates the DOM directly — offline, no server. A single component is ~12 KB gzipped.

What makes it different

One language, back to front. Components, handlers, and the server all live in Fitz. Your type User { ... } is the same on both sides — no duplicated DTOs.
Zero JavaScript build. No npm install, no bundler, no node_modules. The fitz binary compiles everything.
Type-checked templates. The template has its own checker: a prop of the wrong type, an @event bound to a handler that doesn't exist, a <slot slot="x"> with no <slot name="x"> — all caught at compile time, pointing at the .fitzv and the line.
Dual-target: SSR or WASM from one source. Server-rendered for shared, DB-driven, multi-user state; client-WASM for local, zero-round-trip, offline widgets. Same component model either way.
A packaged UI library. fitz_liveviews.ui.* ships drop-in components (Badge, Card, DataGrid, Pager, Input, Select, Tabs, Stepper, TreeView, …), themed through --flv-* design tokens.

There's a live component gallery — real components compiled to WebAssembly, running in your browser, no server. Click around.

By the numbers

These are measured payload/build numbers from the flagship admin app and the gallery — not synthetic throughput claims:

A full server-rendered dashboard page ships ~1.1 KB of JavaScript (3 tiny inline <script> blocks: theme-before-paint + the WebSocket live client), zero external <script src>, and zero build step. The page HTML is ~38 KB and that's the whole thing — there's no framework runtime to download first. Compare that to an SPA, where the framework runtime alone is ~40 KB (Svelte-ish) to ~140 KB (React + ReactDOM) before your code and your hydration payload.
A client-WASM component is ~12 KB gzipped — the entire component, not "your code on top of a 100 KB runtime." The counter demo is 11.4 KB gzipped; the full 12-widget composed gallery is ~44 KB.
Zero node_modules, zero bundler config. The fitz binary is the whole toolchain. git clone → fitz run.
Native binary ≈ 9× faster per interaction than the interpreter (fitz run ↔ fitz build render bit-for-bit identical), so you develop on the interpreter and ship the binary.

(Cross-framework request-throughput benchmarks are honest future work — I'd rather ship measured payload numbers than hand-wave a load test.)

How it compares

	Fitz LiveViews	Phoenix LiveView	Hotwire (Turbo)	React/Vue/Svelte (SPA)	HTMX
Real-time diff over WebSocket	✅ built-in	✅ built-in	~ (Turbo Streams)	manual	~ (extension)
JavaScript build step	none	none	none	required	none
Languages in the stack	1 (Fitz)	1 (Elixir)	2 (Ruby + JS)	2+ (backend + JS/TS)	1 backend + HTML
Offline / client-only target	✅ WASM, same source	❌	❌	✅ (JS)	❌
Type-checked templates	✅ compiler	~ (HEEx)	❌	~ (TS/JSX)	❌
Compiles to a native binary	✅	❌ (BEAM VM)	❌	❌	❌
Packaged UI component library	✅ `fitz_liveviews.ui.*`	community	community	huge ecosystem	community

Where Fitz LiveViews is genuinely different: one language across the whole stack, a dual SSR/WASM target from a single source, compilation to a standalone native binary, and compiler-checked templates. Where it's honestly behind: it's new, so the ecosystem is small — React/Vue/Svelte have a decade of libraries and hiring pools. If that trade — a smaller ecosystem for a radically simpler stack — sounds right for what you're building, read on.

Getting started

1. Install Fitz. Fitz LiveViews is a library for the Fitz language, so you install Fitz first:

curl -sSf https://thegreekman76.github.io/fitz/install.sh | sh
fitz --version

The Fitz course walks through install / uninstall / updating in detail — see Fitz course · C1 — Installation.

2. Install the editor extensions. Two VSCode extensions give you syntax highlighting, diagnostics, hover, and go-to-definition:

Fitz — for .fitz files (the language). Grab the .vsix from the Fitz releases and code --install-extension fitz-language-*.vsix.
Fitz LiveViews — for .fitzv single-file components. Grab it from the fitz-liveviews releases and code --install-extension fitz-liveviews-*.vsix.

3. Add the dependency. In your project's fitz.toml:

[dependencies]
fitz_liveviews = { git = "https://github.com/Thegreekman76/fitz-liveviews" }

That's the whole setup — no Node, no bundler, no package.json.

It's not a toy — there's a flagship

To prove the model on something real, there's a complete back-office admin panel built entirely in Fitz + Fitz LiveViews: login (Argon2id + a signed JWT session cookie), a responsive shell (collapsible sidebar, mobile drawer down to 320px, ES/EN switch, light/dark/auto theme), a dashboard with real counts from Postgres, and two live CRUD screens (employees + departments) with search, filters, sorting, pagination, rich tabbed forms, multi-delete, group-by, per-row expand, and CSV export — all diffed over WebSockets, all internationalized, all in one docker compose up.

Every reusable piece of it is a packaged component in fitz_liveviews.ui.* — the library was extracted from this app. It's the living reference.

Where to go

Repo — github.com/Thegreekman76/fitz-liveviews
Docs — thegreekman76.github.io/fitz-liveviews
Live gallery — /live
Course — a hands-on, chapter-by-chapter build (overview)
Client-WASM guide — the offline-widget target (client-wasm)

What's next in this series

#2 — Your first component, twice. A counter that renders server-side over a WebSocket and compiles to WebAssembly — one source, two targets.
#3 — Forms, payloads, and live inputs. How events carry data, and how @input / @change bind form values.
#4+ — Building the flagship. A deep dive into the admin panel: cookie auth, live DataGrids over Postgres, the packaged UI library, i18n, and Docker.

If real-time UI without a JavaScript build sounds good, star the repo and follow the series. Next up: the counter, twice.

Presentando Fitz LiveViews: UI en tiempo real en un solo lenguaje, sin build de JS

Martin Palopoli — Sat, 01 Aug 2026 12:02:38 +0000

TL;DR — Fitz LiveViews es un framework de UI en tiempo real para Fitz, un lenguaje compilado y de tipado gradual donde HTTP, WebSockets, auth y un ORM son parte de la sintaxis. Escribís componentes de un solo archivo (.fitzv) con state / event / <template>, y el servidor renderiza HTML, lo diffea y parchea el browser por WebSocket — sin paso de build de JavaScript, sin framework de cliente. El mismo .fitzv puede además compilar a WebAssembly para widgets offline sin round-trip. Ya hay una galería de componentes en vivo, un curso, y una app flagship completa (un panel de administración con auth + Postgres + Docker) construida con esto. Repo: github.com/Thegreekman76/fitz-liveviews · Docs: thegreekman76.github.io/fitz-liveviews

Este es el primer post de la serie FitzLiveViews. Arranco con el pitch y el setup; los siguientes construyen cosas.

El problema

Armar una UI web moderna normalmente implica dos lenguajes, dos sistemas de tipos, y un pipeline de build: un backend (Python / Node / Go) más un framework de frontend (React / Vue / Svelte) más su toolchain (Vite / Webpack / Babel). Duplicás tus tipos de un lado al otro del cable, mantenés dos modelos mentales en sync, y node_modules desarrolla personalidad propia.

Phoenix LiveView (Elixir) mostró que hay otra forma: renderizar en el servidor, empujar diffs por WebSocket, y dejar que el browser quede tonto. Sin framework de cliente, sin API que escribir a mano, sin la danza de serializar JSON. Fitz LiveViews trae ese modelo a Fitz — y suma una vuelta de tuerca: el mismo componente puede además compilar a WebAssembly cuando querés interactividad puramente client-side y offline.

Cómo se ve Fitz LiveViews

Un componente es un solo archivo .fitzv — state, event handlers y template, como Vue o Svelte:

component Counter {
  state { count: Int = 0 }

  event increment() { count = count + 1 }
  event decrement() { count = count - 1 }
  event reset() { count = 0 }

  <template>
    <div id="counter-app">
      <p>Count: {count}</p>
      <button @click="increment">+1</button>
      <button @click="decrement">-1</button>
      <button @click="reset">Reset</button>
    </div>
  </template>
}

En el target server-rendered, el framework registra el componente, manda el HTML inicial y — en cada evento — recomputa el HTML, lo diffea, y manda solo los parches por WebSocket. El browser los aplica. Nunca escribís JavaScript de cliente, nunca definís una API, nunca serializás un payload a mano.

En el target client-WASM (fitz build --target wasm-client), el mismo archivo compila a un bundle wasm-bindgen + web-sys que monta y muta el DOM directo — offline, sin servidor. Un componente pesa ~12 KB gzipped.

Qué lo hace distinto

Un lenguaje, del back al front. Componentes, handlers y el servidor viven todos en Fitz. Tu type User { ... } es el mismo de los dos lados — sin DTOs duplicados.
Cero build de JavaScript. Sin npm install, sin bundler, sin node_modules. El binario fitz compila todo.
Templates con chequeo de tipos. El template tiene su propio checker: un prop del tipo equivocado, un @event bindeado a un handler que no existe, un <slot slot="x"> sin <slot name="x"> — todo se caza en compile-time, apuntando al .fitzv y a la línea.
Dual-target: SSR o WASM del mismo source. Server-rendered para estado compartido, DB-driven, multi-usuario; client-WASM para widgets locales, offline, sin round-trip. El mismo modelo de componentes en los dos casos.
Una librería de UI empaquetada. fitz_liveviews.ui.* trae componentes drop-in (Badge, Card, DataGrid, Pager, Input, Select, Tabs, Stepper, TreeView, …), tematizados con design tokens --flv-*.

Hay una galería de componentes en vivo — componentes reales compilados a WebAssembly, corriendo en tu browser, sin servidor. Jugá un rato.

En números

Estos son números medidos de payload/build de la app flagship y la galería — no claims sintéticos de throughput:

Una página completa del dashboard server-rendered envía ~1.1 KB de JavaScript (3 bloques <script> inline chiquitos: el theme-antes-del-paint + el cliente WebSocket en vivo), cero <script src> externos, y cero paso de build. El HTML de la página son ~38 KB y eso es todo — no hay runtime de framework que bajar primero. Compará con un SPA, donde el runtime del framework solo son ~40 KB (estilo Svelte) a ~140 KB (React + ReactDOM) antes de tu código y tu payload de hydration.
Un componente client-WASM son ~12 KB gzipped — el componente entero, no "tu código arriba de un runtime de 100 KB". El demo del counter son 11.4 KB gzipped; la galería completa de 12 widgets compuestos son ~44 KB.
Cero node_modules, cero config de bundler. El binario fitz es todo el toolchain. git clone → fitz run.
Binario nativo ≈ 9× más rápido por interacción que el intérprete (fitz run ↔ fitz build renderizan bit-a-bit idéntico), así que desarrollás sobre el intérprete y shipeás el binario.

(Los benchmarks de throughput de requests cross-framework son trabajo futuro honesto — prefiero shipear números de payload medidos que agitar las manos con un load test.)

Cómo se compara

	Fitz LiveViews	Phoenix LiveView	Hotwire (Turbo)	React/Vue/Svelte (SPA)	HTMX
Diff en tiempo real por WebSocket	✅ built-in	✅ built-in	~ (Turbo Streams)	manual	~ (extensión)
Paso de build de JavaScript	ninguno	ninguno	ninguno	requerido	ninguno
Lenguajes en el stack	1 (Fitz)	1 (Elixir)	2 (Ruby + JS)	2+ (backend + JS/TS)	1 backend + HTML
Target offline / solo-cliente	✅ WASM, mismo source	❌	❌	✅ (JS)	❌
Templates con chequeo de tipos	✅ compilador	~ (HEEx)	❌	~ (TS/JSX)	❌
Compila a binario nativo	✅	❌ (VM BEAM)	❌	❌	❌
Librería de componentes UI empaquetada	✅ `fitz_liveviews.ui.*`	comunidad	comunidad	ecosistema enorme	comunidad

Donde Fitz LiveViews es genuinamente distinto: un lenguaje en todo el stack, un target dual SSR/WASM del mismo source, compilación a binario nativo standalone, y templates chequeados por el compilador. Donde está honestamente atrás: es nuevo, así que el ecosistema es chico — React/Vue/Svelte tienen una década de librerías y de gente que las sabe. Si ese trade — un ecosistema más chico a cambio de un stack radicalmente más simple — suena bien para lo que estás construyendo, seguí leyendo.

Cómo empezar

1. Instalá Fitz. Fitz LiveViews es una librería del lenguaje Fitz, así que primero instalás Fitz:

curl -sSf https://thegreekman76.github.io/fitz/install.sh | sh
fitz --version

El curso de Fitz recorre install / desinstalación / actualización en detalle — mirá Curso de Fitz · C1 — Instalación.

2. Instalá las extensiones del editor. Dos extensiones de VSCode te dan syntax highlighting, diagnostics, hover y go-to-definition:

Fitz — para archivos .fitz (el lenguaje). Bajá el .vsix de los releases de Fitz y code --install-extension fitz-language-*.vsix.
Fitz LiveViews — para componentes .fitzv. Bajalo de los releases de fitz-liveviews y code --install-extension fitz-liveviews-*.vsix.

3. Agregá la dependencia. En el fitz.toml de tu proyecto:

[dependencies]
fitz_liveviews = { git = "https://github.com/Thegreekman76/fitz-liveviews" }

Ese es todo el setup — sin Node, sin bundler, sin package.json.

No es un juguete — hay un flagship

Para probar el modelo en algo real, hay un panel de administración de back-office completo, construido enteramente en Fitz + Fitz LiveViews: login (Argon2id + cookie de sesión con JWT firmado), un shell responsive (sidebar colapsable, drawer mobile hasta 320px, switch ES/EN, tema light/dark/auto), un dashboard con counts reales de Postgres, y dos pantallas CRUD en vivo (empleados + departamentos) con búsqueda, filtros, ordenamiento, paginación, forms ricos con tabs, multi-delete, group-by, expand por fila, y export a CSV — todo diffeado por WebSockets, todo internacionalizado, todo en un docker compose up.

Cada pieza reusable es un componente empaquetado en fitz_liveviews.ui.* — la librería se extrajo de esta app. Es la referencia viva.

A dónde ir

Repo — github.com/Thegreekman76/fitz-liveviews
Docs — thegreekman76.github.io/fitz-liveviews
Galería en vivo — /live
Curso — una construcción práctica, capítulo a capítulo (overview)
Guía Client-WASM — el target de widgets offline (client-wasm)

Qué viene en la serie

#2 — Tu primer componente, dos veces. Un counter que renderiza server-side por WebSocket y compila a WebAssembly — un source, dos targets.
#3 — Forms, payloads e inputs en vivo. Cómo los eventos llevan data, y cómo @input / @change bindean valores de formulario.
#4+ — Construyendo el flagship. Un deep dive al panel de administración: auth por cookie, DataGrids en vivo sobre Postgres, la librería de UI empaquetada, i18n, y Docker.

Si UI en tiempo real sin build de JavaScript te suena bien, dale una estrella al repo y seguí la serie. Lo próximo: el counter, dos veces.

SMTP outbound as a first-class citizen: send emails without pip install yagmail

Martin Palopoli — Mon, 13 Jul 2026 17:43:42 +0000

Notifications, password resets, magic links, alerts. Every language solves SMTP outbound with an external library. In Fitz, smtp.send(opts) is a language builtin. Async from day one. Bit-for-bit parity between fitz run and fitz build. No pip install yagmail / npm install nodemailer / cargo add lettre / Maven JavaMail.

The detail that gets forgotten

Any serious application eventually needs to send emails:

Notifications when a service goes down (incidents → on-call email).
Password reset / magic-link auth (unique link to the user's email).
Welcome email after a signup.
Daily / weekly digest reports dispatched from a cron job.
Alerts when a nightly job fails.

And every language solves this with an external library.

We hit the gap while building fitzwatch (open-source status page written in pure Fitz): the heart of the product alerts on-call when a monitor goes down. Without native SMTP, the only option was webhook → n8n/zapier → email. Two external systems just to send one email.

Today, the 8 sub-blocks of the mini-release are in main. One line — smtp.send({...}).await? — and the email goes out.

The typical Python stack

pip install yagmail
# or use stdlib smtplib (RFC 5321 by hand)

# With yagmail (friendly syntax):
import yagmail

yag = yagmail.SMTP("user@example.com", "password")
yag.send("dest@example.com", "Subject", "Body text")

# With stdlib smtplib (low-level):
import smtplib
from email.mime.text import MIMEText
from email.mime.multipart import MIMEMultipart

msg = MIMEMultipart("alternative")
msg["Subject"] = "Subject"
msg["From"] = "user@example.com"
msg["To"] = "dest@example.com"
msg.attach(MIMEText("Body text", "plain"))
msg.attach(MIMEText("<p>Body HTML</p>", "html"))

with smtplib.SMTP("smtp.gmail.com", 587) as server:
    server.starttls()
    server.login("user@example.com", "password")
    server.send_message(msg)

Two options, both require reading the RFC or learning the yagmail API.

The typical JS/Node stack

npm install nodemailer

import nodemailer from "nodemailer"

const transporter = nodemailer.createTransport({
    host: "smtp.gmail.com",
    port: 587,
    secure: false,
    auth: { user: "user@example.com", pass: "password" },
})

await transporter.sendMail({
    from: "user@example.com",
    to: "dest@example.com",
    subject: "Subject",
    text: "Body text",
    html: "<p>Body HTML</p>",
})

One library, well-designed, but npm install brings ~50 transitive packages to package.json.

The typical Rust stack

cargo add lettre
cargo add tokio --features full

use lettre::message::{header::ContentType, Mailbox, MultiPart, SinglePart};
use lettre::transport::smtp::authentication::Credentials;
use lettre::{AsyncSmtpTransport, AsyncTransport, Message, Tokio1Executor};

let creds = Credentials::new("user@example.com".into(), "password".into());
let mailer = AsyncSmtpTransport::<Tokio1Executor>::starttls_relay("smtp.gmail.com")
    .unwrap()
    .port(587)
    .credentials(creds)
    .build();

let email = Message::builder()
    .from("user@example.com".parse::<Mailbox>().unwrap())
    .to("dest@example.com".parse::<Mailbox>().unwrap())
    .subject("Subject")
    .multipart(MultiPart::alternative()
        .singlepart(SinglePart::builder().header(ContentType::TEXT_PLAIN).body("Body text".to_string()))
        .singlepart(SinglePart::builder().header(ContentType::TEXT_HTML).body("<p>Body HTML</p>".to_string()))
    )
    .unwrap();

mailer.send(email).await.unwrap();

Functional, but verbose. 25 lines to send ONE email.

The typical Java stack

<dependency>
    <groupId>com.sun.mail</groupId>
    <artifactId>jakarta.mail</artifactId>
    <version>2.0.1</version>
</dependency>

And then the canonical recipe of Properties + Session + MimeMessage + Transport.send(...) that probably adds 40 lines.

The Fitz stack

let r = smtp.send({
    "to": "dest@example.com",
    "from": "user@example.com",
    "subject": "Subject",
    "body_text": "Body text",
    "body_html": "<p>Body HTML</p>",
}).await?

That's it.

smtp is a language builtin. No pip install/npm install/cargo add.
body_text + body_html together → automatic multipart/alternative.
.await? propagates errors as Result::Err(Str). The compiler enforces handling.
Config (host, port, user, password, TLS) is read from env vars at first send. Same convention any app in Kubernetes/Docker expects.

r.delivered, r.message_id, and r.duration_ms come out typed as Bool/Str/Int.

What `smtp.send` guarantees you

1. Zero external deps

The fitz binary ships with lettre 0.11 statically linked inside. When you fitz build, the result is ONE executable of ~10 MB containing the SMTP client, TLS via rustls, no openssl on the target host.

ldd ./my-app
# linux-vdso.so.1
# libgcc_s.so.1
# libc.so.6
# (no smtp libs, no openssl)

2. Bit-for-bit parity `fitz run` ↔ `fitz build`

The interpreter (fitz run) and codegen to Rust (fitz build) emit the same wire SMTP. Same handshake, same SCRAM auth, same Message-ID. Bug in one path = bug in the other. E2E tests validate this on every commit.

3. Async from day one

smtp.send(...) returns Future<Result<SmtpResult>>. Integrates naturally with the rest of the stack:

@background
async fn send_welcome(email: Str) -> Null {
    let _ = smtp.send({
        "to": email,
        "subject": "Welcome",
        "body": "Hi, thanks for joining.",
    }).await
    return null
}

@post("/signup")
fn signup(input: SignupInput) {
    // ... create the user in the DB ...
    let _ = spawn(send_welcome(input.email))
    return 201 { "id": new_user_id }
}

The handler returns 201 to the client immediately. The email goes out in another tokio task. If the SMTP server takes 2 seconds, the client doesn't care — it already responded 2 seconds ago.

And with @cron you build digests:

@cron("0 0 9 * * *")  // every day at 09:00
async fn daily_digest() -> Null {
    let r = smtp.send({
        "to": "team@example.com",
        "subject": "Daily digest",
        "body_html": "<p>Today: ...</p>",
    }).await
    match r {
        Ok(_) => log.info("digest.sent"),
        Err(e) => log.error("digest.failed", error: e),
    }
    return null
}

4. `Result<T>` as error model

Transport errors (DNS, auth, TLS, server reject) come as Result::Err(Str) with "smtp: " prefix:

match smtp.send(opts).await {
    Ok(r) => log.info("smtp.delivered", message_id: r.message_id),
    Err(e) => {
        // The prefix lets you classify:
        // "smtp: server rejected mail: ..."     → 5xx from server
        // "smtp: transient error: ..."          → 4xx temporary
        // "smtp: client error: ..."             → TLS/auth fail
        // "smtp: invalid `to` address ..."      → parse error
        log.warn("smtp.failed", error: e)
    }
}

The static checker enforces handling. If your fn returns Result<...>, you can propagate with ?. If not, the checker demands match. Zero runtime exceptions.

5. Magic-link auth in 30 lines

The showcase case of Fitz's first-class web stack: HTTP server-side + auth with jwt.encode + SMTP outbound, all combined in one binary.

type EmailRequest {
    email: Str
}

@post("/auth/magic-link")
async fn magic_link(input: EmailRequest) -> Result<Str> {
    let payload = { "email": input.email }
    let token = jwt.encode(payload, "secret")
    let link = "https://app.example.com/verify?t={token}"
    let r = smtp.send({
        "to": input.email,
        "subject": "Your login link",
        "body_text": "Click here:\n{link}\n\nExpires in 5 min.",
        "body_html": "<p>Click <a href=\"{link}\">here</a>.</p>",
    }).await?
    return Ok(r.message_id)
}

No Auth0, no Supabase, no Stripe webhooks. One binary, one port, one command to deploy.

Local setup with MailHog

For dev you don't want to send real emails. MailHog is a fake SMTP server with a web UI that retains emails without forwarding:

docker run -d --name mailhog -p 1025:1025 -p 8025:8025 mailhog/mailhog
export SMTP_HOST=localhost
export SMTP_PORT=1025
export SMTP_TLS=none
fitz run app.fitz
# Then open http://localhost:8025 in the browser.

In production you change the env vars to Gmail/SES/SendGrid/Mailgun/whatever — your Fitz code doesn't change.

Honest trade-offs (MVP)

No attachments yet. The attachments key is rejected with a clear error. Workaround: bundle attachments via S3/object storage + link in the body. The cleanest pattern for serious production anyway.
No programmatic smtp.configure(...). Config only comes from env vars today. If you need multi-tenant with a different SMTP per tenant, that's pending as post-MVP debt.
No built-in retry. If smtp.send fails, the caller decides what to do. The canonical pattern for production is outbox table + @cron with retry.

This is NOT FUD — these are explicit MVP decisions. All 3 are refinable if real demand shows up.

Closing

smtp.send isn't "another easier library". It's the same mental model you already use elsewhere in Fitz: Result<T> as return type, ? to propagate, .await for async, @background + spawn for fire-and-forget.

If you already know how to chain http.get(...).await? or db.query(...).await?, you already know how to send emails. Zero new API to learn.

And when fitzwatch resumes, the line that was pending to notify incidents goes from "webhook to n8n + translation to SMTP" to smtp.send({...}).await?. One line. That's Fitz.

Try it: fitz version 0.18.0+ (already in GitHub releases). Exhaustive chapter + 3 runnable examples against MailHog in the "SMTP outbound" subsection of chapter 17 of the guide.

Stay tuned: the Fitz series publishes on dev.to every time we close a major mini-release. The next one will cover a concrete feature detected during fitzwatch development.

SMTP outbound como ciudadano de primera clase: mandá emails sin pip install yagmail

Martin Palopoli — Mon, 13 Jul 2026 17:43:20 +0000

Notificaciones, password resets, magic links, alerts. Todos los lenguajes resuelven SMTP outbound con una librería externa. En Fitz, smtp.send(opts) es builtin del lenguaje. Async desde día uno. Paridad bit-a-bit fitz run ↔ fitz build. Sin pip install yagmail / npm install nodemailer / cargo add lettre / Maven JavaMail.

El detalle que se olvida

Cualquier aplicación seria termina necesitando mandar mails:

Notificación cuando se cae un servicio (incidents → email al on-call).
Password reset / magic-link auth (link único al email del user).
Welcome email después de un signup.
Reportes diarios / weekly digests despachados desde un cron job.
Alertas de jobs nocturnos que fallan.

Y todos los lenguajes lo resuelven con una librería externa.

Detectamos el gap construyendo fitzwatch (status page open-source escrito en Fitz puro): el corazón del producto avisa al on-call cuando un monitor cae. Sin SMTP nativo, la única opción era webhook → n8n/zapier → email. Dos sistemas externos para mandar un email.

Hoy, los 8 sub-bloques de la mini-tanda están en main. Una línea — smtp.send({...}).await? — y el email sale.

El stack típico de Python

pip install yagmail
# o usar smtplib del stdlib (RFC 5321 a mano)

# Con yagmail (sintaxis amigable):
import yagmail

yag = yagmail.SMTP("user@example.com", "password")
yag.send("dest@example.com", "Subject", "Body text")

# Con smtplib stdlib (bajo nivel):
import smtplib
from email.mime.text import MIMEText
from email.mime.multipart import MIMEMultipart

msg = MIMEMultipart("alternative")
msg["Subject"] = "Subject"
msg["From"] = "user@example.com"
msg["To"] = "dest@example.com"
msg.attach(MIMEText("Body text", "plain"))
msg.attach(MIMEText("<p>Body HTML</p>", "html"))

with smtplib.SMTP("smtp.gmail.com", 587) as server:
    server.starttls()
    server.login("user@example.com", "password")
    server.send_message(msg)

Dos opciones, ambas requieren leerte la RFC o aprender la API de yagmail.

El stack típico de JS/Node

npm install nodemailer

import nodemailer from "nodemailer"

const transporter = nodemailer.createTransport({
    host: "smtp.gmail.com",
    port: 587,
    secure: false,
    auth: { user: "user@example.com", pass: "password" },
})

await transporter.sendMail({
    from: "user@example.com",
    to: "dest@example.com",
    subject: "Subject",
    text: "Body text",
    html: "<p>Body HTML</p>",
})

Una sola lib, bien diseñada, pero npm install agrega ~50 paquetes transitivos al package.json.

El stack típico de Rust

cargo add lettre
cargo add tokio --features full

use lettre::message::{header::ContentType, Mailbox, MultiPart, SinglePart};
use lettre::transport::smtp::authentication::Credentials;
use lettre::{AsyncSmtpTransport, AsyncTransport, Message, Tokio1Executor};

let creds = Credentials::new("user@example.com".into(), "password".into());
let mailer = AsyncSmtpTransport::<Tokio1Executor>::starttls_relay("smtp.gmail.com")
    .unwrap()
    .port(587)
    .credentials(creds)
    .build();

let email = Message::builder()
    .from("user@example.com".parse::<Mailbox>().unwrap())
    .to("dest@example.com".parse::<Mailbox>().unwrap())
    .subject("Subject")
    .multipart(MultiPart::alternative()
        .singlepart(SinglePart::builder().header(ContentType::TEXT_PLAIN).body("Body text".to_string()))
        .singlepart(SinglePart::builder().header(ContentType::TEXT_HTML).body("<p>Body HTML</p>".to_string()))
    )
    .unwrap();

mailer.send(email).await.unwrap();

Funcional, pero verboso. 25 líneas para mandar UN mail.

El stack típico de Java

<dependency>
    <groupId>com.sun.mail</groupId>
    <artifactId>jakarta.mail</artifactId>
    <version>2.0.1</version>
</dependency>

Y después la receta canónica de Properties + Session + MimeMessage + Transport.send(...) que probablemente sumás 40 líneas.

El stack de Fitz

let r = smtp.send({
    "to": "dest@example.com",
    "from": "user@example.com",
    "subject": "Subject",
    "body_text": "Body text",
    "body_html": "<p>Body HTML</p>",
}).await?

Que es esto.

smtp es builtin del lenguaje. No hay pip install/npm install/cargo add.
body_text + body_html juntos → multipart/alternative automático.
.await? propaga errores como Result::Err(Str). El compilador exige manejo.
Config (host, port, user, password, TLS) se lee de env vars al primer send. Lo mismo que cualquier app en Kubernetes/Docker espera.

r.delivered, r.message_id y r.duration_ms salen tipados como Bool/Str/Int.

Lo que `smtp.send` te garantiza

1. Cero deps externas

El binario fitz ya viene con lettre 0.11 linkeado estático adentro. Cuando hacés fitz build, el resultado es UN ejecutable de ~10 MB que tiene cliente SMTP, TLS via rustls, sin openssl en el host destino.

ldd ./mi-app
# linux-vdso.so.1
# libgcc_s.so.1
# libc.so.6
# (nada de smtp libs ni openssl)

2. Paridad bit-a-bit `fitz run` ↔ `fitz build`

El intérprete (fitz run) y el codegen a Rust (fitz build) emiten el mismo wire SMTP. Mismo handshake, mismo SCRAM auth, mismo Message-ID. Bug en un path = bug en el otro. Tests E2E lo validan en cada commit.

3. Async desde día uno

smtp.send(...) devuelve Future<Result<SmtpResult>>. Integra natural con el resto del stack:

@background
async fn send_welcome(email: Str) -> Null {
    let _ = smtp.send({
        "to": email,
        "subject": "Bienvenido",
        "body": "Hola, gracias por unirte.",
    }).await
    return null
}

@post("/signup")
fn signup(input: SignupInput) {
    // ... crear el user en la DB ...
    let _ = spawn(send_welcome(input.email))
    return 201 { "id": new_user_id }
}

El handler responde 201 al cliente inmediato. El email se manda en otro task tokio. Si el SMTP server tarda 2 segundos, no le importa al cliente — ya respondió hace 2 segundos.

Y con @cron armás digests:

@cron("0 0 9 * * *")  // todos los días 09:00
async fn daily_digest() -> Null {
    let r = smtp.send({
        "to": "team@example.com",
        "subject": "Daily digest",
        "body_html": "<p>Hoy: ...</p>",
    }).await
    match r {
        Ok(_) => log.info("digest.sent"),
        Err(e) => log.error("digest.failed", error: e),
    }
    return null
}

4. `Result<T>` como modelo de error

Errores de transporte (DNS, auth, TLS, server reject) llegan como Result::Err(Str) con prefijo "smtp: ":

match smtp.send(opts).await {
    Ok(r) => log.info("smtp.delivered", message_id: r.message_id),
    Err(e) => {
        // El prefijo te permite clasificar:
        // "smtp: server rejected mail: ..."     → 5xx del server
        // "smtp: transient error: ..."          → 4xx temporario
        // "smtp: client error: ..."             → TLS/auth fail
        // "smtp: invalid `to` address ..."      → parse error
        log.warn("smtp.failed", error: e)
    }
}

El checker estático exige manejo. Si tu fn retorna Result<...>, podés propagar con ?. Si no, te exige match. Cero excepciones runtime.

5. Magic-link auth en 30 líneas

El caso showcase del stack web first-class de Fitz: HTTP server-side + auth con jwt.encode + SMTP outbound, todo combinado en un binario.

type EmailRequest {
    email: Str
}

@post("/auth/magic-link")
async fn magic_link(input: EmailRequest) -> Result<Str> {
    let payload = { "email": input.email }
    let token = jwt.encode(payload, "secret")
    let link = "https://app.example.com/verify?t={token}"
    let r = smtp.send({
        "to": input.email,
        "subject": "Tu link de login",
        "body_text": "Hacé click acá:\n{link}\n\nExpira en 5 min.",
        "body_html": "<p>Hacé click <a href=\"{link}\">acá</a>.</p>",
    }).await?
    return Ok(r.message_id)
}

Sin Auth0, sin Supabase, sin Stripe webhooks. Un binario, un puerto, un comando para deployarlo.

Setup local con MailHog

Para dev no querés mandar mails reales. MailHog es un SMTP server fake con UI web que retiene los mails sin reenviar:

docker run -d --name mailhog -p 1025:1025 -p 8025:8025 mailhog/mailhog
export SMTP_HOST=localhost
export SMTP_PORT=1025
export SMTP_TLS=none
fitz run app.fitz
# Después abrís http://localhost:8025 en el browser.

En producción cambiás las env vars a Gmail/SES/SendGrid/Mailgun/lo que sea — el código de Fitz no cambia.

Trade-offs honestos (MVP)

Sin attachments todavía. La key attachments se rechaza con error claro. Workaround: bundle attachments via S3/object storage + link en el body. Lo más limpio para producción serio igual.
Sin smtp.configure(...) programático. Config sale solo de env vars hoy. Si necesitás multi-tenant con un SMTP por tenant, te queda como deuda post-MVP.
Sin retry built-in. Si smtp.send falla, el caller decide qué hacer. El patrón canónico para producción es tabla de outbox + @cron con retry.

Esto NO es FUD — son decisiones explícitas del MVP. Los 3 son refinables si entra demanda real.

Cierre

smtp.send no es "una librería más fácil". Es el mismo modelo mental que ya usás en el resto de Fitz: Result<T> como retorno, ? para propagar, .await para async, @background + spawn para fire-and-forget.

Si ya sabés cómo encadenar http.get(...).await? o db.query(...).await?, ya sabés cómo mandar mails. Cero API nuevo que aprender.

Y cuando fitzwatch reanude, la línea que tenía pendiente para notificar incidents pasa de "webhook a n8n + traducción a SMTP" a smtp.send({...}).await?. Una línea. Eso es Fitz.

Probalo: fitz versión 0.18.0+ (ya en GitHub releases). Cap exhaustivo + 3 ejemplos runnable contra MailHog en la sub-sección "SMTP outbound" del cap 17 de la guía.

Mantenete al día: la serie Fitz se publica en dev.to cada vez que cerramos una mini-tanda grande. La próxima cubrirá una feature concreta detectada durante fitzwatch.

DEV Community: Martin Palopoli

Forms, payloads, and live inputs in Fitz LiveViews

The payload

1. Click payload — a button that carries a value

2. Form submit — the whole form at once

3. Live value — @input / @change

Putting it together — a live name list

Two honest caveats

What's next in this series

Forms, payloads e inputs en vivo en Fitz LiveViews

El payload

1. Click payload — un botón que lleva un valor

2. Form submit — el form entero de una

3. Valor en vivo — @input / @change

Todo junto — una lista de nombres en vivo

Dos caveats honestos

Qué viene en la serie

A native frontend for a compiled language: .fitzv components that compile to WebAssembly

The problem: a server language needs a frontend, without importing an ecosystem

A component

What the compiler emits

The type is the same type

Why this is different

The honest edges (MVP)

Un frontend nativo para un lenguaje compilado: componentes .fitzv que compilan a WebAssembly

El problema: un lenguaje de servidor necesita frontend, sin importar un ecosistema

Un componente

Qué emite el compilador

El tipo es el mismo tipo

Por qué es distinto

Los bordes honestos (MVP)

A Vite-class dev loop for a compiled language: hot reload + state preservation + a live manifest

The setup: a compiled language with a frontend

The loop

The detail that matters: state survives the reload

The manifest re-resolves live too

Fullstack: two bins, two terminals

Why this is different

The honest edges (MVP)

Un dev loop tipo Vite para un lenguaje compilado: hot reload + preservación de state + manifest en vivo

El setup: un lenguaje compilado con frontend

El loop

El detalle que importa: el state sobrevive el reload

El manifest también se re-resuelve en vivo

Fullstack: dos bins, dos terminales

Por qué es distinto

Los bordes honestos (MVP)

Your first Fitz LiveViews component, twice: SSR and WASM from one source

The component

Target 1 — server-rendered (over a WebSocket)

Target 2 — client-WASM (offline, no server)

Same source — so which target?

What's next in this series

Tu primer componente de Fitz LiveViews, dos veces: SSR y WASM del mismo source

El componente

Target 1 — server-rendered (por WebSocket)

Target 2 — client-WASM (offline, sin servidor)

Mismo source — ¿entonces qué target?

Qué viene en la serie

Introducing Fitz LiveViews: real-time UI in one language, zero JS build

The problem

What Fitz LiveViews looks like

What makes it different

By the numbers

How it compares

Getting started

It's not a toy — there's a flagship

Where to go

What's next in this series

Presentando Fitz LiveViews: UI en tiempo real en un solo lenguaje, sin build de JS

El problema

Cómo se ve Fitz LiveViews

Qué lo hace distinto

En números

Cómo se compara

Cómo empezar

No es un juguete — hay un flagship

A dónde ir

Qué viene en la serie

SMTP outbound as a first-class citizen: send emails without pip install yagmail

The `payload`

3. Live value — `@input` / `@change`

El `payload`

3. Valor en vivo — `@input` / `@change`

What `smtp.send` guarantees you

2. Bit-for-bit parity `fitz run` ↔ `fitz build`

4. `Result<T>` as error model

Lo que `smtp.send` te garantiza

2. Paridad bit-a-bit `fitz run` ↔ `fitz build`

4. `Result<T>` como modelo de error