Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Svelte 5: Runes

svelte.dev

Post reply on HN
Print view View original

301–310 of 404 posts

Re: Svelte 5: Runes

#301

Post by Dnguyen »

orpheansodality wrote: post #266
rich_harris wrote: post #113

Earlier quoted context omitted.

Did you read the bit about how runes make all those things unnecessary in future?

there 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…

Please 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.

Re: Svelte 5: Runes

#302

Post by onsclom »

tln wrote: post #53

I recently wrote a game in Svelte 4, and went through a transition from using the /$ 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".

Make sure you opt in to use runes!

You can do it project wide or per component: https://svelte-5-preview.vercel.app/docs/runes

Re: Svelte 5: Runes

#303

Post by onsclom »

notfed wrote: post #174
sbjs wrote: post #57

> 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 program…

Someone with Svelte experience please help me understand: what did "tricky" mean here? Tricky to compile, tricky for readability, tricky to design, what?

Implicit 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.

Re: Svelte 5: Runes

#304

Post by toastercat »

onsclom wrote: post #261

Most 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-reacti... Solid: https://www.solidjs.com/tutorial/stores_nested_reactivity?so... In Solid, converting something to use nested reactivity is one step. In Svelte,…

This is the biggest weirdness that I hope gets addressed.

Re: Svelte 5: Runes

#305

Post by lolinder »

berkle4455 wrote: post #209
lolinder wrote: post #77

Earlier quoted context omitted.

Yes, the API is very similar to Vue's. $state is ref/reactive, $derived is computed, $effect is watch/watchEffect. > 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 This last part is why Vue and now Svelte didn't adopt React's model. Yes, reactivity and two-way data binding give you enough rope to thoroughly hang yourself, but it also gives you…

What is the difference between $derived/computed and $effect/watch?

I don't know about in Svelte, but in Vue watch is for taking some sort of action when things change, while computed is meant to return a value.

Re: Svelte 5: Runes

#306

Post by softfalcon »

satvikpendem wrote: post #148
softfalcon wrote: post #132

Earlier quoted context omitted.

I could not agree more. There is a huge push to make both side of the rendering “the same”. Next.js is pushing it really hard for their edge level rehydration. I get it, it gives you flexibility to hydrate the view as close to the user, as late as possible. That sounds cool, but I wonder how many folks really use it and how much you pay for not clearly defining where and when each bit is happening.

As someone who tries to limit their client-side JS usage through uBlock/uMatrix, websites that aren't just blank with JS disabled would be nice to see, which is why I like React Server Components. Of course, if it's a useful enough web app, I'll enable JS, but if someone's writing a blog, ecommerce site, or really any site that may not require a full blown SPA. Sending minimal unneeded JS to the client is best, as it…

I agree with you. It seems wasteful to spending a whole "wait around period" for that to eventually load once the js gets around to it.

I also agree that server components make a lot of sense to solve this problem. It's the obvious optimization (and in some ways, a good re-learning from past wins with PHP, Ruby, etc).

I also still feel we have a long way to go before it becomes elegant and obvious how all this is working. It hasn't become standard in the way that everyone easily groks the concept of how it all works and expects it everywhere on every web stack.

Still waiting to see if we go down another rabbit hole of complexity, or see more cautious and careful improvements towards an easier, more maintainable environment.

Re: Svelte 5: Runes

#307

Post by jddj »

MrJohz wrote: post #283
jddj wrote: post #184

Earlier quoted context omitted.

I'm replying to you, but I'm asking the room: what, if anything, stops vue3 from compiling down to pure JavaScript like svelte does and reaping the speed benefits?

I think the main thing is the existence of alternatives. Svelte is cool, but it has the key flaw that the more Svelte you write, the more compiled code appears - generally, Svelte compiles to a size somewhat larger than the original source file. For Svelte as an "island" tool (i.e. for building islands of interactivity in otherwise static pages, like, say, graphs for the New York Times), that's not a problem, because…

This is exactly what I was looking for, cheers.

Looks like early experiments were called Vue 'vapor'

Re: Svelte 5: Runes

#308

Post by softfalcon »

satvikpendem wrote: post #135
softfalcon wrote: post #124

Earlier quoted context omitted.

I mostly agree with you. Unfortunately, many React apps use Relay (another Meta product) and it opens up a world of “magic” that is sometimes a real pain to reason about.

What do you mean by "many?" While I like Relay, I've almost never seen Relay used in the wild. It's sad as it's quite an elegant concept; just as you define your props for your React component, you define your "props" coming from the server as well, through the GraphQL notation. I've been looking at ways to combine both concepts so that there is no client- or server-side state at all, it's all just state, from a cach…

Maybe it's isolated to me and my work here on this repo:

https://github.com/coralproject/talk

I agree that Relay CAN be simple, but it isn't for what we do. Have a look at this ReplyListContainer and its nested Relay logic. I didn't originally write this, but I can see what they were trying to do and how Relay made it difficult for them. Your thoughts are welcome, I won't judge you for being critical of our code and welcome any other Relay dev's opinions.

https://github.com/coralproject/talk/blob/develop/client/src...

Re: Svelte 5: Runes

#309

Post by james2doyle »

RussianCow wrote: post #257
hajile wrote: post #190

Earlier quoted context omitted.

The real-world performance difference between Svelte and React outside of the tiny benchmark apps isn't very much. The fact that React can prioritize rendering of some things over others means that it can be slower overall, but still feel faster to users.

> The real-world performance difference between Svelte and React outside of the tiny benchmark apps isn't very much. I don't know, IME it's pretty easy to run into bottlenecks with React. To resolve these, you have to spend time optimizing data flow and preventing unnecessary re-renders, and it can be really difficult to trace where an update originally comes from. Svelte and other reactive frameworks give you good p…

I agree with you on this.

I never had to deal with `useMemo` and `useCallback` equivalents in Vue apps. The framework is implemented in such a way that it can let me focus on the task at hand. If I have errors in Vue apps, they are logic errors not "you didn't cater to the framework's rendering model" errors

Re: Svelte 5: Runes

#310

Post by rich_harris »

MrJohz wrote: post #283
jddj wrote: post #184

Earlier quoted context omitted.

I'm replying to you, but I'm asking the room: what, if anything, stops vue3 from compiling down to pure JavaScript like svelte does and reaping the speed benefits?

I think the main thing is the existence of alternatives. Svelte is cool, but it has the key flaw that the more Svelte you write, the more compiled code appears - generally, Svelte compiles to a size somewhat larger than the original source file. For Svelte as an "island" tool (i.e. for building islands of interactivity in otherwise static pages, like, say, graphs for the New York Times), that's not a problem, because…

> the more Svelte you write, the more compiled code appears - generally, Svelte compiles to a size somewhat larger than the original source file.

This is one of those things that's more of a problem in theory than in practice, but nevertheless it's worth mentioning that Svelte 5 output is _much_ smaller than Svelte 4 output.

Post reply on HN