4 ms·

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.
        valenterry 4y ago
        I see - I guess the OP had something different in mind when they meant UI, not just the pure View. But point taken, I understand your response.

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.
      - valenterry 4y ago
        I see - I guess the OP had something different in mind when they meant UI, not just the pure View. But point taken, I understand your response.