English for TanStack Start Developers

TanStack Start conversations combine TanStack Router’s type-safety vocabulary with new full-stack concepts — server functions, loaders — so a developer familiar with Router alone still needs new terms for the server side of the framework.

Key Vocabulary

Server function — a function marked to run only on the server, callable directly from client code as if it were local, with TanStack Start handling the network boundary automatically. “Move that database query into a server function — right now it’s running client-side, which means the connection string is shipping to the browser.”

Loader — a route-level function that fetches data before a route renders, colocating data requirements with the route definition instead of fetching inside a component. “Put the product fetch in the route’s loader so the data’s ready before the component mounts, instead of showing a loading spinner on every navigation.”

Type-safe routing — TanStack Start’s guarantee that route params, search params, and loader data are fully typed end-to-end, so a typo in a param name fails at compile time, not at runtime. “Type-safe routing caught this before it shipped — the param was renamed in the route file, and every reference to the old name failed to compile.”

File-based routing — defining routes through the file system structure, where file and folder names map directly to URL paths, generating a fully typed route tree. “Add a new folder under routes/ and the file-based routing picks it up automatically — no manual route registration needed.”

Isomorphic rendering — code that runs identically on server and client without conditional branches for each environment, which server functions and loaders are designed to support cleanly. “We wrote this loader once and it behaves the same on the server-rendered first load and the client-side navigation after — that’s the isomorphic rendering model paying off.”

Common Phrases

• “Should this run as a server function, or does it not touch anything sensitive enough to need the boundary?”
• “Is this data fetch happening in the loader, or is a component fetching it after render?”
• “Did type-safe routing catch this at compile time, or did we actually ship a broken param reference?”
• “Is this route showing up because of file-based routing, or did someone register it manually somewhere else?”
• “Does this code need an environment check, or is it genuinely isomorphic?”

Example Sentences

Debugging a client-side crash: “This crashed in the browser because a Node-only import leaked outside the server function boundary — wrap it properly and the isomorphic code stops trying to run server-only logic on the client.”

Explaining an architecture choice: “We chose TanStack Start specifically for type-safe routing — losing that guarantee on a large app with dozens of dynamic routes wasn’t a risk we wanted to take.”

Reviewing a pull request: “This fetch belongs in the route’s loader, not inside the component’s useEffect — it’ll load before render and you get it typed for free.”

Professional Tips

• Say server function precisely when describing server-only code paths — it’s a specific mechanism with its own security and bundling implications, not just “a backend call.”
• Push data-fetching into loaders in reviews rather than leaving it in component effects — it’s the idiomatic pattern and avoids waterfall loading.
• Cite type-safe routing as a concrete argument for adoption — “it catches broken links at build time” is more persuasive than “it’s more robust.”
• Use isomorphic deliberately when code genuinely runs the same way on both server and client — misusing it for code that secretly branches on environment undermines the term.

Practice Exercise

1. Explain why a database call belongs in a server function rather than directly in client-side code.
2. Describe the difference between fetching data in a loader versus inside a component.
3. Write a sentence explaining what type-safe routing catches that would otherwise be a runtime bug.