I love love love Svelte/Sveltekit. I am an experienced backend engineer and this is the first time I have worked in a FE framework that just clicked.
What I like:
- Not a whole lot of magic syntax.
- The structure of files feels like I am building a backend app, its quite logical and easy to parse through.
- Easy to get up and running, I am sure the decisions exist but I struggle historically with all the sidecar products that can be added into the frontend framework.
- It combines the beauty of native JS/TS with svelte. I can hydrate a store with my own hand rolled api calls.
- There is not a whole lot going on from a API/user perspective. I have stores and routes which are built into the folder structure. I am sure there is more but that gets me to a useful MVP.
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.
I love Svelte, Kit not necessarily.
It's nice but a bit too magic for me. I wrote about this before but I find it weird to write a load function that gets transpiled into a server and a client version and having to use `browser` to check if running in a browser context. Well it's not necessarily weird but it is too magic for me, e.g. an if statement checking this would get compiled away iirc.
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.
Vite does statically replace the `browser` variable with `true` or `false` based on whether you're on the client or server, but this shouldn't affect the correctness of your code. It does allow Vite to remove any unused code, however. E.g. `if (browser)` turns into `if (false)` on the server and any code within that block can be removed. This can avoid shipping unused code to the client.
Astro is also built in top of Vite and the same thing happens there. If you reference `import.meta.env.SSR` it is statically replaced during build and unused code is tree-shaken out: https://vite.dev/guide/env-and-mode#env-variables
Thank you for the explanation, that cleared it up a lot for me. In astro I didn't yet use SSR, I will try this out as well.
I do still believe that it may be good to point this out in the docs more thoroughly. In general though, couldn't there be some situations where using a universal load function like this may increase the chance for some security critical logic bugs?
You should only access credentials in `.server` files. We have a built-in feature that checks that you only access credentials in `.server` files to try to prevent newcomers from accidentally making any mistake in that regard.
I’ve been a backend and data engineer who got my start in full stack. I’m working on a project and selected Svelte for the front end after trying to learn React. I agree 100%. Svelte is great. Even 5 with its warts isn’t as bad as react.
Kit on the other hand has been a major pain. You won’t need a webserver oh wait you do! You have to make drastic tradeoffs when choosing between full SPA and SSR render only. Server side pre-rendering seems like middle ground nightmare that I just I don’t think I can tackle sufficiently right now. I need to get an MVP.
The (browser) issue is a symptom of this greater problem - it’s just not clear what runs on the server side and what doesn’t. The documentation is very poor on this and blogs are flat out wrong.
Files with `.server` in the name run only on the server. The remaining files run on the client and server. This is mentioned in the introduction on https://svelte.dev/docs/kit/routing
What's confusing about this and what could we do to help?
It's all kinda hidden. The documentation steers you towards SSR or assumes it. It appears as though you can't have client side routing without a roundtrip to the server. Take a looked at the "page" documentation immediately under Routing.
How do I serve svelte files using a python or golang backend and still have client side routing? These should have a fairly straightforward answer but I don't think they do.
By default, SvelteKit does SSR for the first page and client-side routing thereafter. This is fully configurable. Perhaps it's worth an additional mention on the routing page. I'll take a look later. Thanks for the suggestion.
The only "magic syntax" I wish Svelte would borrow from other frameworks is a <template> tag to surround the component, in similar to how it already has <script> and <style>. You can do this with preprocessors but having it built in would be golden.
I loved svelte. But svelte5 seems to be a bit of turn off. It's not even the runes. Slots was hands down the best feature of svelte. And they deprecated it I still can't for the life of me figure out how the new way is supposed to work. The migration docs are very limited. And it's super weird that the parent has to intentionally render children instead of a slots?
Also, why deprecate the on:event syntax?
You have a child and a parent component. The snippet is declared on the parent and rendered on the child.
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.
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.
Snippets are far more powerful than slots and so the change is not merely cosmetic. Snippets give you a way to create reusable HTML fragments within a component.
Sure, that is nice - though TBH that kind of feels like a workaround for Svelte's one file, one component design. React doesn't have this issue and can define as many components wherever you like.
Had the same feeling. Because of that I moved on to no-build Preact. I’ve been happy with it so far, and I hope that it will get me closer to ”work for the customers, not for the vims of framework developers”.
I’ve been using Svelte for several years, but haven’t had much time to dive into the many changes in 5.
Maybe someone here can shed light on something about runes that feels very off to me. The rune is on the wrong side of the equal sign? Like:
let counter = $state(0);
Looks like a reactive value assigned to a variable, but that’s not at all what’s going on. It’s actually a reactive variable initialized to 0. So, for example, despite what you’d expect you can’t even move the $state call into a utility function if you’d have some reason to. Very counterintuitive to me, and not really touched upon in the docs as far as I’ve seen, but I have to assume there’s some practical reason why they did it this way.
I remember Svelte 2 (or 1? Can’t remember) had some weird things like this as well, where you’d think you could do something based on your experience from JavaScript but it just wasn’t supported. The label syntax in Svelte 3 was pretty brilliant because it was a clear indication that you shouldn’t expect normal JS rules to apply. It did have other problems that they appear to have fixed though.
That's correct. Svelte has form for overloading JavaScript syntax with its own additions. This rune is not JavaScript. What it actually is is a flag for the compiler to abstract away the complexity of signals by saying "treat this value as reactive". When it's compiled, it generates all the signals needed to make the value reactive. But the ergonomics of using it are as mostly the same as if you were creating a value. It's not the same though, and so there are warnings in case you use it in a way that the compiler won't handle correctly.
The Svelte 5 rollout feels like a frogmarch.
The v3 docs and repls and tutorials are gone, not api versioned.
The new docs are bad, IMO, conpared to the clear documentation 3 and 4 had for years, with constant blurring with SvelteKit, which is a server framework, no thanks.
The new docs font appears designed to make one cease reading. The new syntax is ugly and verbose and vague, IMO, but admittedly i am having difficulty with the documentation, which may be the real issue.
If there were a translation guide from how one does things in Svelte 3 to Svelte 5 it might feel less like learning a new framework.
Well, nothing lasts forever.
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.
That link should be a bit more prominent, until the community has upgraded. Right now I think it's only at the very end of https://svelte.dev/docs/svelte/legacy-overview and I for sure was not aware of it, cursing the new docs layout when maintaining existing code.
I really like svelte 5, personally I find the rune system to be much more explicit about what the code is doing and I prefer that.
I always felt that reading svelte code (prior to svelte 5) required to understand a sort of "magic syntax" very well, which was off putting.
I don't really mind having to declare reactive variables as `$state()`, it makes it very explicit that we want the variable to be reactive. It seems this change has also allowed for a lot more powerful and reusable code so I'm all for it. I guess that people who were already in the ecosystem might have found that they had to learn a lot of new stuff but imo this is very much a case of "might be a bit painful for our current users but it'll make life easier for everyone else in the future".
There's a few things I am a bit conflicted with but it's probably due to myself not really knowing how to solve a determinate problem rather than a problem with the framework itself. It's a bit difficult to get help sometimes.
I've yet to find a problem with React that would justify learning one of those new frameworks. I know it's popular to say React is bad on the internet, but have been using it for 10 years now and it's still going strong in my opinion.
(For some background, I used to code SPAs from scratch with vanilla JS and jQuery in the 2000s, then switched to backbone.js then Angular, before picking up React that solved all the design issues of Angular)
The problems aren't with React itself. The problems are external to React. But, that's a huge problem.
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.
I was trying to learn React shortly after hooks came out. Some in the community claimed you can drop Redux, which totally baffled me. Redux was far simpler.
Then it became “wait just don’t use hooks till we work out the issues.”
> You need to use a separate library for CSS with React
I mean you can just use CSS. Personally I use css modules. Not very buggy or react specific.
> a separate state management library
Yeah I do use tanstack query to manage server state. Does Svelte include something similar out of the box? Otherwise it’s
1) url/query param for app state
2) tanstack query for server state
3) hooks for reusable state or local component state. Not many library bugs with that approach and tbh I’ve never needed something like redux or zustand.
Every framework has its shortcomings, and React just as much so as any other. Learning other frameworks is always worthwhile. I've done Angular, Vue, React, and am currently looking into Svelte.
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.
React has kept changing its design approach and best practices every two years - probably to keep the bootcamps always running and churning the change industry.
Why downvote when this is perfectly known in basic history ? Maybe you only started using React recently ?
Previously,class components were the primary way to manage state and lifecycle methods.
Lifecycle methods like componentDidMount, componentDidUpdate, and componentWillUnmount were heavily used.
Now, functional components with Hooks (useState, useEffect, etc.) are the best practice. There were several iterations of different practices in between.
Previously, props were passed through multiple layers of components (prop drilling was established practice).
Now Context is used. State management, event handlers, component structure, CSS-in-JS: pretty much everything has changed over time.
No - I used React in the past, but no longer use it. Maintenance is a head-ache. I am utterly certain that within the next 2 years, another "life-changing" React paradigm will come into effect - can even bet on it.
Svelte(kit) renewed my love for web development. It gets out of the way when i want it to, is build on web standards so i'm not stuck on annoying "gotchas", and has all the tools I need to build something without pulling in 20 dependencies just to build a basic app.
After being a skeptic of svelte 5, its fully captured me.
I was one of those that really felt like Runes was going to ruin svelte. But after working with it on a small team for a month now, I can see the benefits. We previously had a lot of devs confused with `$:` and other reactive issues. It had always made perfect sense to me but I have to admit, it was a bit magical which was apparently too much for some. With the runes stuff I've seen it click with people in ways it didn't previously. I did like the elegance of the old syntax but I'll take the explicitness of runes if it gets my team on board and causes fewer issues.
I recently started on a frontend project using Svelte, knowing nothing about frontend development. I've found it very easy to use. I had a few failed attempts at this project in the past using React, but I found it quickly overwhelming.
The tutorials on the website are excellent and that was all I needed to get started.
A team I work very closely with as an architect has ditched React in favour of Svelte and the team love it. Everyone prefers it to React and finds it easier and more productive to use.
Maybe I’m in the minority but I still love me a good ole SSR app with either some vanilla JS or jquery sprinkled on it. Seems to do just fine for my needs but then again, I’m not building highly complex applications. Just a bit of interactivity is all I need, and it suits me just fine without needing any build steps.
Not really. Most of these frameworks are just clever attempts at reinventing the wheel. Generally to enable some sort of special syntax/templating system (or force server-side behavior into the client like the React Router abomination).
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."
There is also the Lit approach which really doesn’t have any meaningful misalignments with the underlying web platform primitives and allows people to have the same developer experience without the trade offs.
Virtual DOM has its charms. React is sort of synonymous with Virtual DOM, but isn't the only way to do Virtual DOM and it's probable other Virtual DOM front ends will continue to be built whether or not React goes away.
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.
It's either VDOM or having to depend on a compiler to do everything (how Svelte works). The advantage to the former is it's relatively easy to debug, whereas with a compiler, I'm at the mercy of its developer and their whims.
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.
Lit does not use a virtual DOM, nor require a compile step. Instead, it utilizes object accessors and tagged templates to figure out when to schedule an update.
> It's either VDOM or having to depend on a compiler to do everything (how Svelte works).
Assuming you don't mean JSX transform by "compiler", you really don't have to do either one. For my framework [1], state is directly bound to DOM elements. Dependencies are determined at run time. It's not slow.
Dependencies meaning other components or something else?
And if I understand correctly, you're forming relationships between parents/children by setting extra properties on the DOM nodes themselves (e.g., node.mutraction_parent = <Some Other DOM Node>)?
No. Dependency means a state/data dependency that would require a UI update.
You never need to explicitly assign tree relationships like parents. Here's the example code from the front page. In this case, `model.clicks` is a dependency.
Essentially object proxies. When you invoke a property getter in tracked contexts (like DOM element construction), a dependency is registered for that object property. When you invoke the corresponding setter, the update function for the list of dependencies are notified.
That's the idea, in a nutshell.
I'm definitely not the first one to come up with this idea, but I hadn't found another UI framework that worked exactly like how I wanted. Solid is kind of close, but not it. Vue has some of this as well, but it's a bit more kitchen-sink in its scope.
I love love love Svelte/Sveltekit. I am an experienced backend engineer and this is the first time I have worked in a FE framework that just clicked.
What I like:
- Not a whole lot of magic syntax.
- The structure of files feels like I am building a backend app, its quite logical and easy to parse through.
- Easy to get up and running, I am sure the decisions exist but I struggle historically with all the sidecar products that can be added into the frontend framework.
- It combines the beauty of native JS/TS with svelte. I can hydrate a store with my own hand rolled api calls.
- There is not a whole lot going on from a API/user perspective. I have stores and routes which are built into the folder structure. I am sure there is more but that gets me to a useful MVP.
I agree with everything you highlighted!
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.
I love Svelte, Kit not necessarily. It's nice but a bit too magic for me. I wrote about this before but I find it weird to write a load function that gets transpiled into a server and a client version and having to use `browser` to check if running in a browser context. Well it's not necessarily weird but it is too magic for me, e.g. an if statement checking this would get compiled away iirc.
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.
Vite does statically replace the `browser` variable with `true` or `false` based on whether you're on the client or server, but this shouldn't affect the correctness of your code. It does allow Vite to remove any unused code, however. E.g. `if (browser)` turns into `if (false)` on the server and any code within that block can be removed. This can avoid shipping unused code to the client.
Astro is also built in top of Vite and the same thing happens there. If you reference `import.meta.env.SSR` it is statically replaced during build and unused code is tree-shaken out: https://vite.dev/guide/env-and-mode#env-variables
Thank you for the explanation, that cleared it up a lot for me. In astro I didn't yet use SSR, I will try this out as well.
I do still believe that it may be good to point this out in the docs more thoroughly. In general though, couldn't there be some situations where using a universal load function like this may increase the chance for some security critical logic bugs?
You should only access credentials in `.server` files. We have a built-in feature that checks that you only access credentials in `.server` files to try to prevent newcomers from accidentally making any mistake in that regard.
I’ve been a backend and data engineer who got my start in full stack. I’m working on a project and selected Svelte for the front end after trying to learn React. I agree 100%. Svelte is great. Even 5 with its warts isn’t as bad as react.
Kit on the other hand has been a major pain. You won’t need a webserver oh wait you do! You have to make drastic tradeoffs when choosing between full SPA and SSR render only. Server side pre-rendering seems like middle ground nightmare that I just I don’t think I can tackle sufficiently right now. I need to get an MVP.
The (browser) issue is a symptom of this greater problem - it’s just not clear what runs on the server side and what doesn’t. The documentation is very poor on this and blogs are flat out wrong.
Files with `.server` in the name run only on the server. The remaining files run on the client and server. This is mentioned in the introduction on https://svelte.dev/docs/kit/routing
What's confusing about this and what could we do to help?
It's all kinda hidden. The documentation steers you towards SSR or assumes it. It appears as though you can't have client side routing without a roundtrip to the server. Take a looked at the "page" documentation immediately under Routing.
How do I serve svelte files using a python or golang backend and still have client side routing? These should have a fairly straightforward answer but I don't think they do.
The docs for single page apps live at https://svelte.dev/docs/kit/single-page-apps
By default, SvelteKit does SSR for the first page and client-side routing thereafter. This is fully configurable. Perhaps it's worth an additional mention on the routing page. I'll take a look later. Thanks for the suggestion.
> or assumes it.
I think this succinctly summarizes my gripes. The docs do generally make these assumptions, and are not clear when it's otherwise.
The only "magic syntax" I wish Svelte would borrow from other frameworks is a <template> tag to surround the component, in similar to how it already has <script> and <style>. You can do this with preprocessors but having it built in would be golden.
I like doing
<script lang="ts"> blah </script>
<style> blah blah </style>
<template> blah blah </template>
Isn't <template> an HTML element?
- No useHook() spaghetti
Same
I just wrote about my experience here on a project https://fzakaria.com/2025/01/28/bazel-build-event-protocol-v...
I loved svelte. But svelte5 seems to be a bit of turn off. It's not even the runes. Slots was hands down the best feature of svelte. And they deprecated it I still can't for the life of me figure out how the new way is supposed to work. The migration docs are very limited. And it's super weird that the parent has to intentionally render children instead of a slots? Also, why deprecate the on:event syntax?
You have a child and a parent component. The snippet is declared on the parent and rendered on the child.
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.
https://svelte.dev/docs/svelte/v5-migration-guide#Event-chan...
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.
Snippets are far more powerful than slots and so the change is not merely cosmetic. Snippets give you a way to create reusable HTML fragments within a component.
I was commenting specifically about on:change
I believe the reason for that was to enable event forwarding, which was a highly requested feature and makes a lot of things easier.
Sure, that is nice - though TBH that kind of feels like a workaround for Svelte's one file, one component design. React doesn't have this issue and can define as many components wherever you like.
Had the same feeling. Because of that I moved on to no-build Preact. I’ve been happy with it so far, and I hope that it will get me closer to ”work for the customers, not for the vims of framework developers”.
I'm in agreement, really loved Svelte 1, 2, and 3, but the v5 changes feel like a needle scratch unfortunately.
I love Rich Harris' work and appreciate what he gives to the community, but man he loves to rethink things.
I’ve been using Svelte for several years, but haven’t had much time to dive into the many changes in 5.
Maybe someone here can shed light on something about runes that feels very off to me. The rune is on the wrong side of the equal sign? Like:
Looks like a reactive value assigned to a variable, but that’s not at all what’s going on. It’s actually a reactive variable initialized to 0. So, for example, despite what you’d expect you can’t even move the $state call into a utility function if you’d have some reason to. Very counterintuitive to me, and not really touched upon in the docs as far as I’ve seen, but I have to assume there’s some practical reason why they did it this way.I remember Svelte 2 (or 1? Can’t remember) had some weird things like this as well, where you’d think you could do something based on your experience from JavaScript but it just wasn’t supported. The label syntax in Svelte 3 was pretty brilliant because it was a clear indication that you shouldn’t expect normal JS rules to apply. It did have other problems that they appear to have fixed though.
Have you tried it out? You can definitely move that $state call into a utility function (or a class field, or another file, etc).
I can’t do this:
> $state(...) can only be used as a variable declaration initializer or a class field https://svelte.dev/e/state_invalid_placement (state_invalid_placement)It has to be part of a variable initialization even though it looks like it’s creating a value.
That's correct. Svelte has form for overloading JavaScript syntax with its own additions. This rune is not JavaScript. What it actually is is a flag for the compiler to abstract away the complexity of signals by saying "treat this value as reactive". When it's compiled, it generates all the signals needed to make the value reactive. But the ergonomics of using it are as mostly the same as if you were creating a value. It's not the same though, and so there are warnings in case you use it in a way that the compiler won't handle correctly.
Oh, weird, I could swear I've done that before. Especially weird because a class field is essentially the same thing.
I fell in love with Svelte at v3.
The Svelte 5 rollout feels like a frogmarch. The v3 docs and repls and tutorials are gone, not api versioned. The new docs are bad, IMO, conpared to the clear documentation 3 and 4 had for years, with constant blurring with SvelteKit, which is a server framework, no thanks. The new docs font appears designed to make one cease reading. The new syntax is ugly and verbose and vague, IMO, but admittedly i am having difficulty with the documentation, which may be the real issue. If there were a translation guide from how one does things in Svelte 3 to Svelte 5 it might feel less like learning a new framework. Well, nothing lasts forever.
The v3/v4 docs can be found at https://v4.svelte.dev/
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.
That link should be a bit more prominent, until the community has upgraded. Right now I think it's only at the very end of https://svelte.dev/docs/svelte/legacy-overview and I for sure was not aware of it, cursing the new docs layout when maintaining existing code.
[dead]
I really like svelte 5, personally I find the rune system to be much more explicit about what the code is doing and I prefer that.
I always felt that reading svelte code (prior to svelte 5) required to understand a sort of "magic syntax" very well, which was off putting.
I don't really mind having to declare reactive variables as `$state()`, it makes it very explicit that we want the variable to be reactive. It seems this change has also allowed for a lot more powerful and reusable code so I'm all for it. I guess that people who were already in the ecosystem might have found that they had to learn a lot of new stuff but imo this is very much a case of "might be a bit painful for our current users but it'll make life easier for everyone else in the future".
There's a few things I am a bit conflicted with but it's probably due to myself not really knowing how to solve a determinate problem rather than a problem with the framework itself. It's a bit difficult to get help sometimes.
I've yet to find a problem with React that would justify learning one of those new frameworks. I know it's popular to say React is bad on the internet, but have been using it for 10 years now and it's still going strong in my opinion.
(For some background, I used to code SPAs from scratch with vanilla JS and jQuery in the 2000s, then switched to backbone.js then Angular, before picking up React that solved all the design issues of Angular)
The problems aren't with React itself. The problems are external to React. But, that's a huge problem.
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.
I was trying to learn React shortly after hooks came out. Some in the community claimed you can drop Redux, which totally baffled me. Redux was far simpler.
Then it became “wait just don’t use hooks till we work out the issues.”
> You need to use a separate library for CSS with React
I mean you can just use CSS. Personally I use css modules. Not very buggy or react specific.
> a separate state management library
Yeah I do use tanstack query to manage server state. Does Svelte include something similar out of the box? Otherwise it’s 1) url/query param for app state 2) tanstack query for server state 3) hooks for reusable state or local component state. Not many library bugs with that approach and tbh I’ve never needed something like redux or zustand.
It's only job security if you are fixing another person's bug, otherwise management will rightly ask why you introduced the bug.
Bold of you to assume that management will notice this bug or care if it's something minor on the frontend!
UseEffect(), dependency tracking, too much re-renders??
Problems galore in react, you should try out new js frameworks. Atleast vue and solid, to see what else is on the table
There are definitely problems with react, but I think his point was that they're not big enough to justify a change.
Though I agree trying other frameworks is a good practice. See what you're missing, or understand your preferred framework better.
Every framework has its shortcomings, and React just as much so as any other. Learning other frameworks is always worthwhile. I've done Angular, Vue, React, and am currently looking into Svelte.
https://bower.sh/react-is-bad-because-its-great
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.
Using it as a developer or as a user?
React has kept changing its design approach and best practices every two years - probably to keep the bootcamps always running and churning the change industry.
Why write this comment? All you're doing is showing you don't actually use React? React absolutely does not change paradigm every two years.
Why downvote when this is perfectly known in basic history ? Maybe you only started using React recently ?
Previously,class components were the primary way to manage state and lifecycle methods.
Lifecycle methods like componentDidMount, componentDidUpdate, and componentWillUnmount were heavily used.
Now, functional components with Hooks (useState, useEffect, etc.) are the best practice. There were several iterations of different practices in between.
Previously, props were passed through multiple layers of components (prop drilling was established practice).
Now Context is used. State management, event handlers, component structure, CSS-in-JS: pretty much everything has changed over time.
No - I used React in the past, but no longer use it. Maintenance is a head-ache. I am utterly certain that within the next 2 years, another "life-changing" React paradigm will come into effect - can even bet on it.
Svelte(kit) renewed my love for web development. It gets out of the way when i want it to, is build on web standards so i'm not stuck on annoying "gotchas", and has all the tools I need to build something without pulling in 20 dependencies just to build a basic app.
After being a skeptic of svelte 5, its fully captured me.
I was one of those that really felt like Runes was going to ruin svelte. But after working with it on a small team for a month now, I can see the benefits. We previously had a lot of devs confused with `$:` and other reactive issues. It had always made perfect sense to me but I have to admit, it was a bit magical which was apparently too much for some. With the runes stuff I've seen it click with people in ways it didn't previously. I did like the elegance of the old syntax but I'll take the explicitness of runes if it gets my team on board and causes fewer issues.
I recently started on a frontend project using Svelte, knowing nothing about frontend development. I've found it very easy to use. I had a few failed attempts at this project in the past using React, but I found it quickly overwhelming.
The tutorials on the website are excellent and that was all I needed to get started.
A team I work very closely with as an architect has ditched React in favour of Svelte and the team love it. Everyone prefers it to React and finds it easier and more productive to use.
I love Svelte and v5 is real nice with runes, what an incredible update. It works amazingly well with Elixir Phoenix thanks to live_svelte package.
After years of react, svelte is such a relief. It’s such a joy to do webdev again. Claude’s auto completions in Cursor are often not great though.
I haven't used Claude much personally, but have seen https://svelte-llm.khromov.se/ built to help on that front, do you might want to check it out.
Actually, I forgot that this landed as an official part of the docs now: https://svelte.dev/docs/llms
It might still be a bit big, but PRs welcome if folks want to try slimming it down to just the stuff that's new in Svelte 5.
They're not expected to be with anything too new though It's in the nature of the training, you need many examples to get high quality
Maybe I’m in the minority but I still love me a good ole SSR app with either some vanilla JS or jquery sprinkled on it. Seems to do just fine for my needs but then again, I’m not building highly complex applications. Just a bit of interactivity is all I need, and it suits me just fine without needing any build steps.
SSR only with SvelteKit is a per-page option, right now: https://svelte.dev/docs/kit/page-options#csr
My magic wand wish is that they publish a separate rollup plugin for the rune syntax only, then allow me to write my ui in another jsx based framework
The push of to SSR in Svelte5 has been so off putting. I know CSR is possible but 1) it's not easy, and 2.) practically undocumented
https://svelte.dev/docs/kit/single-page-apps ?
All these frameworks just tell me there is a big problem with the way browsers deliver web apps.
Plus they continue reinventing themselves because that initial design just wasn't good enough.
Not really. Most of these frameworks are just clever attempts at reinventing the wheel. Generally to enable some sort of special syntax/templating system (or force server-side behavior into the client like the React Router abomination).
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."
There is also the Lit approach which really doesn’t have any meaningful misalignments with the underlying web platform primitives and allows people to have the same developer experience without the trade offs.
Ah yes, Web Components. Famous for having exactly zero tradeoffs and excellent dev experience.
I see you haven’t actually used Lit by this comment.
It seems obvious to me the next generation front end frameworks will not use a virtual DOM, which at this point seems antiquated and slow.
Virtual DOM has its charms. React is sort of synonymous with Virtual DOM, but isn't the only way to do Virtual DOM and it's probable other Virtual DOM front ends will continue to be built whether or not React goes away.
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.
It's either VDOM or having to depend on a compiler to do everything (how Svelte works). The advantage to the former is it's relatively easy to debug, whereas with a compiler, I'm at the mercy of its developer and their whims.
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
Lit does not use a virtual DOM, nor require a compile step. Instead, it utilizes object accessors and tagged templates to figure out when to schedule an update.
> It's either VDOM or having to depend on a compiler to do everything (how Svelte works).
Assuming you don't mean JSX transform by "compiler", you really don't have to do either one. For my framework [1], state is directly bound to DOM elements. Dependencies are determined at run time. It's not slow.
[1] https://mutraction.dev/
Dependencies meaning other components or something else?
And if I understand correctly, you're forming relationships between parents/children by setting extra properties on the DOM nodes themselves (e.g., node.mutraction_parent = <Some Other DOM Node>)?
No. Dependency means a state/data dependency that would require a UI update.
You never need to explicitly assign tree relationships like parents. Here's the example code from the front page. In this case, `model.clicks` is a dependency.
Gotcha. Interesting...how does it work? Sounds like a pretty novel way to solve the problem.
Essentially object proxies. When you invoke a property getter in tracked contexts (like DOM element construction), a dependency is registered for that object property. When you invoke the corresponding setter, the update function for the list of dependencies are notified.
That's the idea, in a nutshell.
I'm definitely not the first one to come up with this idea, but I hadn't found another UI framework that worked exactly like how I wanted. Solid is kind of close, but not it. Vue has some of this as well, but it's a bit more kitchen-sink in its scope.
Thanks for sharing, that's a cool idea. Will have to wrap my head around it a bit more but got me thinking about how to strip vdom.
Too barebones for my taste. Small ecosystem. Lots of manual fiddling. Prefer React currently.
I use Svelte when I want static site generation. It's good for that.
I hate that it's all different from v4 to v5.