I'll be the first to mourn the (future) loss of $: but the video clearly shows that the changes are a pretty enticing way to make your code that little bit cleaner, and solve all of the "but Redux!" style questions.
I found `$:` to be extremely confusing, full of weird quirks, and completely turned me off to using svelte for anything more than basic sites.
Runes seem like a clear improvement, but brings Svelte a step closer to React -- which hurts its appeal to me.
The difference between `let counter = $state(0)` and `const [counter, setCounter] = useState(0)` is near its initial value -- zero.
I do love the view library competitive landscape and enjoy seeing different paradigms leveraging reactivity. I also like the compiler optimizations that Svelte is bringing to the entire ecosystem.
The fact that the frameworks are converging on the same idea should suggest that it is necessary complexity in the framework for any sufficiently complex app.
Or that they are too invested to drop features in place of adding more? When this happens, incumbent frameworks appear. Svelte was one but it became just like the old ones before its prime time.
It looks so close to react hooks, that is the first thing that struck me. Of course the syntax is slightly different but functional it is mostly the same. It seems weird that we are definitely converging between the various frameworks. For a while with svelte I though we were diverging but that seems to be changing now.
This might be the impression on first glance because it uses the word "state." But keep reading, and its much more akin to what Solid is doing. In fact, the new docs openly credit the work Solid's team is doing. They also credit Knockout's approach form way back in 2010.
Under the hood it's doing something more similar to solid, but the API exposed is a step in the direction of React (it doesn't expose the signals to the user). It's not quite React either because there's no 'setter', just a different way to opt in to reactivity which also (IIUC) makes it possible in .js/.ts files
For a second, ignore Hooks, Signals and Runes, and look at the way Runes were presented in the video "Introducing Runes.. with Rich Harris". You will find this presentation very similar to but much shorter than "React Today and Tomorrow and 90% Cleaner React With Hooks" video. Both of them talk about:
1. primitives for managing state - $state vs useState
2. removal of lifecycle mechanisms - onMount vs componentDidMount
3. replacing lifecycle mechanisms with new primitives - $effect vs useEffect
It's like the Svelte team took a leaf out of React team's book on how to upgrade a framework - this is evident by the way these features are presented as opt-in like how React marketed Hooks as opt-in. I would go on to predict that the upgrade to Runes will just like the upgrade to Hooks. Developers will use it and then love it - because it presents improvements to the way codebases will be structured and maintained just like React did with Hooks. This is really a Hooks moment for Svelte. Good job Rich and the Svelte team!
This example is a bit strange to me. I wonder if `$effect` will actually replace all usage of `onMount` and `onDestroy` for Svelte. In Solid you could totally do these things with `useEffect` too, but they chose to keep `onMount` and `onDestroy` (which they call `onCleanup`) to make this kind of thing more simple.
`onMount` and `onDestroy` feel like really useful, dependable callbacks. `$effect` is scary because if you add a reference to state in it, you can't depend on it being called like `onMount`.
This looks great. Stores are one of the unexpected pleasures of Svelte and this seems like it will extend them both in terms of power and also grokability
I thought that quote of yours was a sarcastic overview you yourself had written but no, it's an actual quote from the article!
> Like every other framework, we've come to the realisation that Knockout was right all along.
> Svelte 5's reactivity is powered by signals, which are essentially what Knockout was doing in 2010. More recently, signals have been popularised by Solid and adopted by a multitude of other frameworks.
> We're doing things a bit differently though. In Svelte 5, signals are an under-the-hood implementation detail rather than something you interact with directly.
That's a sad development and further makes the framework more complect (as defined by Rich Hickey), with more hidden layers and "magic".
We used to know that, too. We also used to know that entirely event-driven architectures were a level of chaos you shouldn’t invite into your enterprise. Don’t need to look hard to see those either.
Whole industry has been cycles of collective amnesia going back to at least 1975.
[Edit] but in this case what we seem to be doing is having another go at Aspect Oriented Programming, which I was interested in for some time but concluded it, like event-only systems, are a poor fit for the average developer’s mental model, and also a terrible way to encode business requirements. Particularly from a testing perspective. They are usually dabbling at functional core, imperative wrapper architectures, but tend to retain global shared state which is a reliability nightmare waiting to happen.
> I’m still waiting for every other framework to realize that jQuery was right all along.
I find myself feeling this way a lot while writing front-end code.
While I am primarily a back-end developer by trade, I find myself working in Vue or React quite often just to get things done and regularly come to the realization that the majority of the reactivity in the projects I am working on is either unnecessary or so simple that it would be handled with less complexity as a line or two of jQuery.
Thats similar to me as a frontend dev seeing all the backend complexity and thinking it would be easier just to read and write a json file instead of a db + apis.
It works but on longer projects where requirements can explode in complexity it becomes a problem. It really helps to have tools that can stay maintainable.
That comparison works against your point quite well because there are an absolutely incredible amount of backend services built with scalability and sharded postgres dbs with redis caching or what-have-you that would have been perfectly served by a perl script and an sqlite file.
We sometimes have to step back from our high tech bubble. Check out jQuery's usage on the web. The unbeatable juggernaut that React seems from up here clocks at under 5% market share. It's sobering.
Regarding page views, from a quick search, the only top 10 sites that use React are from Meta.
So it’s either a strange distribution curve, with a bump in the neck and a colossal tail, or we’re trapped in a bubble and blinded by our own crazy reality distortion field.
As to number of developers, if a lot more of us are needed to write a tiny fraction of the pages, maybe that’s the symptom right there.
jQuery is not a framework by any definition of the word. It's a collection of largely unnecessary (in modern times) utility functions for imperative DOM manipulation.
You probably haven’t used jQuery beyond the basics. Its API is much more powerful, composable and terse than the native one. We lost a great opportunity to standardize on what everybody was already using.
jQuery: returns an array-like structure that is consistent with the rest of the API whether it's one element returned, no elements are returned, or many elements are returned.
DOM:
- few if any DOM methods work on an array of elements. Or even on a NodeList
- `querySelector`: returns null if not found, Element if found. Throws if there's a selector syntax exception.
So you have to wrap it in a try/catch and in a check against null when you need to use it
- `querySelectorAll`: returns NodeList, Throws if there's a selector syntax exception.
NodeList is not an array. It's so badly designed that even the .forEach method was only added to it two years after the method was introduced.
If you need anything but .forEach, it's better to call Array.from() on the result than deal with iterator shenanigans of it's sparse interface
But sure, "it has 98% and 10% extra", whatever that means.
And that's just two of the methods. Everything else is just as bad: 90s-era verbose imperative object-oriented API.
> If it ever happened, I guess I'd just use a try?
Exactly, you'd "just use a try". Instead of not using it.
> Much of the time "checking for null" consists of adding a single question mark.
Note: this API was introduced way before the `?` was even thought of. Which tells you a lot about the quality of the API.
So. Just for the simple task of selecting elements:
- you have to different APIs for "select 1 element"/"select multiple elements"
- these APIs differ in their behaviour. They can also throw
- almost none of the DOM APIs work with the return values of one of those APIs (e.g. your example stops working the second you use querySelectorAll)
On top of that:
- none of the DOM APIs can be chained, or combined in any meaningful way, so if you want to do more than just call one method, you're up for some very verbose and tedious boilerplate
> You can use qsa all the time if you want a consistent interface.
Indeed. And qsa is so much more verbose.
Note how this whole discussion started with:
- [jQuery] a collection of largely unnecessary (in modern times) utility functions for imperative DOM manipulation
- It's still much easier to manipulate DOM with jQuery than with any of the "modern times" APIs
My last statement is still a fact. "Modern" DOM APIs are anything but. They are the same 90s era OOP that is extremely verbose, cannot be composed in any meaningful way, and provides just a handful of somewhat useful utility functions that don't mean much in a grand scheme of things.
There's a reason that even the most staunch of anti-framework people (like most of the web component crowd) immediately fall back do just dumping strings into DOM via .innerHtml
Knockout is fine to use if your JS doesn't exceed 1000 lines or so. After that, in more complex apps, 2 way data binding becomes an absolute mess of side effects.
I've used knockout in much larger apps than this. I still don't understand what side effects people are talking about when they say this.
I don't love knockout, but I find it easier to debug than react. Mainly because stuff is synchronous, meaning the thing that caused the change is above the problem in the callstack. In react, a lot of stuff goes through an async work scheduler, so the originator of the problem is long gone.
I've built frontends that are much larger than that (and I'm not even a frontend developer) and they all worked fine.
If anything it makes it clear what's going on and when, which is important for the kind of stuff I do which has a lot of interconnected components which are constantly refreshing.
I think Rich clearly demonstrated the pitfalls in today's Svelte and the introduction of runes seemed like a great solution to them. I'm not a Svelte user but this new feature does seem clearer to me when looking at the refactored code than the magic reactivity behind the `$` syntax. Overall a net win in my opinion.
Svelte 3 came out in early 2019, and the framework hasn't really changed much in that time — one thing we can't be accused of is making changes for changes' sake.
But since then, the front end community has discovered valuable new ideas and techniques. Meanwhile, people have encountered the limits of the Svelte 3 approach. Svelte is really good at solving most of the problems you throw at it, but it's not perfect. The changes we announced today are _necessary_.
This makes a lot of sense and will simplify some confusions around reactivity.
I'm guessing runes will make it easier for the compiler to track the reactivity which will enable stuff like automatic partial hydration? Maybe even something like qwik?
I only read the blog post and didn't watch the video... was there any mention on perf and size improvements?
And the output from the compiler is much smaller. You can compare the output on the Svelte 4 REPL to the output on the Svelte 4 REPL. The runtime has grown a bit, but the output overall is still much smaller even when factoring that in
React Hooks has its problems, but it got so many things right from the start - code written in 2018, when hooks first came out, still works today. No need to rewrite everything when a new major release comes out.
That said, svelte5 does solve a lot of problems that stop me from trying it.
jQuery from 2009 also still works today. What I meant was, developers want to use the latest and greatest. Hooks added in 2018 havent changed, there’s no replacement api for them - it’s still modern code.
They got the DX right from the start, that other libraries are still trying to emulate.
that's one thing I admired about the React team back then, they took the time to think about how things "should" work long term. The functional/hooks release was criticised as people liked their class components, but time has shown that hooks were the correct decision.
I feel they lost that as people gradually rotated out of the team, around the time they announced concurrent-mode, now suspense and the half baked RSC "release".
Yeah, I'm pretty skeptical about concurrent mode. People have been trying to implement something like this since ~2010, and I haven't seen it done well yet.
> They got the DX right from the start, that other libraries are still trying to emulate.
The DX isn't "right". It's just the one they are sticking to. There are many issues with the actual developer experience when it comes to hooks in React.
So it's a good thing that other frameworks are iterating and finding new and possibly improved ways of doing things. E.g. neither Svelte nor Solid require dependency arrays to effects or other reactive primitives. Their effects work everywhere, and not just inside component code. You're not beholden to the order and number of effects, unlike with hooks. Etc.
I have a sapper (pre-sveltekit) project from 2019 that doesn't build. I needed to make a tiny update and neither my current computer nor my previously configured netlify autodeploy can produce a build that works. I have no idea, my first guess was that one of the sapper people didn't pin the version of an important dependency, but the project was simple enough that I just wrote a new one from scratch.
I dont use Svelte or react, im sure its lovely and solves real problems. And maybe im just getting old, but over the last 20 years all evidence I have is that "magic" is a trap. Its so strange to me to see such a high profile project leaning into it like this. Youre writing javascript, but the way you must reason about what your code is doing is so different than javascript.
React gets a bad rap because of all the rubbish built around it, but if you do ever want to try the declarative model over vanilla/jQuery, React is actually exactly what you want if you want to avoid compile time magic. The only thing happening at compile time with React is a line-for-line swap from JSX tags:
<foo bar="baz">{boop}</foo>
to a createElement function call:
React.createElement("foo", { bar: "baz" }, ...boop);
Other than that it's entirely Javascript. No templates, computed/derived values or any of that other bullshit. You could probably implement the compile step in like 5 lines of code.
I've built big projects in Vue and find it almost impossible to find a reason to use it. Svelte looks cut from the same cloth. They just fundamentally have the wrong approach.
And you can eschew the JSX syntax entirely with nothing but a small cost to dev ergonomics.
A company I worked at had a O(1 MLoC) React frontend with no JSX at all for a long period of time due to the Typescript compatibility issue, just `export const El = React.createElement`
yes, good point, I shouldnt have evoked react itself, its everything else thats been built on top of it. But yes, Vue is exactly what I mean. Its so difficult to reason about how things work unless you live in it all day every day.
So it's a kind of type system using a kind of Hungarian notation? :Flashbacks to Win32 intensify:
I think a real type system (i.e. compiler checked, rather than relying on falibilities of human programmers) would be a better solution. If Svelte already has a compiler why not implement this as part of it?
Adding annotations (runes) to expressions to describe their properties is basically putting type annotations on expressions. Maybe I missed something, but that what it seemed like to me.
I don't really know them well enough yet but some of these frameworks do seem to be in need of some compiler engineers e.g. with this compile time reactivity for example I was surprised there was no mention of dataflow analysis.
I’m not particularly comfortable with some of the nature of the change. Runes are magic compiler symbols, but they look even more like just normal code than was the case before. Previously, Svelte’s reactivity model was very easy to understand, including its limitations, because it was the result of very simple analysis—you can cover the rules in a few minutes without difficulty. It included some things that were obviously magic: $: reactive blocks and $ prefixes on stores.
When you had this:
let count = 0;
count += 1;
… it made reasonable sense, because that’s just normal JavaScript; the fact that `count` was made reactive was basically incidental.
But once it’s this:
let count = $state(0);
count += 1;
This looks like you’ve called a function named $state, and given that you’re talking about migrating from compile-time to runtime reactivity, you might (I think reasonably) expect `count` then to be some object, not just an integer, and so `+= 1` would be the wrong (since JavaScript doesn’t let you overload those operators). But no, it’s instead some kind of decorator/annotation.
Yes, stores are unwieldy as you scale them up, and definitely have some practical problems, but that createCounter stuff looks fragile. I’m curious how it all works, because it looks like it’d be needing to do quite a lot of control flow analysis, but not curious enough to investigate at this time. But my intuitions suggest it’s probably markedly more complex and difficult to explain, though perhaps and hopefully more consistent.
> it looks like it’d be needing to do quite a lot of control flow analysis
Implementation-wise, this is vastly simpler than Svelte 4, because everything is explicit.
One thing we didn't really show today is how this works in your editor in practice — for example, TypeScript thinks `$state` and `$derived` are just the identity function. It makes sense when you use it, but I appreciate that I'm basically asking you to just trust me on that!
> Previously, Svelte’s reactivity model was very easy to understand, including its limitations, because it was the result of very simple analysis
I totally understand what you're saying. But in fact the analysis is _anything but_ simple — in places it's frighteningly complicated, to the point that even I sometimes don't understand what's going on! And that's part of the problem — because Svelte 4 is more implicit, you can't really know what's happening in a lot of cases, you just have to hope that the compiler knows what it's doing.
Fair enough. I’ll see how things go and wish you well. For simple cases, the new will be syntactically-inferior, but it makes sense that the explicitness allows it to be more consistent. Ah, modelling mutable trees as stores… not a great deal of fun.
> for example, TypeScript thinks `$state` and `$derived` are just the identity function
That seems like a missed opportunity on Svelte’s part… but hard to fault, because TypeScript doesn’t support nominal primitive types very well. Ideally it would be something like Reactive<T> to signal (ha) that it’s not just a plain value.
> TypeScript will 'unwrap' the type anyway, unless you do funky stuff like this […] in which case things like `value += 1` will cause type errors because it coercies `value` from `Reactive<number>` to `number`.
Yeah. I’ve spent more time than I’d like to admit trying to find a nice solution to this, and I’ve ultimately arrived at “it needs type system support to work for the general case”. I think you can make your brand (symbol) optional to address this case, but it doesn’t address this:
> The type of `obj.message` is Reactive<string>, but it's _not_ reactive — it's a non-reactive snapshot of the value when the object was created.
And here is the real problem: the types are right (in this case)! It’s Svelte that is wrong (in that it deviates from the JavaScript language semantics, which TypeScript has correctly modeled).
This leads to my other ultimate conclusion with nominal primitive types: most of the time you’re better off just boxing the value… unless, or until, it becomes problematic for other reasons (eg performance, which would probably be a concern here, albeit one worth testing). Boxing allows correct, refined typing; it makes semantics of the value clear. The only downside is convenience… but this sort of convenience is exactly the kind of thing people rightly judge about the JS ecosystem.
I’m not likely to use Svelte (for a variety of other reasons), so I don’t have a particular dog in this race… but I will say I find more explicit types for signals a great deal nicer to work with. Whether the explicit mechanism is a function call (like Solid) or an accessor (like many others).
With Rust, mutable variables are underlined by RustAnalyzer by default - it would be really useful for reactive variables in Svelte to have a similar distinction.
I've seen the demo and you're right, in cases where the code gets more complex, it does look way cleaner. I also really appreciate that you guys made it so that you can still use Svelte in the same old way.
But at the same time I just wish there was some other solution to this while keeping it implicit somehow. I would do anything to keep things implicit while solving the backend complexity some other way. The thing I most love about Svelte is the principle / vector of "as little learning as possible", as well as in many cases transfer of learning, makes it much more user friendly, and I wish evolutions of Svelte continued to evolve along that direction, by reducing more and more.
But things like `$something` are a bit strange. Even `$:` is strange. It adds cognitive load. It's not very English-like and in turn not easily parseable. `on:click` is closer to the attractor of user friendliness. I think all programming languages and frameworks should try to approach English or Python, to allow for maximum "transfer of learning" so things just feel like they flow "without thought". Taking inspiration from UI/UX... things should be as close as possible to 'understanding at a glance'
Functions can return primitives, so there’s nothing wrong with $state() returning a number that you can +=1.
What is weird is that it’s actually typed as a svelte-compiler-only ‘extended int’ that can have side effects when you increment it, and weird knock on results from reading it.
I don't know svelte, but it seems like every front end framework introduces 'new' reactivity concepts deep into it's lifetime. A lot of them start looking like react hooks too.
"At first glance, this might seem like a step back — perhaps even un-Svelte-like. Isn't it better if let count is reactive by default? Well, no. The reality is that as applications grow in complexity, figuring out which values are reactive and which aren't can get tricky. And the heuristic only works for let declarations at the top level of a component, which can cause confusion. Having code behave one way inside .svelte files and another inside .js can make it hard to refactor code, for example if you need to turn something into a store so that you can use it in multiple places."
This is absolutely true. I have been confused many times figuring out what are reactive states and what are not.
I never knew Svelte needs changes like this, but seeing this, it sounds like a good plan.
it is reactive by default, just if you use $: and the dependent value never updated, it would give undefined, personally i never got this kind of issue XD so I'll stick with old syntax until I really2 need $state/$effect/$derived
So if I’m understanding this, Svelte is moving from reactive by default to declarative reactivity? That does seem like an improvement in signal to noise ratio.
Shared-everything does not scale. It ends in whack-a-mole and an escalating blame game about whether team members are fit to work on the project. It’s bunk. It’s deflecting from the real problem which was dereliction of duty by the “architects” who took a laissez-faire stance on state management instead of providing structure. Worked on a couple of those. Never again.
Practically the whole point of encapsulation is gated access to data, putting constraints on sharing, compressing the possible state space of the system closer to the desired state space.
403 comments
[ 2.8 ms ] story [ 175 ms ] threadSvelte for Apps. Svelte for Sites.
I found `$:` to be extremely confusing, full of weird quirks, and completely turned me off to using svelte for anything more than basic sites.
Runes seem like a clear improvement, but brings Svelte a step closer to React -- which hurts its appeal to me.
The difference between `let counter = $state(0)` and `const [counter, setCounter] = useState(0)` is near its initial value -- zero.
I do love the view library competitive landscape and enjoy seeing different paradigms leveraging reactivity. I also like the compiler optimizations that Svelte is bringing to the entire ecosystem.
I wrote my initial thoughts on sveltekit when I built neovimcraft: https://bower.sh/my-experience-with-svelte-kit
> The magic of Svelte isn't `let count = 0`, it's `count += 1`
That part hasn't changed!
Svelte:
Vue3:1. primitives for managing state - $state vs useState
2. removal of lifecycle mechanisms - onMount vs componentDidMount
3. replacing lifecycle mechanisms with new primitives - $effect vs useEffect
It's like the Svelte team took a leaf out of React team's book on how to upgrade a framework - this is evident by the way these features are presented as opt-in like how React marketed Hooks as opt-in. I would go on to predict that the upgrade to Runes will just like the upgrade to Hooks. Developers will use it and then love it - because it presents improvements to the way codebases will be structured and maintained just like React did with Hooks. This is really a Hooks moment for Svelte. Good job Rich and the Svelte team!
<script> let time = $state(new Date().toLocaleTimeString());
</script><p>Current time: {time}</p>
Example: https://www.solidjs.com/examples/counter
`onMount` and `onDestroy` feel like really useful, dependable callbacks. `$effect` is scary because if you add a reference to state in it, you can't depend on it being called like `onMount`.
They claim most (but not all) of current usage of `onMount` will be better off using `$effect` instead
Nope, nope. Been there, done that, with 2-way data binding and never going back.
> Like every other framework, we've come to the realisation that Knockout was right all along.
> Svelte 5's reactivity is powered by signals, which are essentially what Knockout was doing in 2010. More recently, signals have been popularised by Solid and adopted by a multitude of other frameworks.
> We're doing things a bit differently though. In Svelte 5, signals are an under-the-hood implementation detail rather than something you interact with directly.
That's a sad development and further makes the framework more complect (as defined by Rich Hickey), with more hidden layers and "magic".
We used to know that, too. We also used to know that entirely event-driven architectures were a level of chaos you shouldn’t invite into your enterprise. Don’t need to look hard to see those either.
Whole industry has been cycles of collective amnesia going back to at least 1975.
[Edit] but in this case what we seem to be doing is having another go at Aspect Oriented Programming, which I was interested in for some time but concluded it, like event-only systems, are a poor fit for the average developer’s mental model, and also a terrible way to encode business requirements. Particularly from a testing perspective. They are usually dabbling at functional core, imperative wrapper architectures, but tend to retain global shared state which is a reliability nightmare waiting to happen.
But if these guys are only now reaching Knockout, I still have to wait for them to catch up to Backbone.js, I guess.
I find myself feeling this way a lot while writing front-end code.
While I am primarily a back-end developer by trade, I find myself working in Vue or React quite often just to get things done and regularly come to the realization that the majority of the reactivity in the projects I am working on is either unnecessary or so simple that it would be handled with less complexity as a line or two of jQuery.
It works but on longer projects where requirements can explode in complexity it becomes a problem. It really helps to have tools that can stay maintainable.
Just watch out for that dust, if you sneeze next to a 5 year old Node.js/React project, the whole thing falls apart.
https://w3techs.com/technologies/overview/javascript_library
So it’s either a strange distribution curve, with a bump in the neck and a colossal tail, or we’re trapped in a bubble and blinded by our own crazy reality distortion field.
As to number of developers, if a lot more of us are needed to write a tiny fraction of the pages, maybe that’s the symptom right there.
Hell, even querying the DOM is still easier with jQuery.
DOM:
- few if any DOM methods work on an array of elements. Or even on a NodeList
- `querySelector`: returns null if not found, Element if found. Throws if there's a selector syntax exception.
So you have to wrap it in a try/catch and in a check against null when you need to use it
- `querySelectorAll`: returns NodeList, Throws if there's a selector syntax exception.
NodeList is not an array. It's so badly designed that even the .forEach method was only added to it two years after the method was introduced.
If you need anything but .forEach, it's better to call Array.from() on the result than deal with iterator shenanigans of it's sparse interface
But sure, "it has 98% and 10% extra", whatever that means.
And that's just two of the methods. Everything else is just as bad: 90s-era verbose imperative object-oriented API.
Much of the time "checking for null" consists of adding a single question mark.
Exactly, you'd "just use a try". Instead of not using it.
> Much of the time "checking for null" consists of adding a single question mark.
Note: this API was introduced way before the `?` was even thought of. Which tells you a lot about the quality of the API.
So. Just for the simple task of selecting elements:
- you have to different APIs for "select 1 element"/"select multiple elements"
- these APIs differ in their behaviour. They can also throw
- almost none of the DOM APIs work with the return values of one of those APIs (e.g. your example stops working the second you use querySelectorAll)
On top of that:
- none of the DOM APIs can be chained, or combined in any meaningful way, so if you want to do more than just call one method, you're up for some very verbose and tedious boilerplate
This has happened zero times so far, to me.
You can use qsa all the time if you want a consistent interface. I consider throwing to be a good thing if the input was bad.
For me, none of these things represent a significant enough problem to take on another dependency.
I'm probably doing different things than you. If JQuery solves some of your problems, I'm not trying to convince you to stop using it.
I know you're asking/wishing it was the standard library. I don't even disagree, really.
This has happened more than zero times to me.
> You can use qsa all the time if you want a consistent interface.
Indeed. And qsa is so much more verbose.
Note how this whole discussion started with:
- [jQuery] a collection of largely unnecessary (in modern times) utility functions for imperative DOM manipulation
- It's still much easier to manipulate DOM with jQuery than with any of the "modern times" APIs
My last statement is still a fact. "Modern" DOM APIs are anything but. They are the same 90s era OOP that is extremely verbose, cannot be composed in any meaningful way, and provides just a handful of somewhat useful utility functions that don't mean much in a grand scheme of things.
There's a reason that even the most staunch of anti-framework people (like most of the web component crowd) immediately fall back do just dumping strings into DOM via .innerHtml
I don't love knockout, but I find it easier to debug than react. Mainly because stuff is synchronous, meaning the thing that caused the change is above the problem in the callstack. In react, a lot of stuff goes through an async work scheduler, so the originator of the problem is long gone.
If anything it makes it clear what's going on and when, which is important for the kind of stuff I do which has a lot of interconnected components which are constantly refreshing.
But since then, the front end community has discovered valuable new ideas and techniques. Meanwhile, people have encountered the limits of the Svelte 3 approach. Svelte is really good at solving most of the problems you throw at it, but it's not perfect. The changes we announced today are _necessary_.
If you're not convinced, I encourage you to watch this video, where I talk about why that is: https://www.youtube.com/watch?v=RVnxF3j3N8U
Perhaps, just perhaps it's a good change for a lot of people?
I built two Svelte apps. I liked using Svelte but was a bit annoyed by the aspects these changes are fixing.
The code also seems easier to write and to understand.
My feeling that the Svelte team has taste is strengthened.
I'm guessing runes will make it easier for the compiler to track the reactivity which will enable stuff like automatic partial hydration? Maybe even something like qwik?
I only read the blog post and didn't watch the video... was there any mention on perf and size improvements?
And the output from the compiler is much smaller. You can compare the output on the Svelte 4 REPL to the output on the Svelte 4 REPL. The runtime has grown a bit, but the output overall is still much smaller even when factoring that in
I see it a bit like chess now, there will always be people making progress on a particular opening and variant.
That said, svelte5 does solve a lot of problems that stop me from trying it.
Does not Svelte from 2018 works today?
They got the DX right from the start, that other libraries are still trying to emulate.
I feel they lost that as people gradually rotated out of the team, around the time they announced concurrent-mode, now suspense and the half baked RSC "release".
DX Amaze.
The DX isn't "right". It's just the one they are sticking to. There are many issues with the actual developer experience when it comes to hooks in React.
So it's a good thing that other frameworks are iterating and finding new and possibly improved ways of doing things. E.g. neither Svelte nor Solid require dependency arrays to effects or other reactive primitives. Their effects work everywhere, and not just inside component code. You're not beholden to the order and number of effects, unlike with hooks. Etc.
I've built big projects in Vue and find it almost impossible to find a reason to use it. Svelte looks cut from the same cloth. They just fundamentally have the wrong approach.
A company I worked at had a O(1 MLoC) React frontend with no JSX at all for a long period of time due to the Typescript compatibility issue, just `export const El = React.createElement`
I think a real type system (i.e. compiler checked, rather than relying on falibilities of human programmers) would be a better solution. If Svelte already has a compiler why not implement this as part of it?
When you had this:
… it made reasonable sense, because that’s just normal JavaScript; the fact that `count` was made reactive was basically incidental.But once it’s this:
This looks like you’ve called a function named $state, and given that you’re talking about migrating from compile-time to runtime reactivity, you might (I think reasonably) expect `count` then to be some object, not just an integer, and so `+= 1` would be the wrong (since JavaScript doesn’t let you overload those operators). But no, it’s instead some kind of decorator/annotation.Yes, stores are unwieldy as you scale them up, and definitely have some practical problems, but that createCounter stuff looks fragile. I’m curious how it all works, because it looks like it’d be needing to do quite a lot of control flow analysis, but not curious enough to investigate at this time. But my intuitions suggest it’s probably markedly more complex and difficult to explain, though perhaps and hopefully more consistent.
Implementation-wise, this is vastly simpler than Svelte 4, because everything is explicit.
One thing we didn't really show today is how this works in your editor in practice — for example, TypeScript thinks `$state` and `$derived` are just the identity function. It makes sense when you use it, but I appreciate that I'm basically asking you to just trust me on that!
> Previously, Svelte’s reactivity model was very easy to understand, including its limitations, because it was the result of very simple analysis
I totally understand what you're saying. But in fact the analysis is _anything but_ simple — in places it's frighteningly complicated, to the point that even I sometimes don't understand what's going on! And that's part of the problem — because Svelte 4 is more implicit, you can't really know what's happening in a lot of cases, you just have to hope that the compiler knows what it's doing.
That seems like a missed opportunity on Svelte’s part… but hard to fault, because TypeScript doesn’t support nominal primitive types very well. Ideally it would be something like Reactive<T> to signal (ha) that it’s not just a plain value.
type Reactive<T> = T; function $state<T>(value: T): Reactive<T>
...then TypeScript will 'unwrap' the type anyway, unless you do funky stuff like this...
type Reactive<T> = T & { [uniquesymbol]: any };
...in which case things like `value += 1` will cause type errors because it coercies `value` from `Reactive<number>` to `number`.
But it also creates problems here:
let message = $state('hello'); obj = { message };
The type of `obj.message` is Reactive<string>, but it's _not_ reactive — it's a non-reactive snapshot of the value when the object was created.
It's possible that we can do some fun stuff with TypeScript plugins, but we haven't dived too deeply into it yet.
Yeah. I’ve spent more time than I’d like to admit trying to find a nice solution to this, and I’ve ultimately arrived at “it needs type system support to work for the general case”. I think you can make your brand (symbol) optional to address this case, but it doesn’t address this:
> The type of `obj.message` is Reactive<string>, but it's _not_ reactive — it's a non-reactive snapshot of the value when the object was created.
And here is the real problem: the types are right (in this case)! It’s Svelte that is wrong (in that it deviates from the JavaScript language semantics, which TypeScript has correctly modeled).
This leads to my other ultimate conclusion with nominal primitive types: most of the time you’re better off just boxing the value… unless, or until, it becomes problematic for other reasons (eg performance, which would probably be a concern here, albeit one worth testing). Boxing allows correct, refined typing; it makes semantics of the value clear. The only downside is convenience… but this sort of convenience is exactly the kind of thing people rightly judge about the JS ecosystem.
I’m not likely to use Svelte (for a variety of other reasons), so I don’t have a particular dog in this race… but I will say I find more explicit types for signals a great deal nicer to work with. Whether the explicit mechanism is a function call (like Solid) or an accessor (like many others).
But at the same time I just wish there was some other solution to this while keeping it implicit somehow. I would do anything to keep things implicit while solving the backend complexity some other way. The thing I most love about Svelte is the principle / vector of "as little learning as possible", as well as in many cases transfer of learning, makes it much more user friendly, and I wish evolutions of Svelte continued to evolve along that direction, by reducing more and more.
But things like `$something` are a bit strange. Even `$:` is strange. It adds cognitive load. It's not very English-like and in turn not easily parseable. `on:click` is closer to the attractor of user friendliness. I think all programming languages and frameworks should try to approach English or Python, to allow for maximum "transfer of learning" so things just feel like they flow "without thought". Taking inspiration from UI/UX... things should be as close as possible to 'understanding at a glance'
The gold standard would be to approach something like this level of intuitiveness in the future as crazy as it may seem: https://twitter.com/brianjoseff/status/1617556877218570241 https://twitter.com/mathemagic1an/status/1700232760756207956...
I have many ideas on how, but it would no longer be a programming language.
What is weird is that it’s actually typed as a svelte-compiler-only ‘extended int’ that can have side effects when you increment it, and weird knock on results from reading it.
This is absolutely true. I have been confused many times figuring out what are reactive states and what are not.
I never knew Svelte needs changes like this, but seeing this, it sounds like a good plan.
Or am I missing something important?
Or have I missed something important?
They are too close for the similarities to be a mere coincidence
Shared-everything does not scale. It ends in whack-a-mole and an escalating blame game about whether team members are fit to work on the project. It’s bunk. It’s deflecting from the real problem which was dereliction of duty by the “architects” who took a laissez-faire stance on state management instead of providing structure. Worked on a couple of those. Never again.
Practically the whole point of encapsulation is gated access to data, putting constraints on sharing, compressing the possible state space of the system closer to the desired state space.
I do not like magic in code.