Why a desktop app at all

Freddy's notes app works fine in a browser. So why would he want a desktop app, and why this framework? This chapter answers both, and maps what he already knows from Laravel onto what he is about to learn.

Freddy and his notes

If you followed Freddy the Notetaker, you know Freddy: he built a notes app with Laravel, Inertia, Svelte and SQLite. It runs in a browser, and it is good. But Freddy keeps wanting three things a browser tab is bad at: a window that is there when he presses a shortcut, notes he can read on a train with no network, and a nudge when a colleague mentions him, even with the tab closed.

That is a desktop app. In this course Freddy builds one with Elyra Framework, first on its own, with its own database on his machine, and then as the desktop half of the Laravel app he already has.

What Elyra Framework is

In its own words, Elyra Framework is a Rust + Svelte 5 framework for hyper-responsive desktop apps, with Laravel's ergonomics — container, providers, middleware, a typed bridge — but compiled, binary, and without runtime overhead. The backend is Rust, compiled to a single native binary with no runtime interpreter. The window is a webview, and in it runs a Svelte 5 app. Between the two is Elyra's own bridge: MessagePack over an elyra://localhost custom protocol, with no JSON in the hot path.

The command-line tool is Ratatosk, rata: the squirrel that runs messages up and down Yggdrasil, between the Rust root and the Svelte crown. It scaffolds projects, generates code, runs migrations and installs what coding agents need. You will meet it in every chapter.

The Laravel map

Freddy's best asset is that he already knows Laravel. The guide's architecture page maps it, and this course follows the same map:

Freddy reads the last row twice. There is no Blade here: the page is a Svelte app that calls Rust, the way an Inertia page calls a controller, except that the call never leaves the machine.

The page is untrusted

One idea from the architecture page is worth carrying through the whole course: the webview is untrusted. Anything running in the page, your code, a dependency, injected content, can reach the bridge. So Elyra gates it before dispatch with three mechanisms: a random per-run token injected into the webview before any page script runs, origin isolation with no CORS headers at all in a production build, and a capability model where destructive routes are opt-in. Request bodies are capped in size and nesting depth too.

You will see this again and again: a command that deletes can be marked so the page cannot call it until the app grants it (chapter 3), the sign-in token lives in the keychain and never reaches the page (chapter 11), and a notification's full URL is never opened by itself (chapter 14).

Freddy's plan

1. Chapters 2–4: a project, commands the page can call, and the container.
2. Chapters 5–7: a database on the desktop, screens generated from a model, and lists that update themselves.
3. Chapters 8–10: windows, menus, the tray, the settings store and secrets, AI in the app, and coding agents that know the framework.
4. Chapters 11–14: the same app as the desktop half of his Laravel app, signed in, following the web, working offline and showing notifications.
5. Chapter 15: tests, a release, and the updater.

What you learned

• Elyra Framework is Rust and Svelte 5, compiled to one native binary, with Laravel's building blocks.
• The bridge is MessagePack over an elyra://localhost protocol, and the page on the other side of it is treated as untrusted.
• rata is the framework's Artisan.
• The framework is not on crates.io or npm; an app depends on a tagged release.