Live data from Hacker News

Svelte 5: Runes

svelte.dev

251–260 of 404 posts

Re: Svelte 5: Runes

#251

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?

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

Re: Svelte 5: Runes

#252

What 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 "Increment" "Count: {count}" imba.mount Try this example here: 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 )

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

Re: Svelte 5: Runes

#253
post #176

Earlier quoted context omitted.

> An analogous concept might be quite interesting to implement in all these signal based frameworks as well. Which is what Svelte 5 is doing with its compiler. > […] given a large enough codebase, that sort of spaghetti mess will emerge on its own, as not everyone will be so thorough. LOL! You've just described React projects! Yes, of course you and your team are wonderful and have all the FP experience, so obviously…

Based on your profile and comments, it seems you have some particular grudge against React, so I'm not sure I can convince you of anything React related that you have not already convinced yourself of. Nevertheless, I (nor you, it seems) have not used Svelte 5 yet so I cannot judge, just that based on my, yes, personal experience, 2 way data binding based frameworks create messes. Even though you can shoot yourself i…

I’m not expert in Svelte or React and have been following your conversation. You stress the point that two-way data binding creates mess. I tend to agree since I did my share of desktop programming long time ago. However, I don’t see how React solves the problem fundamentally. When you combine React with Redux or hooks IMHO you get exactly the same thing. The big difference is syntax that makes it easier to reason how view would re-render in response to change. But in a large enough project I can see how this became less and less true as distant modification trigger cascades of model updates/reducers/hooks and result in an unexpected behavior.

Re: Svelte 5: Runes

#254
post #122

Earlier quoted context omitted.

Yes, Vue and Solid — like Knockout — use a dependency tracking mechanism. Back in the day it was called `ko.observable`, nowadays we call them signals. That's the part Knockout was right about. It's absolutely true that you can mishandle them and create a spaghetti mess, _if your design allows it_. Svelte 5 doesn't — it uses signals as an implementation detail, but in a way that prevents the sorts of headaches you're…

Not everyone has teams of perfect developers given all the time they want to make their perfect frontend app. Most of us deal with average teams where half the devs are at or below par while managing very tight deadlines. The spaghetti from everything in the whole system mutating always comes back to bite. You call signals an "implementation detail", but if someone doesn't know that's what they are, then they'll wind…

> Not everyone has teams of perfect developers given all the time they want to make their perfect frontend app.

Yes, but having gone through this at previous companies, the average/non-front end specialist developers definitely had an easier time understanding 2 way binding ala Knockout, MobX, Svelte, etc. The Redux style stuff was only pushed by the frontend brainiac types.

Re: Svelte 5: Runes

#255
post #91
post #6

This looks like it’s moving closer to React Hooks, but using the compile step to optimize them out? Kinda like a better React Forget?

For sure. Look at this Svelte 5 example: let time = $state(new Date().toLocaleTimeString()); $effect(() => { const timer = setInterval(() => { time = new Date().toLocaleTimeString(); }, 1000); return () => clearInterval(timer); }); Current time: {time}

This example is a bit strange to me. I wonder if `$effect` will actually replace all usage of `onMount` and `onDestroy` for Svelte. In Solid you could totally do these things with `useEffect` too, but they chose to keep `onMount` and `onDestroy` (which they call `onCleanup`) to make this kind of thing more simple.

Example: https://www.solidjs.com/examples/counter

`onMount` and `onDestroy` feel like really useful, dependable callbacks. `$effect` is scary because if you add a reference to state in it, you can't depend on it being called like `onMount`.

Re: Svelte 5: Runes

#256
post #176

Earlier quoted context omitted.

> An analogous concept might be quite interesting to implement in all these signal based frameworks as well. Which is what Svelte 5 is doing with its compiler. > […] given a large enough codebase, that sort of spaghetti mess will emerge on its own, as not everyone will be so thorough. LOL! You've just described React projects! Yes, of course you and your team are wonderful and have all the FP experience, so obviously…

Based on your profile and comments, it seems you have some particular grudge against React, so I'm not sure I can convince you of anything React related that you have not already convinced yourself of. Nevertheless, I (nor you, it seems) have not used Svelte 5 yet so I cannot judge, just that based on my, yes, personal experience, 2 way data binding based frameworks create messes. Even though you can shoot yourself i…

[deleted]

Re: Svelte 5: Runes

#257
post #190

Earlier quoted context omitted.

Counterpoint: https://ericwbailey.website/published/modern-health-framewor... Performance does matter to the people who depend on our products. Can we please stop throwing people under the bus in the name of churning out more crap?

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 performance by default, so it's very unlikely you ever have to do this in the first place.

Re: Svelte 5: Runes

#258

Earlier quoted context omitted.

second this, plus its mature ecosystem, which is very valuable for the long term. though, the SSR madness movement including React concerns me, everyone tries to mix CSR and SSR into one now, which makes things way more complex than it needs.

The "ecosystem" is taking vanilla js libraries that work without modification in other frameworks and making them work with react via a wrapper. The react ecosystem is nothing.

React Three Fiber is a good “wrapper” library that proves the ecosystem is far from “nothing”

https://docs.pmnd.rs/react-three-fiber/getting-started/examp...

Re: Svelte 5: Runes

#259
post #199

Earlier quoted context omitted.

> 99.99999% of times it goes great. I'll disagree with you on that. I've seen and used enough 2-way binding in various projects to know that even the best of devs can create tangles of effects everywhere. At some point, you gotta blame the tool for having footguns, which is why Rust was created over C and C++, to solve such footguns. In the same vein, something like that should be made for frontend frameworks too.

But have you used 2-way binding with a more modern framework? Or are you still hanging on to your experience with a defunct framework like Knockout from over a decade ago? And don't get me started on React's "put all the logic you want in our templating language that doesn't even target HTML5" elephant-footgun. Oh! Sorry! Forgot that React's footguns are aKeats elegant and reasonable while everything else's footguns…

> And don't get me started on React's "put all the logic you want in our templating language that doesn't even target HTML5" elephant-footgun.

Sorry, but how is JSX a footgun? I have a lot of issues with React, but JSX doesn't even come close to making the list.

Re: Svelte 5: Runes

#260

Earlier quoted context omitted.

second this, plus its mature ecosystem, which is very valuable for the long term. though, the SSR madness movement including React concerns me, everyone tries to mix CSR and SSR into one now, which makes things way more complex than it needs.

The "ecosystem" is taking vanilla js libraries that work without modification in other frameworks and making them work with react via a wrapper. The react ecosystem is nothing.

I disagree—I regularly find (and use) libraries that are built specifically for React and don't have a vanilla JS analog. As someone who uses Svelte on personal projects, I actually find this really frustrating and wish most of these libraries were just wrappers over some core functionality built without React.
Post reply on HN