# 001. What SnapFire FSR is

**For:** everyone. A one-page overview.

FSR is a full-stack runtime for TypeScript applications that runs on Rust, with no JavaScript engine in the serving path.

You write routes, loaders, pages and components in TypeScript. A build step lowers them. The parts that run on the server become data, an intermediate representation the Rust host interprets directly. The parts that run in the browser become a normal ES module bundle. At runtime the host answers a request by evaluating the lowered loader, rendering the page from the plan and writing HTML. There is no Node process, no V8 and no JavaScript heap on the server.

## The two artifacts

Every build produces exactly two artifacts, a plan and a bundle. Most of FSR's behaviour follows from the split between them.

The **plan** is a JSON file describing your application: every route pattern, every loader body as lowered IR, every component tree and every action signature. The host reads it at boot and builds its routing tables from it. Since it is data, it can be checked, diffed, hashed and swapped in place while the process runs.

The **bundle** is the browser's half: the islands, the client runtime and the vendored dependencies. Only the browser loads it. The server never executes it.

## What you get

**Deployment is a binary and a directory.** There is no runtime to install, no version of Node to match and no `node_modules` on the server.

**Rendering is cheap.** A page whose loader reads nothing request-specific can be prerendered to a file at build time and answered from disk. Everything else is a Rust function call over interpreted IR instead of a JavaScript VM start.

**The contract is checked in both directions.** The loader's return type is inferred at build time and written back as the page's props type. A page cannot read a field the loader does not return. When one tries, the build fails instead of the page.

**Reloads keep sessions.** The host rebuilds its tables from a new plan and swaps them. Requests in flight finish on the old tables and nobody is signed out.

## What it refuses to do

FSR will not lower a loader that reaches for something it cannot reason about. What is left over when a body cannot be fully lowered is called **residue**. The build reports it as a diagnostic instead of silently falling back to a JavaScript engine. This is deliberate. It is probably also the first thing that will frustrate you. A loader describes how to get data. It is not an arbitrary program.

## Where it sits

FSR is one of four pieces in the SnapFire stack: the **compiler** (`snapfirec`, which bundles TypeScript without Node), **typecheck**, **web** (the browser-side module system) and **FSR** itself. You can use the compiler without FSR. You cannot usefully use FSR without the compiler. The build wires it up for you.

## Try it

Open the [IR inspector](https://snapfirers.com/fsr) on the main site. It shows real TypeScript beside the exact IR the lowerer produced from it, including one sample that is deliberately refused. It is the quickest way to see what lowering actually means.