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

391–400 of 404 posts

Re: Svelte 5: Runes

#391

Post by vjerancrnjak »

ramesh31 wrote: post #390
vjerancrnjak wrote: post #385

Earlier quoted context omitted.

Yes, this clarifies what you've meant and I can see the case that is not covered with MobX+React but I assume it is covered by Svelte's runes. You're saying that I can have the whole app written in a single file without any separation and the updates will still happen only in the place that needs it. That makes sense. With MobX, this could be done but not with React and not without a bunch of boilerplate that obtains…

>With MobX, this could be done but not with React and not without a bunch of boilerplate that obtains html elements that are referencing the state. It's trivial with MobX. The Observer component essentially gives you an "inline" component wherever you need reactivity, without the need to actually componentize. i.e using a MobX State Tree store: const store = types.model('Store', { value: types.string }).create({value…

Cool, did not know that, last time I seriously used MobX was on 2016 primitives. But I see it works similarly to before. All of the accesses will be figured out during the first render.

Observer component is so simple. Just a deferred function invoke. Could have been done with 2016 primitives too.

Re: Svelte 5: Runes

#392

Post by diob »

recursive wrote: post #326
diob wrote: post #96

Earlier quoted context omitted.

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.

My experience is it tends to depend on the folks who made the application. Regardless of what framework you chose, they can't save you from yourself in a lot of cases.

Re: Svelte 5: Runes

#393

Post by onsclom »

rich_harris wrote: post #367
onsclom wrote: post #261

Most of this I really love. One thing seems a bit strange though... Let's compare Svelte's and Solid's approach to nested reactivity. Both of them implement the same nested reactivity todo example: Svelte: https://svelte-5-preview.vercel.app/docs/fine-grained-reacti... Solid: https://www.solidjs.com/tutorial/stores_nested_reactivity?so... In Solid, converting something to use nested reactivity is one step. In Svelte,…

FWIW you can of course implement createSignal in four lines of code, if you prefer the ergonomics of that: function createSignal(initial) { let value = $state(initial); return [() => value, (v) => value = $state(v)]; } Note that the Solid change is _not_ 'one step' — the `completed` property is being turned from a property to a function, which means you must update all the usage sites as well. Using getters and sette…

These are great points! Thanks for the super thoughtful reply. I'm actually sold.

1. It's really nice that it's so easy to make a `createSignal`

2. I didn't realize that in Solid you had to update all the usage sites too, so now I'd rather stick to the Svelte usage. Nested reactivity is not as effortless as I thought in Solid.

  get done() { return done },
  set done(value) { done = value },
  get text() { return text },
  set text(value) { text = value }
Looks a bit boilerplate-y maybe, but keeping your preoptimized call sites is totally worth it.

This might be common enough that some syntax sugar might be worth it?

The short hand for:

  todos = [...todos, {
    get done() { return done },
    set done(value) { done = value },
    get text() { return text },
    set text(value) { text = value }
  }];
Could be:

  todos = [...todos, {
    $done,
    $set
  }];

Re: Svelte 5: Runes

#394

Post by troupo »

recursive wrote: post #379
troupo wrote: post #355

Earlier quoted context omitted.

> If it ever happened, I guess I'd just use a try? Exactly, you'd "just use a try". Instead of not using it. > Much of the time "checking for null" consists of adding a single question mark. Note: this API was introduced way before the `?` was even thought of. Which tells you a lot about the quality of the API. So. Just for the simple task of selecting elements: - you have to different APIs for "select 1 element"/"se…

> Exactly, you'd "just use a try". Instead of not using it. This has happened zero times so far, to me. You can use qsa all the time if you want a consistent interface. I consider throwing to be a good thing if the input was bad. For me, none of these things represent a significant enough problem to take on another dependency. I'm probably doing different things than you. If JQuery solves some of your problems, I'm n…

> This has happened zero times so far, to me.

This has happened more than zero times to me.

> You can use qsa all the time if you want a consistent interface.

Indeed. And qsa is so much more verbose.

Note how this whole discussion started with:

- [jQuery] 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

My last statement is still a fact. "Modern" DOM APIs are anything but. They are the same 90s era OOP that is extremely verbose, cannot be composed in any meaningful way, and provides just a handful of somewhat useful utility functions that don't mean much in a grand scheme of things.

There's a reason that even the most staunch of anti-framework people (like most of the web component crowd) immediately fall back do just dumping strings into DOM via .innerHtml

Re: Svelte 5: Runes

#395

Post by avarun »

rmilejczz wrote: post #374
josephg wrote: post #359

Earlier quoted context omitted.

I have a friend who's a car guy. He bought some fancy Mazda that he just adores and he takes to the track sometimes. He's not pearl clutching. He's in love with that car. He keeps it immaculate and he has a sparkle in his eye when he talks about it. Some people are the same with furniture. They buy super expensive, custom stuff and look after it for decades. Not me! All through my 20s I didn't care at all and my vari…

My comment was meant to be a more humorous jab at my own efforts as a software engineer but in re reading I think it came across as rude and I apologize. I think if you feel strongly about something you should defend it!

Was not funny at all FYI. Trotting out overused clichés about how little pride you have in your work is never funny.

Re: Svelte 5: Runes

#396

Post by EvanYou »

wentin wrote: post #384
EvanYou wrote: post #376

Earlier quoted context omitted.

> $state and $ref are quite different. I wouldn't say they are "different" - they are fundamentally the same thing: compiler-enabled reactive variables backed by runtime signals! But yes, Vue already exposes the underlying concept of refs, so for users it's two layers of abstractions. This is something that Svelte doesn't suffer from at this moment, but I suspect you will soon see users reinventing the same primitive…

In Svelte 4, the let counter = 0 syntax is already reactive by default, a feature enabled by the compiler. This has been the status quo for Svelte prior to the rune change. The introduction of the $state(0) rune actually provides more hints about its reactivity than before, and restore the original meaning of let counter = 0 (in rune mode). While it's true that the compiler's "invasion" into JS/TS syntax has been a p…

I’m specifically taking about non-component context, i.e. plain JS/TS files.

Previously Svelte was able to get a pass on this because magic only happens in svelte files - but in the future, any JS/TS files in a rune-enabled Svelte project will technically be SvelteScript, this never happened before and I doubt the community has already “absorbed” how significant this change is.

Re: Svelte 5: Runes

#397

Post by cayter »

Can anyone share how this change would help with your current app/library? Would be great if we get to see how this change leads to real world use case improvement.

Re: Svelte 5: Runes

#398

Post by adantes »

For a large code base, this is a massive step backwards. Open up a Svelte file and try to figure out which, if any of these, are reactive:

  
  let thing_a = createThingA()
  let thing_b = createThingB()
There's no hints from the Svelte language. There's no hints from the tooling. You have to manually open up both of those functions to see what they're doing. For a large code base, they probably just call another layer of utility functions so you that's another level to dig deeper.

And that's on top of plain *.js/*.ts suddenly being hi-jacked. New team members can look at the *.svelte extension and know to go look at Svelte documentation. Why would they think to do that for plain *.js? They already know JavaScript.

Re: Svelte 5: Runes

#399

Post by cjcjcj2 »

adantes wrote: post #398

For a large code base, this is a massive step backwards. Open up a Svelte file and try to figure out which, if any of these, are reactive: let thing_a = createThingA() let thing_b = createThingB() There's no hints from the Svelte language. There's no hints from the tooling. You have to manually open up both of those functions to see what they're doing. For a large code base, they probably just call another layer of u…

[dead]
Post reply on HN