5 ms·

> The problems with observable boil down to the fact that the callback requires a lot of context to know what change should happen in response to the event. In

> The problems with observable boil down to the fact that the callback requires a lot of context to know what change should happen in response to the event. In this way, I think it is fundamentally in tension with the goals of reactive UI, though some systems have managed to reconcile the two, often with compiler help to translate fairly straightforward declarative logic into an observable-based implementation: SwiftUI and Svelte come to mind. I don't understand the main issue brought up with observables. What exactly is that "context" you're talking about, and how is it bad? Observables, at least the way used in my https://github.com/raquo/Laminar/ https://github.com/raquo/Laminar/ UI library, define the dataflow graph of your application, letting you channel data into other data and/or into incremental DOM updates without using virtual DOM. You don't need any additional "context" to know what change happens in response to what, defining the flow of data with observables and then binding some of them to DOM parts that you want them to affect or to source data from is literally how you write your application logic. You will need to express that application logic somehow, and doing that using observables is quite straightforward. I'm not familiar with SwiftUI, but Svelte is not really any more about observables than React is. Disregarding how it's implemented under the hood, Svelte's API is made to be superficially similar to React but without virtual DOM, and that comes at a very high cost of designing their own language and requiring their own compiler. So you end up with a callback-driven API that to the user feels a lot like React's state + props + render method, and it's nothing like working with plain observables.

jbritton 6y ago
I think there might be an issue with definitions. I thought maybe Raph was talking about the Observer pattern from Gang of Four, and that you are talking about Observables as incrementally computed expressions. I can remember a long time ago reading about an Observer pattern for a UI. Views would subscribe to a model. When the model changed, the views were notified. The Views then queried the model and determined how to update. It was suggested that for more efficient updates the change notification could carry some information(context) to indicate what had changed. The article didn’t discuss this information optimization further.
- nikitaga 6y ago
  I see, you're most probably right, and this makes sense, thanks! But what does the author think of using observables then I wonder? I mean the streaming kind, like ReactiveX (but not ReactiveX specifically). They're first class representations of event streams and state – exactly the domain of a UI library – and working with observables has been very pleasant in my experience.
  - raphlinus 6y ago
    Yes, I think there was terminology confusion (terminology in this space can be a real dumpster fire - you don't want to know how many different things are called "widget"). I don't have very strong feelings either way about stream-based computation. I am skeptical that using them as a primary primitive for building UI is going to work out well. Things are nice in the static case, but it seems to break down a bit when there's dynamic reconfiguration. Evan Czaplicki has given good talks on his evolution away from purist FRP. It's also interesting to compare the original Elm thesis[1] with the farewell[2]. That said, I think it's a super-interesting experiment to try to integrate these ideas with the Crochet architecture and see how it turns out. [1]: https://people.seas.harvard.edu/~chong/pubs/pldi13-elm.pdf https://people.seas.harvard.edu/~chong/pubs/pldi13-elm.pdf [2]: https://elm-lang.org/news/farewell-to-frp https://elm-lang.org/news/farewell-to-frp
    - nikitaga 6y ago
      Elm has very different design goals than what I care for. I guess it's not purist FRP anymore but the elm architecture is definitely purist something. The problem in both cases is the purist part. It's way too much ideology and way too much machinery to achieve the simplest things. Look at this pinnacle of elm architecture for example: https://elm-lang.org/examples/time https://elm-lang.org/examples/time All this boilerplate just to display current time in current timezone. The same can be done with three very obvious lines of code in Laminar for example, without any regard for abstract purities, but with the same concrete outcome – a well bahaved h1 element that displays time. Scales to larger components and applications very well too. Cycle.js has the same problem as old signal-based Elm by the way, and for the same reasons: obsession with purity, and ignoring that observables are a poor match for virtual DOM. You can have one without the other, and have a much simpler system. If you already use observables, virtual DOM adds nothing of value, only a way to satisfy the irrational demand for purity.

jbritton 6y ago

I think there might be an issue with definitions. I thought maybe Raph was talking about the Observer pattern from Gang of Four, and that you are talking about Observables as incrementally computed expressions. I can remember a long time ago reading about an Observer pattern for a UI. Views would subscribe to a model. When the model changed, the views were notified. The Views then queried the model and determined how to update. It was suggested that for more efficient updates the change notification could carry some information(context) to indicate what had changed. The article didn’t discuss this information optimization further.

nikitaga 6y ago
I see, you're most probably right, and this makes sense, thanks! But what does the author think of using observables then I wonder? I mean the streaming kind, like ReactiveX (but not ReactiveX specifically). They're first class representations of event streams and state – exactly the domain of a UI library – and working with observables has been very pleasant in my experience.
- raphlinus 6y ago
  Yes, I think there was terminology confusion (terminology in this space can be a real dumpster fire - you don't want to know how many different things are called "widget"). I don't have very strong feelings either way about stream-based computation. I am skeptical that using them as a primary primitive for building UI is going to work out well. Things are nice in the static case, but it seems to break down a bit when there's dynamic reconfiguration. Evan Czaplicki has given good talks on his evolution away from purist FRP. It's also interesting to compare the original Elm thesis[1] with the farewell[2]. That said, I think it's a super-interesting experiment to try to integrate these ideas with the Crochet architecture and see how it turns out. [1]: https://people.seas.harvard.edu/~chong/pubs/pldi13-elm.pdf https://people.seas.harvard.edu/~chong/pubs/pldi13-elm.pdf [2]: https://elm-lang.org/news/farewell-to-frp https://elm-lang.org/news/farewell-to-frp
  - nikitaga 6y ago
    Elm has very different design goals than what I care for. I guess it's not purist FRP anymore but the elm architecture is definitely purist something. The problem in both cases is the purist part. It's way too much ideology and way too much machinery to achieve the simplest things. Look at this pinnacle of elm architecture for example: https://elm-lang.org/examples/time https://elm-lang.org/examples/time All this boilerplate just to display current time in current timezone. The same can be done with three very obvious lines of code in Laminar for example, without any regard for abstract purities, but with the same concrete outcome – a well bahaved h1 element that displays time. Scales to larger components and applications very well too. Cycle.js has the same problem as old signal-based Elm by the way, and for the same reasons: obsession with purity, and ignoring that observables are a poor match for virtual DOM. You can have one without the other, and have a much simpler system. If you already use observables, virtual DOM adds nothing of value, only a way to satisfy the irrational demand for purity.