I’m in favour. Mobx is great. This will focus efforts on making better devtools.
A proposal to add signals to JavaScript
211–220 of 336 posts
Re: A proposal to add signals to JavaScript
#212Earlier quoted context omitted.
> Anything wrong with that? Well, don't events only bubble upwards? You need to know the exact element of it is not on a lower level in the DOM tree. Events were too messy, so I wrote a small pub/sub message queue type of thing. Anyone anywhere in the DOM can subscribe to messages based on subject regexes. Makes things a lot easier, especially when I added web components to wrap existing elements so that publishing a…
You can also fire events on pretty much any object, essentially creating a channel where the message bus queue is the vm event queue.
> You can also fire events on pretty much any object,
Only if you have a reference to the object.
The reason I made up my own message queue pub/sub is because events required a lot of complexity in acquiring the correct reference to the correct object or subtree in the DOM.
With pub/sub type message queue, any element can emit a message with subject "POST /getnetpage" and the function listening for (subscribed) POST messages emits a RESPONSE message when the response comes back. This lets a third element listen (subscribe) for a "RESPONSE FROM /getnextpage" subject message, and handle it.
None of the 3 parties in the above need to have a reference to each other, nor do they even have to know about each other, and I can inject some nice observability tools because I can just add a subscriber for specific message types, which makes debugging a breeze.
Re: A proposal to add signals to JavaScript
#213Am I the only one that thinks the vanilla js example is actually easier to read and work with? - "The setup is noise and boilerplate heavy." Actually the signals example looks just as noisy and boilerplate heavy to me. And it introduces new boilerplate concepts which are hard for beginners to understand. - "If the counter changes but parity does not (e.g. counter goes from 2 to 4), then we do unnecessary computation…
I dislike both examples but find the Signals one far worse, no question.
You can do it that way, but… why? When you could just not?
Re: A proposal to add signals to JavaScript
#214Earlier quoted context omitted.
I believe memory leaks to start
Memory leaks can occur when a component adds events to an element outside of the component (such as the window) and then gets removed from the DOM without removing the event handler from the window. This is solved in native Web Components by the mount/unmount methods where you can run code to remove event listeners when the component has been unmounted. For other event listeners, they get removed when the DOM element…
Removing event listeners upon some component being removed actually sounds like a great use case for the new FinalizationRegistry API[1]
[1]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
Re: A proposal to add signals to JavaScript
#215Earlier quoted context omitted.
You don't need to be building Facebook or Google to have a TON of state in a webpage. Obviously if you are doing a basic dashboard, a blog or something similar, it isn't really needed. But for more complex stuff I think react provides a much better way to handle state changes than just using vanilla js. It's not like using react makes an app more complex, because if you wanted to do the same thing in vanillajs you'd…
Could you give a concrete example for the more complex stuff?
Maybe try making something like Grafana's dashboard by hand.
Re: A proposal to add signals to JavaScript
#216Earlier quoted context omitted.
Maybe they can call it "EventEmitter" https://nodejs.org/en/learn/asynchronous-work/the-nodejs-eve...
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)
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?
Re: A proposal to add signals to JavaScript
#217Off topic, but I’m wondering if anyone attracted to this topic could help me understand why JavaScript doesn’t have macros. I’m aware of much conversation around dismissing macros, often in the context of bad dev experience — but this sounds like a shallow dismissal to me. At the end of the day, we have some of the results of macros in the JavaScript ecosystem, but rather than being supported by the language they are…
Interpreted languages rarely have macros. But more importantly, do you really want script tags on webpages defining macros that globally affect how other files are parsed/interpreted? What if the macro references an identifier that's not global? What if I define a macro in a script that loads after some other JavaScript has already run? Do macros affect eval() and the output of Function.prototype.toString? Sure, you…
It turns out there might actually be a benefit of the compilation step which has been introduced now that everyone uses Typescript... would be really interesting to see macros get added, though I suspect it's too far away from Typescript's mandate to add as few new features on top of Javascript as possible
Re: A proposal to add signals to JavaScript
#218Why 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 diffe…
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 standard…
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
Sorry, just – nothing about this makes sense to me.
Re: A proposal to add signals to JavaScript
#219When they added Promises to JavaScript, I bristled at the thought that I might have to start writing `new Promise` everywhere. In practice, I can count on two hands the number of times I’ve written `new Promise`. What did happen, though, is I started to write `.then` a whole lot more, especially when working with third party libraries. In the end, the actual day-to-day effect of the Promise addition to JavaScript was…
I assumed the Promises was added primarily so that async/await could be added, which is where the really substantial quality of life improvement is. In practice you rarely need to explicitly go “new Promise” yourself.
While .then in initial promises was a great improvement over nested delegates and is fine for simple chained promises, once you start conditionally chaining different promises or need different error handling for particular chains in the promise, or wanting to do an early return, the code can become much harder to read and work with.
With async/await though you just write the call essentially as if it’s not a promise and can easily put try/catch around particular promise calls, easily have early returns, etc.
Re: A proposal to add signals to JavaScript
#220Earlier quoted context omitted.
There's no existing "good enough" solution for reactive values in JS. Also https://news.ycombinator.com/item?id=39887187
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.
No one says you can't build large complex applications using current tools