what this page is
A proof page
Each section maps a conference claim to a working route, a visible behavior, and a source file in this repo.
/slides/tanstack-start/showcase
Start over convention
A conference companion for showing how this site uses TanStack Start: typed URLs, explicit server boundaries, opt-in rendering choices, and Cloudflare-native deployment.
This page is not a second slide deck. It is a live prop: open it when the talk moves from claims to proof, click one feature, show the code path, then jump back to the deck.
what to do
Click, inspect, return
Pick a feature pill, show the live behavior, mention the listed files, then return to the main deck before the page becomes the talk.
why it helps
No toy app required
The audience can see the primitives in a real website: slides, analytics, MDX, static pages, auth routes, and Cloudflare infrastructure.
feature / router
Typed router state
Next.js pressure
Search params usually arrive as loose strings that every page has to parse again.
Start move
The route validates URL state once, then loaders, links, and components share the type.
Repo proof
- /stats validates period and feeds loaderDeps
- /slides/tanstack-start stores slide, step, live, master, and presenter in the URL
- Header links use typed TanStack Router links with intent preloading
How this helps the talk
Use this first. It is the smallest way to show the audience that Start treats the URL as application state, not a string bag.
What to do live
Click the feature pills and change `?feature=` in the URL. The route validates bad values back to `router`, then loaderDeps keys the server function call from the parsed value.
Files to open
- src/routes/(main)/stats/route.tsx
- src/routes/slides/tanstack-start/route.tsx
- src/routes/slides/tanstack-start/showcase/route.tsx
supporting demos
Small things to point at
Use these cards when someone asks “but where is that actually happening?” They link this route back to real app behavior instead of abstract framework marketing.
Typed links + URL state
Hover these links in an editor: the destination and search object are checked against the route tree.
<Link to="/stats" search={{ period: "30d" }} />
<Link to="/slides/tanstack-start" search={{ live: "demo" }} />RSC as data
The blog loader fetches a server-rendered MDX subtree and composes client islands through it.
const Renderable = await renderServerComponent(
<MDXContent components={{ Sparkles }} />
);
return { post, Renderable };Environment functions
One function has separate server and client implementations; each side is tree-shaken from the other bundle.
createIsomorphicFn()
.server(() => "server render")
.client(() => "hydrated browser")Current runtime: server render
Deferred hydration
This island is server-rendered into the document, but Start can delay loading and hydrating its JavaScript until the boundary is close to the viewport.
For the talk, the useful framing is: “I do not have to choose between HTML now and JavaScript now.” The page still has meaningful markup, while the button below only becomes interactive after the hydration trigger runs.
hydration waits for visibility
Visible HTML, delayed JavaScript
This is useful for comments, charts, embeds, and other below-fold UI: keep the page indexable and good-looking, but do not make the browser hydrate everything up front.
suggested speaker flow
Use it in four short passes
step 1
Start with URL state
Show the feature pills and explain that a typed search param is driving both the UI and the loader dependency.
step 2
Call the server function
Press the refresh button and point out that the same function works from SSR and the hydrated browser.
step 3
Separate rendering from hydration
Scroll to the hydration island and frame Start as a set of knobs, not one global rendering ideology.
step 4
Return to the live deck
Close on the slide poll: the deck itself is the Cloudflare/Durable Object deployment proof.