Svelte 5 and the Future of Frameworks: A Chat with Rich Harris

I'll add that my career isn't programming. However, Svelte let's me come back to my code base and understand everything, even after months. There is minimal framework related syntax to retain in my memory. Just have to know typescript well and that's it. Additionally, I don't need to retain all the rendering gotchas that other frameworks (eg, react) have. This has changed slightly with runes but I find them pretty easy to refresh on if I find im confused.

For me, this trade-off is well worth the limited availability of third party libraries. I wish someone would create a Laravel-like extension for Sveltekit. If I could just pull in user login flows, hashing, mail, etc all from organized Laravel-like docs, Sveltekit would be perfect for full-stack.

On the other hand, I've been trying out astro with svelte and it's been super nice, especially with the ability to have runes in other typescript files.

I like doing

<script lang="ts"> blah </script>

<style> blah blah </style>

<template> blah blah </template>

I just wrote about my experience here on a project https://fzakaria.com/2025/01/28/bazel-build-event-protocol-v...

So, you will have the snippet where you want it to be rendered on the child:

```child.svelte

<script> let { myFirstSnippet, mySecondSnipper } = $props(); </script>

<div id="Your first snippet goes here"> {@render myFirstSnippet()} </div>

<div id="Your second snippet goes here"> {@render mySecondSnippet()} </div> ```

Here we are declaring that this child takes 2 snippets called `myFirstSnippet` and `mySecondSnippet` and we place them wherever they might go.

And then on the parent we need to actually build those snippets:

```parent.svelte

<script> import Child from ... </script>

{#snippet myFirstSnippet()} <span>Hello from firstSnippet!</span> {/snippet}

<Child {myFirstSnippet}>

{#snippet mySecondSnippet()} <span>Hello from secondSnippet!</span> {/snippet}

</Child> ```

Here we are taking that `Child` component and rendering the two snippets that will go into it, as you see, you can either pass the snippet as a named prop or you can declare it inside the child component with the same name as the prop the child gets.

The end result of this will be a `Child` component that's rendered on the `Parent` with the two snippets inside this child component.

I hope that clears things up.

Yes, what a completely frivolous change that will only cause headaches.

Changes like this are why I dislike the mentality in the JS ecosystem. It was just cosmetic, and creates unnecessary churn. They seem to be addicted to changing things. They didn't like the old syntax? Though. What's done is done.

Don't make frivolous changes in frameworks damn it.

I love Rich Harris' work and appreciate what he gives to the community, but man he loves to rethink things.

There is a migration guide as well as a migration tool that will migrate most of your code for you. You can also see what an individual file looks like when migrated in the playground.

You need to use a separate library for CSS with React. Svelte has the best way to deal with CSS built in. Which CSS library do you choose for your React project? There are so many libraries to consider, and so many bugs in each of those libraries.

You need to use a separate state management library with React. Svelte has state management built in. Which state management library do you choose for your React project? There are so many to consider, and so many bugs.

People think they want to use React because of the "ecosystem." But, they don't realize that React coerces you to use an ecosystem, an ecosystem that is full of buggy software and those bugs create impossible permutations of configuration issues and bugs (see Create React App). Bugs are not specific to React at all, all software has bugs. But, React forces you to use an ecosystem, and that's a bad thing. I write a lot of Svelte code with very few external libraries.

React does give you job security fixing all those bugs. I'll give you that. It is a wise career choice.

Svelte 5 is a big change. But, today, I refactored a bit of reactive code (which talks to a server and uses async code) inside a single template into an external shared component. That component has reactive code that can be shared across Svelte UI components. I could do that before with stores, but I had to be careful about how to use the reactivity. This new component isolates the reactivity in the right way and shares it in the right way. And, that share component is testable. It is an incredible experience when you get it.

Problems galore in react, you should try out new js frameworks. Atleast vue and solid, to see what else is on the table

If you are building an SPA there is no reason to choose something other than React. Many of these other frameworks focus on apps that aren't full-blown SPAs. Htmx, deno fresh, astro, remix, next.js, these are all designed for users that don't want SPAs.

I think that's great, but often we conflate these use cases which cause mass confusion. Htmx is not great for highly dynamic "desktop class" web apps and the same goes for next.js.

Those things can have utility (mostly subjective), but it comes at a cost of circumventing basic web behavior just to ship some HTML, CSS, and JS to the browser in a novel way.

The browser env is the best it's ever been (seriously—I say that as an IE6 veteran). But if your motivations are beyond just delivering HTML, CSS, JS, and WASM to the browser, you can invent some serious footguns and are forced to rationalize it as "a better approach."

VDOM may be "antiquated" (I mean it's a nested object or linked list which are standard paradigms) but slow depends on what you're doing. I did a linked list for my own full-stack framework's [1] component library and it's quite snappy.

[1] https://github.com/cheatcode/joystick

At very least, Virtual DOM will survive at WASM borders if nowhere else. There's still talk of making it a lot easier to bind the DOM across WASM borders, but even then overhead may always be a strange trade-off making it useful to just pass a full Virtual DOM object to JS code on the other side of the border and letting it diff/patch. Most of the WASM-based front ends I've seen are generally some form of Virtual DOM under the hood.

That said, yes, the possibilities in doing more "direct DOM manipulation" again and "Vanilla DOM" are exciting and it is a bit of flip from the brief period when major React fans thought Virtual DOM was the greatest. I've been seeing some cool results in my own "non-Virtual DOM" projects.