3 ms·

Promises are a nice success story, but without async/await it wasn't really necessary to standardize > The current draft is based on design input from the auth

by __s 3y ago

Promises are a nice success story, but without async/await it wasn't really necessary to standardize > The current draft is based on design input from the authors/maintainers of Angular, Bubble, Ember, FAST, MobX, Preact, Qwik, RxJS, Solid, Starbeam, Svelte, Vue, Wiz, and more… Would be interested what existing library authors think of this proposal. Interesting that React is not in that list Signals are a bit like channels, except they're broadcast instead of single receiver. It'd be neat if this could somehow be leveraged to allow web workers to communicate with channels instead of onMessage callbacks. Specifically being able to `select` over signals/channels/promises like in Go would over a syntactic benefit over having to try manage multiple concurrent messaging mechanism with callbacks (maybe by allowing signals to be included in `Promise.any`)

watson 3y ago
> Promises are a nice success story, but without async/await it wasn't really necessary to standardize One benefit of standardisation that's not tied to async/await is that the JavaScript engines has been able to do performance optimisations not otherwise possible which benefit Promise-heavy applications
KRAKRISMOTT 3y ago
Maybe they can call it "EventEmitter" https://nodejs.org/en/learn/asynchronous-work/the-nodejs-event-emitter https://nodejs.org/en/learn/asynchronous-work/the-nodejs-eve...
- __s 3y ago
  That looks like it fits with the theme, but events are difficult to compose & tend to have easy leaks by requiring explicit attach/detach (not that I'm sure the proposal here addresses those issues)
  - pcthrowaway 3y ago
    Could you not just compose a new EventEmitter constructor that uses the new FinalizationRegistry API to drop all handlers of subjects which have since been garbage collected?
pavlov 3y ago
> “Interesting that React is not in that list” Signals are not a part of the core React API, unlike Preact. My vague gut feeling is that signals are too much like a generalized useEffect() and would only introduce further confusion into React by muddling what happens during the render cycle. For better and worse, React takes a different tack to updates than signals do. But maybe I’m wrong about their applicability.
- whizzter 3y ago
  My feeling is that it's philosophically outside the purview of React whose focus is rendering (and components and their state but not global state), RxJS and and MobX are both usable with React and have signals whilst Redux goes another route and React is "above" that choice.
  - troupo 3y ago
    Rendering in React would benefit greatly from fine-grained reactivity (which what signals offer). However, for some reason the React team insists that the lowest level of reactivity in their system os the component, no matter how large or complex it is.
- Fatalist_ma 3y ago
  There is an interesting debate about React and signals in the comments of this article, between Dan Abramov and Ryan Carniato - https://dev.to/this-is-learning/react-vs-signals-10-years-later-3k71 https://dev.to/this-is-learning/react-vs-signals-10-years-la...
  - pavlov 3y ago
    I read it until the point where he defends the idea that these two functions obviously do something completely different: function One(props) { const doubleCount = props.count * 2; return <div>Count: {doubleCount}</div>; } function Two(props) { return <div>Count: {props.count * 2}</div>; } It honestly made me wonder whether the article was dated April 1 and I’d been had. More generously, JS framework design is hard. If you’re ambitious at all, you end up fighting the language and your runtime paradigms will hang like ill-fitting clothes on its syntax. The One/Two example above shows how easily expectations break in this world of extensions to extensions. There’s no way to know what an apparently simple piece of code will actually do without knowing the specifics of a given framework.
dclowd9901 3y ago
React isn’t in this list because its effects are declarative, not imperative (except for props changes and re-renders which you could argue are in fact declarative, just one abstraction removed). UseEffect neatly compartmentalizes imperative behavior. This looks a lot like ember data binding which becomes an imperative nightmare. Its default state is “foot gun” with tons of cognitive overhead and meta patterns to keep it from getting that way.
- Offler 3y ago
  Nah I use Legend-State with Context to provide component stores and it's much nicer than the foot gun riddled useEffect standard React. Fine grained reactivity is fantastic.
bastawhiz 3y ago
> without async/await it wasn't really necessary to standardize Hard disagree. `x instanceof Promise` simply doesn't work. If my library has a then method that accepts a catch callback and yours doesn't, they're silently non-interoperable, and there's no way to detect it. When does `finally` run? What expectations can you have around how async the callbacks are? Without a standard, every single library that uses promises needs to bring its own polyfill because you can't trust what's there. And you can't actually consume any other library's promises, because you can't trust that they behave in the way you expect them to. And I'm not just speculating, this was reality for many years and a hell that many of us had to endure.
Offler 3y ago
React isn't in the list because the creator had a bad experience with backbone.js in 2013 and dislikes Signals. The team have kept true to his preferences without considering modern Signal approaches, concepts like components, dependency injection and TypeScript, npm packages which provide better encapsulation, discoverability and modularity than the state of the art in 2013.

by __s 3y ago

watson 3y ago

> Promises are a nice success story, but without async/await it wasn't really necessary to standardize One benefit of standardisation that's not tied to async/await is that the JavaScript engines has been able to do performance optimisations not otherwise possible which benefit Promise-heavy applications

KRAKRISMOTT 3y ago

Maybe they can call it "EventEmitter" https://nodejs.org/en/learn/asynchronous-work/the-nodejs-event-emitter https://nodejs.org/en/learn/asynchronous-work/the-nodejs-eve...

__s 3y ago
That looks like it fits with the theme, but events are difficult to compose & tend to have easy leaks by requiring explicit attach/detach (not that I'm sure the proposal here addresses those issues)
- pcthrowaway 3y ago
  Could you not just compose a new EventEmitter constructor that uses the new FinalizationRegistry API to drop all handlers of subjects which have since been garbage collected?

pavlov 3y ago

> “Interesting that React is not in that list” Signals are not a part of the core React API, unlike Preact. My vague gut feeling is that signals are too much like a generalized useEffect() and would only introduce further confusion into React by muddling what happens during the render cycle. For better and worse, React takes a different tack to updates than signals do. But maybe I’m wrong about their applicability.

whizzter 3y ago
My feeling is that it's philosophically outside the purview of React whose focus is rendering (and components and their state but not global state), RxJS and and MobX are both usable with React and have signals whilst Redux goes another route and React is "above" that choice.
- troupo 3y ago
  Rendering in React would benefit greatly from fine-grained reactivity (which what signals offer). However, for some reason the React team insists that the lowest level of reactivity in their system os the component, no matter how large or complex it is.
Fatalist_ma 3y ago
There is an interesting debate about React and signals in the comments of this article, between Dan Abramov and Ryan Carniato - https://dev.to/this-is-learning/react-vs-signals-10-years-later-3k71 https://dev.to/this-is-learning/react-vs-signals-10-years-la...
- pavlov 3y ago
  I read it until the point where he defends the idea that these two functions obviously do something completely different: function One(props) { const doubleCount = props.count * 2; return <div>Count: {doubleCount}</div>; } function Two(props) { return <div>Count: {props.count * 2}</div>; } It honestly made me wonder whether the article was dated April 1 and I’d been had. More generously, JS framework design is hard. If you’re ambitious at all, you end up fighting the language and your runtime paradigms will hang like ill-fitting clothes on its syntax. The One/Two example above shows how easily expectations break in this world of extensions to extensions. There’s no way to know what an apparently simple piece of code will actually do without knowing the specifics of a given framework.

dclowd9901 3y ago

React isn’t in this list because its effects are declarative, not imperative (except for props changes and re-renders which you could argue are in fact declarative, just one abstraction removed). UseEffect neatly compartmentalizes imperative behavior. This looks a lot like ember data binding which becomes an imperative nightmare. Its default state is “foot gun” with tons of cognitive overhead and meta patterns to keep it from getting that way.

Offler 3y ago
Nah I use Legend-State with Context to provide component stores and it's much nicer than the foot gun riddled useEffect standard React. Fine grained reactivity is fantastic.

bastawhiz 3y ago

> without async/await it wasn't really necessary to standardize Hard disagree. `x instanceof Promise` simply doesn't work. If my library has a then method that accepts a catch callback and yours doesn't, they're silently non-interoperable, and there's no way to detect it. When does `finally` run? What expectations can you have around how async the callbacks are? Without a standard, every single library that uses promises needs to bring its own polyfill because you can't trust what's there. And you can't actually consume any other library's promises, because you can't trust that they behave in the way you expect them to. And I'm not just speculating, this was reality for many years and a hell that many of us had to endure.

Offler 3y ago

React isn't in the list because the creator had a bad experience with backbone.js in 2013 and dislikes Signals. The team have kept true to his preferences without considering modern Signal approaches, concepts like components, dependency injection and TypeScript, npm packages which provide better encapsulation, discoverability and modularity than the state of the art in 2013.