251–260 of 336 posts
Earlier quoted context omitted.
I've literally never needed to do that. What's a real world use case?
Doing multiple async tasks concurrently as opposed to in sequence. If you have never used this you have either worked on extremely simple systems or have been leaving a ton of perf gains on the table.
Am 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…
counter.set(counter.get() + 1)
Am 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…
Why do you think this is premature memoization? This is an example, boiled down to a simple function. Do you think people just came up with the use case for this without ever having needed it? I think an effort in standardizing signals, a concept that is increasingly used in UI development is a laudable effort. I don't want to get into the nitty gritty about what is too much boilerplate and whether you should build a…
...common usage is not really a justification for putting it into the language standard though. Glancing over the readme I'm not seeing anything that would require changes to the language syntax and can't be implemented in a regular 3rd-party library.
In a couple of years, another fancy technique will make the rounds and make signals look stupid, and then we are left with more legacy baggage in the language that can't be removed because of backwards compatibility (let C++ be a warning).
Earlier quoted context omitted.
Why do you think this is premature memoization? This is an example, boiled down to a simple function. Do you think people just came up with the use case for this without ever having needed it? I think an effort in standardizing signals, a concept that is increasingly used in UI development is a laudable effort. I don't want to get into the nitty gritty about what is too much boilerplate and whether you should build a…
> ...but since signals are something that is used in a variety of frameworks... ...common usage is not really a justification for putting it into the language standard though. Glancing over the readme I'm not seeing anything that would require changes to the language syntax and can't be implemented in a regular 3rd-party library. In a couple of years, another fancy technique will make the rounds and make signals look…
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?!
Can't we just call javascript 'done'? We keep adding things to the language, and never subtract anything, which means learning it as a language is getting harder and harder.
Earlier quoted context omitted.
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…
I think you’re right, I don’t see how building this into the base library makes some things possible which weren’t before. I think that the Promise API was not the actual thing people directly wanted (and on its own had no compelling reason to be added to the base library), but a standardised Promise API was needed in order to add the hugely useful async/await keywords which are unachievable without changes to the la…
In JS, the async syntax is largely syntactic sugar around chaining promises with `.then()`. Promises alone fixes callback hell and brings structure and scoping to multi-stage async operations - at least to the extent possible in such a dynamic environment as JS. There are only a couple minor additions relating to the main entry points, microtasks and interactions with the runtime, to make the main async/await experience we enjoy today. This is actually a good thing, when you can build abstractions on top of other core constructs, without affecting the rest of the language too much.
There may absolutely be analogous syntactic ergonomic constructs on top of signals, reactivity or observables - whichever is sensible - that could be layered on top to compose really powerful user-facing features in the future. So the success of promises and async is a still a supporting story, in my view. A lot more research and scrutiny is needed, but it’s certainly one of the top interesting ideas.
Earlier quoted context omitted.
Why do you think this is premature memoization? This is an example, boiled down to a simple function. Do you think people just came up with the use case for this without ever having needed it? I think an effort in standardizing signals, a concept that is increasingly used in UI development is a laudable effort. I don't want to get into the nitty gritty about what is too much boilerplate and whether you should build a…
> 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.)
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/signalsandslots.html
"Signals are emitted by objects when they change their state in a way that may be interesting to other objects."
However what I think they are proposing in the article is a much more complex abstraction: they want to automate it so that whenever any part of a complex graph of states changes, every piece of code depending on that specific state gets notified, without the programmer explicitly writing code to notify other pieces of code, or doing connect() or addEventListener() etc.
What are your thoughts on that? I'd be interested to hear since I'm sure you have more experience than me.
Earlier quoted context omitted.
> In other words, can't this be a library? You answered your own question: > I know that SolidJS is able to It already is, obviously. But how is SolidJS supposed to work with other non-SolidJS code? It can't. Unless every library builds support for every other library, they can't possibly interoperate.
> It already is, obviously. But how is SolidJS supposed to work with other non-SolidJS code? Who actually writes code like this? People use some signal graph library for application code typically, I’ve never seen anyone mixing SolidJs with MobX in application code or as a consequence of a library dep.
https://github.com/preactjs/preact/blob/757746a915d186a90954...
Am 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 was wondering about this awkward code: counter.set(counter.get() + 1) One would think that proper integration into the language also means getting rid of those "noisy" setter/getter calls.