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

341–350 of 404 posts

Re: Svelte 5: Runes

#341

Post by wentin »

EvanYou wrote: post #340

This is (surprisingly) almost identical to the Reactivity Transform explorations we did in Vue: 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 - Take 2, Aug 20…

Hi 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!

Re: Svelte 5: Runes

#342

Post by jakelazaroff »

ttfkam wrote: post #191
kabes wrote: post #115

Earlier quoted context omitted.

You make it sound like react is a dark box with a lot of magic behind the curtains, but I always found the react model very easy to reason about. Modifying state is explicit and is the only thing that can trigger a rerender. These rerenders can only happen down from where in the tree the state change happens.

Let's be honest: the state (see what I did there?) of React state management is a dumpster fire. https://fe-tool.com/awesome-react-state-management That's an article listing the top 18 state management libraries for React. 18?!? React devs can't even agree on a common development model for state, but you think it's explicit and very easy to reason about? Folks don't adopt utility libraries for things that were alread…

> That's an article listing the top 18 state management libraries for React.

> 18?!?

I mean, the top library has more weekly NPM downloads than every other library in the list combined.

> Yes, after it has DIFFED the whole tree to see where the changes occurred in the first place. Madness. Layers of utter madness.

That is not how rendering works in React.

Re: Svelte 5: Runes

#343

Post by recursive »

troupo wrote: post #337
recursive wrote: post #327

Earlier quoted context omitted.

Barely. document.querySelectorAll() has about 98% of the capability, and 10% extra too.

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

I have never heard of a case where I need to care about selector syntax errors. If it ever happened, I guess I'd just use a try?

Much of the time "checking for null" consists of adding a single question mark.

    document.querySelector("div#options")?.setAttribute("hidden", "true");

Re: Svelte 5: Runes

#344

Post by Heechul »

I 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?

Re: Svelte 5: Runes

#345

Post by tipiirai »

EvanYou wrote: post #340

This is (surprisingly) almost identical to the Reactivity Transform explorations we did in Vue: 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 - Take 2, Aug 20…

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

Re: Svelte 5: Runes

#346

Post by onsclom »

nenaoki wrote: post #336
onsclom wrote: post #302

Earlier quoted context omitted.

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

> The easiest way to opt in to runes mode is to just start using them in your code. Opt-in is optional, no?

Whoops, I missed that. Good catch! I'm not sure how tln's problem is happening then.

Re: Svelte 5: Runes

#347

Post by kabes »

softfalcon wrote: post #124
kabes wrote: post #115

Earlier quoted context omitted.

You make it sound like react is a dark box with a lot of magic behind the curtains, but I always found the react model very easy to reason about. Modifying state is explicit and is the only thing that can trigger a rerender. These rerenders can only happen down from where in the tree the state change happens.

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.

Relay tries to solve the problem of: let a component define its (server) data dependencies. It indeed does this with more magic. But it's not exactly the same problem and you can't really fault react for it. It's also a problem other frameworks don't try to solve.

Re: Svelte 5: Runes

#348

Post by MrJohz »

rich_harris wrote: post #310
MrJohz wrote: post #283

Earlier quoted context omitted.

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.

I assume that the Svelte 5 output is smaller because more stuff is being handled internally by signals, rather than the compiled output. Does that mean that the shared "runtime" code is larger, or have you just managed to shrink everything down here?

I'm very impressed by this stuff - I'm still not sold on the implicit reactivity, but I'm really excited about the pressure this is putting on the ecosystem as a whole and where that's going to go.

Re: Svelte 5: Runes

#349

Post by bafe »

satvikpendem wrote: post #289
rmilejczz wrote: post #207

Earlier quoted context omitted.

I’ve written a lot of react apps (first used it in a hackathon in 2014) and this list is really just fluff. hooks + context make all of these libraries pretty much unnecessary for most react apps as they are not that complex I think the more glaring criticism is the lack of any unified component library. The amount of different Button implementations alone is astounding

> hooks + context make all of these libraries pretty much unnecessary for most react apps as they are not that complex To be fair, context is not a state management tool [0], an article by acemarke, the Redux maintainer. It does work as a dependency injection tool and for many people, that's enough, but it's not a true state management tool. [0] https://blog.isquaredsoftware.com/2021/01/context-redux-diff...

React context is is just a way to bridge props deep down a component hierarchy. By combining it with an appropriate hook you can almost obtain the effect of a state manager like redux. There are limits to this however; being just a way to pass props it doesn't give you any fine control over reactivity

Re: Svelte 5: Runes

#350

Post by satvikpendem »

bafe wrote: post #349
satvikpendem wrote: post #289

Earlier quoted context omitted.

> hooks + context make all of these libraries pretty much unnecessary for most react apps as they are not that complex To be fair, context is not a state management tool [0], an article by acemarke, the Redux maintainer. It does work as a dependency injection tool and for many people, that's enough, but it's not a true state management tool. [0] https://blog.isquaredsoftware.com/2021/01/context-redux-diff...

React context is is just a way to bridge props deep down a component hierarchy. By combining it with an appropriate hook you can almost obtain the effect of a state manager like redux. There are limits to this however; being just a way to pass props it doesn't give you any fine control over reactivity

Yes, that is indeed what the article I linked says.
Post reply on HN