4 ms·

Why do you think this is premature memoization? This is an example, boiled down to a simple function. Do you think people just came up with the use case for thi

Why do you think this is premature memoization? This is an example, boiled down to a simple function. Do you think people just came up with the use case for this without ever having needed it? I think an effort in standardizing signals, a concept that is increasingly used in UI development is a laudable effort. I don't want to get into the nitty gritty about what is too much boilerplate and whether you should build an event system or not, but since signals are something that is used in a variety of frameworks, there might be a good reason to it? And why not make an effort and standardize them over time?

38 3y ago
> I don't want to get into the nitty gritty about what is too much boilerplate and whether you should build an event system or not You're basically saying you want this thing, but you don't want to have to justify it
- shermantanktop 3y ago
  The rationale for it is the fact that multiple frameworks provide their own versions of this mechanism. The proposal is to relocate extremely popular and common functionality from framework space to the language/runtime space. The popularity of React is itself the rationale for the utility of this idea, and any terse version of the rationale is for show. Is that a good enough rationale? Maybe, maybe not, but you are shooting the messenger.
  - refulgentis 3y ago
    Most importantly: OP is right re: vanilla example is most legible. Reading the proposal, I have no idea what this "Signal" word adds other than complexity. Less important: I really, really, really, really, am reluctant to consider that is something that needs standardizing. Disclaimer: I don't have 100% context if this concept is _really_ the same across all these frameworks. But frankly, I doubt it, if it was that similar, why are there at least a dozen frameworks with their own version?* Also, I've lived through React, Redux, effects, and so on becoming Fundamentally Necessary, until they're not. Usually when it actually is fundamental you can smell it outside of JS as well. (ex. promises <=> futures). I've seen 1000 Rx frameworks come into style and go out of style, from JS to Objective-C to Kotlin to Dart. Let them live vibrant lives, don't tie them to the browser. * I know that's begging the question, put more complex: if they are that similar and that set in stone that its at a good point to codify, why are there enough differences between them to enable a dozen different frameworks that are actively used?
    - catlifeonmars 3y ago
      > But frankly, I doubt it, if it was that similar, why are there at least a dozen frameworks with their own version?* Welcome to the fashion cycle that is JavaScript. Given a few years, every old concept gets reinvented and then you have half a dozen frameworks that are basically the same but sufficiently different so that you have to relearn the APIs. This is what I think standardization helps circumvent A good standard library prevents fragmentation on ideas that are good enough to keep getting reinvented
    - eyelidlessness 3y ago
      > Disclaimer: I don't have 100% context if this concept is _really_ the same across all these frameworks. Very nearly[1] every current framework now has a similar concept, all with the same general foundation: some unit of atomic state, some mechanism to subscribe to its state changes by reading it in a tracking context, and some internal logic to notify those subscriptions when the state is written. They all have a varied set of related abstractions that build upon those fundamental concepts, which… > But frankly, I doubt it, if it was that similar, why are there at least a dozen frameworks with their own version?* … is part of what distinguishes each such framework. Another part is that state management and derived computations are only part of what any of the frameworks do. They all have, beyond their diverse set of complementary reactive abstractions, also their own varied takes on templating, rendering models, data fetching, routing, composition, integration with other tools and systems. Moreover, this foundational similarity between the frameworks is relatively recent. It’s a convergence around a successful set of basic abstractions which in many ways comes from each framework learning from the others. And that convergence is so pervasive that it’s motivating the standardization effort. This especially stands out because the reference polyfill is derived from Angular’s implementation, which only very recently embraced the concept. From reading the PR notes, the implementation has only minor changes to satisfy the proposed spec. That’s because Angular’s own implementation, being so recent, internalizes many lessons learned from prior art which also inform the thinking behind the spec itself. This is very much like the analogy to Promises, which saw a similar sea change in convergence around a set of basic foundational concepts after years of competing approaches eventually drifting in that same direction. [1]: Most notably, React is unique in that it has largely avoided signals while many frameworks inspired by it have gravitated towards them.
spacechild1 3y ago
> a concept that is increasingly used in UI development For a desktop app developer that's a pretty funny statement, given that the Qt framework introduced signals and slots in the mid 90s. I am curious how many web devs think that signals are a new concept. (I don't necessarily mean the parent poster.)
- MzHN 3y ago
  This is an interesting topic so I tried to dive in a bit. From my reading I understood that Qt signals & slots (and Qt events) are much more closely related to JavaScript events (native and custom). In both you can explicitly emit, handle, listen to events/signals. JavaScript events seem to combine both Qt signals & slots and Qt events. Of course without the type safety. For example, taken from https://doc.qt.io/qt-6/signalsandslots.html https://doc.qt.io/qt-6/signalsandslots.html "Signals are emitted by objects when they change their state in a way that may be interesting to other objects." However what I think they are proposing in the article is a much more complex abstraction: they want to automate it so that whenever any part of a complex graph of states changes, every piece of code depending on that specific state gets notified, without the programmer explicitly writing code to notify other pieces of code, or doing connect() or addEventListener() etc. What are your thoughts on that? I'd be interested to hear since I'm sure you have more experience than me.
  - spacechild1 3y ago
    This sounds interesting. The code examples reminded me of Qt signals but all the answers to my post suggest that JS signals would be much more powerful. Honestly, I'd need to take a closer look.
    - naasking 3y ago
      JS signals come from functional reactive programming, which is a generalization of synchronous reactive programming from the Lustre and Esterel programming languages from the 80s and 90s. I believe the first version was FrTime published in 2004. You can think of reactive signals as combining an underlying event system with value construction, ultimately defining an object graph that updates itself whenever any of the parameters used to construct it change. You can think of this graph like an electronic circuit with multiple inputs and outputs, and like a circuit, the outputs update whenever inputs change.
flohofwoe 3y ago
> ...but since signals are something that is used in a variety of frameworks... ...common usage is not really a justification for putting it into the language standard though. Glancing over the readme I'm not seeing anything that would require changes to the language syntax and can't be implemented in a regular 3rd-party library. In a couple of years, another fancy technique will make the rounds and make signals look stupid, and then we are left with more legacy baggage in the language that can't be removed because of backwards compatibility (let C++ be a warning).
- Zababa 3y ago
  From what I understand, a few/many of the big frameworks are converging on signals, and another commenter said that Qt had signals in the 90s https://news.ycombinator.com/item?id=39891883 https://news.ycombinator.com/item?id=39891883. I understand your worries, and I would appreciate some wisdom from non-JS UI people, espcially if they have 20+ years of experience with them.
  - Offler 3y ago
    Every framework is moving to signals, apart from React and I'd say if this became a standard even they will. This is like Promise. It's a sensible shared concept.

38 3y ago

> I don't want to get into the nitty gritty about what is too much boilerplate and whether you should build an event system or not You're basically saying you want this thing, but you don't want to have to justify it

shermantanktop 3y ago
The rationale for it is the fact that multiple frameworks provide their own versions of this mechanism. The proposal is to relocate extremely popular and common functionality from framework space to the language/runtime space. The popularity of React is itself the rationale for the utility of this idea, and any terse version of the rationale is for show. Is that a good enough rationale? Maybe, maybe not, but you are shooting the messenger.
- refulgentis 3y ago
  Most importantly: OP is right re: vanilla example is most legible. Reading the proposal, I have no idea what this "Signal" word adds other than complexity. Less important: I really, really, really, really, am reluctant to consider that is something that needs standardizing. Disclaimer: I don't have 100% context if this concept is _really_ the same across all these frameworks. But frankly, I doubt it, if it was that similar, why are there at least a dozen frameworks with their own version?* Also, I've lived through React, Redux, effects, and so on becoming Fundamentally Necessary, until they're not. Usually when it actually is fundamental you can smell it outside of JS as well. (ex. promises <=> futures). I've seen 1000 Rx frameworks come into style and go out of style, from JS to Objective-C to Kotlin to Dart. Let them live vibrant lives, don't tie them to the browser. * I know that's begging the question, put more complex: if they are that similar and that set in stone that its at a good point to codify, why are there enough differences between them to enable a dozen different frameworks that are actively used?
  - catlifeonmars 3y ago
    > But frankly, I doubt it, if it was that similar, why are there at least a dozen frameworks with their own version?* Welcome to the fashion cycle that is JavaScript. Given a few years, every old concept gets reinvented and then you have half a dozen frameworks that are basically the same but sufficiently different so that you have to relearn the APIs. This is what I think standardization helps circumvent A good standard library prevents fragmentation on ideas that are good enough to keep getting reinvented
  - eyelidlessness 3y ago
    > Disclaimer: I don't have 100% context if this concept is _really_ the same across all these frameworks. Very nearly[1] every current framework now has a similar concept, all with the same general foundation: some unit of atomic state, some mechanism to subscribe to its state changes by reading it in a tracking context, and some internal logic to notify those subscriptions when the state is written. They all have a varied set of related abstractions that build upon those fundamental concepts, which… > But frankly, I doubt it, if it was that similar, why are there at least a dozen frameworks with their own version?* … is part of what distinguishes each such framework. Another part is that state management and derived computations are only part of what any of the frameworks do. They all have, beyond their diverse set of complementary reactive abstractions, also their own varied takes on templating, rendering models, data fetching, routing, composition, integration with other tools and systems. Moreover, this foundational similarity between the frameworks is relatively recent. It’s a convergence around a successful set of basic abstractions which in many ways comes from each framework learning from the others. And that convergence is so pervasive that it’s motivating the standardization effort. This especially stands out because the reference polyfill is derived from Angular’s implementation, which only very recently embraced the concept. From reading the PR notes, the implementation has only minor changes to satisfy the proposed spec. That’s because Angular’s own implementation, being so recent, internalizes many lessons learned from prior art which also inform the thinking behind the spec itself. This is very much like the analogy to Promises, which saw a similar sea change in convergence around a set of basic foundational concepts after years of competing approaches eventually drifting in that same direction. [1]: Most notably, React is unique in that it has largely avoided signals while many frameworks inspired by it have gravitated towards them.

spacechild1 3y ago

> a concept that is increasingly used in UI development For a desktop app developer that's a pretty funny statement, given that the Qt framework introduced signals and slots in the mid 90s. I am curious how many web devs think that signals are a new concept. (I don't necessarily mean the parent poster.)

MzHN 3y ago
This is an interesting topic so I tried to dive in a bit. From my reading I understood that Qt signals & slots (and Qt events) are much more closely related to JavaScript events (native and custom). In both you can explicitly emit, handle, listen to events/signals. JavaScript events seem to combine both Qt signals & slots and Qt events. Of course without the type safety. For example, taken from https://doc.qt.io/qt-6/signalsandslots.html https://doc.qt.io/qt-6/signalsandslots.html "Signals are emitted by objects when they change their state in a way that may be interesting to other objects." However what I think they are proposing in the article is a much more complex abstraction: they want to automate it so that whenever any part of a complex graph of states changes, every piece of code depending on that specific state gets notified, without the programmer explicitly writing code to notify other pieces of code, or doing connect() or addEventListener() etc. What are your thoughts on that? I'd be interested to hear since I'm sure you have more experience than me.
- spacechild1 3y ago
  This sounds interesting. The code examples reminded me of Qt signals but all the answers to my post suggest that JS signals would be much more powerful. Honestly, I'd need to take a closer look.
  - naasking 3y ago
    JS signals come from functional reactive programming, which is a generalization of synchronous reactive programming from the Lustre and Esterel programming languages from the 80s and 90s. I believe the first version was FrTime published in 2004. You can think of reactive signals as combining an underlying event system with value construction, ultimately defining an object graph that updates itself whenever any of the parameters used to construct it change. You can think of this graph like an electronic circuit with multiple inputs and outputs, and like a circuit, the outputs update whenever inputs change.

flohofwoe 3y ago

> ...but since signals are something that is used in a variety of frameworks... ...common usage is not really a justification for putting it into the language standard though. Glancing over the readme I'm not seeing anything that would require changes to the language syntax and can't be implemented in a regular 3rd-party library. In a couple of years, another fancy technique will make the rounds and make signals look stupid, and then we are left with more legacy baggage in the language that can't be removed because of backwards compatibility (let C++ be a warning).

Zababa 3y ago
From what I understand, a few/many of the big frameworks are converging on signals, and another commenter said that Qt had signals in the 90s https://news.ycombinator.com/item?id=39891883 https://news.ycombinator.com/item?id=39891883. I understand your worries, and I would appreciate some wisdom from non-JS UI people, espcially if they have 20+ years of experience with them.
- Offler 3y ago
  Every framework is moving to signals, apart from React and I'd say if this became a standard even they will. This is like Promise. It's a sensible shared concept.