5 ms·

FRP is a fascinating paradigm, but I find I really have to turn my brain inside-out to "get" it. But it's really cool to have UIs that are completely consistent

FRP is a fascinating paradigm, but I find I really have to turn my brain inside-out to "get" it. But it's really cool to have UIs that are completely consistent.

mpweiher 4y ago
The funny thing is that good ole MVC also gave us UIs that are completely consistent.
- valenterry 4y ago
  Not really. It's just that at the time, SPAs and concurrent requests were not really a thing or only used rarely.
  - cybrox 4y ago
    You can build perfectly fine SPAs using an MVC architecture, even with lots of concurrent requests and data fetching. This is why JS has an event loop and why we invented data-binding.
    - wiseowise 4y ago
      You can build perfectly fine SPAs in one big file, what’s your point?
  - mpweiher 4y ago
    Yeah, actually really. Actual MVC has the model notifying the UI that it has changed and then the UI updating itself from the model, by pulling data. That's always consistent. We then did all sorts of things that we call MVC, but that do not follow the MVC-defined interaction patterns at all, particularly either the model or other views incrementally poking data into the view. That doesn't work, and it is nigh impossible to keep consistent. It also isn't MVC. I haven't written this up stand-alone, but I talk about it a little here: https://blog.metaobject.com/2022/06/blackbird-simple-reference-architecture.html https://blog.metaobject.com/2022/06/blackbird-simple-referen...
    - valenterry 4y ago
      So, what if you have a background process (running in the controller I assume) that updates data in the model periodically from somewhere. And at the same time you have the user making changes to the model. How is consistency guaranteed here by having "UI updating itself from the model, by pulling data"? Maybe I have a different understanding of "consistency" but this might very well lead to undesired results if the logic of data updates isn't well-controlled. The developer needs to decide if the updates can happen arbitrarily or if some kind of transaction-model needs to be used, forcing the background process to wait during user interactions or the other way around, etc. I don't see how MVC solves that problem.
      - mpweiher 4y ago
        This is not MVC's problem to solve. It also doesn't solve global warming. If you have unprotected multithreaded imperative updates of global data, nothing is consistent. Has nothing to do with MVC or no MVC. Actually having a consistent state to present to the UI is the model's problem. Oh, and for goodness sake, don't have any kind of async update process running in the controller. All this stuff belongs in the model. If you're doing that sort of stuff in the controller, I can see why you're having problems with concurrency. You're also almost certainly not doing MVC.
        valenterry 4y ago
        > If you have unprotected multithreaded imperative updates of global data, nothing is consistent. Yeah, but that is exactly what FRP solves (or strives to solve) and MVC does not give you on it's own (as you said). Ofc MVC can be used in combination with other techniques to gain consistency, but it doesn't provide it on its own, which is what I believe was implied by your original post. If you were just talking about the UI in isolation, then yeah, maybe MVC gives you that, but it misses the point of what FRP gives you.
        mpweiher 4y ago
        > If you were just talking about the UI in isolation Comment I was replying to: >> But it's really cool to have UIs that are completely consistent. So yes, we kinda were talking about the UI, keeping that consistent (with the model, presumably). Hence MVC. Keeping the model consistent is another topic.
- klysm 4y ago
  Yeah but for a limited subset of desirable functionality. It sucks to use for something where you want a dynamic UI.
  - mola 4y ago
    Can you elaborate? An example for a feature which would be a real pain in MVC but easypeasy with FRP?
    - klysm 4y ago
      I’m not saying FRP makes anything easy, just that there’s a set of things that are desirable that MVC makes difficult. Right now I’m making a graphical node editor with a lot of drag and drop that displays live data streams. I can go into more detail about why a typical MVC sucks for this but it definitely does.
      - mola 4y ago
        I apologize if it came out as if I don't agree. I asked out of ignorance I truly find FRP interesting and wonder when is it the right tool. It'll be very interesting to see this a sort of concrete comparison.
- daxvena 4y ago
  Another funny thing is that good ole vacuum tube computers could automate computation before transistors became widespread.
- valcron1000 4y ago
  I disagree. The moment my controller needs to "set" or "update" something in the model the whole thing becomes a mess in my experience. FRP requires that you change the way you code but it's 100% worth IMO.
  - mpweiher 4y ago
    Well, you can let the view do this and things get better ;-)

FRP is a fascinating paradigm, but I find I really have to turn my brain inside-out to "get" it. But it's really cool to have UIs that are completely consistent.

mpweiher 4y ago

The funny thing is that good ole MVC also gave us UIs that are completely consistent.

valenterry 4y ago
Not really. It's just that at the time, SPAs and concurrent requests were not really a thing or only used rarely.
- cybrox 4y ago
  You can build perfectly fine SPAs using an MVC architecture, even with lots of concurrent requests and data fetching. This is why JS has an event loop and why we invented data-binding.
  - wiseowise 4y ago
    You can build perfectly fine SPAs in one big file, what’s your point?
- mpweiher 4y ago
  Yeah, actually really. Actual MVC has the model notifying the UI that it has changed and then the UI updating itself from the model, by pulling data. That's always consistent. We then did all sorts of things that we call MVC, but that do not follow the MVC-defined interaction patterns at all, particularly either the model or other views incrementally poking data into the view. That doesn't work, and it is nigh impossible to keep consistent. It also isn't MVC. I haven't written this up stand-alone, but I talk about it a little here: https://blog.metaobject.com/2022/06/blackbird-simple-reference-architecture.html https://blog.metaobject.com/2022/06/blackbird-simple-referen...
  - valenterry 4y ago
    So, what if you have a background process (running in the controller I assume) that updates data in the model periodically from somewhere. And at the same time you have the user making changes to the model. How is consistency guaranteed here by having "UI updating itself from the model, by pulling data"? Maybe I have a different understanding of "consistency" but this might very well lead to undesired results if the logic of data updates isn't well-controlled. The developer needs to decide if the updates can happen arbitrarily or if some kind of transaction-model needs to be used, forcing the background process to wait during user interactions or the other way around, etc. I don't see how MVC solves that problem.
    - mpweiher 4y ago
      This is not MVC's problem to solve. It also doesn't solve global warming. If you have unprotected multithreaded imperative updates of global data, nothing is consistent. Has nothing to do with MVC or no MVC. Actually having a consistent state to present to the UI is the model's problem. Oh, and for goodness sake, don't have any kind of async update process running in the controller. All this stuff belongs in the model. If you're doing that sort of stuff in the controller, I can see why you're having problems with concurrency. You're also almost certainly not doing MVC.
      - valenterry 4y ago
        > If you have unprotected multithreaded imperative updates of global data, nothing is consistent. Yeah, but that is exactly what FRP solves (or strives to solve) and MVC does not give you on it's own (as you said). Ofc MVC can be used in combination with other techniques to gain consistency, but it doesn't provide it on its own, which is what I believe was implied by your original post. If you were just talking about the UI in isolation, then yeah, maybe MVC gives you that, but it misses the point of what FRP gives you.
        mpweiher 4y ago
        > If you were just talking about the UI in isolation Comment I was replying to: >> But it's really cool to have UIs that are completely consistent. So yes, we kinda were talking about the UI, keeping that consistent (with the model, presumably). Hence MVC. Keeping the model consistent is another topic.
klysm 4y ago
Yeah but for a limited subset of desirable functionality. It sucks to use for something where you want a dynamic UI.
- mola 4y ago
  Can you elaborate? An example for a feature which would be a real pain in MVC but easypeasy with FRP?
  - klysm 4y ago
    I’m not saying FRP makes anything easy, just that there’s a set of things that are desirable that MVC makes difficult. Right now I’m making a graphical node editor with a lot of drag and drop that displays live data streams. I can go into more detail about why a typical MVC sucks for this but it definitely does.
    - mola 4y ago
      I apologize if it came out as if I don't agree. I asked out of ignorance I truly find FRP interesting and wonder when is it the right tool. It'll be very interesting to see this a sort of concrete comparison.
daxvena 4y ago
Another funny thing is that good ole vacuum tube computers could automate computation before transistors became widespread.
valcron1000 4y ago
I disagree. The moment my controller needs to "set" or "update" something in the model the whole thing becomes a mess in my experience. FRP requires that you change the way you code but it's 100% worth IMO.
- mpweiher 4y ago
  Well, you can let the view do this and things get better ;-)