Our great sponsors
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
ReactiveUI
An advanced, composable, functional reactive model-view-viewmodel framework for all .NET platforms that is inspired by functional reactive programming. ReactiveUI allows you to abstract mutable state away from your user interfaces, express the idea around a feature in one readable place and improve the testability of your application.
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
-
electric
a reactive Clojure dialect for web development that uses a compiler to infer the frontend/backend boundary (by hyperfiddle)
I took a similar approach in my Racket library, gui-easy[1,2]. Though I opted to not defer any computations, any observable (similar to a signal from the post) update propagates to observers immediately, and there's no incrementality -- observables are just boxes whose changes you can subscribe to. Regarding the disposal problem, I used weak references and regarding the where to take observables and where to take concrete values as input question, I decided that any place an observable can go in, a concrete value can as well and it's been a convenient choice so far. For fun, here's an example[3] that builds the todo UI from the post.
[1]: https://docs.racket-lang.org/gui-easy/index.html
It's interesting how every build system, frontend framework, programming language implements its own promise pipeline/delayed execution/observables/event propagation.
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.
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
Thanks for this thoughtful and insightful comment.
Many problems can be workflow problems, sometimes even pulling in a rule engine, or require a job queue to do things that can fail.
Then you have software such as https://temporal.io/ which is really powerful for resilient workflows.
Imagine coordinating the user with a workflow with asynchronous data collection steps.
Imagine programming "reaction to user behaviour as a workflow engine".
await user.login();
I assume you would have conditions for each workflow which are then pattern matched to user behaviour to see if that workflow is relevant.
You still have a globally defined happy path of coordination but your overarching application logic isn't spread everywhere but contained in one place.
The preconditions for the logout would trigger a different workflow workflow.
I am the author of additive-gui, which is based around the idea that you provide all the rules of the GUI and the computer works it out.
https://github.com/samsquire/additive-gui
It's not ready for anything, it's just a proof of concept. But it doesn't really implement workflows yet.
ReactiveUI is based on Rx and very popular in the .Net world: https://www.reactiveui.net/.
DarkReader is your friend.
https://darkreader.org/
I use it on every site except a select foew that have beetter Stylus UserStyles.
HN happens to be one i use a custom stylesheet for.
May be of interest: I released a port of Incremental to Rust the other week. It has a bit of a way to go in polish and docs, but the core implementation and API should be very familiar. It has Expert nodes so incremental-map is feasible and already works. I’ve been using it as the state management for some UI with much success. Credit to the authors because it’s a good design. https://github.com/cormacrelf/incremental-rs
Interesting that this is Clojure and it doesn't mention Hoplon/Javelin[0] as prior work. I've used Hoplon/UI[1] to implement a moderately complex web app ~6 years ago. The library is practically a prototype, pretty much dead by now. However, I found the ideas interesting.
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.
[0]: https://github.com/hoplon
[1]: https://github.com/hoplon/ui
"Signal" has been used in FRP circles for some time [1,2]. The original FRP stuff was events/signals and behaviours. But I agree that JS didn't use this terminology until more recently. S.js is maybe one of the earlier ones, but that was still over 8 years ago.
[1] https://scholarworks.rit.edu/cgi/viewcontent.cgi?article=651...
[2] https://github.com/14427/signal
[3] https://github.com/adamhaile/S/tree/e897ec1212a073bb1fe695e1...
"Signal" has been used in FRP circles for some time [1,2]. The original FRP stuff was events/signals and behaviours. But I agree that JS didn't use this terminology until more recently. S.js is maybe one of the earlier ones, but that was still over 8 years ago.
[1] https://scholarworks.rit.edu/cgi/viewcontent.cgi?article=651...
[2] https://github.com/14427/signal
[3] https://github.com/adamhaile/S/tree/e897ec1212a073bb1fe695e1...
The author does a lovely job of covering a number of the interesting ideas in this space. But reactive programming is such a tough sell. I know from experience.
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.
It predates it by a few years https://github.com/tonsky/tonsky.github.io/commit/fd5e59a837...