Elm vs Assisticant architecture
Opened this issue · 1 comments
As you can tell I'm just snooping around your repos for interesting things. I've never looked at the Elm architecture... does it differ from standard MVC?
There's a UI architecture that I immediately loved, because when I discovered it around 2010, I had been thinking along similar lines for years but hadn't been able to figure out exactly how it should work. I first saw it in a library called Update Controls, which the author eventually replaced with a similar thing called Assisticant. This is similar, but different, to the architectures in JS libraries like MobX and Vue3. To be honest I've never been a fan of MVC, and I don't see why people would choose it over something like Assisticant. But to have made this repo, you must be a fan of Elm's version of MVC, so I'd like to hear your thoughts and what you like about it.
I've never looked at the Elm architecture... does it differ from standard MVC?
The ELM architecture is basically what inspired React+Redux, Fable (Elmish) in F#, and the MAUI in the upcoming .NET 6.
At the core, it is an MVU - Model-View-Update loop, with the single model store, and the diff reconciliation algorithm (on top of the "virtual" DOM). I suggest reading the official document.
The ELM is also very fitting for such a kind of architecture - because it is a pure functional language with no mutable state or uncontrolled side-effects.
What I love, is the no events or randomly mutable state, plus state history rewind - automatic undo-redo.
There are downsides as well, first the performance (virtual dom, reconciliation) and plus more ceremony in some implementations like React-Redux, which I am particularly not a big fan of.
I believe there may be an "ideal" hybrid approach to UI with the functional updates and the direct bindings where needed. I don't have a proof for that but I'd love to experiment with this stuff.
similar thing called Assisticant.
I saw it once, but don't remember what is that, will check, thanks.