Offler's comments

On: A proposal to add signals to JavaScript

[Offler]

That's basically every major framework apart from React and it includes some major React libraries.

On: A proposal to add signals to JavaScript

[Offler]

They weren't used in virtually every single frontend framework though while Signals are

On: A proposal to add signals to JavaScript

[Offler]

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.

On: A proposal to add signals to JavaScript

[Offler]

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.

On: A proposal to add signals to JavaScript

[Offler]

I work on FX trading applications with hundreds of thousands of lines of code. Full fat desktop application replacements. Good luck not using a framework. 20-30 developers with multiple clients with their own devs.

On: A proposal to add signals to JavaScript

[Offler]

Look at legend-state, it's most definitely not Redux (in a good way IMO).

On: A proposal to add signals to JavaScript

[Offler]

Signals are used in every framework except React. Observables weren't. That's a huge difference.

On: A proposal to add signals to JavaScript

[Offler]

Indeed at a certain scale the "easy" approach ends up becoming a mess. A simple counter isn't complex enough but this is a great idea and would be a positive for the language.

On: A proposal to add signals to JavaScript

[Offler]

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.

On: A proposal to add signals to JavaScript

[Offler]

I much prefer the explicit get/set methods. MobX I think used the magic approach as did svelte and I believe svelte have realized it's a mistake. It makes it harder to reason about the code, better to be explicit.