I do not want to distract from the content of the article, which is highly relevant for folks who built UIs with frameworks that are conceptually based on signals, but the way that the reading experience is designed really great, in particular the guided reading flow through the instructive code path is something that I rarely have seen done at all, and this even works pretty well on mobile. It's a delightful reminder on how a dynamic medium can be more than the simulation of print on screens.
The "2 * x" is rather - why would the reaction from a change in X display many gradual increments of 1 instead of showing the final value once? And then why does Z =Y+1 instead of +1 to Y repeats all the steps again from X? That's not how real signal frameworks work, and also not how you'd imagine they should work
Then the next cascading example: ok, if Signal is a button, not the underlying mechanism behind it, then "computed 1" is also a signal, why isn't it called that?
(though intuitively you'd think the moving dots are signals, not buttons)
Beautiful presentation... @willybrauner, I would like to read your spin on a follow-up piece on `glitch-freedom`.
But in all honesty, this journal entry/post is a work of art; a testament to your journey as a technologist!.
I know it is out of scope for this article, but there are variants where the operations are monadic rather than applicative and the shape of the graph can change depending on values. And also variations with state - where history can be taken into account.
However, I really wonder if this scales to real applications…
I’ve seen too many people get initially mesmerized by “event driven” programming only to find the system eventually becomes a steaming mess that nobody can comprehend or debug. Or it manages to work but has serious performance issues (in an exclusively “push” design)…
Maybe in a single process, single threaded environment, it is more difficult to screw up?
15 comments
[ 3.2 ms ] story [ 34.3 ms ] thread* I think the first implementation in JS land was Flapjax, which was around 2008: https://www.flapjax-lang.org/publications/
* The article didn't discuss glitch-freedom, which I think is fairly important.
Mind you, the framework still has a hostile learning curve, but for those who already made that investment, it's a boon.
The "2 * x" is rather - why would the reaction from a change in X display many gradual increments of 1 instead of showing the final value once? And then why does Z =Y+1 instead of +1 to Y repeats all the steps again from X? That's not how real signal frameworks work, and also not how you'd imagine they should work
Then the next cascading example: ok, if Signal is a button, not the underlying mechanism behind it, then "computed 1" is also a signal, why isn't it called that? (though intuitively you'd think the moving dots are signals, not buttons)
Cheers
Jane street briefly summarizes some options here: https://blog.janestreet.com/breaking-down-frp/
And they have an interesting talk on the trade-offs and how their own system, incremental, evolved: https://blog.janestreet.com/seven-implementations-of-increme...
However, I really wonder if this scales to real applications…
I’ve seen too many people get initially mesmerized by “event driven” programming only to find the system eventually becomes a steaming mess that nobody can comprehend or debug. Or it manages to work but has serious performance issues (in an exclusively “push” design)…
Maybe in a single process, single threaded environment, it is more difficult to screw up?