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

151–160 of 404 posts

Re: Svelte 5: Runes

#151

Post by nicoburns »

Raed667 wrote: post #109
orangepanda wrote: post #44

Earlier quoted context omitted.

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…

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.

Re: Svelte 5: Runes

#152

Post by satvikpendem »

hajile wrote: post #140
bhouston wrote: post #60

Earlier quoted context omitted.

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

It's not convergence, it's the cycle of development patterns. Patterns come and go leaving bad memories that become anecdotes. Anecdotes become "misunderstanding the paradigm" and even the misunderstandings are long forgotten when the pattern that made them comes into vogue again.

I wonder if it's due to how new people are to the industry, as well as how new the industry itself is. In disciplines like mechanical or chemical engineering, you don't see nearly this much reinvention of the same patterns. I imagine most people these days using React, Vue, Svelte, or Solid have never even used jQuery or Knockout, as those are almost 15 years or older at this point.

Re: Svelte 5: Runes

#153

Post by rmilejczz »

josephg wrote: post #126
hajile wrote: post #112

Earlier quoted context omitted.

React is the pragmatic answer. Most devs are of average talent and will hang themselves and everyone else with the stateful webs they weave. Even with careful PR reviews, these things have a way of sneaking in and becoming permanent hinderances. Performance hasn't been a dealbreaker in most JS apps for years now. What HAS been a problem is getting good code out the door as fast as business needs. MOST React code is d…

> What HAS been a problem is getting good code out the door as fast as business needs. MOST React code is disposable based on the whims of the company. I know you're right; but this still deeply saddens me. I want well crafted software. I want the code I write and the code I depend on to be made in a way that holds reverence and honor for the craft of software engineering. I don't want to be running crappy, badly per…

I don’t know about you, but I have bills that need paid. I’ll clutch my pearls over something else

Re: Svelte 5: Runes

#154

Post by joeldrake »

joeldrake wrote: post #68

Why not just call it signal and computed? (instead of state and derived)

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

Re: Svelte 5: Runes

#156

Post by gsuuon »

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

Re: Svelte 5: Runes

#157

Post by jauntywundrkind »

pimterry wrote: post #133

It'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 comp…

It 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

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

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

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

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.

Re: Svelte 5: Runes

#158

Post by jasim »

nicoburns wrote: post #146
jasim wrote: post #86

What 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. Bu…

Did you try setting the `key` property in React?

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

Re: Svelte 5: Runes

#159

Post by kokizzu5 »

supz_k wrote: post #37

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

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

Re: Svelte 5: Runes

#160

Post by gabeidx »

pimterry wrote: post #133

It'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 comp…

You may be thinking of the ECMAScript Observable proposal: https://github.com/tc39/proposal-observable
Post reply on HN