See the web app. It is a more productive style of coding. Simple, and no need to deal with hooks and useState and useContext and none of that nonsense.
I've read the web app and it seems to me it is just https://backbonejs.org/ re-written in Typescript and allows JSX.
I'm very certain Typescript and JSX will have improved the DX for Backbone like apps, but it doesn't address all of the other issues that teams had with Backbone.
e.g. Cyclical event propagation, state stored in the DOM (i.e. appendChild is error prone in large multi-person code bases), etc.
There is no two-way data binding in use here, so you're wrong.
The style used is MVC. Do you think MVC is not suitable for multi-person teams? If so how do you explain MVC in Cocoa, ASP.NET Core, JSP and JSF, Ruby on Rails, and Django (Python)? They are all based on MVC.
> There is no two-way data binding in use here, so you're wrong.
Cyclical data bindings and two-way data bindings are fundamentally different issues. Not knowing the difference makes it pretty clear you haven’t lived through a codebase that had these types of issues.
MVC seems great in sprit and breaks down at the first real interactive, stateful usecases.
> Do you think MVC is not suitable for multi-person teams? If so how do you explain MVC in …
Correct, I do not find MVC suitable for multi-person teams. You won’t believe me, but it is an incomplete abstraction that was previously relied on but since React and also modern video game engines it is no longer in favor.
Why is it still used by all those legacy frameworks? Because, frankly, they are old and haven’t evolved.
Apple has moved on from Cocoa to SwiftUI. Java devs have all but moved on from JSP (goodness those days were terrible). Rails for all its awesomeness has been stuck for years not able to move past itself and typically now paired with React or Vue.
MVC was a good stepping stone, but now we have learned and we are moving on!
Sorry none of this makes any sense to me. You can't have cyclical data binding when you only have 1-way data binding. MVC is absolutely perfect for stateful use cases. In fact, it is React that suffers a total breakdown in stateful use cases. If your component is stateful and you need to update props then the recommendation is to set and change a key, which replaces the component with a new instance. This of course eliminates any benefit that React provides.
Looks like MVC/MVVC, something that has been available to do in JS since long time ago (Backbone.js was a popular option for doing a modified version of this). Or I'm missing something obvious. Care to explain a bit more in detail?
No, Backbone.js doesn't do 2-way data binding, although some certainly made it do that. But it doesn't by default, it has a 1-way data binding (the UI updates when the model changes, but doesn't update the model automatically when the UI changes).
> Some people mistakenly think MVC implies 2-way data binding. It does not.
What? Who does that? I certainly didn't and I haven't heard anyone in my +decade of web development.
Famously, a Facebook engineer declare on stage that MVC doesn't scale. Later it turned out that she was talking about one specific implementation of MVC that used 2-way data binding. She assumed that 2-way data binding is part and parcel of MVC, because that's all she had seen.
"Lucene based search" vs React ? Seems like comparing trees to tractors.