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

321–330 of 404 posts

Re: Svelte 5: Runes

#321

Post by [deleted] »

hajile wrote: post #190
mwcampbell wrote: post #165

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.

[deleted]

Re: Svelte 5: Runes

#322

Post by aradalvand »

4kimov wrote: post #65

Having moved from React to Svelte, it was always a breath of fresh air to write less and have it just work. Feels strange seeing state/props/effect again, almost like I'm back to React.

Svelte 5 is basically a Vue 3 wannaba; except that it has a smaller ecosystem/community, a smaller team, and is less feature-rich. Genius, really. It just lost its #1 selling point and they're talking about it as if it's a good thing.

Re: Svelte 5: Runes

#323

Post by aradalvand »

matthewmueller wrote: post #179

Congrats on the announcement! This seems like an impressive step forward to accommodate larger Svelte apps while making the language simpler. One thing that popped out was that it seems like .js files will also need to be transformed now to accommodate the $ to rune translation. Feature request to make that optional, perhaps something like: import { rune } from "svelte/rune" let $count = rune(0) Oh, one other thing.…

"step forward" lmao

Re: Svelte 5: Runes

#324

Post by aradalvand »

barrongineer wrote: post #181

Svelte has never looked more like Vue to me. I don't mean this as a dig, I think it looks great. It's just even less obvious to me why I might pick it over Vue at this point.

Svelte 5 is just Vue 3 with a smaller ecosystem. That's basically it.

Re: Svelte 5: Runes

#325

Post by dbbk »

tambourine_man wrote: post #223
paavohtl wrote: post #78

Earlier quoted context omitted.

jQuery is not a framework by any definition of the word. It's a collection of largely unnecessary (in modern times) utility functions for imperative DOM manipulation.

Library vs framework is a largely pointless distinction, IMO.

Not really. A framework is something that has opinions about the structure and architecture of your whole application. A library doesn't.

Re: Svelte 5: Runes

#326

Post by recursive »

diob wrote: post #96
satvikpendem wrote: post #52

This is basically what Vue and Solid do, no? Same sort of state and derive/computed variables, it seems like. Also, I will never understand why people like reactive signals. The article even quotes "Knockout being right all along" which, no, reactivity and two way data binding creating a spaghetti mess of changes affecting other changes all over the place unless you're really careful is why React was made in the firs…

Yeah, I have no desire to go back, regardless of "performance" gains. React keeps me sane and it's fairly simple to keep it performant.

I've worked on react codebases, and non-react codebases. Maybe it's a coincidence, but I find the react ones in general to be harder to debug. And not great for my sanity either.

Re: Svelte 5: Runes

#327

Post by recursive »

troupo wrote: post #295
paavohtl wrote: post #78

Earlier quoted context omitted.

jQuery is not a framework by any definition of the word. It's a collection of largely unnecessary (in modern times) utility functions for imperative DOM manipulation.

It's still much easier to manipulate DOM with jQuery than with any of the "modern times" APIs. Hell, even querying the DOM is still easier with jQuery.

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

Re: Svelte 5: Runes

#328

Post by recursive »

chrisco255 wrote: post #80
mgaunard wrote: post #66

Earlier quoted context omitted.

My experience with JavaScript is limited, but knockout is what I use because it's what makes sense.

Knockout is fine to use if your JS doesn't exceed 1000 lines or so. After that, in more complex apps, 2 way data binding becomes an absolute mess of side effects.

I've used knockout in much larger apps than this. I still don't understand what side effects people are talking about when they say this.

I don't love knockout, but I find it easier to debug than react. Mainly because stuff is synchronous, meaning the thing that caused the change is above the problem in the callstack. In react, a lot of stuff goes through an async work scheduler, so the originator of the problem is long gone.

Re: Svelte 5: Runes

#329

Post by truetraveller »

satvikpendem wrote: post #130
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.

React is honestly how I used to write my code in jQuery too, for some pages that had a lot of state. Basically, just like in game dev, I had a render() function that I'd call at the end of the file that would re-render everything. The pattern itself is very easy to understand, re-rendering efficiently is the hard part, but for React users today, that's an implementation detail. Hooks are also very interesting, they'r…

Same here. For complex UIs, I almost always had my own 'render()' function.

Re: Svelte 5: Runes

#330

Post by jgalt212 »

satvikpendem wrote: post #52

This is basically what Vue and Solid do, no? Same sort of state and derive/computed variables, it seems like. Also, I will never understand why people like reactive signals. The article even quotes "Knockout being right all along" which, no, reactivity and two way data binding creating a spaghetti mess of changes affecting other changes all over the place unless you're really careful is why React was made in the firs…

> React will soon get its own compiler as well which will made regenerating the DOM even more efficient.

This will be amazing if works as people are hoping it will. I suspect it's an impossible task (in the general case). My hope is a certain coding style will be the path forward, and not a new version of putting shouldComponentUpdate (and others) all over the place.

Post reply on HN