English for SvelteKit Developers

SvelteKit’s file-based routing system uses a distinctive set of conventions — +page.svelte, +layout.svelte, +page.server.ts — and these names can be confusing to say out loud in English, especially during a standup or code review. Beyond the naming conventions, SvelteKit introduces concepts like server-only load functions, form actions, and the handle hook that require precise vocabulary to discuss clearly. This guide gives you the language you need to talk about SvelteKit confidently with your team in English.

Key Vocabulary

Load function A load function is an exported load function in a +page.ts, +page.server.ts, or +layout.server.ts file that fetches or prepares data before a page or layout renders, returning an object that the component receives as data. Example: “The load function fetches the blog post from the database and returns it — the component just renders what it receives.”

Server load function A server load function is a load function inside a +page.server.ts file that runs exclusively on the server, giving it access to private environment variables, databases, and cookies that should never be exposed to the browser. Example: “I moved the API key call into a server load function so the secret never reaches the client bundle.”

Layout A +layout.svelte file defines a shared UI wrapper — navigation, sidebars, footers — that persists around all child routes in the same directory, with a <slot /> where the child page content is inserted. Example: “The dashboard layout wraps every page in the /dashboard route group with the sidebar and header.”

Error page A +error.svelte file is a component SvelteKit renders automatically when a load function throws an error or calls error(), replacing the normal page with a fallback UI scoped to that route level. Example: “I added a +error.svelte to the blog directory so a missing post shows a friendly 404 message rather than the global error page.”

SSR (server-side rendering) SSR means the page HTML is generated on the server for each request, giving the browser fully rendered markup immediately; SvelteKit uses SSR by default but lets you disable it per-route when static or client-only output is preferred. Example: “We keep SSR enabled on the product pages for SEO, but the interactive configurator is CSR-only because it doesn’t need to be indexed.”

Form action A form action is an exported actions object in a +page.server.ts file that handles POST form submissions server-side, returning success data or validation errors back to the page without a full redirect. Example: “The contact form uses a form action — on validation failure it returns the errors and re-renders the form with the user’s input preserved.”

Handle hook The handle hook is a function exported from src/hooks.server.ts that intercepts every incoming request before it reaches a route, commonly used for authentication, session loading, or custom response headers. Example: “We added the user session to event.locals inside the handle hook so every load function can access it without repeating the auth check.”

Prerendering Prerendering is a SvelteKit build-time option that generates static HTML for a route once during the build, rather than on each request, resulting in fast delivery from a CDN with no server required at runtime. Example: “The about page and all the blog posts are prerendered — they’re just static files served from the CDN.”

Common Phrases

In code reviews:

• “Sensitive data should go in the server load function, not the shared +page.ts — it will be exposed in the client bundle otherwise.”
• “This logic is duplicated across three load functions; can we lift it into the root +layout.server.ts and access it through parent()?”
• “The handle hook is the right place for session validation — not inside each individual load function.”

In standups:

• “I’m setting up the handle hook today to load the user session and attach it to event.locals.”
• “Finished the form actions for the settings page — validation errors are returned inline without a redirect.”
• “Blocked on prerendering — some pages pull from a database that’s not available at build time, so I need to decide which routes stay dynamic.”

In documentation:

• “Place shared data fetching in the nearest +layout.server.ts and access it from child load functions via await parent().”
• “To disable SSR for a route, export export const ssr = false from +page.ts.”
• “Form actions must be in a +page.server.ts file; they are not available in client-only +page.ts files.”

Phrases to Avoid

Saying “the server file” — there are several server files in SvelteKit (+page.server.ts, +layout.server.ts, hooks.server.ts). Always use the full filename to avoid ambiguity. Correction: “I added the database call to +page.server.ts, not the shared layout server file.”

Saying “I used SSR to make it faster” — SSR improves initial page load perception and SEO, not raw speed. Using it to justify performance gains is imprecise. Correction: “I kept SSR enabled on this page so search engines receive fully rendered HTML instead of an empty shell.”

Saying “I added a middleware” — SvelteKit does not use the word “middleware”; the equivalent is a hook (specifically the handle hook in hooks.server.ts). Correction: “I added the authentication check to the handle hook so it runs on every request before routing.”

Quick Reference

Term	How to use it
load function	”Export a load function from +page.ts to fetch data before rendering.”
server load function	”Use +page.server.ts when the load function needs secrets or database access.”
layout	”Add a +layout.svelte to wrap all routes in this directory with shared UI.”
form action	”Define an actions object in +page.server.ts to handle POST submissions.”
handle hook	”Register session loading in the handle hook in hooks.server.ts.”
prerendering	”Set export const prerender = true to generate a static HTML file at build time.”

Expanding Your Professional Vocabulary

The core of becoming a proficient SvelteKit developer isn’t just knowing how to write code; it’s communicating effectively about that code. Whether you’re collaborating with teammates on a complex routing strategy, explaining the intricacies of a load function to a less experienced colleague, or documenting your work for future maintainers, clear and precise English is absolutely crucial. This section focuses specifically on building your professional vocabulary related to SvelteKit development, addressing the nuances often missed when simply translating technical terms.

One common challenge for non-native speakers is understanding subtle differences in phrasing. For example, saying “I’m having trouble with this” can be interpreted very differently than “I need clarification regarding…” The latter sounds more proactive and focused on finding a solution. Similarly, describing code changes in SvelteKit often involves using specific terminology – terms like “SSR (Server-Side Rendering),” “hydration,” “route parameters,” and “load functions.” Simply saying “this is slow” isn’t enough; you need to articulate why it’s slow, perhaps referencing metrics or the impact on user experience. A code review comment shouldn’t just be a criticism; it should offer constructive feedback with actionable suggestions. Consider this: instead of writing “This needs refactoring,” try “Could we explore utilizing a more modular approach for this component to improve maintainability and reduce potential duplication?” This demonstrates an understanding of the bigger picture beyond just the immediate code change. Furthermore, paying attention to formal vs. informal language is important. Slack conversations are often casual, but documentation and PR descriptions demand a higher level of professionalism.

Another area where many developers struggle is articulating technical trade-offs. SvelteKit’s flexibility allows for various approaches – each with its own advantages and disadvantages. Being able to explain why you chose one method over another, referencing performance considerations, developer experience, or future scalability, is a key skill. You might say, “While using a +page.server.js file for this route offers immediate SSR benefits, we’re opting for a standard Svelte component approach to maintain a simpler codebase and reduce the overhead associated with server-side logic.” This demonstrates a thoughtful consideration of various factors.

Finally, don’t underestimate the power of concise descriptions. When writing PR descriptions, aim for clarity and brevity. Focus on what you changed and why, rather than getting bogged down in technical details that aren’t immediately relevant to reviewers.

# Example: Using svelte-kit dev command

npm run dev -- --host 0.0.0.0