by geospeck on 5/17/23, 9:45 AM with 124 comments
by mpweiher on 5/19/23, 8:03 AM
So it (a) appears to be a very useful or at least attractive concept, and (b) somehow difficult to fit into current programming languages/practice in a clean way.
[1] https://blog.metaobject.com/2014/03/the-siren-call-of-kvo-an... (HN: https://news.ycombinator.com/item?id=7404149 )
by samsquire on 5/19/23, 7:36 AM
But the implementations are rarely extracted out for general purpose usage and rarely have a rich API.
I've been thinking a lot about a general purpose "epoll" which be registered on objects that change. I want to be able to register a reaction to a sequence of actions on arbitrary objects with an epoll style API.
One of my ideas is GUI thunking. The idea that every interaction with the GUI raises a new type that can be interacted with, to queue up behaviours on the GUI. This is essentially Future<> that are typed and the system reacts to the new type based on what you did and presents a GUI that is as if the operation you queued up was completed. (You can interact with the future because any action on something that isn't done yet, is queued up)
It's a bit like terraform plan and apply, but applied to general purpose GUIs.
For example, you can click download file, then queue up installation and then using the application, ALL BEFORE it is installed. Because the actual computation is separate from the type information that was queued up.
Imagine using AWS Console to set up an entire infrastructure and wire everything together but not actually execute anything until the very end when you click "Run".
https://github.com/samsquire/gui-thunks
I feel we are still early days with regard how to build computer user interfaces that are easy to build, maintain and understand the code for.
I used knockout and angularjs 1 and I enjoyed Knockout especially. ko.observables and the map plugin makes creating reactive code very straightforward.
by naasking on 5/19/23, 1:10 PM
You might be tempted to say that the lazy approach might avoid some recomputations, but if a node isn't actually going to be accessed then that node is effectively no longer live and should be disposed of/garbage collected, and so it will no longer be in the update path anyway!
The mixed push/pull approach has only once nice property: it avoids "glitches" when updating values that have complex dependencies. The pull-based evaluation implicitly encodes the correct dependency path, but a naive push-based approach can update some nodes multiple times in non-dependency order. Thus a node can take on multiple incorrect values while a reaction is ongoing, only eventually settling on the correct value once the reaction is complete.
In other push-based reactive approaches, you have to explicitly schedule the updates in dependency order to avoid such glitches, so perhaps this push/pull approach was picked to keep things simple.
by Bogdanp on 5/19/23, 9:05 AM
[1]: https://docs.racket-lang.org/gui-easy/index.html
[2]: https://www.youtube.com/watch?v=7uGJJmjcxzY
[3]: https://github.com/Bogdanp/racket-gui-easy/blob/364e8becaafa...
by pdamoc on 5/19/23, 8:37 AM
If ease of use is targeted, signals might not be the best approach. I distinctly remember things becoming easier when they went away.
by EMM_386 on 5/19/23, 10:31 AM
Used in some places to simplify RxJs or not need it at all. Some, not all.
They are looking towards a future where they can get rid of Zone.js and its strategry to change detection. I see this as a step along that part.
by slevcom on 5/19/23, 3:28 PM
I maintain a reactive, state management library that overlaps many of the same ideas discussed in this blog post. https://github.com/yahoo/bgjs
There are two things I know to be true:
1. Our library does an amazing job of addressing the difficulties that come with complex, interdependent state in interactive software. We use it extensively and daily. I'm absolutely convinced it would be useful for many people.
2. We have completely failed to convince others to even try it, despite a decent amount of effort.
Giving someone a quick "here's your problem and this is how it solves it" for reactive programming still eludes me. The challenge in selling this style of programming is that it addresses complexity. How do you quickly show someone that? Give them a simple example and they will reasonably wonder why not just do it the easy way they already understand. Give them a complex example and you've lost them.
I've read plenty of reactive blog posts and reactive library documentation sets and they all struggle with communicating the benefits.
by bradrn on 5/19/23, 7:21 AM
by inglor on 5/19/23, 8:10 AM
Heck even in lisps there was reagent which was basically this and had atoms/signals :)
by codeulike on 5/19/23, 8:22 AM
by dm3 on 5/19/23, 12:01 PM
I find the biggest benefit of using a fringe library like this is the ability to read and understand the whole implementation. It's really simple compared to something like React.
by lewiscarson on 5/19/23, 7:41 AM
by tijssss on 5/19/23, 10:50 AM
by itronitron on 5/19/23, 9:08 AM
by KRAKRISMOTT on 5/19/23, 8:40 AM
by SergeAx on 5/19/23, 3:05 PM