Live data from Hacker News

Svelte 5: Runes

svelte.dev

291–300 of 404 posts

Re: Svelte 5: Runes

#291

I see these changes as net positive in the long run. Especially since it sounds like performance is getting a boost as well. The $props rune isn't something I realized I needed, but it definitely clears up code clarity. The $effect runes makes people think we are going down the React useEffect route... but I didn't see a dependency array attached there waiting to obliterate performance? I'm all for removing a tiny pi…

> The $effect runes makes people think we are going down the React useEffect route... but I didn't see a dependency array attached there waiting to obliterate performance?

This is exactly what SolidJS already does, and SolidJS is #1 in almost all performance benchmarks.

Re: Svelte 5: Runes

#292

Perhaps I'm just the grumpy old guy that's afraid of change. But I fell in love with Svelte because it was dead simple (according to me). It was a breeze of fresh air and I felt I just program again without wiring enchantments together. I do agree that its simplicity has downsides too, so perhaps it's just nothing to be afraid of? But I can't help seeing this as ominous: > This is just the beginning though. We have a…

Largely agree. I've got a couple of thousand hours of Svelte dev experience, and these changes offer me nothing I really want. Svelte dependencies outside my .svelte files? No thanks, I'll keep them usable in non-Svelte projects. A new way to do reactivity to try to appeal to React users? ("When people come to our community in future..." in the vid.) No, thanks! Svelte 3/4 reactivity was very straightforward, one cou…

I’m definitely getting some react vibes from this. And I hate react.

Maybe I just need to try it out.

Re: Svelte 5: Runes

#293
post #33

Earlier quoted context omitted.

> code written in 2018, when hooks first came out, still works today Does not Svelte from 2018 works today?

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.

> They got the DX right from the start, that other libraries are still trying to emulate.

The DX isn't "right". It's just the one they are sticking to. There are many issues with the actual developer experience when it comes to hooks in React.

So it's a good thing that other frameworks are iterating and finding new and possibly improved ways of doing things. E.g. neither Svelte nor Solid require dependency arrays to effects or other reactive primitives. Their effects work everywhere, and not just inside component code. You're not beholden to the order and number of effects, unlike with hooks. Etc.

Re: Svelte 5: Runes

#294

Earlier quoted context omitted.

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

I know what react three fiber is and I find the idea of using xml for 3d rendering to be terrible.

Re: Svelte 5: Runes

#295

Earlier quoted context omitted.

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.

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.

Re: Svelte 5: Runes

#296

The whole selling point of Svelte was that it was simple, like a breath of fresh air. You could update the state of your component just by assigning a variable. I guess this is the natural progression of web frameworks.

To be fair, assignments to variables still update the state of your component. `count += 1` will still update the state of your component. I think what you meant is that you now need to explicitly declare `count` as state. Personally, I think the magic of Svelte is that assignment part. And now the magic of Svelte works across files and even inside regular `.ts` and `.js` files!

Re: Svelte 5: Runes

#297

I've been trying Svelte for the last couple of months. At first the claim was that it's not complicated like React because there's a lot less concepts to learn. And it's just using basic Javascript and CSS so those skill sets are transferable to any other job. As I use it more and more, there's more and more special way of doing things I have to learn: store, reactive variable, $, $$, etc. I didn't mind, sure I'm in…

I'd argue that there are way more libraries, since vanilla JS libraries integrate beautifully, unlike in React. Unless you are only talking about component libraries, of course.

Yes, UI component libraries. I just want to leave the UX to the expert and get going on the rest of the application.

Re: Svelte 5: Runes

#299

I dont use Svelte or react, im sure its lovely and solves real problems. And maybe im just getting old, but over the last 20 years all evidence I have is that "magic" is a trap. Its so strange to me to see such a high profile project leaning into it like this. Youre writing javascript, but the way you must reason about what your code is doing is so different than javascript.

React gets a bad rap because of all the rubbish built around it, but if you do ever want to try the declarative model over vanilla/jQuery, React is actually exactly what you want if you want to avoid compile time magic. The only thing happening at compile time with React is a line-for-line swap from JSX tags: {boop} to a createElement function call: React.createElement("foo", { bar: "baz" }, ...boop); Other than that…

Fair points, though React has hugely complex runtime magic. SolidJS's compiler magic is just as simple while also having much a simpler runtime.

Re: Svelte 5: Runes

#300
post #167

As someone who just started Svelte two days ago, my naïve take is that this feels like adding verbosity. 1. Is there no way for the compiler to automatically, recursively find reactive dependencies? 2. Assuming no, is there not a more terse way to decorate reactive expressions?

Instead of finding reactive dependencies at compile time, `$effect` and `$derived` automatically track dependencies at runtime. This might feel like it would result in a performance decrease, but it is what SolidJS has been doing. And SolidJS is #1 in most performance benchmarks!
Post reply on HN