That reactivity line is still useful today. Sometimes you need reactivity, sometimes you don’t. That might help inform conversations about what technology is needed to build a website. Not that I’m eager to spark a debate about what is an “app” and what is a “site”, I do kinda think “reactive to state” is the kind of thing that makes people think “I’m building an app” and then pick other technology that is aligned with that.
Say three components on the page need to know about those current permission levels of the user. They could be nested anywhere on the page. So you keep the state at the “top” of that tree and percolate it down through the forest to the components that need it. That’s the thing: some people hate that. It can be messy, complicated, error prone, and I dunno typey. So Signals says: no problem, set that state up top and pew pew shoot out signals when that state changes and the components that care can listen. Seems like pub/sub to me but I’m no architecture genius.
CodePen is a React app for the most part, and we use Apollo which feels like it has answers for a lot of this. You can use all the native React state you want,
useState and whatnot. Then you’ve got this Apollo Store/Cache which is kind of “at the top” an can be client-only if you want it to be, so you’re querying/mutating that state from wherever you need it. Plus there are reactive variables which seem pretty signal-y to me.
There is a little hot drama here though, as while Preact is basically “lightweight React”, they are the originators of the “Signals are good” side, while React itself seems more like uhmmmmm no. You can read some of the play out in React vs Signals: 10 Years Later in the post and comments. The spirit from React being: “we intentionally didn’t do it this way because thar be dragons.” Others are like “you don’t need it, yo, use this other thing instead.”
I pointed at Preact’s thing as a catalyst, but if you hopped over to that 10 years later post, you’ll see it’s largely about Solid, who Andrea Giammarchi says was first in Signals: the nitty-gritty. I appreciate the attempt here to make this really-pretty-mindbending concept clear:
A signal is “a wrapped value” that automatically subscribes any callback accessing it while it’s executing. As a stretched metaphor, it’s like an object that automatically add listeners reaching itself and dispatches those listeners whenever the wrapped value changes.
If you’re hoping for the chillest possible way to start understanding this stuff, the Syntax fellas talked about it the other week. I found a podcast to be a nice way to let it wash over me, as spinning up an application complex enough to even care about Signals felt like too much effort. It was interesting to hear about how this debate won’t even pop up in, say, Svelte, because it just isn’t needed. Where other big frameworks are more like, well if that’s what the people want.
Perhaps notably, you don’t need a “big” framework, or one that requires any build step or bundling at all, in order to buy some reactivity. I just saw Strawberry the other day and Web Component style with super little code and built-in reactivity actually felt really nice.
Mostly I enjoy the whole drama of it all. “We don’t do this because we were around for The Past” vs. “Times have changed, old timer.” which is literally the same as when React itself came out.