25 ms·
Svelte 5: Runes
- joeldrake 3y agoWhy not just call it signal and computed? (instead of state and derived)
- dagamerish 3y agoAngular right?
- joeldrake 3y agoYes, and Preact. Vue also uses ”computed”, but ”ref” instead if signal. It just strikes me that a lot of frameworks seem to implement the same thing (signals) but use different names for it.
- joeldrake 3y agoAfter reading this from rich_harris: ”Basically, you can only modify state _where it's declared_. If you want to allow the 'outside world' to modify that state, you need to expose a function that does so. This is unlike cases where you're passing around an observable object where anyone with a reference, which they need for reading, can also write to it by doing `thing.value += 1`. This is something Solid gets right — you can only change a signal's value if you have a reference to its setter.” I now realize that this isn’t exactly the same thing as Vues ref of Preacts signal. Maybe its own name is good after all.
- jaeming 3y agoYeah, you know that thing Vue did with the composition API that a bunch of their users didn't like and then subsequently turned to Svelte over? Well, it turns out they were right and we're going to do the same thing.
- EugeneOZ 3y agoSame thing but without magic - Angular Signals. I do not like magic in code.
- high_priest 3y agoSvelte slowly shapeshifting into jquery. Day after day, methodical evolution.
- vore 3y agoApart from the superficial use of the $ sign, what else is jQuery about any of this?
- wirahx 3y agoI'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. Svelte for Apps. Svelte for Sites.
- bowsamic 3y agoI'm not going to miss $, I've found it to be a weirdly documented nightmare...
- qudat 3y agoI originally created https://neovimcraft.com https://neovimcraft.com in Svelte to learn how it works. 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 https://bower.sh/my-experience-with-svelte-kit
- bowsamic 3y agoYeah I gotta agree. No comment on runes but $: was so weird that I was immediately confused at why I would try and use svelte for anything
- rich_harris 3y agoAs we've taken to saying around the virtual Svelte offices: > The magic of Svelte isn't `let count = 0`, it's `count += 1` That part hasn't changed!
- schietegal 3y agoComparisons (Svelte 4 vs. Svelte 5 and other Frameworks): https://component-party-runes.vercel.app/ https://component-party-runes.vercel.app/
- topoftheforts 3y agothank you so much for sharing this site! I've been having a hard time wrapping my head around some Vue2->Vue3 changes and this is very helpful
- bdlowery 3y agoThe vue 3 composition api syntax. Very clean
- bufferoverflow 3y agoIt's a really strange comparison. They didn't even try to be consistent in code formatting. Svelte: <button on:click={nextLight}>Next light</button> Vue3: <button @click="nextLight"> Next light </button>
- ortor 3y agoHey, cool site, but it's down now :(
- dladlk 3y ago[dead]
- epmatsw 3y agoThis looks like it’s moving closer to React Hooks, but using the compile step to optimize them out? Kinda like a better React Forget?
- harrygeez 3y agoI kind of feel the same. React and all the new stuff now feels like unnecessary complexity but they definitely got the initial DX right
- cornfutes 3y agoThe 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.
- meiraleal 3y agoOr 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.
- bhouston 3y agoIt 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.
- pevey 3y agoThis 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.
- 3y ago
- zztop44 3y agoThis 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
- chrisco255 3y ago"Like every other framework, we've come to the realisation that Knockout was right all along." Nope, nope. Been there, done that, with 2-way data binding and never going back.
- deleted 3y ago[deleted]
- capableweb 3y agoI 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".
- deleted 3y ago[deleted]
- hinkley 3y ago> with 2-way data binding and never going back. 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.
- 3y ago
- schnebbau 3y agoThis is what happens when bored developers just have to improve something that doesn't need improving.
- disintegrator 3y agoI 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.
- rich_harris 3y agoSvelte 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_. 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 https://www.youtube.com/watch?v=RVnxF3j3N8U
- pbowyer 3y agoThat's a great - and funny - video. Nicely done!
- danaw 3y agoAlways gotta be someone like you in the crowd eh? Perhaps, just perhaps it's a good change for a lot of people?
- jraph 3y agoI was a bit apprehensive reading the comments here, but reading the presented changes, I'm actually quite happy. 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.
- tootie 3y agoPerl called these sigils. They were incredibly useful and powerful, but the dev community decided that they hated them.
- vore 3y agoApart from the superficial use of the $ sign, what else is Perl about any of this?
- notfed 3y agoParent made no such comparison to perl, but merely observed a lesson learned from perl.
- tambourine_man 3y agoThere’s almost nothing that Perl hasn’t done before and first.
- pier25 3y agoThis 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?
- kevinak 3y agoSmaller and faster :)
- pier25 3y agoCan't wait to see some numbers!
- benmccann 3y agoReactivity is faster now: https://twitter.com/Rich_Harris/status/1688581184018583558 https://twitter.com/Rich_Harris/status/1688581184018583558 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
- karol 3y agoI never expected that in 2023 someone will still be inventing new abstractions in JavaScript. I see it a bit like chess now, there will always be people making progress on a particular opening and variant.
- noelwelsh 3y agoSo 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?
- JoRyGu 3y agoCan you clarify what you mean? I'm not sure how you watched/read that and got "type system" out of it.
- noelwelsh 3y agoAdding 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.
- mhh__ 3y agoI 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.
- orangepanda 3y agoReact 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.
- timeon 3y ago> code written in 2018, when hooks first came out, still works today Does not Svelte from 2018 works today?
- orangepanda 3y agojQuery 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.
- Raed667 3y agothat'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".
- nicoburns 3y agoYeah, 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.
- Rapzid 3y ago> Component re-rendered because hook 16 updated. DX Amaze.
- netcraft 3y agoI 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.
- BigJono 3y agoReact 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.
- akavi 3y agoAnd 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`
- netcraft 3y agoyes, 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.
- onsclom 3y agoFair points, though React has hugely complex runtime magic. SolidJS's compiler magic is just as simple while also having much a simpler runtime.
- amadeuspagel 3y agoExporting functions makes so much sense. Had asked myself why this doesn't work many times.
- yencabulator 3y agoExporting a function from a Svelte component has been a feature at least since Svelte v3, in 2019.
- jamincan 3y agoAs I understand it, this should make it possible to subscribe to non-top-level stores and avoid having to use the horrible hack from svelte-subscribe.
- chrismorgan 3y agoI’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.
- rich_harris 3y ago> 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.
- klysm 3y agoI 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.
- supz_k 3y ago"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.
- kokizzu5 3y agoit 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
- Nezteb 3y agoRunes remind me of Recoil atoms/selectors: https://recoiljs.org/docs/introduction/core-concepts https://recoiljs.org/docs/introduction/core-concepts
- sambeau 3y agoIsn’t this just Qwik? Or am I missing something important?
- chrismorgan 3y agoIt’s nothing like Qwik, nothing at all. Qwik’s key selling point is being what they call resumable. Svelte is not that.
- joeldrake 3y ago[flagged]
- wg0 3y agoThis seems better and makes JS uniform all across but I hope we don't go to the nightmare called hooks. useXXX - please no.
- sambeau 3y agoIsn’t this just qwik? Or have I missed something important?
- deleted 3y ago[deleted]
- rk06 3y agoIt is actually taking inspiration from vue https://vuejs.org/guide/extras/reactivity-transform.html https://vuejs.org/guide/extras/reactivity-transform.html They are too close for the similarities to be a mere coincidence
- hinkley 3y agoSo 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.
- deleted 3y ago[deleted]
- satvikpendem 3y agoThis is basically what Vue and Solid do, no? Same sort of state and derive/computed variables, it seems like. Also, I will never understand why people like reactive signals. The article even quotes "Knockout being right all along" which, no, reactivity and two way data binding creating a spaghetti mess of changes affecting other changes all over the place unless you're really careful is why React was made in the first place, to have only one way data binding and to re-render the entire page in a smart way. React will soon get its own compiler as well which will made regenerating the DOM even more efficient. It's like every other framework is slowly rediscovering why React made the decisions it made. I am assuming it's because the users who are making these frameworks now have not used or do not remember the times where "signals" were called observables, or the usage of Rx libraries, and how having too many of these would cause you to lose your mind debugging the intricate webs you inadvertently spun.
- bhouston 3y ago> It's like every other framework is slowly rediscovering why React made the decisions it made. Definitely there is convergence in DX now. No need for everyone to admit one or another framework was right first or not - that is just creating antagonism or negating people lived experiences and innovation. But I do find it pretty weird that this convergence is happening. Initially I thought it was diverging with svelte but it seems to be reserving direction.
- satvikpendem 3y ago> * But I do find it pretty weird that this convergence is happening. Initially I thought it was diverging with svelte but it seems to be reserving direction.* Convergent evolution [0]. Just as a shark, dolphin, and ichthyosaur all have the same body shape which is efficient for swimming and hunting in the water, so too do technologies converge when the problems are all the same and the solutions are understood, only as humans we can learn from each other rather than randomly mutating our codebases [1]. It's the same reason why we see a lot of languages starting to adopt more functional features such as not using `null` and having exhaustive pattern matching, such as Rust (from OCaml), Dart 3, recent versions of Java, etc. [0] https://en.wikipedia.org/wiki/Convergent_evolution https://en.wikipedia.org/wiki/Convergent_evolution [1] https://en.wikipedia.org/wiki/Genetic_programming https://en.wikipedia.org/wiki/Genetic_programming
- tln 3y agoI recently wrote a game in Svelte 4, and went through a transition from using the <script>/$ reactivity to stores. This looks MUCH nicer to deal with. Their examples seem to be missing some imports? Trying to use $state as shown with svelte@5.0.6 gives "ReferenceError: state is not defined".
- benmccann 3y agoNo, runes like $state do not need to be imported. They're similar to import() that they look similar to functions, but are keywords built into the language.
- onsclom 3y agoMake sure you opt in to use runes! You can do it project wide or per component: https://svelte-5-preview.vercel.app/docs/runes https://svelte-5-preview.vercel.app/docs/runes
- spankalee 3y agoAll these compilers and language forks, man...
- 4kimov 3y agoHaving moved from React to Svelte, it was always a breath of fresh air to write less and have it just work. Feels strange seeing state/props/effect again, almost like I'm back to React.
- aradalvand 3y agoSvelte 5 is basically a Vue 3 wannaba; except that it has a smaller ecosystem/community, a smaller team, and is less feature-rich. Genius, really. It just lost its #1 selling point and they're talking about it as if it's a good thing.
- sbjs 3y ago> 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. People keep re-learning that there's a certain amount of context that needs to be explicit, and you can't just imply everything. Just like when ruby and python made the mistake of getting rid of let/contst/var/etc and programmers said wait no that's a bad idea, now it just makes everyone's job harder, because neither the compiler nor the developer can figure out what context something belongs to.
- notfed 3y agoSomeone with Svelte experience please help me understand: what did "tricky" mean here? Tricky to compile, tricky for readability, tricky to design, what?
- onsclom 3y agoImplicit reactive `let` statements make the code harder to understand for humans AND the compiler. This new explicit state pattern even simplifies designing. Now reactive state can work outside of components and across files as you would expect. It was tricky in all three ways.
- mgaunard 3y agoWeb tech. So much noise about trivial things.
- scop 3y agoHey man, I'm busy making a career here concatenating strings.
- vorbiscuit 3y agoI'm not a website programmer like most people here (I work mostly in C and ARM assembly) so can someone knowledgeable on this topic please explain what is the purpose and background of this? Also, I don't really understand why it's at the top of HN either, is this a groundbreaking change to whatever Svelte is?
- micahbule 3y agojQuery changed the game for frontend web development. Instead of static pages on the browser, interactivity for the client-side proliferated because DX on top of jQuery was way better. Then they started cursing jQuery for its limitations. Then came React -- which again changed the game for frontend web development. Instead of wonky scripts and targetting CSS classes, you get a modular and reactive approach in building the web. Then they started cursing React because of performance issues and implementation complexities. Svelte was designed to behave like React but perform better and reduce the implementation complexities. I had the chance to work with Svelte 1 back then and as a React developer, it would really make you think "Why did React do that?". This is probably on top of HN because people loved Svelte too -- but some followers are now questioning the direction as this change is gravitating towards solutions that React already implemented. As it happens, React did solve a lot of problems for the frontend, and they really nailed it.
- vorbiscuit 3y agoThank you for explaining.
- jussayin 3y agoI'm evaluating Svelte for a project. The previous Svelte syntax governing reactivity is easier to reason about. For what it's worth, I don't understand the new proposal after several readings. I suggest that the Svelte team pause and consider feedback for a year before jumping into a what appears to be a wrong design direction.
- danaw 3y agoHad the opposite experience. It seems intuitive and a step forward making the API clearer. It also eliminates a bunch of potential footguns at the same time.
- emmanueloga_ 3y agoHmmm. Perhaps "intrinsic" would have been ok for this? "a function which a compiler implements directly". In any case, it really seems like mainstream frontend programming has gone too far, and has started parodying itself... Runes... sigh :-p Facebook itself (and FB messenger) are pretty buggy apps that are built on React, so not even the "masters" know how to do React properly, judging by the results... To be honest, I don't know that the whole thing that KnockoutJS started is really necessary. These days I prefer to work with the DOM directly when possible. http://domenlightenment.com/ http://domenlightenment.com/ is a good resource for people wanting to explore how to implement HTML5 applications, going back to the basics.
- handsaway 3y agoI've dabbled with Svelte and find it pleasant to use and I think this is a step in the right direction. The main reason I ultimately keep coming back to React is I find the compile-time alterations to the semantics of my code difficult to reason about. I've spent a lot of time building an intuition for how Javascript code executes and how I can combine its primitives to make reasonable abstractions. The fact that this _looks_ like Javascript but suddenly operates differently is almost more confusing to me than if Svelte was just a non-Javascript language. React's `useState`, `useMemo`, etc. are perhaps more verbose but they're just functions. Dependency arrays are messy but it's fairly easy to extrapolate their behavior from a basic description.
- jasim 3y agoWhat about long arrays? Is there a mechanism where Svelte knows which element is mutated, and do fine-grained recomputation/update only the corresponding view elements? This is the primary place where we have to go outside the framework in React. Only a large linear list has this problem -- if it was a decently balanced component tree, then we could skip updating huge swathes of it by skipping at a top level node. But it is not possible in an array. You have it iterate through each element and do a shallow comparison to see if the references have changed. That said, it is fairly easy to escape to DOM from inside a React component with useRef and the portal pattern. Then we can write vanilla JS which makes updates to only the values it changes. If Svelte solves this in an elegant manner, then it would be a very compelling feature over React. I'm asking here because last I checked, most of the examples in Svelte's documentation pointed to simple counters and regular objects, and I couldn't find an example of a large linear list.
- rich_harris 3y agoYep! https://svelte-5-preview.vercel.app/docs/fine-grained-reactivity https://svelte-5-preview.vercel.app/docs/fine-grained-reacti...
- jasim 3y agoThank you!
- nicoburns 3y agoDid you try setting the `key` property in React?
- jasim 3y ago`key` informs React of the identity of an element. That helps it during the reconciliation phase -- if it knows only one `key` in a list of DOM elements has changed, then it will run the DOM updates only on that one. Similarly if the order has changed, it only needs to move its index in the parent DOM element. But it doesn't help in the rendering phase - aka when the virtual DOM is constructed when `render` is called on the root component, and all our JSX code is executed across the component hierarchy. Virtual DOM reconciliation cost is only a part of the performance penalty, re-running the "view as a function of state" computation is another major chunk.
- mbStavola 3y agoAs a recent adopter of Svelte, these changes are intriguing but I don't really have a grasp of how I feel about it quite yet. One thing that I am definitely happy to see is the removal of $: as it should help Typescript users. Personally, I was quite sick of writing: let input = 'Hello'; // ... let loudInput: string; $: loudInput = `${input)!`; Instead of: let input = 'Hello'; // ... $: loudInput: string = `${input)!`; It's an incredibly minor thing, but when you do it 1000 times it becomes very frustrating. Having reactivity be rune-based should help TS avoid the syntactic confusion, bringing us to: let input = $state('hello'); // ... let loudInput: string = `${input)!`;
- rich_harris 3y agoHaving a great experience with TypeScript was very much one of our goals. Many design ideas failed to clear this hurdle
- aradalvand 3y agoThat specific TS issue has literally been fixed for ages. What version of Svelte were you on?!
- skrebbel 3y agoIf you like this, I recommend you also look into SolidJS, which is basically this idea with less compiler magic and fewer dollar signs (and more JSX). It also comes with a built-in model layer called Stores which is genius in its simplicity. In React land I’ve used Flux, Redux, MobX, mobx-state-tree, zustand and pullstate, and IMO Solid Stores beats them all (because Solid makes this possible, not because those libs are dumb) https://www.solidjs.com/ https://www.solidjs.com/
- satvikpendem 3y agoWhat is different about stores compared to what React offers?
- kabes 3y agoWhy didn't you like mobx then? In the end, it's just implicit signals (where modifying the signal is done by the proxy)
- cornfutes 3y ago> 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 Actually, it was Svelte who coined the term and sold us on the idea of reactivity by default. I don’t think anybody asked for “Reactivity by default”. Svelte advanced this idea, and it helped the framework gain traction. It was easy to get started, and gave Svelte this sense of better ergonomics than other frameworks. I was always skeptical about the performance claims, amortized, and the real selling point of Svelte was ergonomics and the dev experience. The problem with the Node.js ecosystem is the devs are borderline marketing and sales type. They’ll justify, rationalize and make things sound good after the fact. Previously, Svelte was persuading us that Svelte was better than the rest because of reactivity by default. Now they did a literal 180. It’s probably in the right direction, and maybe how things should have been. A related symptom of the Node.js ecosystem is reinventing and rediscovering the wheel. The problem here is a lost of trust. Anything else which Svelte purports it’s got figured out or is more enlightened about should be taken with a grain of salt. So it seems those boring FANG engineers with React has it right all along. They had experiencing building sufficiently complex apps where verbose but explicit code was necessary. > Because the compiler can 'see' where count is referenced, the generated code is highly efficient Yeah, I don’t believe such claims anymore. Sure, in cherry picked and constrained settings, the performance benchmarks might seem good. As much as I hate to admit, I will reach for the production ready and battle tested React, as boring as it is.
- rich_harris 3y agoWe never made any such claim! In fact, the reverse: https://twitter.com/nsthorat/status/1653890181592653825 https://twitter.com/nsthorat/status/1653890181592653825 In Svelte 3, you had to opt in to running code on updates, using things like the `$:` label. It was designed to be conservative about updating components, unlike virtual DOM solutions that like to update everything unless you opt _out_. I too am very sceptical of benchmarks — they can certainly obscure more than they reveal at times. But you don't have to take my word for it, or the benchmark results showing that Svelte 5 is faster than every other framework in existence (https://twitter.com/Rich_Harris/status/1688581184018583558 https://twitter.com/Rich_Harris/status/1688581184018583558) — you just need to understand the different mechanisms in play.
- Dnguyen 3y agoI've been trying Svelte for the last couple of months. At first the claim was that it's not complicated like React because there's a lot less concepts to learn. And it's just using basic Javascript and CSS so those skill sets are transferable to any other job. As I use it more and more, there's more and more special way of doing things I have to learn: store, reactive variable, $, $$, etc. I didn't mind, sure I'm in Svelte's world. But the number of libraries is limited and it really slowed me down tremendously. Now with runes, it's just more "magic" to learn. I think that's the last straw for me. I'm done with Svelte experiment. Back to React land.
- rich_harris 3y agoDid you read the bit about how runes make all those things unnecessary in future?
- orpheansodality 3y agothere are so many comments here that really feel like they didn't read any part of the announcement other than that there's a thing called runes. For me personally I tried svelte in the past and bounced off because there was too much implicitly happening that I needed to have a deep understanding of to model correctly. This solves basically all those problems for me. I thought your video[1] especially did a great job walking through the pros this change brings. Thanks for all your great work on this! 1. Link for the curious: https://www.youtube.com/watch?v=RVnxF3j3N8U&t=6s https://www.youtube.com/watch?v=RVnxF3j3N8U&t=6s
- Dnguyen 3y agoPlease don't get me wrong. You guys are doing great work. And I did notice the hard work you put into runes to make things better. My point is that, it feels like I'm just trading one complexity for another. Like most people, I am constantly searching for ways to do my job better.
- FireInsight 3y agoI'd argue that there are way more libraries, since vanilla JS libraries integrate beautifully, unlike in React. Unless you are only talking about component libraries, of course.
- jzig 3y agoEveryone comparing to React but this looks similar to RxJS Observables as well. Don't leave out us Angular folks!
- bilekas 3y ago> Like every other framework, we've come to the realisation that Knockout was right all along. I never had so much fun and understanding of a UI framework as I did when working with KnowckoutJS and DurandalJS way back when.
- ranting-moth 3y agoPerhaps I'm just the grumpy old guy that's afraid of change. But I fell in love with Svelte because it was dead simple (according to me). It was a breeze of fresh air and I felt I just program again without wiring enchantments together. I do agree that its simplicity has downsides too, so perhaps it's just nothing to be afraid of? But I can't help seeing this as ominous: > This is just the beginning though. We have a long list of ideas for subsequent releases that will make Svelte simpler and more capable. Please don't turn Svelte into a black magic box.
- benmccann 3y agoThis set of changes makes things more explicit. That's the opposite of a black magic box as far as I can see
- pier25 3y agoDefinitely. It's surprising to see all these magic comments. Maybe it's because of using the "runes" word :)
- sanitycheck 3y agoLargely agree. I've got a couple of thousand hours of Svelte dev experience, and these changes offer me nothing I really want. Svelte dependencies outside my .svelte files? No thanks, I'll keep them usable in non-Svelte projects. A new way to do reactivity to try to appeal to React users? ("When people come to our community in future..." in the vid.) No, thanks! Svelte 3/4 reactivity was very straightforward, one could learn the whole thing in a day from the excellent tutorials. It was better than React. There was definitely a bit of weirdness with overuse of reactive vars but that's been incentive to keep components small and simple. A good thing! Personally I'm still stuck on v3 because 4 introduced breaking changes I haven't had a chance to debug, so it'll be a while until any of this impacts me anyway.
- phero_cnstrcts 3y agoI’m definitely getting some react vibes from this. And I hate react. Maybe I just need to try it out.
- bluelightning2k 3y agoI've always respected Rich Harris and the Svelte team. They do an excellent job of some pretty substantial tech. But also the way he/they explain it is so powerful. That includes the blog posts, the videos, the framework itself and the playground. This does seem like a unifying step. Seems like (at least) Svelte and Angular have both declared this model superior to their existing implementations. The video gave credit to prior art in general but would have been better to give the specific projects credit - not just ethically but also to be explicit about what is and is not similar.
- pupppet 3y agoThese updates lean heavily towards how Vue approaches setting reactivity. Is there any slam-dunk case for using Svelte over Vue?
- pimterry 3y agoIt's great to see people moving in this direction, but I'm disappointed that everybody has decided to reimplement basically the same thing independently. Mobx was ahead of the game here (though, granted, it too draws on Knockout.js). You can use Mobx to declaratively describe reactive state, much like this. But it isn't integrated into any framework - you can use it in vanilla JavaScript with no other runtime or compilation required. You define models with Mobx, then on top of that there's mobx-react, which ties your model into React's update APIs (essentially making render() automatically observe values, and making relevant changes trigger a re-render), or there's mobx-vue, or mobx-svelte, or mobx-preact, etc etc. Decoupling this is super helpful - for example I'm using mobx to model raw state, computed state & reactions to changes in server side Node.js, no problem. Meanwhile, recreating the same reactive concepts independently in each library instead makes all the resulting code incompatible, so even your pure JS state models are coupled to your UI framework - e.g. createCounter in this post has to import & use $state from Svelte. That makes it far harder to change frameworks in future, hard to share code between apps using different frameworks (plausibly even different versions of the same framework), etc etc. I'd love to see a native common standard for this, similar to how promises were eventually standarized and suddenly everything had a compatible model for handling async future results (I could swear I've seen initial discussion on exactly that already, but I can't find it anywhere now sadly).
- jauntywundrkind 3y agoIt kind of had to get sent back to the drawing board to work well (avoid all the absurd one-at-a-time limitations of generators), but async-iteration-helpers I think will be an incidental huge help in normalizing/nudging the consumer api into "just an async iterable". Updating/writing state might be more complex, speak to the implementation, but seeing things change should have a semi-standard api. https://github.com/tc39/proposal-async-iterator-helpers https://github.com/tc39/proposal-async-iterator-helpers One huge sadness I have is that when you have a callback in .then or .next, your handler doesn't get a gratis reference to what you were listening to. I'd love to have this be a better record. DOM is so good about having thick events that say what happened, and it's so helpful, sets such a rich base, but js snubbed that path & left passing data in 100% to each event producer to decide as it will. Consumers can craft closures to seal some data into their handlers but it sucks compared to having an extensible data flow system. We're kind of sort of finally fixing this crime the hard way by standardizing async context/async_hooks, which is a whole new ambient way to create context that we can enrich our async events with, since there was no first class object to extend for having omitted passing in the promise to the promise handler. https://github.com/tc39/proposal-async-context https://github.com/tc39/proposal-async-context Also worth pointing out, maybe arguable as a hazard tale, observables was proposed a long long time ago. There's still a ton of adoption. But it also feels extremely similar yet notably apart & worse ergonomics than async iteration. It's imo a good thing it didn't get formalized. https://github.com/tc39/proposal-observable https://github.com/tc39/proposal-observable Alas one reactivity I really wish we had had is object.observe (note: different API than observables), or something like it. Undoing good specification work & saying, 'yeah, if users want it, they can implement it themselves with proxies' has lead to no one doing it. And you can't just observe anything; whomever is the producer has to up front make the decision ahead of time for all consumers, which turned a great capability into something first boutique then quickly forgotten. Alas! https://esdiscuss.org/topic/an-update-on-object-observe https://esdiscuss.org/topic/an-update-on-object-observe I ack your ask, and there's no shortage of options that are pretty damned good. But I feel like we are still in a discovery not deployment phase, still delay competing because we have a lot of terrain and idea space to consider. Before we pick, standardize & ship one.
- viviansolide 3y agoIt's pretty cool to see the direction this framework is taking. It was already easy enough to work on Svelte, but now it's even easier. Especially if you're familiar with a framework like Vue or React. Performance seems to have improved quite a bit too. GG
- gsuuon 3y agoInteresting that signals are coming back hard - Elm had and removed signals due to the learning curve and complexity. With solidjs I pretty immediately ran into the gotchas of signals. I like that reactivity is explicit rather than implicit in svelte 5 - implicit reactivity makes debugging stale views pretty unintuitive.
- rich_harris 3y agoYes. Signals are a wonderful mechanism, but they do come with headaches. Our goal was very much to adopt the elegant reactivity model without all the downsides, and we've approached this by making them an under-the-hood implementation detail that you don't interact with directly.
- yewenjie 3y agoThis is all great stuff but my silly mind was expecting new cool features from Svelte 5, not only DX improvements.
- makingstuffs 3y agoGuess that puts an end to the whole spiel of "You already know Svelte"
- notfed 3y agoAs someone who just started Svelte two days ago, my naïve take is that this feels like adding verbosity. 1. Is there no way for the compiler to automatically, recursively find reactive dependencies? 2. Assuming no, is there not a more terse way to decorate reactive expressions?
- onsclom 3y agoInstead of finding reactive dependencies at compile time, `$effect` and `$derived` automatically track dependencies at runtime. This might feel like it would result in a performance decrease, but it is what SolidJS has been doing. And SolidJS is #1 in most performance benchmarks!
- wikoj1021 3y agoWhat about scoped reactivity? Sometimes you need to react on some of the states not all of them. Right now we are achieving this by passing function with arguments to react on to $: but with $derived and $effect it seems to be not possible because it takes variables from every function passed. Are there any plans how to resolve this? Also nested $effect instead of onMount looks awfull and to be honest is less readable.
- mkishi 3y agoYou can use `untrack` [1] when you don't want to react to some state inside an effect. You can still use `onMount`. It's not deprecated [2], although `$effect` could be used similarly going forward. [1] https://svelte-5-preview.vercel.app/docs/functions#untrack https://svelte-5-preview.vercel.app/docs/functions#untrack [2] https://svelte-5-preview.vercel.app/docs/runes#$effect-what-this-replaces https://svelte-5-preview.vercel.app/docs/runes#$effect-what-...
- wentin 3y agoOne of Svelte's biggest advantages is its compiler, positioning it more as a language than just another JS framework. If I'm not mistaken, the compiler allows Svelte to define its syntax to anything they want. Given this, I'm curious: couldn't the traditional syntax of `let counter = 0` be made to function similarly to the new let count = $state(0);? Transpile it to let count = $state(0) under the hood? If that can work technically, instead of introducing a new rune for reactivity, why not introduce a "negative" rune to denote non-reactive statements? This way, the change wouldn't break existing code; it would be more of a progressive enhancement. I agree the move to unify the Svelte <script> tag with regular js/ts files is an improvement. It was indeed a little odd that certain syntactic sugar, like the $, would work exclusively within the Svelte <script> and not in a js/ts file that's right next to it. However, from what I gather, it seems the Svelte team is aligning the Svelte script more with js/ts, rather than bringing the js/ts closer to Svelte's unique syntax. This trajectory seems to be pushing Svelte towards resembling traditional JavaScript frameworks, like React. It's a departure from Svelte's unique strength of having a custom compiler and behaving more like a language. If every syntax in Svelte is expected to mirror its behavior in js/ts, eventually svelte will lose all it secret sauce that made it so unique. Why can't we add a rune into js/ts file, a note in the beginning to tell svelte compiler that this is svelte enhanced js/ts file, compile it like svelte script tag code? Bring js/ts more alike to svelte?
- deleted 3y ago[deleted]
- rich_harris 3y agoWe evaluated somewhere close to 50 different design ideas (seriously) before settling on this one, and what you describe was one of those ideas. But one of our goals was for you to be able to use Svelte's reactivity inside .js/.ts files, since that's one of the things people have been crying out for since we released Svelte 3. For that to work, reactivity has to be opt-in, not opt-out. And that's how it _should_ be — someone reading the code should be clued into the fact that this `let` won't behave like a normal `let` in JavaScript, and it should be possible to move code between modules (and between modules and components) without worrying about whether a specific file was opted in to certain behaviour. In other words this... > This way, the change wouldn't break existing code ...isn't quite right — it would break _all_ your existing code that wasn't in .svelte files. > If I'm not mistaken, the compiler allows Svelte to define its syntax to anything they want. On this point specifically: unfortunately not. The code in a .ts file, for example, has to be valid and typecheckable. You can't insert a preprocessing step ahead of the TypeScript compiler. Again though we concluded that this is a good thing, since it means this all works with all existing ecosystem tooling.
- matthewmueller 3y agoCongrats on the announcement! This seems like an impressive step forward to accommodate larger Svelte apps while making the language simpler. One thing that popped out was that it seems like .js files will also need to be transformed now to accommodate the $ to rune translation. Feature request to make that optional, perhaps something like: import { rune } from "svelte/rune" let $count = rune(0) Oh, one other thing. Will reactivity apply to nested fields in objects and arrays?
- aradalvand 3y ago"step forward" lmao
- barrongineer 3y agoSvelte has never looked more like Vue to me. I don't mean this as a dig, I think it looks great. It's just even less obvious to me why I might pick it over Vue at this point.
- aradalvand 3y agoSvelte 5 is just Vue 3 with a smaller ecosystem. That's basically it.
- zenbai 3y agoSolid is still the best implementation of fine grained reactivity.
- spencerchubb 3y agoThe whole selling point of Svelte was that it was simple, like a breath of fresh air. You could update the state of your component just by assigning a variable. I guess this is the natural progression of web frameworks.
- onsclom 3y agoTo be fair, assignments to variables still update the state of your component. `count += 1` will still update the state of your component. I think what you meant is that you now need to explicitly declare `count` as state. Personally, I think the magic of Svelte is that assignment part. And now the magic of Svelte works across files and even inside regular `.ts` and `.js` files!
- donpark 3y agoUnless I misunderstood, Svelte 5 'runes' appears to be just 'markers' making explicit what used to be implicit with two noteworthy benefits: - simpler compiler implementation - easier to identify moving parts If so then the intro article needs a rewrite to be simpler without unnecessary districting details.
- corbezzoli 3y ago[flagged]
- trafnar 3y agoWhat I like about Imba is that you can update a variable, and the result in the view/page is updated, without any special syntax. let count = 0 def increment count++ tag App <self> <button @click=increment> "Increment" <div> "Count: {count}" imba.mount <App> Try this example here: https://scrimba.com/scrim/cpbmKzsq https://scrimba.com/scrim/cpbmKzsq (Imba is a compile-to-js language that includes JS/HTML/CSS and a react-like framework all as part of the language. https://www.imba.io https://www.imba.io)
- ilrwbwrkhv 3y agoImba is the only sane framework (and mithril used to be) because it actually uses "events" as the driver of state which makes sense since the web is event driven and allows you to avoid runes, horcruxes and incantations.
- aarpmcgee 3y agoFor me, in both Firefox and Chrome (but not Safari), all the code samples look like this: https://imgur.com/yGXHb1h https://imgur.com/yGXHb1h Anyone know what's going on here?
- crackinmalackin 3y agoI see these changes as net positive in the long run. Especially since it sounds like performance is getting a boost as well. The $props rune isn't something I realized I needed, but it definitely clears up code clarity. The $effect runes makes people think we are going down the React useEffect route... but I didn't see a dependency array attached there waiting to obliterate performance? I'm all for removing a tiny piece of Svelte magic to improve code clarity and performance gains. Seems like a big win to me. Thanks Rich and team!
- onsclom 3y ago> The $effect runes makes people think we are going down the React useEffect route... but I didn't see a dependency array attached there waiting to obliterate performance? This is exactly what SolidJS already does, and SolidJS is #1 in almost all performance benchmarks.
- beders 3y ago> Like every other framework, we've come to the realisation that Knockout was right all along. And we are back full-circle ;)
- toastercat 3y agoI'm cautiously optimistic for this. My first instinct is that it doesn't seem to provide much value add over just sticking with stores, which I think were already thoughtfully designed, but I won't knock it till I've tried it.
- kalpolintrol 3y agotheyre really not mucking about - just a cursory play in the live preview and it promises to solve basically 99% of the weirdness I encounter in my projects. it makes sense that automatic reactivity for any let was always overkill, and the use of $: in complex scenarios got stringy. $state / $derived / $effect seems elegant and I'm sure will make everyday grokking + maintenance easier ("ergonomics"). bigup
- onsclom 3y agoI snooped around Rich's GitHub history and found he's working on esrap[1], a package to convert an AST into code. It uses Bun for development and testing! Crazy theory: esrap will be part of a transpiler that converts Svelte 4 code to Svelte 5 code. I'm not sure if that's actually the case or if it's even technically possible. But it would be really cool! [1] https://github.com/Rich-Harris/esrap https://github.com/Rich-Harris/esrap
- revskill 3y agoWhat you don't get about React is that, in React, the reactivity atom is the component itself, not those state in useState. It's encapsulated if you look from the outside. And what you really care is reactivity at the component level.
- ramesh31 3y agoIf you collect them all, does Douglas Crockford magically appear to grant you three wishes?
- lominming 3y agoObviously there are huge similarities to solid-js and other signals based framework with creating a signal, creating computed/derived, creating effects, etc. Would it be fair to say that Svelte 5 is going to more "runtime reactivity" rather than compiled time?
- deleted 3y ago[deleted]
- ptrwis 3y agoThis is cool, Svelte5 may be the lightest signal-based library. I hope that the old, outdated things mentioned at the end of the article will be finally removed in the future. I like it's API for signals more than in SolidJS returning an array with setter and getter.
- jcuenod 3y agoNow the only thing missing is JSX
- ilrwbwrkhv 3y agoAll of these frameworks like react vue svelte solid are basically the same framework. If you actually want something different and better look at Imba.
- aatd86 3y agoCan you build a $derived from multiple other $derived? If yes, how do you deal with two $derived sharing some dependencies? Will the end result see temporary, half-updated values?
- rich_harris 3y ago> Can you build a $derived from multiple other $derived? Yes > Will the end result see temporary, half-updated values? No. It uses a push-pull mechanism — dependency changes don't result in a re-evaluation until something asks for the value, meaning derivations are 'glitch-free'
- aatd86 3y agoNice! :)
- onsclom 3y agoMost of this I really love. One thing seems a bit strange though... Let's compare Svelte's and Solid's approach to nested reactivity. Both of them implement the same nested reactivity todo example: Svelte: https://svelte-5-preview.vercel.app/docs/fine-grained-reactivity https://svelte-5-preview.vercel.app/docs/fine-grained-reacti... Solid: https://www.solidjs.com/tutorial/stores_nested_reactivity?solved https://www.solidjs.com/tutorial/stores_nested_reactivity?so... In Solid, converting something to use nested reactivity is one step. In Svelte, it is two steps. And that second step is really verbose and annoying: todos = [...todos, { get done() { return done }, set done(value) { done = value }, get text() { return text }, set text(value) { text = value } }]; Solid makes read and write segregation very simple and obvious. You don't need to manually make all these getters and setters. It is nice that runes allows nested reactivity in Svelte, but it feels nicer to use in Solid.
- toastercat 3y agoThis is the biggest weirdness that I hope gets addressed.
- rich_harris 3y agoFWIW you can of course implement createSignal in four lines of code, if you prefer the ergonomics of that: function createSignal(initial) { let value = $state(initial); return [() => value, (v) => value = $state(v)]; } Note that the Solid change is _not_ 'one step' — the `completed` property is being turned from a property to a function, which means you must update all the usage sites as well. Using getters and setters also allows you to use Svelte's convenient `bind:value` approach, which is much less verbose than using the equivalent event handler code. And don't get me started on the [type narrowing issues](https://www.typescriptlang.org/play?#code/C4TwDgpgBA4hzAgJwDwBUB8UC8UAUAlDlmgNwBQokUAyvIqpjvgG4BcUaR2JF5AZgFcAdgGNgASwD2wqKKQQAhohoSA5sMUAbdBjwttgiBy4cA2nATJdAGlr1rmALpQA3uSieoC4IKSyzQmIoAy0jO30Tbix9Q2hcFgInCgBfcnIAegyoAFo89IlhBn5FUWgAVQBnZDcPL00AW2MoSuAkQrVU9NEZVqgzQWqkO2rgKuQXXHklFXVNHXGkKAAfKGFBLS09dy81xSaOAHJ20QALQ-IUgj4JfnxB5EIiHa8sqFOJABMOkLjKqAARhAPsJPlAhGJJDI5NotP8kFJBJJhBAtCA6p43gpKhtgP9ClBFMJhFIQD8qNBkAikJUMXJelItBAAHRaKRqPAAA1OqLZUAAJK4HkhCMzGhAUgBCTnXS5AA https://www.typescriptlang.org/play?#code/C4TwDgpgBA4hzAgJwD...). There's nothing _wrong_ with the Solid approach, but the ergonomics aren't to our liking. If we need to take a hit in terms of verbosity, we'd rather do it once at the declaration site than n times at every usage site.
- jcuenod 3y agoI have a complicated spaghetti object that I need to render. Given: let spaghetti = $state(uglyMess) Does `uglyMess.thingOne[1].anotherThing = { moreMess }` re-render the whole tree or just the children of `uglyMess.thingOne[1].anotherThing`?
- onsclom 3y agoIf you created `anotherThing` as nested state, then just the children! See this for a real example: https://svelte-5-preview.vercel.app/docs/fine-grained-reactivity https://svelte-5-preview.vercel.app/docs/fine-grained-reacti... Here is the same thing in SolidJS with more explanation: https://www.solidjs.com/tutorial/stores_nested_reactivity https://www.solidjs.com/tutorial/stores_nested_reactivity
- jcuenod 3y agoI must say, when I see `$` in js, I think it is going to refer to a DOM element. Maybe the new kids don't have those vestigial jquery instincts, but I dislike the use of $ for non-DOM element things.
- tamimio 3y agoIs this the turning point where svelte start to over engineer stuff and becomes just like other frameworks/libraries? The whole selling point of svelte is simplicity and straightforward implementation, you over complicate it, I will just use something else, popular at least.
- math_dandy 3y agoSeems like Svelte 5 is conceptually simpler and significantly less "clever" than its predecessors. No more playing fast and loose with the semantics of Javascript syntax. It was the hoops Svelte had to go through to provide reactivity that always that always seemed like over-engineering to me.
- michaelsbradley 3y agoIt's amazing how far back all the research and experimentation goes on reactive Web/JS tech, e.g. Brown PLT's work on Flapjax starting back in 2006, even before the JS renaissance kicked off by googl's V8! https://github.com/brownplt/flapjax https://github.com/brownplt/flapjax https://cs.brown.edu/~sk/Publications/Papers/Published/mgbcgbk-flapjax/ https://cs.brown.edu/~sk/Publications/Papers/Published/mgbcg... http://static.cs.brown.edu/research/pubs/theses/ugrad/2007/lmeyerov.pdf http://static.cs.brown.edu/research/pubs/theses/ugrad/2007/l... It might be interesting to do a compare/contrast with v5's Runes and Flapjax's implementations.
- nsonha 3y agoLots of roundabout thinking to eventually reinvent observable
- connectkushal 3y ago[dead]
- meiraleal 3y agoHonestly, quite the over-engineered solution for a problem they were supposed to solve. What does svelte brings to the table with this much complexity? Speed?
- connectkushal 3y ago[dead]
- EvanYou 3y agoThis is (surprisingly) almost identical to the Reactivity Transform explorations we did in Vue: https://vuejs.org/guide/extras/reactivity-transform.html https://vuejs.org/guide/extras/reactivity-transform.html let count = $ref(0) const double = $computed(() => count * 2) watchEffect(() => { console.log(double) }) We started experimenting with this ling of thought almost 3 years ago: - First take (ref sugar), Nov 2020: https://github.com/vuejs/rfcs/pull/228 https://github.com/vuejs/rfcs/pull/228 - Take 2, Aug 2021: https://github.com/vuejs/rfcs/pull/368 https://github.com/vuejs/rfcs/pull/368 - Take 3, Nov 2021: https://github.com/vuejs/rfcs/discussions/369 https://github.com/vuejs/rfcs/discussions/369 We provided it as an experimental feature and had a decent number of users trying it out in production. The feedback wasn't great and eventually decided to drop it. https://github.com/vuejs/rfcs/discussions/369#discussioncomment-5059028 https://github.com/vuejs/rfcs/discussions/369#discussioncomm...
- wentin 3y agoHi Evan You! (Hi from wentin) It's great to see you here in this thread. It's such a wonderful gesture for the open-source community to collaborate in this manner, by sharing valuable lessons learned the hard way. It’s intriguing to see where the Svelte exploration will lead. Will it face disapproval or achieve success? While I agree that both implementations have arrived at the same place (almost serendipitously), their origins differ. For Vue, it's about adding the syntactic sugar by dropping .value, making it less explicit and more magical. In contrast, Svelte made the change to make things more explicit and reduce the “black magicness” from the svelte compiler, and bring it more similar to javascript. This difference might trigger totally different reaction, time will tell. Looking forward to more insightful discussions!
- tipiirai 3y agoI guess we are all waiting for Rich Harris to step in and comment on this one. I'm sure he has followed this Vue experimentation and has a clear argument to make. At least I hope so.
- vjerancrnjak 3y agoAll of this looks like MobX
- Heechul 3y agoI feel weird that runes are being used in `.js` files without explicit imports. This means some `.js` files without runes can still be interpreted independently without being compiled, but some `.js` files with using runes will not (how do I tell my editor to not warn about these runes while still being `.js/.ts` files?) . For components, using `.svelte` instead of something like `.jsx` allowed avoiding this kind of issue. What would be a good solution to this? Would explicit imports fix this issue?
- tipiirai 3y agoThe canvas painting / $effect() demo on the video was super cool! Is the source publicly available somewhere?
- codelikeawolf 3y agoThere's a lot of comments here so I may be asking a question that was already answered, but will the runes be explicitly importable in non-Svelte files? Or does it use an approach similar to testing frameworks like Jest and Vitest where you have access to them as globals? I'm thinking of the implications for TypeScript. I usually opt out of globals and import explicitly when I can.
- machiaweliczny 3y agoDoesn’t it basically another implementation of MobX? Seems like Vue, Signals, Angular 14 all copy this reactive pattern which IMO is simplest to write testable apps. The only drawback with MobX is that’s its upadates are as granular as components but in practice it’s not hard to optimise manually.
- lakomen 3y agoAw man... It's spreading. Soon Svelte will be identical to Vue, React and to a degree Angular. Why bother
- cayter 3y agoCan anyone share how this change would help with your current app/library? Would be great if we get to see how this change leads to real world use case improvement.
- adantes 3y agoFor a large code base, this is a massive step backwards. Open up a Svelte file and try to figure out which, if any of these, are reactive: <script> let thing_a = createThingA() let thing_b = createThingB() </script> There's no hints from the Svelte language. There's no hints from the tooling. You have to manually open up both of those functions to see what they're doing. For a large code base, they probably just call another layer of utility functions so you that's another level to dig deeper. And that's on top of plain *.js/*.ts suddenly being hi-jacked. New team members can look at the *.svelte extension and know to go look at Svelte documentation. Why would they think to do that for plain *.js? They already know JavaScript.
- cjcjcj2 3y ago[dead]