3 ms·

Why does it need to be a part of the language? This could be a library. There are such libraries. They are small, so including them in your code is no big deal.

Why does it need to be a part of the language? This could be a library. There are such libraries. They are small, so including them in your code is no big deal. Adding this to the language should not even be a goal. Thinking that the current crop of JS UI libraries designed their signals in such a good way that it needs to become a part of the language is hubris. Signals have many possible implementations with different tradeoffs, and none of them deserve to have a special place in the JavaScript spec. Before these libraries used signals, they or their predecessors used virtual DOM. Luckily, that didn't become part of JS, but how are signals any different? They aren't. The argument for making them standard is even worse than for virtual DOM. Are we just going pile every fad into a runtime that basically has no way to dispose of no-longer-wanted features without breaking the web? That is quite short sighted.

imbnwa 3y ago
Remember the Observable proposal?
- tengbretson 3y ago
  The Observable proposal made a stronger case in my opinion, since Observables provide an interface that is functionally unique and useful for the boundaries between app logic and libraries, so a single standard approach has benefits. Signals on the other hand live right where application state binds to the ui. Is this really somewhere that people are patching together a hodge podge of libraries that need to use a consistent api? I'm not so sure.
  - Offler 3y ago
    Signals are used in every framework except React. Observables weren't. That's a huge difference.
- Sammi 3y ago
  There's the old one that fizzled out: https://github.com/tc39/proposal-observable https://github.com/tc39/proposal-observable And there's the new one which seems to be getting implemented in node right now: https://github.com/WICG/observable https://github.com/WICG/observable
klabb3 3y ago
Good points. We don’t want the wrong thing. But we want the right one! Reactive UI won. The main thing stopping me from using vanilla JS is the absolute explosion in complexity managing state for even small sized applications. To me, any reactive framework is better than vanilla, so perhaps there is a construct missing? Now that it’s been a decade or so, we should start thinking about possible cut-points for standardization. Like with promises, this could bring down complexity for extremely common use-cases, if done right. I think a better way to evaluate it would be: “would this proposal be used by existing reactive frameworks?”. If not, why? What’s missing? What’s superfluous? What about lessons from UI annd reactivity from other languages? There’s a lot of fragmented experience to distill, but it’s a worthwhile endeavor imo.
- nikitaga 3y ago
  If you want to do "the right thing" – implement your proposal as a library, AND convince people to use it on its own technical merits. Then when everyone uses it (because it's so obviously "the right thing"), you can start asking if anyone wants your library to be built into the language. But that's not what you're doing. You're gunning for becoming the standard from the start – you are trying to convince people to use your draft implementation based on its status as a proposed standard, instead of them using it on its own technical merits. Ditch the status, and see if anyone still wants it. -- Yes, reactive UI won – just fine, without having signals in the JS standard. Because not having signals in the language was never an actual problem holding back reactive UI development in JS. Your proposal does not "bring down complexity". It simply moves the complexity from UI libraries into the JS standard. In doing that, you forcefully marry the ecosystem to that particular style of complexity. Every browser vendor will need to implement it and support it... for how many decades? And to what end? Unlike e.g. promises that are useful on their own, your proposal isn't nearly ergonomic enough to allow building reactive UIs in vanilla JS. Users will still need to use libraries for that, just like they do today. You're just moving one piece of such libraries into the standard, without building the case for why it's needed there. -- Your proposal spends pages selling the readers on signals, but that is not what you need to sell. We already have many implementations of signals. You need to sell why your (or any) signals implementation needs to be in the JavaScript standard. You have one tiny "Benefits of a standard library" subsection under "Secondary benefits" but it's just ridiculous. You're basically saying that we should add signals to JS because we've added (much simpler or more needed) things to JS before – is that really your best argument? And... "saving bundle size"? You want to bless one implementation of a complex problem to save what, 5KB of this: https://cdn.jsdelivr.net/npm/s-js https://cdn.jsdelivr.net/npm/s-js Sorry, just – nothing about this makes sense to me.
Too 3y ago
One good argument for standardizing Signals is that debugging them seems to be a nightmare. Imagine a deep tree of calculated signals firing off each other and you need to find the source of what started the chain reaction. Standardizing will allow devtools to develop around it.
- wruza 3y ago
  They don't fire off each other, they simply depend on each other like functions do: a = () => 42 b = () => a() - 1 c = () => a() + b() * 2 It isn't a bigger nightmare than debugging pure functions. The source for `c` is `a` and `b`. All signal values (as proposed) will be lexically available in a body of a dependent signal, so there's no hidden registry to navigate anyway. If in-browser IDEs want to record a call tree for an activation record, they can do that without a standard.
  - Too 3y ago
    There is still a watch() mechanism that from a consumers point of view hide the originating event of an update. Otherwise if all you wanted was functions, just use functions. When watch fires out of control, you need debugging tools to understand why your render() function is being invoked more often than it should. This type of problem happens all the time in react and you need to trace upwards to find that 7 components up the chain someone accidentally included new Date() in the state that propagates down through props and re-renders everything.
    - wruza 3y ago
      Signals are basically lazy functions. You can't "just" use functions if performance is a concern, cause that's the least efficient way to keep everything consistent. Since watching seems(?) to be synchronous in the proposal, why do you think extra debugging tools are needed? You can breakpoint into render() with a regular debugger and look at the stack trace.
kabes 3y ago
You can say this about most things in the standard library. But as stated in the motivation, there's an ongoing trend to extend the rather small standard library js offers, so you don't need to have a package for each and every common task. You can argue about the need for this, but if we're going to extend the standard lib, then looking at what is popular is a good approach IMO. > Before these libraries used signals, they or their predecessors used virtual DOM Signals are not a replacement for virtual DOM.

imbnwa 3y ago

Remember the Observable proposal?

tengbretson 3y ago
The Observable proposal made a stronger case in my opinion, since Observables provide an interface that is functionally unique and useful for the boundaries between app logic and libraries, so a single standard approach has benefits. Signals on the other hand live right where application state binds to the ui. Is this really somewhere that people are patching together a hodge podge of libraries that need to use a consistent api? I'm not so sure.
- Offler 3y ago
  Signals are used in every framework except React. Observables weren't. That's a huge difference.
Sammi 3y ago
There's the old one that fizzled out: https://github.com/tc39/proposal-observable https://github.com/tc39/proposal-observable And there's the new one which seems to be getting implemented in node right now: https://github.com/WICG/observable https://github.com/WICG/observable

klabb3 3y ago

Good points. We don’t want the wrong thing. But we want the right one! Reactive UI won. The main thing stopping me from using vanilla JS is the absolute explosion in complexity managing state for even small sized applications. To me, any reactive framework is better than vanilla, so perhaps there is a construct missing? Now that it’s been a decade or so, we should start thinking about possible cut-points for standardization. Like with promises, this could bring down complexity for extremely common use-cases, if done right. I think a better way to evaluate it would be: “would this proposal be used by existing reactive frameworks?”. If not, why? What’s missing? What’s superfluous? What about lessons from UI annd reactivity from other languages? There’s a lot of fragmented experience to distill, but it’s a worthwhile endeavor imo.

nikitaga 3y ago
If you want to do "the right thing" – implement your proposal as a library, AND convince people to use it on its own technical merits. Then when everyone uses it (because it's so obviously "the right thing"), you can start asking if anyone wants your library to be built into the language. But that's not what you're doing. You're gunning for becoming the standard from the start – you are trying to convince people to use your draft implementation based on its status as a proposed standard, instead of them using it on its own technical merits. Ditch the status, and see if anyone still wants it. -- Yes, reactive UI won – just fine, without having signals in the JS standard. Because not having signals in the language was never an actual problem holding back reactive UI development in JS. Your proposal does not "bring down complexity". It simply moves the complexity from UI libraries into the JS standard. In doing that, you forcefully marry the ecosystem to that particular style of complexity. Every browser vendor will need to implement it and support it... for how many decades? And to what end? Unlike e.g. promises that are useful on their own, your proposal isn't nearly ergonomic enough to allow building reactive UIs in vanilla JS. Users will still need to use libraries for that, just like they do today. You're just moving one piece of such libraries into the standard, without building the case for why it's needed there. -- Your proposal spends pages selling the readers on signals, but that is not what you need to sell. We already have many implementations of signals. You need to sell why your (or any) signals implementation needs to be in the JavaScript standard. You have one tiny "Benefits of a standard library" subsection under "Secondary benefits" but it's just ridiculous. You're basically saying that we should add signals to JS because we've added (much simpler or more needed) things to JS before – is that really your best argument? And... "saving bundle size"? You want to bless one implementation of a complex problem to save what, 5KB of this: https://cdn.jsdelivr.net/npm/s-js https://cdn.jsdelivr.net/npm/s-js Sorry, just – nothing about this makes sense to me.

Too 3y ago

One good argument for standardizing Signals is that debugging them seems to be a nightmare. Imagine a deep tree of calculated signals firing off each other and you need to find the source of what started the chain reaction. Standardizing will allow devtools to develop around it.

wruza 3y ago
They don't fire off each other, they simply depend on each other like functions do: a = () => 42 b = () => a() - 1 c = () => a() + b() * 2 It isn't a bigger nightmare than debugging pure functions. The source for `c` is `a` and `b`. All signal values (as proposed) will be lexically available in a body of a dependent signal, so there's no hidden registry to navigate anyway. If in-browser IDEs want to record a call tree for an activation record, they can do that without a standard.
- Too 3y ago
  There is still a watch() mechanism that from a consumers point of view hide the originating event of an update. Otherwise if all you wanted was functions, just use functions. When watch fires out of control, you need debugging tools to understand why your render() function is being invoked more often than it should. This type of problem happens all the time in react and you need to trace upwards to find that 7 components up the chain someone accidentally included new Date() in the state that propagates down through props and re-renders everything.
  - wruza 3y ago
    Signals are basically lazy functions. You can't "just" use functions if performance is a concern, cause that's the least efficient way to keep everything consistent. Since watching seems(?) to be synchronous in the proposal, why do you think extra debugging tools are needed? You can breakpoint into render() with a regular debugger and look at the stack trace.

kabes 3y ago

You can say this about most things in the standard library. But as stated in the motivation, there's an ongoing trend to extend the rather small standard library js offers, so you don't need to have a package for each and every common task. You can argue about the need for this, but if we're going to extend the standard lib, then looking at what is popular is a good approach IMO. > Before these libraries used signals, they or their predecessors used virtual DOM Signals are not a replacement for virtual DOM.