3 ms·

Looks bad. It adds what looks like more nonsense complexity. Also, "Signals" as a name is not descriptive to what is proposed (see e.g. Qt Signals).

tqwhite 3y ago
Yes. Thank you. I am already tired trying to figure out how this would improve my life and annoyed at trying to read other people's code that has more abstracted crap in it.
- cuddlecake 3y ago
  Promises are, technically speaking, "abstracted crap". So is abstracted crap only ok if it's already in the JS standard library?
  - Izkata 3y ago
    Promises proved themselves in libraries before they got added to Javascript.
    - tqwhite 3y ago
      I hate promises. Writing: let result; let error; await blah .then(r=>result=r) .catch(e=>error=3) .final(callback(err, result)); Is disgusting.
    - troupo 3y ago
      Signals have, too. And it is literally spelled out in the readme, in the introduction section
      - Izkata 3y ago
        They did create a polyfill, but the readme says it was based on design input from other projects, not on aligning multiple existing designs. This at least sounds like the opposite of what happened with promises, where they already existed in multiple libraries before the Promises/A design came out.
        troupo 3y ago
        > where they already existed in multiple libraries Signals exist in multiple libraries with what are really minor variations on the theme. > before the Promises/A design came out. That's why the current proposal asks for input about design. IIRC, promises also had multiple iterations on the design. There were calls to make them more monadic, less monadic, cancelable, non-cancelable etc. And the original proposal looks nothing like the eventual API: https://groups.google.com/g/commonjs/c/6T9z75fohDk https://groups.google.com/g/commonjs/c/6T9z75fohDk [1] And new things are still being added to them (like Promise.withResolvers etc.) [1] There's a great long presentation on the history of promises here: https://samsaccone.com/posts/history-of-promises.html https://samsaccone.com/posts/history-of-promises.html
notnullorvoid 3y ago
I do personally think signal is a bit of a poor naming choice, but it has become probably the most recognizable term used for the concept in the JS ecosystem. There's not a whole lot of short concise naming options either, but maybe "Reactive Values" is better?

tqwhite 3y ago

Yes. Thank you. I am already tired trying to figure out how this would improve my life and annoyed at trying to read other people's code that has more abstracted crap in it.

cuddlecake 3y ago
Promises are, technically speaking, "abstracted crap". So is abstracted crap only ok if it's already in the JS standard library?
- Izkata 3y ago
  Promises proved themselves in libraries before they got added to Javascript.
  - tqwhite 3y ago
    I hate promises. Writing: let result; let error; await blah .then(r=>result=r) .catch(e=>error=3) .final(callback(err, result)); Is disgusting.
  - troupo 3y ago
    Signals have, too. And it is literally spelled out in the readme, in the introduction section
    - Izkata 3y ago
      They did create a polyfill, but the readme says it was based on design input from other projects, not on aligning multiple existing designs. This at least sounds like the opposite of what happened with promises, where they already existed in multiple libraries before the Promises/A design came out.
      - troupo 3y ago
        > where they already existed in multiple libraries Signals exist in multiple libraries with what are really minor variations on the theme. > before the Promises/A design came out. That's why the current proposal asks for input about design. IIRC, promises also had multiple iterations on the design. There were calls to make them more monadic, less monadic, cancelable, non-cancelable etc. And the original proposal looks nothing like the eventual API: https://groups.google.com/g/commonjs/c/6T9z75fohDk https://groups.google.com/g/commonjs/c/6T9z75fohDk [1] And new things are still being added to them (like Promise.withResolvers etc.) [1] There's a great long presentation on the history of promises here: https://samsaccone.com/posts/history-of-promises.html https://samsaccone.com/posts/history-of-promises.html

notnullorvoid 3y ago

I do personally think signal is a bit of a poor naming choice, but it has become probably the most recognizable term used for the concept in the JS ecosystem. There's not a whole lot of short concise naming options either, but maybe "Reactive Values" is better?