Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

State-based vs Signal-based rendering

jovidecroock.com

Post reply on HN
Print view View original

51–60 of 64 posts

Re: State-based vs Signal-based rendering

#51

Post by rahkiin »

taeric wrote: post #35
GCUMstlyHarmls wrote: post #24

Earlier quoted context omitted.

Can you expand a bit on what you mean? To me (extremely amateur game programmer), that's what, event buses? more explicit state machines?

Just general code organization is all I really mean. Typically an explicit main loop where you go through all of the stuff that the game cares about. With the proliferation of frontend frameworks, you often don't even have an analogue of a main method, anymore. I have similar questions on asset management. But I think that one makes a bit more sense, though? Game studios often have people that are explicitly owners o…

Game engines do not own their main loop anymore either. A lot of host platforms are event based now, including ios, macos, android, web, and to a lesser extend windows. This means you tell the host ‘call this function every X milliseconds’. This also means you do not have full control of a main loop and you get event calls. It is moving more towards event based like in web:) it prevents lockups

Re: State-based vs Signal-based rendering

#52

Post by rudedogg »

kragen wrote: post #50
rudedogg wrote: post #46

Earlier quoted context omitted.

There’s a difference, see https://www.builder.io/blog/signals-vs-observables

Thanks! But what's being described there as "observable" is something other than the Observer pattern that "observable" comes from, which is closer to what it calls "signals". https://en.wikipedia.org/wiki/Observer_pattern

I think they are the same, Observable or Observer pattern both require a manual subscription, and publishing is done through a callback offering the latest in a stream of values.

See https://github.com/tc39/proposal-signals?tab=readme-ov-file#... for more on how signals differ. Mainly no manual bookkeeping and the signal is kind of like a handle, and it allows lazy/computed signals that reference other signals and do the change tracking

Re: State-based vs Signal-based rendering

#53

Post by paweladamczuk »

My mind immediately jumped to the recent Chat Control drama after reading the title.

One way I frame such issues in my mind is that it's about who has control (and how much) over what is rendered and when on the screen I carry in my pocket. To some extent it is now Signal when I use the app. One day it might be my State instead.

Re: State-based vs Signal-based rendering

#54

Post by taeric »

rahkiin wrote: post #51
taeric wrote: post #35

Earlier quoted context omitted.

Just general code organization is all I really mean. Typically an explicit main loop where you go through all of the stuff that the game cares about. With the proliferation of frontend frameworks, you often don't even have an analogue of a main method, anymore. I have similar questions on asset management. But I think that one makes a bit more sense, though? Game studios often have people that are explicitly owners o…

Game engines do not own their main loop anymore either. A lot of host platforms are event based now, including ios, macos, android, web, and to a lesser extend windows. This means you tell the host ‘call this function every X milliseconds’. This also means you do not have full control of a main loop and you get event calls. It is moving more towards event based like in web:) it prevents lockups

But even in that scenario, you have a main function that is called under a deadline, no? You don't necessarily set the heart beat, but you do have a specific method that is called over and over.

That is, yes, I shouldn't have mentioned the "main" method. You don't even necessarily want to own the main loop, if you will. The logic that you do every iteration of the loop, though, is something you will almost certainly see in most games. I don't think I've seen many (any?) applications where you could identify the main loop logic. Is typically spread out over god knows how many locations in the code.

Re: State-based vs Signal-based rendering

#55

Post by alserio »

rivetfasten wrote: post #7
hhthrowaway1230 wrote: post #2

knockout js is that you?

I was about to mention this too. Compare: "import a specific lightweight library and wire together as needed" vs "write the whole app in terms of a bloated framework". I've been out of the frontend game for a while, but what does react give you that knockout and maybe some url management logic do not? I guess components are supposed to standardize modularity, so you can easily import some random widget?

The biggest downside of knockout is that it parses the template from the dom, and the template is rendered as dom until first execution. Then that it eval it's bindings. I suppose tko should help with those issues but seems kinda dead. Knockout reactivity primitives are also a lot more naive then modern signals implementations.

Re: State-based vs Signal-based rendering

#56

Post by alserio »

ptak wrote: post #36
zxspectrumk48 wrote: post #8

This article is completely backwards. We do not want to manually manage what-gets-refreshed-when. The whole point of React was to react to state changes automatically.

Yeah, I'm interested to learn more about signals, but the article seems to miss the whole point of brute-force state updates -- less cognitive complexity.

I can understand the point, and the fact that in virtual dom implementations you in general specify the state -> view mapping and don't need to distinguish between first render and updates. However, practically and personally I find working with signals way simpler, and that is even without considering the debugging experience.

Re: State-based vs Signal-based rendering

#57

Post by alserio »

SebastianKra wrote: post #45
jjj123 wrote: post #13

Earlier quoted context omitted.

I’m confused by your comment. Signals do reduce manual render management. By default, usestate causes unnecessary rerenders which signals avoid (all automatically).

It's not automatic though. Theres function calls() and you must createSignal for every derived value. When you ignore the performance aspect, React has the objectively least amount of boilerplate for reactivity. The question, that I genuinely don't know the answer to, is a) whether the performance improvement is worth it, and b) whether that's still the case after the compiler.

have you tried svelte 3/4?

Re: State-based vs Signal-based rendering

#58

Post by naasking »

kragen wrote: post #49
naasking wrote: post #41

Earlier quoted context omitted.

Original FRP was "behaviours" (continuous time-varying values) and "events" (discrete events, which map to current signals).

Yes, you're right. I think I read some later FRP papers that used the term "signal" instead of "behavior", and I thought that was what you were talking about. FRP "events" are kind of like the kind of signals being discussed here, but there are still big differences.

> FRP "events" are kind of like the kind of signals being discussed here, but there are still big differences.

I don't think the differences are that significant, JS signals are basically `latch(frp-event-stream)`, eg. FRP events yield edge-triggered systems and JS signals yield level-triggered systems, and latches transform edge-triggered to level triggered.

I understand why people can see JS signals as FRP behaviours though, as both have defined values at all times t, but the evaluation model is more like FRP events (push-based reactivity), so I think edge vs. level triggered is the real difference, and these are interconvertible without loss of information.

IIRC, the FRP literature calls both of them "signals" as a general category, just two different types.

Re: State-based vs Signal-based rendering

#59

Post by SebastianKra »

alserio wrote: post #57
SebastianKra wrote: post #45

Earlier quoted context omitted.

It's not automatic though. Theres function calls() and you must createSignal for every derived value. When you ignore the performance aspect, React has the objectively least amount of boilerplate for reactivity. The question, that I genuinely don't know the answer to, is a) whether the performance improvement is worth it, and b) whether that's still the case after the compiler.

have you tried svelte 3/4?

Svelte:

  let doubled = $derived(count * 2);
React:

  const doubled = count * 2

Re: State-based vs Signal-based rendering

#60

Post by codedokode »

Jaxan wrote: post #9
codedokode wrote: post #5

I don't like the style of code in the article, with weird functions like "useState" and "useSignal". Looks ugly to me. Also, it seems that with signals you must use immutable values only. Imagine if you have, let's say, a text document model, and you need to create a new copy every time the user types a letter. That's not going to work fast. And there will be no granular updates, because the signal only tracks the va…

Immutable does not mean you have to copy the whole structure. You can store only the changes. This is how immutable data structures work in functional languages such as Haskell.

I know about different data structures but they are all more complicated than mutable data structures. For example, if you "store only changes", it will take more time to access the data, and you need to flatten your changes once in a while.

Also, for nested data structures you need to either do path copying, or use "modification boxes" [1].

[1] https://en.wikipedia.org/wiki/Persistent_data_structure#Tech...

Post reply on HN