SvelteKit 3 takes on Next.js with type-safe remote functions

SvelteKit is the backend counterpart to Svelte, the JavaScript framework Rich Harris built in 2016. Harris, a U.K. journalist who was then a graphics editor at the New York Times, wanted an easier way to build graphical components for online stories, which led him to release Svelte 1.0 as a lighter alternative to React.js that shipped without React's boilerplate. SvelteKit grew out of Svelte to handle backend chores such as routing and rendering, occupying roughly the space Next.js occupies for React, and the two frameworks have been competing on that ground for a while. The Register cites a recent, unnamed benchmark that found SvelteKit's server side rendering (SSR) function returning an HTML payload three times smaller than Next.js's for an equivalent product page.

The new SvelteKit 3.0 release candidate is now elevating an experimental feature called remote functions, available since SvelteKit 2.27, to equal status alongside SvelteKit's traditional load functions, once the remaining bugs in it are sorted. In its own release candidate announcement, the SvelteKit project team wrote: 'Remote functions make everything else look a bit clunky.' Adherents say the approach could disrupt the landscape of remote procedure calls (RPCs). Vercel Svelte core developer Simon Holthausen described it on a Svelte Society podcast this way: 'This is our take on RPCs.'

Remote functions let a single Svelte component fetch or mutate server data on its own, without refreshing the whole page and without losing type safety, a problem developers had previously worked around with hacky, type-unsafe patches. Each remote function is written in JavaScript or TypeScript and compiled ahead of time into a lightweight client-side RPC wrapper; calling it triggers a fetch to the server from inside the component itself, with no extra routing or boilerplate required. On the server side, SvelteKit validates the incoming request, queries the database or other data source, then returns the serialized result to the component, the standard steps of an RPC call. 'You don't have to worry about where this code is running,' developer Scott Tolinski said in an episode of a Syntax videocast titled 'SvelteKit has solved data loading.' The hosts illustrated the point with a mostly static site whose only dynamic element is a footer that needs fresh data: rather than marking the whole page dynamic, which is computationally costly and slow to load, or writing a top-down route loader, the footer component can fetch and refresh its own data directly. 'From within a normal Svelte component, you can just straight up import that query or mutation as a function, then call that function in your code,' Tolinski explained.

Next.js has its own answer to part of this problem: Server Functions, formerly called Server Actions, let client components invoke server-side mutations directly. But unlike SvelteKit's remote functions, the report says, Next.js's Server Functions were built primarily for writing data rather than fetching or querying it.

Harris himself now works at Vercel, the company that owns Next.js and also sponsors Svelte's development. A Vercel spokesperson told The Register that, despite backing both frameworks, the company sees both approaches as reflecting 'a broader convergence toward typed, server-side functions callable from the client.' Tolinski was more blunt about the bar remote functions have to clear: 'I'm not saying no other RPC systems have done it as good as this, but it better be as good as this if you want me to use it.'

Key facts

SvelteKit's 3.0 release candidate promotes 'remote functions,' an experimental feature available since SvelteKit 2.27, to equal status with the framework's traditional load functions, once its remaining bugs are resolved.
A remote function lets one Svelte component fetch or mutate server data directly, keeping full type safety and skipping a full page refresh, by compiling into a lightweight client-side RPC wrapper that calls the server from inside the component.
An unnamed, unlinked benchmark cited in the report found SvelteKit's server side rendering returns an HTML payload three times smaller than Next.js's for an equivalent product page.
Next.js already offers Server Functions, formerly called Server Actions, for client-to-server calls, but the report says those were built mainly for writing data rather than fetching or querying it.
Svelte creator Rich Harris, who released Svelte 1.0 in 2016, now works at Vercel, the company that owns Next.js and sponsors Svelte; a Vercel spokesperson calls both frameworks' approaches part of 'a broader convergence toward typed, server-side functions callable from the client.'

Why it matters

SvelteKit 3 is not just adding a feature, it is changing what SvelteKit treats as the default way to move data between server and browser. Until now, a component that needed live data went through a route level load function, or the whole page had to be marked dynamic; both options added structure a developer had to plan around before writing any business logic. Promoting remote functions to equal status with load functions means SvelteKit is betting that fetching and mutating data straight from inside a component, with the type checker watching the whole path, becomes the pattern most developers reach for by default. That is also a direct move onto Next.js's ground: the report's own comparison, that Next.js's Server Functions were built mainly for writing data rather than querying it, frames remote functions as covering territory Vercel's flagship framework does not fully cover yet, even though Vercel is behind both projects.

Who it affects

Most directly, developers building on SvelteKit and teams choosing between SvelteKit and Next.js for a new project. The framework's own SSR comparison, an HTML payload three times smaller than Next.js's for an equivalent product page per an unnamed recent benchmark, speaks to teams building content or e-commerce sites where markup size affects load time. It also affects anyone maintaining a SvelteKit app today with load functions or actions: the SvelteKit team's own framing, that remote functions make those older patterns look clunky, signals where the framework's guidance is heading, even though nothing forces an immediate migration. And it touches Vercel itself, which ends up promoting two different data fetching philosophies at once, one on each side of the Svelte and Next.js divide it sponsors and owns respectively.

How to use it

Remote functions are written in JavaScript or TypeScript and compiled ahead of time into a lightweight client-side RPC wrapper. A developer imports a query or mutation directly into a normal Svelte component and calls it like any other function; SvelteKit handles validating the incoming request, querying the database or other data source, and returning the serialized result on the server side, with no extra routing or boilerplate to write by hand. The feature has been available experimentally since SvelteKit 2.27. The 3.0 release candidate is what proposes treating it as equal to load functions, conditional on the SvelteKit team clearing the bugs it says remain; the source gives no count or description of those bugs, and no release date for the finished, non-release-candidate 3.0.

How solid is it

The report draws on more than a single source: the SvelteKit team's own release candidate announcement, Vercel Svelte core developer Simon Holthausen speaking on a Svelte Society podcast, developer Scott Tolinski on a Syntax videocast, and a Vercel spokesperson who answered The Register directly. That gives the central claims about how remote functions work reasonable grounding. The softer point is the performance comparison: the claim that SvelteKit's SSR output is three times smaller than Next.js's traces to an unnamed, unlinked recent benchmark that measured general SSR payload size on one product page scenario, not remote functions themselves, and the source gives no performance numbers for remote functions specifically. The piece is straight technical reporting, carrying a byline from The Register's software development and cloud reporter, not one of the outlet's satirical pieces.

Risks and caveats

The feature is still a release candidate, and the SvelteKit team's own framing concedes there are remaining bugs, though the source does not say what they are, how many, or when the finished, non-release-candidate 3.0 will ship. The claim that SvelteKit's SSR output is three times smaller than Next.js's should not be read as evidence that remote functions themselves are faster: it is an unnamed, unlinked benchmark of SvelteKit's general server rendering output on a single product page scenario, not a measurement of remote functions. The clearest voice endorsing convergence between SvelteKit's and Next.js's approaches is a Vercel spokesperson, and Vercel owns Next.js while also sponsoring Svelte, so that comment sits closer to a company position than an independent assessment; no maintainer of Next.js is quoted directly on the comparison.

“Remote functions make everything else look a bit clunky.”

— SvelteKit project team, in the 3.0 release candidate announcement