MVU might not be what you think it is

When I was reading the official announcement the other day, I was surprised what was presented there as MVU:

readonly State<int> count = 0;

[Body]
View body() => new StackLayout
{
    new Label("Welcome to .NET MAUI!"),
    new Button(
        () => $"You clicked {count} times.",
        () => count.Value ++)
    )
};

As far as I am concerned, this is not MVU. I already wrote down some thoughts on why I think so here.

Don Syme, who, as I understand, spent several months of 2018 on implementing MVU on top of Xamarin.Forms and building what later became Fabulous, is a bit more diplomatic, but the bottom line is the same.

So, what’s my point?

• I would love you to implement the real architectural pattern, no matter if in C# or F#. Reaching out to the people behind Fabulous could be a start here.
• If you are not interersted in that but have a clear vision on building on top what is available today as the Comet library, then please consider using a more appropriate name for that “app model.” Invent something new. Name it MSMVU. Whatever. But don’t sell apples for oranges.

Cheers!

[dsyme]

Since I’ve been mentioned here, I will just say a few things.

• I think MAUI is great and I think learning about MVU as an architecture can be useful for people to understand MAUI.

• It’s easy to get hung up about words, and we should probably all take a breather and try not to worry about it at this stage, since there’s plenty of time to adjust the words that are used and I think the message about accurate terminology has been heard. Personally I think Elm has established that the unadorned, unqualified use of “MVU” means explicit messages, explicit update, functional models, functional view recalculation and differential update. But there are many variations of MVU and MAUI is one point in that spectrum (which covers all the way to MVVM as a sort of manually-incrementalized message processing system with implicit, pervasive mutable state). The SwiftUI communication is interesting from this perspective.

• I notice people tend to have very strong beliefs and opinions in this area and can take things quite personally. I know what that’s like, and like programming language design I think all points in the space have pros and cons. I’d encourage everyone to try out, use, learn, share and work together to make the best range of technologies possible.

[aspnetde]

How would you expect to see C# MVU in .NET MAUI?

Have you ever heard anyone saying C# MVC or C# MVVM? Model-View-Update aka The Elm Architecture is a well-defined architectural pattern, not a language-dependent implementation.

What new language features would you see needed, if any?

• While union types would help to simplify the definition of messages massively, that can be done through interfaces/abstract classes and a sub-class per message, although that requires a bit more boilerplate code to write.
• In order to process messages, pattern matching is helpful if not required. I think the current state of C# switch expressions is already good enough for that, as the shape of messages will be simple.
• Last but not least, the most important feature I see is immutability by default and enabled structural equality comparisons. As far as I remember the current proposal of records in C# 9 (aka data classes), those will deliver exactly that.

So C# 9 would, while still be more noisy than F#, be good to go from my current point of view.

Could/should we consider integrating Fabulous and/or what patterns does it make sense to make common between C# and F#, and what ought to be different?

As written above, there should not be anything particularily language-specific in the overall approach as MVU itself is just the architectural style or app model as you call it.

@TimLariviere Has made some proposals to move Fabulous forward recently, which also includes ideas around a more SwiftUI-like DSL. You might want to have a look and/or engange there, too.

---

By the way: I’ve made a 1:1 comparison of XF + C# + MVVM and XF + F# + MVU last year, the results can be found here – including source code.