3 ms·

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

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.

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.