21–30 of 64 posts
"Traditional state management like React hooks triggers..." Traditional? I remember when React was the new kid on the block. I am getting old! :-D
Like, I understand why people aren't going full 3d game simulation style for applications. But I don't understand why things are as divergent as they are?
Is this just my off perspective?
I feel like at some point we are gonna complete the cycle and have MVVM/MVC binding engines in frontend dev.
There is barely any difference left between createContext+useSignal vs. C# DataContext+ObservableProperty.
It remains a bit of a mystery to me that applications seem to grow further and further from traditional game techniques. Both in how state is propagated through the application, and in how it is represented. Like, I understand why people aren't going full 3d game simulation style for applications. But I don't understand why things are as divergent as they are? Is this just my off perspective?
I don't like the style of code in the article, with weird functions like "useState" and "useSignal". Looks ugly to me. Also, it seems that with signals you must use immutable values only. Imagine if you have, let's say, a text document model, and you need to create a new copy every time the user types a letter. That's not going to work fast. And there will be no granular updates, because the signal only tracks the va…
> Also I don't like that React requires installing Node and compilation tools, this is a waste of time when making a quick prototype. Vue can be used without Node.
I don't like the style of code in the article, with weird functions like "useState" and "useSignal". Looks ugly to me. Also, it seems that with signals you must use immutable values only. Imagine if you have, let's say, a text document model, and you need to create a new copy every time the user types a letter. That's not going to work fast. And there will be no granular updates, because the signal only tracks the va…
Too small. Imagine if you have a 2GB mutable file. Each keystroke in the middle of the file has to move the whole 2nd gigabyte backward.
Relatedly, there is a stage-1 proposal to add first-class signals to Javascript: https://github.com/tc39/proposal-signals It's a collaboration between multiple library maintainers, attempting to standardize and unify their shared change-tracking approach.
I wonder some years down the future, if there will be no need for JS frameworks since a lot of what they offer will be integrated into JS itself.
In the time that I’ve been using ClojureScript, the whole react community has switched to hooks. I find it so baffling - requiring your entire data structure to be contained within your component lifecycle? The thousands of calls to individual “useState” to track the same number of state items? The fact that every function is closing over historical state unless you manually tell it to change every time the variable does — and then this last bit in combination with non-linear deep equality comparisons?
I recently have been in the process of switching phrasing.app from reagent atoms to preact/signals for performance reasons (and as part of a longer horizon move from react to preact) and I have to say it’s been fantastic. Maybe 50 lines of code to replicate reagent atoms with preact/signals, all the benefits, and much much faster.
Very happy that there is react-like library so devoted to first class support of signals.
I don't like the style of code in the article, with weird functions like "useState" and "useSignal". Looks ugly to me. Also, it seems that with signals you must use immutable values only. Imagine if you have, let's say, a text document model, and you need to create a new copy every time the user types a letter. That's not going to work fast. And there will be no granular updates, because the signal only tracks the va…
> it seems that with signals you must use immutable values only. Imagine if you have, let's say, a text document model, and you need to create a new copy every time the user types a letter. Too small. Imagine if you have a 2GB mutable file. Each keystroke in the middle of the file has to move the whole 2nd gigabyte backward.