Live data from Hacker News

A proposal to add signals to JavaScript

github.com

271–280 of 336 posts

Re: A proposal to add signals to JavaScript

#271
post #227
post #197

Earlier quoted context omitted.

Promises proved themselves in libraries before they got added to Javascript.

Signals have, too. And it is literally spelled out in the readme, in the introduction section

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.

Re: A proposal to add signals to JavaScript

#272
post #269

Earlier quoted context omitted.

1) Almost no one is building FB or Gmail, yet act like it. The precise reason why still escapes me. 2) For other use cases, it’s not that hard to manually update some elements in the DOM. You very quickly learn how not shot yourself in the foot. Certainly a lot easier (and faster) than dealing with the mess that is the React ecosystem.

This sounds more like a complaint the kids aren't happy to eat turnips and mashed bugs (just pick the legs and wings out!) like we had to and that their newfangled 'sandwiches' are too fancy. What if they get caught out in the forest with nothing but sandwiches? That oughta learn'em real quick.

Haha, if you want to go with the food analogy, I'd say they are discussing over meat sticks brands without having tasted a real steak.

Or better still, running a meat stick factory because doing the dishes is hard.

But I don't know if such analogies are any good other than being funny.

Re: A proposal to add signals to JavaScript

#274
post #7

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 c…

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.

Re: A proposal to add signals to JavaScript

#275
post #7

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 c…

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 kee…

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.

Re: A proposal to add signals to JavaScript

#276
post #258

Earlier quoted context omitted.

> 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.)

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…

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.

Re: A proposal to add signals to JavaScript

#277
post #266

Earlier quoted context omitted.

> 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.)

While they share the same name, and are both reactive primitives, there are some fairly key differences between these signals and the QT signals and slots mechanism. The main one is that QT signals are, as far as I understand, a fairly static construct - as you construct the various components of the application, you also construct the reactive graph. This graph might be updated over time, but usually when components…

Thanks for the great reply! I definitely need to take a closer look.

Re: A proposal to add signals to JavaScript

#278

Earlier quoted context omitted.

Getters and setters work pretty well. addEventListener("foo", () => {...}, {once: true}) Is a pretty easy way of handling one-shot events. Those have been "good enough" for me to build large, complex healthcare applications.

>> Getters and setters work pretty well. What do you mean can you explain more?

Sure.

I structure my apps with light DOM vanilla web components, using lit-html (not lit) as a renderer.

I'll use a hypothetical patient profile component as an example. Let's say that it's a top level "page" and needs to support deep linking.

set patient_id(value) would trigger a loadPatient(). loadPatient would set this.patient when loading is complete. The setter for this.patient triggers a render and paints the component.

You can expand on that as needed. Maybe sometimes I want to render that component in a modal, maybe sometimes as a slide out drawer. Maybe there are little differences in the header or something depending on how it's being hosted - I can just add a setter for something like "display_mode" (making this up) that would trigger a render on change.

It's really no different than any reactive flow, and about the same as big frameworks when you count total LOC, but it's all just vanilla and simple.

For cross component communication, custom events work great, especially the one-shot ones. In a component constructor, I can add a listener, assign a property or call a component function, and the reactive flow just goes as normal.

No framework needed.

Works with any renderer, if you don't like lit-html, there are JSX and others out there. I like lit-html because it's super fast template node clones, so you don't need to worry about calling render() redundantly, it's cheap.

Re: A proposal to add signals to JavaScript

#279
post #238

Earlier quoted context omitted.

> 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…

what makes useState different than signals?!

They’re very similar, and you can definitely squint right to see them as fundamentally the same concept… if while squinting you also see a React component itself as a reactive effect. Which is all technically correct (the best kind), but generally not what people mean when they’re talking about signals in practical terms.

Re: A proposal to add signals to JavaScript

#280
Signals only made sense in the past of desktop programming languages, because the ones on mainstream lacked lambdas and closures.

Smalltalk, and Lisp derived ones did just fine without them.

Modern JavaScript already has them as well, no need for what is basically a closure with a listeners list.

Post reply on HN