[nogridbag]

I've used several MVC UI frameworks in the past both on the desktop and web, and they all had the same problems. When the view becomes out of sync with the model, it becomes a nightmare to figure out why that's happening.

You have your model (data), and conceptually, you just want to bind that model to the view. But you have to write all this imperative code to do that. It's very simple with an imperative UI to have infinite loops even with very simple UIs. "When this field changes, I want to update this other field". But that other field has it's own event listeners that trigger other effects. The event listeners work fine in their own silo, but the interactions between fields cause unintended effects that are not obvious reading the code.

When the component is mounted, the behavior is very hard to reason about and you spend lots of time in a debugger tracing through all the event listeners just to reach the initial state of the UI. Additionally, in these frameworks the developer is typically responsible for cleaning up all the event listeners. It's very easy to forget to clean these up properly.

Once a UI reaches a certain complexity, you try to rewrite the imperative code so that it almost reads declarative and you wish you could simply use a declarative UI framework. I can't speak for React as I have not used that in a long time, but in Vue.js I never write the UI to use global state. All state is local to the views that it pertains to and with defineModel introduced back in late 2023, you can write small UI components without all the plumbing required in earlier versions. I've never experienced such a simple and reliable UI framework previously.

[mpweiher]

Author here.

> "When this field changes, I want to update this other field".

That's the problem MVC solves, and that not just a vast majority of so-called MVC frameworks (that are nothing of the sort) get fundamentally wrong, but also a lot of people talking about MVC, in particular those who want to "fix" this non-problem of MVC (see: React).

In MVC, fields never update other fields. The model also doesn't update any fields.

1. UI events update the model, and only the model

2. The model notifies the UI that it has been updated, and the UI is now inconsistent. It does not initiate an actual update, nor does send data to the UI.

3. The UI fixes the inconsistency by updating itself from the model. This can be a full update, or it can do something more clever to only update parts it knows have changed. This may be in response to an update notification or not.

No update loops. No inconsistencies (well except the temporary ones until the UI has updated itself, but those are part of the deal). Solved in the 70s.

I wrote about this here: Model Widget Controller (MWC) aka: Apple "MVC" is not MVC

https://blog.metaobject.com/2015/04/model-widget-controller-...

And here: Blackbird: A reference architecture for local-first connected mobile apps

https://blog.metaobject.com/2022/06/blackbird-simple-referen...

[nogridbag]

The update loop occurs as a result of step 3 in which the UI updates itself from the model which then, due to a combination of developer inexperience, UI framework design/complexity, or application complexity, the UI then automatically triggers updates to the model. In my experience, this was a common defect in all applications I've seen that used various MVC style frameworks or home grown MVC architectures.

In a declarative framework, while it is still technically possible, it is very rare. The current app I'm working on is one of the largest front-end apps I've worked on (multiple years of dev). We've had a single infinite loop issue reported that was trivial to fix. We have very junior UI devs compared to teams I've worked on in the past, yet our UI defect rate is incredibly low.

[marcosdumay]

> It's very simple with an imperative UI to have infinite loops even with very simple UIs.

That's something that reactive UIs inherited from the imperative events by design. It's not a differentiator here. You may be able to debug them better, but infinite event streams are pretty much still an issue, and about as easy to get.

Anyway, almost every problem in the article is a react problem, not a FRP problem. Vue may not have them, I don't know it well enough to say (but some do really look like a FRP in javascript problem, so they should apply there too).