MVU might not be what you think it is

[aspnetde]

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!

[davidortinau]

Thanks @aspnetde, I hope you'll join us as we work on implementing this idea over the next 18 months or so. Given your history with MVU, I expect you'll have much to contribute.

I think it's too early to say that .NET MAUI is or is not MVU since we haven't actually built it yet. :)

Yes, we have a prototype. Yes, it's inspired by the Comet experiment. And yes, we know that there is concern that what we have shown thus far doesn't match everyone's definition of MVU.

My hope is that we can collaborate! If what we end up designing and shipping deserves a different label, I agree we should give it one.

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

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

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?

[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.

[forki]

I think it's too early to say that .NET MAUI is or is not MVU

It's not about if MAUI will be MVU in the end. It's about the sample in the announcement blog that already raised so much confusion in the community. Basically I have to assume that the authors did not really look into MVU yet. Talking about "C# MVU" doesn't make this any better.

[dersia]

I agree with @aspnetde and @forki the problem here lies in communication.

I think none of us is arguing to drop or change the comet inspired C# DSL for MAUI/XF, but even if we take what is so far being done with it, this is still using the underlining binding-concept which is part of MVVM pattern.

This is something I have been asking over and over again in direct communication and alo in issues, maybe it is a good think for everyone involved to read up on different patterns like MVVM and MVU.

That being said, there is even a way of implemting MVU on top of MVVM, but the question remain what problem it would solve.

[davidortinau]

Have you ever heard anyone saying C# MVC or C# MVVM?

Yes, I understand it's odd to say C# or XAML followed by an architectural pattern like MVVM or MVU. Among the broader community of developers I speak with, there is the need to make clear that you can utilize any number of combinations within your project. The intention is not to say that a "C# MVVM" is architecturally different than "XAML MVVM", but that the combination is possible and the developer experience as a whole is thus slightly different.

I thought this thread might discuss how MVU would look in .NET MAUI, but perhaps the more productive discussion here is how we talk about multiple developer experiences and architecture patterns within a single product?

It seems like that's the direction of most comments here, wanting to discuss what we call and label things and how we use terms. I would dearly love your input on this, since I do much of the communication and want to make sure I'm indeed adding clarity and not generating confusion.

It's about the sample in the announcement blog that already raised so much confusion in the community.

That was my contribution to the blog and I apologize for the confusion it created for you. I miscalculated that by adding links to Elm and @aspnetde's blog that we were saying "this is what MVU is", and I didn't anticipate how much weight the code snippet would bear for those of you with existing MVU experience and expectations as to what it would/should look like here.

Basically I have to assume that the authors did not really look into MVU yet.

We have had extensive conversation and debate on the topic. Please don't assume, and I'll try not to as well.

the question remain what problem it would solve.

@dersia the general problem to be solved is giving developers choice. If you're asking what MVU on top of MVVM solves, I have no clue - this isn't something being asked for or something we are trying to do.

The refactoring as proposed in #28 and #66 is partially about separating the databinding and MVVM specific things from the renderer implementations such that if you opt for MVU you won't be taking on additional features used in MVVM.

[forki]

I didn't anticipate how much weight the code snippet would bear

But that's the meat, right? And I'm sorry it did not match the label.

[aspnetde]

@davidortinau

It seems like that's the direction of most comments here, wanting to discuss what we call and label things and how we use terms. I would dearly love your input on this, since I do much of the communication and want to make sure I'm indeed adding clarity and not generating confusion.

I'm not sure what's left to add from my side. I think I expressed my position loud and clear :-). If you're going to implement MVU, you will push at an open door. If it's what can be assumed by looking at the snippet in the announcement post and the Comet repository, feel free to do so – but please stop calling it MVU.

Thanks.

[Krzysztof-Cieslak]

As Don was mentioned in this thread :-) - CC: @dsyme

[isaacabraham]

I don't understand why this is being called MVU, when it isn't. It might be a great paradigm and work just great here - why not come up with a suitable term that fits the paradigm and doesn't confuse?

[tomasfabian]

@aspnetde what left from your side? A lot I suppose :).
I read some parts of your thesis. I have to say that I liked it. I also read the book from Don Syme about F#. I like functional programming. From my experience its concise, but difficult to grasp (understand). Readability is very important part of the development life cycle. Lot of the time is actually spent on reading code. And recursion is write only. You can write it once, but almost no one can read it (similarly to regexp).
In the past I tried Redux with Angular during my prototyping/research time in the company. Is it a half Elmish approach? It was a valuable experience. I learnt that I have to take care to not mutate the state, and as a result I will don't have to remember the whole stack, where exactly the state can suddenly change.
I understand the benefits of immutability, but I saw a presentation with Erik Meijer who suddenly tore apart a teddy bears head, to show us, that the real world is mutable.

So what I would like to point out: Isn't our natural thinking against these paradigms? What is your experience?

I have a lot of experience with XAML/C#/MVVM, so I'm wondering why Don Syme considers XAML unnecessary.
From my experience it helps to separate concerns (UI, presentation, business, etc. logic). I'm not really sure whether these DSLs (C# markups) and MVU are helping to improve the code quality in the long term. Not experienced/not caring developers will mix the responsibilities. I need also more experience with MVU pattern, to understand it correctly, but you tried both of these paradigms and it is very valuable for the whole community.
Please share as much as you can. Thanks @aspnetde!

Thank (all of) you very much for your understanding

[dersia]

@davidortinau maybe there was an misunderstanding here, I am totally for choice and leaving it to everyone to choose for themselves what pattern/paradigm to use. I was just trying to say, that we should name things correctly. As everyone in software development knows naming things is one of the hardest things to do, but if there are well defined things named already we shouldn't start reusing those names for things that they are not.

Miss communication Miscommunication is one of the biggest problems in our world today, I think as a community, as contributors to a project, as a leading project we should help everyone in understanding things and should also be open to criticism and admit mistakes and get together to fix that.
In this case I think using wrong wording needs to be fixed and for that to happen I'd love for this project to
a) understand that MVU is the wrong name for what we are talking about here
and b) to find the right term to describe what we are trying to establish here
and then c) update everyone and start using that new name

I think we are still at a point we're we can still go back and fix it. Let's do it right, the worst thing that could happen is that the XF/Maui community understands MVU as something else than the rest of the world.

That being said, I am a big fan of MVU and I also love MVVM, and I think the fluent MVVM approach (I don't have a better name yet) as in Comet and what has been presented so far is great and helps a lot of devs and I will support it, I just think we should fix the naming.

Edit: miss communication dropped out of the contest.

[dersia]

I understand the benefits of immutability, but I saw a presentation with Erik Meijer who suddenly tear apart a teddy bears head, to show us, that the real world is mutable.

@tomasfabian this is wrong.

You have to start to see the world as a series of events, that's what it actually is (no I don't want to start an event sourcing discussion here).
What happened to the teddy bear is only that a new event was added to its state, the event in this case is "ripped of head". And as you than can realize once an event happened you can't revert, as in you can't just undo or delete what happens. To get the head back onto the teddy you'd need a new event called "sewed head back on body". 😉

[isaacabraham]

Discussing the benefits or not of FP and MVU is IMHO off topic here. This issue was, I thought, just about the potential for miscommunication and accurate naming.

[tomasfabian]

@isaacabraham maybe you are right, and I apologize for it. It is my fault. I know that naming things is important, but on the other hand the issue's title is "MVU might not be what you think it is". So it is hopefully a little bit more broad topic than naming things.
Thank you, Tomas