You’ll Write Less Code With Svelte 5.0, Promises Rich Harris

Svelte 5.0 will be “just better” in every way, creator Rich Harris promised during a recent podcast.

“It’s more robust, it’s more reliable, it’s smaller, it’s faster, it’s more flexible, it’s more composable,” Harris promised. “It’s just easier. You will end up writing less code with Svelte 5 than you did with Svelte 4 and it’s just going to feel nicer.”

Svelte 5 adds fine-grained universal reactivity, which means developers will no longer be restricted to Svelte components, he said during a The Modern Web podcast to discuss React Server Components and Svelte 5. He was joined by podcasters Tracy Lee, Ben Lesh and Adam Rackis.

“You can declare reactive state inside .cell.json.cell.ts modules, which is super cool,” he said. “All of the things that people liked about Svelte 3 and 4 are still there, like all of the motion primitives, transitions, scoped CSS, super-fast server-side rendering.”

Users will find an application framework that “dovetails really elegantly with the component framework,” Harris continued, but it’s packaged in a better version. He also specifically addressed criticism of the compiler.

“For the people who looked at the compiler output of Svelte in the past and said, ‘This looks really confusing and wonky, and also, if I have a lot of these components it’s going to end up being a larger bundle than if I just used a bigger framework in the first place, that’s no longer true, because the compiler output is so much leaner,” he said. “On every dimension, it’s just better.”

Svelte 5 is available as a release candidate, and there is a playground that lets developers preview the framework.

Why Svelte Adopted Signals

Svelte was created during the top of the Signals hype and Harris said he was glad Svelte had settled on using Signals.

“It means that the code that the compiler generates is really easy to read and we don’t need to generate a lot of code at all because Signals give you so much for free,” he said. “And our implementation of Signals is … very efficient, it’s very memory efficient, it’s very performant because, as a compiler, we’re able to make design choices that are difficult for other frameworks to make.”

“We’re actually one of the more conservative frameworks, honestly.”
– Rich Harris, creator of Svelte

Signals are reactive primitives that handle application states. They allow developers to easily manage and respond to changes in their applications. They actually go back to about 2008, when Knockout was around, Harris said. Lesh added that they were called observables then, but Harris noted that the ergonomics weren’t great.

He explained the adoption curve of Signals, which he traced to Vue 3 and then he credited Ryan Carniato, the creator of Solid, with evangelizing about Solid’s benefits.

“We’re actually one of the more conservative frameworks, honestly,” Harris said of Svelte. “We have a reputation for being like this sort of innovative scrappy thing, but we’re definitely one of the slower moving frameworks when it comes to design, not because we don’t have development velocity, but just because we were very picky about what we build. And so it’s taken us a long time to get there.”

Harris Calls React Server Components “Phenomenal”

The podcast team also asked Harris about React Server Components, which have been all the talk in React circles over the past two years. Harris acknowledged this was a tricky conversation for him since he works for Vercel, which has adopted React Server Components.

“I do have opinions about RSCs, not bad opinions — I actually think they’re pretty phenomenal,” he said. “For me, the big appeal of React Server Components is that it is the logical next step of this journey that we’ve been taking over the last decade or so, to co-locate all of our stuff together.”

Basically, he said, the frontend had this idea — he called it “an absurd notion” — of separating HTML, JavaScript and CSS. Largely thanks to React, people came to accept that as a very bad idea, he added.

“People came to accept that that was a very, very bad idea indeed, and that actually, if you have some CSS that relates to a specific piece of markup in your application, and you have some JavaScript that relates to that same markup, then it all belongs together, and so we started colocating stuff,” he said. “Svelte was, at least for a while, one of the more aggressive adherents of that philosophy, because not only do we have our behaviors alongside our markup, but we actually have styles right there inside the component file, so everything is this nice little self-contained thing.”

“For me, the the big appeal of React Server Components is that it is the logical next step of this journey that we’ve been taking over the last decade or so, to co-locate all of our stuff together.”
– Harris

One piece missing, though, was data fetching, he said.

“The assumption was that you are going to have that data passed into the component, maybe when the component initializes in the browser, it’s going to send off a network request and fetch some data, and then it’s going to update some internal state,” he said.

While that works, it has a bunch of drawbacks, he said.

“One of those drawbacks is you really don’t want to be doing that stuff out over the network if you can help it because you’re going to have loading spinners and you probably have all sorts of waterfalls and grubby stuff like that,” he said. “But the real problem is that you need to have that data fetching code, if you’re going to pass it into the component, in some other location than the component itself.”

The problem is, if you delete a component, your program could still be fetching the data and you might not realize it, he said.

“You have no idea that you’ve deleted the code that needs the data, but not the data itself,” he explained. “Conversely, if you add a component deep in your tree somewhere, then you might need to update your data loading function, which is quite remote and might even be overseen by a different team. You just have this really nasty coordination problem.”

RSC eloquently solves this, he said.

“The code for getting the data that belongs to the component exists in the component itself,” he said. “If you no longer need that component, you can delete it, and you’re no longer going to fetch that data for that component. So that is a really nice, elegant thing that I don’t think I’ve seen anyone solve as well as RSCs have solved.”

RSC’s ‘Catch’

What’s the catch, Rackis asked.

The catch is that developers essentially create two separate worlds — components on the server and components on the client, Harris said.

“There [are] obviously good reasons for that, like the server is this stateless environment, so it doesn’t make sense to have stateful hooks; and [with] your client components, it doesn’t make sense that they should be able to access the database directly — stuff like that,” he said. “There are obviously reasons for the behavioral differences between server components and client components, but what we’ve seen is that the difference is just really confusing for people.”

Harris admitted it can even be confusing to him as a framework creator.

“I sympathize with that. I want to just have the same mental model throughout my application,” he said. “To the extent possible, I don’t want to be thinking, what are the rules, again, on how I can combine these different components and what data can be serialized, all of that stuff? It just confuses me. And it confuses a lot of people. That is the main sticking point — that it’s difficult.”