241–250 of 336 posts
Earlier quoted context omitted.
> In practice you rarely need to explicitly go “new Promise” yourself However you do quite often need to use Promise.all, even when using async/await.
I've literally never needed to do that. What's a real world use case?
Earlier quoted context omitted.
> In practice you rarely need to explicitly go “new Promise” yourself However you do quite often need to use Promise.all, even when using async/await.
I've literally never needed to do that. What's a real world use case?
It is shorter to write than a for of loop, and importantly, all images will be loaded in parallel rather than sequentially, which can be significantly faster.
images = Promise.all(uris.map(loadImage))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 diffe…
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.
a = () => 42
b = () => a() - 1
c = () => a() + b() * 2
To be as a long-time react.js user – these examples look like a kinda weird mix of declarative with some bitter imperatives. Like, foo.set depending on foo.get and having to manually set element innerText inside the side-effect, eww, I can only imagine how messy it can get for a somewhat more complex application. React boilerplate for this case looks so much better in my opinion, take a look ``` function Component()…
Functional usually means the output can only depend on the input. But this is depending on some external state getting smuggled in through a hook. FWIW some people prefer the alternatives over this.
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…
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.)
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 diffe…
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.
Earlier quoted context omitted.
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 ha…
> In practice you rarely need to explicitly go “new Promise” yourself However you do quite often need to use Promise.all, even when using async/await.
Earlier quoted context omitted.
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 ha…
> In practice you rarely need to explicitly go “new Promise” yourself However you do quite often need to use Promise.all, even when using async/await.
function sleep(ms) {
return new Promise((resolve) => setTimeout(resolve, ms));
}
await sleep(100);
Looks useful, but what baffles me is.. Why is every framework setting state or their "signals" using "setX" functions? What's wrong with the built in getter and setters that you can either proxy or straight up override? This feels arguably cleaner: something = "else"; Than: setSomething("else");
Adding these features in-browser would seriously slow down DOM and JS and thus all websites for real. So instead we load megabytes of JS abstraction wrappers and run them in a browser to only simulate the effect.
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?!
I personally mostly prefer more explicit handling of "observable values" where function signatures show which signals/observables are used inside them.