New features Added Jump.CredoChecks.NoManualContentDisposition check, courtesy of @ftes (PR. Added Jump.CredoChecks.LiveViewPubSubRequiresConnected, which flags Phoenix.PubSub.subscribe/{2,3} call...

> 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.

> 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.

Phoenix LiveView workalikes for different languages and frameworks - liveviews/liveviews

Building reusable, stateful widgets in Phoenix LiveView has been challenging. LiveComponents can’t access the process mailbox for PubSub integration, while embedded LiveViews create performance overhe...

Explore our curated collections

Bluesky firehose consumer built with Phoenix LiveView - notactuallytreyanastasio/atmospheric_hoover

What's Changed Features Calculate assigns size by @kraleppa in #795 Trace diffs sent to browser by @kraleppa in #801 Add dead LiveViews section by @hhubert6 in #798 Add resources page by @kralepp...

A framework for building native applications with Phoenix LiveView - liveview-native/live_view_native

Yeah, don't do it

LiveView Basics · the basics to get you up and running creating your first LiveViews while giving you the foundation to build more complex ones

How to leverage Live Session for complex structures

This PR refactors how comprehensions are handled by LiveViews diffing algorithm. It improves upon the keyed comprehensions introduced in LiveView 1.1.0-rc.0 in the following ways: all comprehensio...

New cameras in our Pictimo webcam directory