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

31–40 of 404 posts

Re: Svelte 5: Runes

#32

Post by jamincan »

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

Re: Svelte 5: Runes

#33

Post by timeon »

orangepanda wrote: post #19

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.

> code written in 2018, when hooks first came out, still works today

Does not Svelte from 2018 works today?

Re: Svelte 5: Runes

#34

Post by chrismorgan »

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.

Re: Svelte 5: Runes

#35

Post by klysm »

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.

Re: Svelte 5: Runes

#36

Post by devmor »

tambourine_man wrote: post #27
chrisco255 wrote: post #8

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

I’m still waiting for every other framework to realize that jQuery was right all along. 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’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.

Re: Svelte 5: Runes

#37

Post by supz_k »

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

Re: Svelte 5: Runes

#38

Post by bowsamic »

qudat wrote: post #30
bowsamic wrote: post #21

Earlier quoted context omitted.

I'm not going to miss $, I've found it to be a weirdly documented nightmare...

I originally created 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] = useS…

Yeah 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

Re: Svelte 5: Runes

#39

Post by JoRyGu »

noelwelsh wrote: post #23

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?

Can you clarify what you mean? I'm not sure how you watched/read that and got "type system" out of it.
Post reply on HN