mergeconflict212
[00:00:00] James: [00:00:00] Yes, Frank you're opening today. 
Frank: [00:00:12] Can you do the three, two again? Sure. Three, 
James: [00:00:16] two, one. 
Frank: [00:00:18] Hey James, this week, I have kind of requested topic from a friend of the show, Ryan, but it's also something that I think we've talked about before. And I think that I just keep making, passing arguments. I thought we would do a whole episode.
Brace yourselves. It's an architecture episode on M V you model view, update the architecture that is replacing all your known patterns. James. Um, what are your thoughts? Can we do a whole episode on this puppy? Yeah, 
James: [00:00:52] mostly. I mean, we've done full episodes on MVVM on react on all the different things under the sun and.
There [00:01:00] has more recently been more talk about NVU it's been around for a long time. I, I sort of think of it in correlation to sort of like, um, I would say more like F sharp as programming, functional programming, flutter development really is me a stance with NVU, but there's a lot of other frameworks that are out there, I think is even react technically kind of an MDU framework.
Not 
Frank: [00:01:28] just technically, I would say it's the most successful. Absolutely. Yeah. And as you know, react is on JavaScript, so it's definitely not just a functional language thing. Hmm. But, um, you're absolutely right. Definitely, um, the functional language world, especially the immutable data world has really embraced it for a way to build user interfaces.
I don't know how many functional language books you've read in your life, but basically none of them talk about user [00:02:00] interfaces. It's kind of sad. 
James: [00:02:02] But I guess if, if there, if there's no talk of, well, that's a nice thing is there's no talk about user interfaces, then they can talk just about the pattern, right?
People that really want to get into the pattern. But what I'm assuming is the issue. Is that the two go together like peanut butter and jelly. Like the, the, if the UI framework pairs very nice with the architecture then bingo, bingo. Everything is great. Like as how I sort of think of XAML and MVVM because XAML the declarative markup with the binding.
System plays very nice with an MVVM model view, view model, updating pattern and command system, the coupling, if you will. Those two things, uh, play nice together because the UI, uh, syntax was sort of built around the architecture. 
Frank: [00:02:54] Yeah. Yeah. There's a lot to unpack there. You had to say MVVM so I'm like we could [00:03:00] probably spend two hours comparing and contrasting these two frameworks, but if you don't mind, uh, could I take a step back and just give a high level overview of kind of how I see the whole world so that we're kind of talking on the same page here.
James: [00:03:14] I like that. This is how Frank sees the world 
Frank: [00:03:19] of architecture. I remember. 
James: [00:03:21] Architecture 
Frank: [00:03:22] flashing lights, um, electrical engineer over here. So we tend to think in diagrams and data flows, and we like to draw little diagrams for describing systems. Uh, we draw a block for some data, and then we draw another block, which is some other kind of data.
And then you draw an arrow between them. And that means I transform this data into that data. Uh, you might also see this called category theory for the math nerds out there. But, you know, you can break any system down. We love to draw diagrams of, you know, data goes here, then it goes through the system.
Then it goes through the system. It's a very logical way to think of your applications. [00:04:00] So the big epiphany or revelation, sorry to use religious words there, but with NVU is that the user interface is just data. Also. So if I can write a function that goes between one data model data type into another data model data type, then would it be nice if one of those data model data sites was just user interface.
So if I want a button, I can just say, put a button here. I can transform from my model to buttons. And I think that that's kind of the most wonderful part of MDU is that. Simplicity there that in the end, it's just kind of a function, maybe a complicated function, but it's just going from one data to another.
Otherwise there's nothing special going on. Yeah. 
James: [00:04:44] And when we think of, I guess, M VVM side of XAML development, right? Cause MVVM is separate from. XAML like they're, they're completely separate again. VVM is the architecture and then VU is the architecture and then there's the UIs that shove [00:05:00] them together.
I guess the question I have is, I guess if you were building just coded UI, like, you know, just C-sharp UI or whatever, I'm like a new button. How I guess is that different with MBU? Cause you're saying like it's a data type, but isn't. A button already a type in the code behind technically or knows a difference.
Frank: [00:05:23] Yeah, it is. Um, so the big can of worms that I left off there was, I was talking about data flow in one direction from your model data into a button, but I totally left off the, what happens when a user clicks that button, basically the click event handler, how do you do event handlers and this kind of data flow ish kind of thing, right?
And get to do the comparison to MVVM and MVVM we have binding and you just work your way back up that chain. And the data kind of has persistence. [00:06:00] It's, you know, an object, it's a reference type. It's not a value type. And so they sit around, they all subscribed to each other's events. So, you know, data flows and run one direction and then data flow backwards.
So of course, We call that feedback. So feed forward feedback. Um, So, of course you need that in MBU and that's where you get into the millions different frameworks for NVU it's everyone's solving the feedback problem. How do I go from a click handler back, but just to take another pause moment, that's a nice company and contrast moment with MVVM where.
And MVVM you have a million, little data paths, a million events, a million objects, property subscriptions. So it's not like this beautiful feedforward graph. It's really a million little tendrils. It looks like a forest kind of graph. 
James: [00:06:52] Yeah, the MVVM approach is very event based. I mean, you literally trigger an [00:07:00] event to notify your user interface, to go update something.
So, uh, and then in that instance, the, uh, framework, the framework then needs to subscribe to that event and know how to update the UI control. So an example is that. How buttons an event for a click is subscribed to which then triggers a method that you say, please call this method that has an interface attached to it.
When some user does something, and then you do some stuff in that method, which is decoupled from the UI. Then you update some properties and then you say, Hey, User interface. Hope you're listening. And please update these right. Please go update these things that I'm going to manually tell you. I have to raise a notification to say, go update this stuff.
And then if you've set up your user interface correctly to subscribe and bind, if you will, to those properties, [00:08:00] when said. Property is updated the UI updates a while. So it's kind of this full circle pattern of venting, right? There's literally a native event that triggers your action, which then triggers events that are subscribed to, to update.
So this is very, uh, long list ended in a way. I mean, it works out. Look at me. When you think, when you think of it, everything's an event. And, uh, you're subscribing, you know, the framework subscribing and stuff, but the UI subscribing this stuff and you tell it what to do and when to do it, uh, it works very well together.
Uh, however, that does seem like a lot, a lot of, uh, when you think of MVVM it is, it seems like a lot, like a lot's happening. Like you said, there's all sorts of stuff. Everything is happening. 
Frank: [00:08:44] Yeah. And you said that very well. Um, so it sounds nice. Um, there are kind of two big problems with it. I think we've all found when dealing with it.
Um, the first is kind of obvious, especially if you don't have a good binding framework, [00:09:00] like we, we keep mentioning XAML and XAML is great because it has a nice binding framework, but if you've ever done native Android programming or iOS programming, you know, you don't. Have such a wonderful system and therefore James, you know, the annoyance of sure.
Sure. My UI has subscribed to all these events, but when the UI is hidden or otherwise goes off screen, it should unsubscribe from those events. And it's a pain, like the more events you subscribe to, the more work you have to do to unsubscribe at the right moment and all of that, there are whole frameworks designed to ease that burden because it's honestly such a pain.
I know, you know that pain we've talked about it before. 
James: [00:09:39] No, it, it is pain. I've, I've rolled my own frameworks before you've rolled your own, uh, before Xamarin forms and before prison. And before MVVM cross before all of these other ones that were out there, uh, you know, cause often coming from like the windows world with WPF or, or UWP or phone or Silverlight or [00:10:00] whatever, right there was, there was all built into this framework.
So it was very XAML MVVM binding first. And iOS and Android, we're not like you said, uh, Android now has some binding stuff if you're doing it in Kotlin. Uh, however that said, I believe even Google kind of wants to go to a code first approach. Uh, I don't know if they're really going with an MVV or an NVU approach, but funnily enough, they have a data type called view model.
In in, in theirs. And in fact, iOS has a view controller, which comes from an, um, MVC type of thing. Right. So all different architectures, but it is fascinating that that MVC and MVVM often play very with a declarative syntactical [00:11:00] gooey based user interface. So for an example, is. Um, obviously the designer, the storyboard, right?
Or the Android XML or the XAML, you usually there's some declarative glue that, uh, can be represented in a graphical user interface. Whereas when I look at Swift UI, which has a preview or whatever has some stuff over there, it's not really exactly the same. It's more of like, here's a snapshot of. Of your running application in a way.
Um, and same with like flutter, right? It's like run your real application. Cause there is no drag and drop thing. 
Frank: [00:11:37] Yeah. Um, I guess the most insulting way to talk about and Samels to call it a template ING engine, you're just going from, here's a model, here's the UI to present for that model. It's better than that because it can go backwards.
But I mean, think back to NBC, where, what is the one of the largest deployments of NBC? It's the web, it's a Ruby on rails [00:12:00] and that's a templating engine. That's HTML. So they solve that. What I call the forward problem very easily. Um, here's a model generate a UI for me, but I was talking about, um, all those events and the unsubscription problem and the, the root of that problem.
Is that these UI elements are persistent they're objects, the reference types, they're big, heavy reference types. You create a button it's allocating some major OSTP resources. You know, it's going to hang on to its events as long as I can got a whole life cycle cycle associated with it. Whereas to contrast an NVU.
The user interface is very lightweight. You can create objects and throw away objects at will. They are, you're supposed to consider them pretty much free. And therefore you don't have, I have the event on subscription problem because the Symantec model is you're throwing out the UI [00:13:00] every time the model changes anyway.
That's the semantic model. There is no concept of this is a button and will always be a button. And it's on the screen right now. It's just more like given the state of the app and given the model data, build me a new UI. So me personally, that's kind of actually where I first fell in love with this. Um, UI style was, I was just getting tired of events, simply put, and I wanted a simpler UI kind of building system.
Now it's ironic that that same lightweight. UI system, you can build it out of good syntax and create something like Swift UI, but fundamentally it's that difference of this is a UI generate quickly, or is it some kind of persistent thing that I have to manage over time? 
James: [00:13:46] Yeah, that makes sense. It's almost as if it's a yeah, like you said, did you say like a higher level object?
That's so most  decoupled from the underlying platform. Is that like a good way? 
Frank: [00:13:58] Yeah, it [00:14:00] doesn't have to be. It's just that all our platforms are object oriented and heavy weight. So right now we have this classically, we call it the impedance mismatch. It's like when you create an ORM and object, relational mapper, now you need, um, A lightweight UI to heavy UI mapper and the react world, they call this the shadow Dom.
It is just like the Dom, except it doesn't carry all the weight of the Dom. It's not, it doesn't have all the events. It's more, just a simple data structure that they can throw in and out then the whole trouble, the whole, I mean, the entire NBU framework is, uh, just. Making that lightweight representation reflected in the, um, the heavy O S one.
So that's all an NVU library does, is take this shadow version of the UI and make the UI actually change into it. So it's handling that heavy part for you and ideally. Gotcha. 
James: [00:14:58] Gotcha. Yeah. That [00:15:00] makes sense. 
Frank: [00:15:01] The other problem with the a million events strategy to writing applications. And we try not to think about this, James and we do our best not to think about this, but if you have one event, life is easy.
It comes in once and nothing else can happen. Okay. Two events, well, a can happen before B or B can happen before a fine. Three events. Oh, a a, B, C a C B, B, C a, B a, you know, there's a big ordering of events that can happen. And it's a full permutation of the set of events. So if you're subscribing to 2030 events, your test space for what you should be testing in your app is.
Bigger than the number of atoms in the universe. It's ridiculous QS, exponential growth that you can get into with an event system. Now we lie to ourselves and say, well, this event could never happen before that event, but it's [00:16:00] all. I mean, honestly, I feel like the majority of bugs are us just not getting our event orders.
Correct. And understanding them. 
James: [00:16:07] Got it. Yes, I do. I believe that that is a I've events are always complicated because it's like, okay, well, to me, when I was rolling my own sort of framework, I look at it and I'm like, okay, Well, when do I subscribe? And when do I own subscribe on appearing or after, or on create or after create, like, if I do it on create, what if I navigate back?
Like, does it matter if I'm on the screen, but what if someone's updating that screen? You know, there's a lot of, uh, conundrums, like very, a lot of edge cases and raise conditions between your application and, uh, the operating system. 
Frank: [00:16:44] Yeah. And there's a lot of implicit assumptions that you might make even just by event names, like button down.
Well, is there always a button up to follow? Could there ever be a button up before a button down? Like we always just kind of assume there's going to be a button down and then a button up. But [00:17:00] you know, I built where I know how switches work. It might, you might get an errand signal or something like that.
So there are just permutations upon permutations of event orderings that we literally just can't test for. And don't test for. Both of those words, the nice thing about the MDU architecture. Is that semantically again, this is not exactly how they're implemented, but the way it should work in your mind is there's only ever one event.
That event is the data changed. It's up to, to you to regenerate the UI now based upon the current data. So instead of you having to figure out those 8 billion permutations of events that could ever happen in your app, your task is back to your basic task of just build the app and we'll handle it.
Inevitably the event ordering will be settled for you because you're only ever going to get one event and it's going to be the everything changed. You have to assume at the beginning that the entire world changed every time you'd rebuild [00:18:00] the UI. 
So 
James: [00:18:01] that is sort of the update part of model view update, right?
Which is, Hey, in the, when we thought about the events of anything could change, anytime we gotta subscribe, make sure it's correct. And we're. W w we think of that as a nicety, because we believe that the UI frameworks are basically, you know, doing the right thing and updating only the bits and pieces that need to update.
That's what we hope that they're doing at least. Um, whereas, or you're saying that with the update, it will just call at least the method to regenerate the user 
Frank: [00:18:41] interface. Yeah, the entire user interface. If you have 10 windows, it's got to do it 10 times for each one of those windows. And I think that that insults a lot of people just like, as an engineer, you're like, well, that's too much work.
Um, that's ridiculous. But, um, if you take some [00:19:00] time and think through the actual numbers that we're talking about and how complex UIs actually are, like UIs are. 10 levels deep, roughly, um, 10, 10 levels wide. You know, they're actually not that big if you account for all the labels and the buttons and the hierarchy and all that.
So we're generating whatever. I'm not going to do the math, but you know, a hundred to a thousand objects, you know, each time, you know, if you concatenate yeah. Two strings, you're allocating potentially like kilobytes and kilobytes of data, you can fit a UI in kilobytes and kilobytes of data. It turns out so.
Even though it sounds horrendous that you're rebuilding the entire UI, no matter what happens, there's no intelligence being applied. It's a big hammer. You're knocking down the house and rebuilding it, knock the house down, rebuild it. Um, it's really not that bad. And then the, the, the intelligence of the framework of the NVU framework is taking that lightweight representation.
Like I was saying earlier [00:20:00] and making the actual heavy way, Oh, West UI match 
James: [00:20:03] it. Got it. Well, let's talk about some of those UI works and sort of how they go about implementing it, because I believe a lot of this envy Utah will be of interest when it comes to Don and Maui, which is a new UI framework launching next fall, the evolution of Xamarin forms.
And we think about Xamarin forms. We think of XAML. We think of MVVM now we're thinking of some new stuff, but let's quickly take a quick break here and thank our good sponsor this week. Ray gun. Listen, are you struggling to replicate bugs and performance issues that your customers are reporting happens to me all the time.
Don't worry. It's okay. We can admit it. All you gotta do is plug Reagan into your web or mobile application or both, and you can diagnose problems in minutes rather than hours. You can kiss goodbye. Having to dig through log files on frustrated user reports, and you can make your software development life so much easier using Reagan's built in error, crash, and performance monitoring tools.
Every single software team can create flawless software experiences for their [00:21:00] customers with Reagan. Try it for free today@reagan.com. Go to reagan.com and start your free trial today. And thanks to Reagan for sponsoring this week's pod. 
Frank: [00:21:11] Thanks Reagan. And thanks, James, for not making fun of how many bugs I have on my apps.
James: [00:21:15] Yeah, no, I don't know. This time I gave you a, gave you a pass, you know, whenever we talk about, about architecture, I get real excited. 
Frank: [00:21:22] Okay. So just got to keep you in a good mood. Yes. So I thought we would, um, a lot. But I actually wanted to get out today. That was fun. Kind of doing an overview, but I've actually been asked online, there's this real debate going around about what's real.
NVU James and what's fake and VU. You know, we have a bunch of frameworks coming out that are implementing something along the lines of what I've been talking about and. I don't like this debate at all. Um, I think we've already seen how many similarities there are between MVVM and VC and the you that, [00:22:00] you know, there's infinite variety 
James: [00:22:02] out there that there's an, all of them.
There's a model and a view, 
Frank: [00:22:06] right? Yeah. I mean, you could almost argue what I was calling the feed forward path before it's identical in all of these. So we're really only talking about that last little bit about how do we get the data back. Into the model. I really deep down feel that way. And so whenever someone's calling out a library is, Oh, that's taken view because it's not using, we'll get to it.
But the Elm architecture is a really popular version of the IU part. Um, people are like, it's fake. It's not real. But to me, you're really missing the point. The point to me is the simplification of the event system. And the idea that you build. The UI from scratch every time, therefore not having all these race conditions in your app, but that said, Oh my God, people out there have opinions on how to do the IU part.
James: [00:22:55] Well, I mean, that makes sense too. Cause I think that there's a lot of opinions on how to do the VM of [00:23:00] VM. And just in general, I mean, if there's architecture, people will have opinions. 
Frank: [00:23:06] Yeah, exactly. Fair enough. Fair enough. So if we go back, um, let's see. We could go by, I no know the exact history of any of this stuff, because it is a pattern.
People have been doing this for ever since there've been computers. People have been writing UI like this, but it's gotten all the rage. I think the big one that really shook the world was react. Because up til now, um, all web frameworks, especially JavaScript UI frameworks, where jQuery and angular, all things, trying to be kind of native programming.
Kind of setups, especially cause that's how the Dom works. The Dom is an object oriented thing or with events and you're supposed to subscribe to events and unsubscribed from events. It's very complicated. So react was kind of the first framework that said, look, just write some [00:24:00] functions that converts from your data model to your UI.
We'll even give you this template language, but whatever. That's a secondary thing who cares. This is the template language, right? Go write these functions. We're going to create this crazy thing called the shadow Dom. And we're going to take care of the updates. Your events system is simplified. Now one update, blah, blah being.
Blong no bugs. And people are like, dang, this is great. Her no bugs, because look what happens when you simplify high programming. So I think react is one of my favorites. The problem with react, James is they did not solve the you part. They left off the you part. Uh, they said, write us these functions.
We'll build you UI what you do inside your button, click the hand, or the we're not going to talk about that. So it left a lot of, um, well, diversity we'll call it diversity on how people implemented that. And you might've seen a framework called like redox or something like that. That was Facebook's attempt at the U part.
But I think just. React needs to get its recognition for kind of waking up the web world to [00:25:00] the style. 
James: [00:25:01] Yeah. I sort of remember going to a few react, uh, um, sessions at different conferences back in the day and sort of understanding it, which was. Pure react was whenever someone does something, just, it updates the entire thing, like, boom, here's, here's the update.
Like you sort of figure it out. Um, and they didn't really get beyond that because it was really just introduction to react. And then didn't want to introduce all the other shenanigans, which we have talked about Redux, I believe on a previous Todd. So I think there's a lot of, uh, A lot of overlap there, right.
As we start to talk about NVU and these other things that are there. But I guess when I look at, um, other things like F sharp or fabulous or flutter, or sort of the new stuff with Donnette Maui, are those, I guess, considered, or would you consider those [00:26:00] sort of the, the, the, um, relay. Relay, no redox part of it relay, there are so many things that start with our Redux part of it, like, are those built into that framework?
So there's other things on top of it, or how does that work? 
Frank: [00:26:14] Well, you know, the worst part is I've read the Redux white paper a hundred times and it makes absolutely zero sense. Like it's so. Vaguely specified generalize. However you want to call that, that when I say Redux, it's actually a library people use because the spec is just useless.
Um, but um, if we get into. Um, like Maui, I think the current version of Maui, um, does not seem to have embraced the, we rebuild the UI from scratch every time. Now there was a.net project. I know you're familiar with it. Cause it's friend of the show Clancy building his comment API and yeah. Comment is a proper [00:27:00] full on, um, NVU.
That said even comment got a lot of flack from the MDU people for how exactly the U part was being implemented. Yeah. And it's awkward cause it's just like, yeah, yeah. I'm sorry. Okay. It's awkward because it's a vaguely specific if I problem with a million solutions. So of course there's a million good solutions and the way, um, comment did it, was it, it stuck with the, um, mutating objects that we all know from dotnet.
So we have observable objects with settable properties and observable collections, you know, the standard. VM or yeah, VM view model stuff from MVVM. Uh, so comment was really cool cause it really kind of bridged those two worlds because there is an understanding that there is a lot of dotnet code out there that assumes mutation and I notify property change and it'd be silly to throw all that knowledge.
And stuff [00:28:00] away. So comment had that forward pass that I was describing about the light wait creation, but then you old timey.net stuff for, um, the update part. Yeah. 
James: [00:28:12] Got it. Got it. That makes, that makes sense. Well, also, because the thing is in a mobile application, it's not super realistic to recreate the entire user interface because I'll label updated.
You know what I mean? 
Frank: [00:28:28] Yeah, you would think so. So someone said that online and I got very upset and I went and wrote a library called a mutable UI. And then you and I did a podcast on set library called immutable UI. 
James: [00:28:40] That's true. I remember. Yes. 
Frank: [00:28:42] I'm going to make you 
James: [00:28:43] 200. I have no idea what I, yeah. 
Frank: [00:28:47] See, I tricked you.
This is actually a mutable UI too. I got my library into this one 
James: [00:28:52] class, 
Frank: [00:28:53] Frank. Yeah. So, um, it goes back to that argument. I was saying before, it's just, how well do you implement, [00:29:00] how lightweight can you make that UI layer? And it turns out that that's really good at creating a lot of quick little temporary objects.
It's kind of what the garbage collector was designed to do. It's why we have a generational collector. It can detect, um, Short lived objects versus long lived objects that can detect small objects versus large objects. It's a smart, garbage collector, you know, use it. So, um, so the whole trick again, was translating from that lightweight representation to the heavyweight.
That's what immutable UI did now that spawn fabulous. So the F sharp people said, look at us, we're a proper functional language. You want to translate from one data. Data type or whatever, um, ontology to another, we'll do it. We can do that. We're all functional. So they built the amazing library, fabulous, which, uh, gives you that forward path, that envy we [00:30:00] generate the whole world on every event, but then did something a little crazy and a little clever with the you path and they implemented yet another architecture out there called Elm.
Have you heard of Elm? Uh, 
James: [00:30:14] I have heard of Alan because I have talked to the fabulous folks to understand a little bit about the project where it came from, but that they went in. I don't think they'd really describe, we did a few videos on the Xamarin show that I don't know if to, they really went into much into the Elm and Amish part of it.
It was sort of a, you know, it does it. So here's how you do it. You don't have to necessarily understand the Elm L miss stuff to hopefully use the library. 
Frank: [00:30:42] Yeah, you might. I'm sure there are parts of the, let me start over mish. Elm is a programming language. El mish is yet another architecture or style or pattern, whatever word you want to use for that, for doing the update part that we're talking about.
[00:31:00] So just to be clear, elements is language, whatever. Got it. Um, yeah. So what else tried to do Elm was written in. A language that's even more functional than F sharp. Can you believe that? 
James: [00:31:12] Impossible. 
Frank: [00:31:14] I know they really hate mutation to the point where they don't really part it at all, which is awkward. If you've how to write a program without using mutation, it might blow your mind a little bit, but that's where you get into the wonderful things called the monads and how to carry state along with your entire app.
Anyway, LA de da. They came up with a pattern where instead of events, you have things called commands fine. And there is a very strict way in which you handle commands. So instead of having, um, on ClickHandlers for buttons, you might have a command like, um, submit form. That would be the command. You do [00:32:00] this in your VM work, right?
Because do you put commands that's in your view model or are you anti command? 
James: [00:32:05] Oh, I bet the commands in my name have you model where they go. 
Frank: [00:32:09] Yeah. Okay. So this is, this is perfect for you. So they, but they are very strict. Okay. There are no event handlers. Um, there are only commands, so yeah. So everything, anything that can be event you create a command for, which is kind of nice.
It's like a bookkeeper's dream of, you know, everything's written down and kind of one place it's very organized. Um, It's very, you know, retentive. I'm trying not to give away how I feel about it, but what, how I feel about it is it's a little too restrictive for me. 
James: [00:32:47] It's opinionated. It's extremely opinionated on how you should do it.
And to the fact that there's only one way to do 
Frank: [00:32:53] it. Right and worse. It's opinionated to build you wise of a [00:33:00] certain type. Now this one came out of the web world. This is a web framework. And as we know, all web websites are just web forms. That's all they do. They just put text boxes in front of you and demand that you click more buttons and then they show you a picture of a cat, and then it's more buttons 
James: [00:33:14] that's accurate and that's 
Frank: [00:33:16] truth.
It's how the web works. And so this is an amazing pattern for building. Webpages to be, to be blunt and. Kind of harsh. It's great for that. How do you build a CAD program in it? It becomes a quite a bit more difficult because the pattern while you know how it is with patterns, James, the pattern is great.
When you first learn it, you're like I'm going to write the whole app in this pattern. And then you're onto the third page of your app. And you're like, I'm going to have to break the pattern here. 
James: [00:33:47] The pattern is great until it's not great. And then, you know, and then you have to decide. You know, when is it okay for you to break that pattern?
I mean, a good example is, you know, with, even with [00:34:00] MVVM all the time, there's the discussion of, well, should you put any code in your code behind? And I'm like, yeah, why not need to put it back? And we did a whole episode on co behind stuff. Just put it back there. That's fine. I mean, do you need to ship today?
Maybe just do that instead of, you know, I don't know. That's sort of how I've always looked at. It is. I don't know, maybe it's whatever, whatever you decide. So, 
Frank: [00:34:25] yeah. Yeah. Yeah. So I think that's what I find so frustrating about the El mish architecture for the U part of MDU is that. It says, this is how you do updates.
And I'm like, Hey man, the world's more complex than that. Like maybe I want to do an update here, a little update there, you know, on smart. I know when to do the updates. Um, but it doesn't allow that. And so that's why I'm slightly opinion on fabulous because they adopt that, um, pattern. It's not just that they adopted, they enforce it.
You're stuck with it. Um, whereas something like immutable UI, I did the MV part. [00:35:00] I did not do the U part, the U was up to you. So I just, you know, I abstained, I said, it's, it's a hard problem. And honestly, I think I've been going around to conferences, giving presentations on the style of programming for years.
And every time I presented on it, I slightly changed how I did my updates. And, you know, that's how it is. Every app's a little different, all your data sources are a little bit different. And I like that control personally in my apps. 
James: [00:35:29] Yeah. I mean, that's sort of why I've always. Thought about how I've evolved.
I sort of got into the same where like how I do MVP. Yeah. It was like pretty standardized now, but it wasn't for awhile. And then sometimes my still change it. Cause I'm like, Oh, but what if I do it this way? Or what if I just change this a little bit? And then there's other, you know, libraries and architecture patterns on top of that.
Like, you know, how do I handle navigation and that's going to be a little bit different or do I put this? Yeah. Do I put this into a, a service or do I put that service into [00:36:00] my, into my view model? Like, what is the, how far away is the separation? Some, some people think that the view model itself should know pretty much nothing about the data that it's serving up.
It should just be a very thin client. And that's why a lot of people have data services and those data services as an interface and those interfaces are how the view model does it. So if you make, if you. You know, make it, so your UI doesn't know anything about the view model and the view model doesn't know anything about that.
The whole idea is you can swap out anything at any time and that's fantastic, but even though you never do that, uh, you know, and then navigation, it doesn't know about that. So you're like, okay, but, but maybe in 2025, uh, we'll be able to update that. So, so that's always the conundrum I think is, is how far and how strict are you?
Right. And I can understand. By the way, looking at the El mish type of programming that you've described as like, Hey, this is how like, this is, [00:37:00] you know, some strictness and if you're in a business or, you know, having solid principles and you're doing, I like this is great because it really enforces this pattern.
And that's great because it's going to help us longterm do X, Y Zed. And, uh, that's also has its advantages too, in some way. 
Frank: [00:37:18] Oh, absolutely. You know, I, I feel a little bad that I talked so much trash about, um, because I have to give it props for a popularizing the style of coding, but B, because it has some fancy features your MVVM does not have.
So if you can, if you can handle the handcuffs, you get some wonderful features. For example. Um, state restoration because all the data, the app is encapsulated into this one kind of root object. Guess what? Turn that into Jason, put that on the hard drive. Next time, the app loads though, that Jason and you restore your UI instantly.
So it's like free state restoration. And there are even [00:38:00] the testability becomes ridiculously simple because it's a matter of initialize. Some data send this command at it. So the same benefits of view models you can get from it. Uh, so those are some definitely, uh, definite positives, but it's funny. Um, something I haven't.
No. If I stressed quite enough as a you're writing in the interview style, you're just writing functions for the most part functions that take data and output UI. And so when you talk about like swapping things in and out, one of the things I like most about it is. You just changed the name of a function and write a different version of that function or whatever.
And it's super easy to swap things out. So I build test you wise all the time, because they're just so lightweight that building a UI is basically easy. It's just a function. I'll take some data, I'll put some UI. And so I find myself, um, just experimenting more. Because it's so easy. I find myself creating test UAS that we'll probably see, [00:39:00] never see the light of day, but they're useful in my development and all that.
I love that simplicity of, you know, just write a function, write a 
James: [00:39:09] function, and you done how's that. 
Frank: [00:39:12] Okay. I like it. That's a show title, write a function and you're done do dude. I love it. Ah, that, that, that was. Everything. Everything I know about, I'm huge.
James: [00:39:29] And I have right. And I'm sure a lot of people are thinking is, you know, especially going into 2021 is, Hey, do I need to go learn this MBU thing? Or will this MBU thing play nice with my MVVM thing? Do you have thoughts on that? 
Frank: [00:39:43] Um, yeah. Um, it's tricky right now because you're basically. Well, let me just take a step back.
These are patterns. So you can do a little bit of your app this way, a little bit of your app. Well, you know, the world's up to you. You can do a little bit of [00:40:00] fabulous here and do XAML and other places. So absolutely. Um, it can fit in with other apps. And I actually want to give a little shout out to Swift UI here, which has done kind of a neat Trek of.
They've kind of combined the immutable world with the comment world using, um, I notify property changed and setters and PR, um, Mutability they've merged immutability with mutability and made their UI Mark capable of handling both. I don't think we haven't anything quite that advanced and not at the moment, but you know, it's just a few lines of code away.
So who knows if we'll ever get it? But if you have a library like immutable UI are fabulous, then the rest is just the pattern. The rest is up to you on how you want to take advantage of lightweight UI construction. Um, I hope if nothing else, um, [00:41:00] This is just an introduction to the concepts, but maybe go right.
A little basic app in it. And I think when, when I wrote a continuous, my IDE, I kind of kept bragging to you that I wrote it in F sharp, therefore, no bugs, but a large part of that is because I adopted this style in it. It was just so easy to code and so easy to test out that it really was. So much easier to find bugs in it.
Got it, 
James: [00:41:30] got it. I'm going to go give it a try. I've been meaning to go learn a bunch of stuff. I sort of understand the basics. Like when I. When I see almost a, sort of the new C-sharp extensions and Mark have stuff that they have in Xamarin forms, or you can sort of still do the MV VM stuff in a way, but you can sort of construct a lot more of functions and whatnot.
I think it's like a good first step. And then like [00:42:00] go all in, like, Hey, how do I progress? Because. With the NVU model, it is code driven. Right? So you're going to have updates you want, might want to get used as, Hey, I got my MVVM stuff, but how do I maybe take a code first approach? And then how do I leverage that?
Take that even further to update this and learn some new things to me, he was like, yeah, mess around with this and mess around with that. So it might be a good first step. 
Frank: [00:42:24] Yeah, absolutely. I love that. Um, you know, it's funny that there's nothing stopping templates from working in NVU or even XAML like you could use XAML for SVU.
Uh, the thing is it's just historical, uh, for sure the MDU came out of a very code driven UI world where people were building UIs and code. And so it's just more of a historical accident that we're not using templates that much. I mentioned that react. What I think is one of the most successful NVU frameworks out there.
Actually did release templates, they have JSX files. So it's a funny mix between the two. So, but [00:43:00] definitely if you want a great intro to this world, try to code up some UIs and C-sharp absolutely you and I, we, we both love, I know, I know you're a XAML person, but I know that you also, like, I will code driven UI from time to time who doesn't it's it's a easy, fun way to create UIs.
James: [00:43:19] Yeah, I've got to have a little in there. I like it. I don't like 
Frank: [00:43:22] it. Oh my goodness. Don't get put off by the Amish style. If you see messages and commands and things like that, know that someone is selling you a little bit of snake oil. They're like, Hey, this is a pattern that's going to solve all your problems.
The pattern here is. Lightweight functions, generating UI. Don't get distracted by the other stuff. Don't get distracted by the feedback loop. Um, yeah. So just take your time, breathe and try to see the forest for the trees. 
James: [00:43:55] Nice. I will do that. All right, Frank. Um, I mean, this is pretty [00:44:00] educational for me, so I appreciate it.
Cause I have looked at fabulous for a while and I've looked at react a little bit here and there, but I haven't had the motivation. So maybe I've finally. Become 
Frank: [00:44:08] motivated. And I'm sorry. I totally, just before I would feel terrible blazer laser, they call it, um, component driven, blah, blah, blah. I don't know what they call it, but it's MPU.
It's pure. It's simple. It's quite simply NVU they? I mean, they're even doing UI synchronization over the wire. So a pleaser is, I mean, it's basically, Microsoft's better react because it's much more thorough, much better. 
James: [00:44:35] Nice. I like that. 
Frank: [00:44:37] Yeah. Try blazer if you want a good introduction to all us. 
James: [00:44:40] Yeah.
We've done that. So I guess I'm pretty much an NVU pro at this 
Frank: [00:44:43] look at you always ahead of the curve. 
James: [00:44:46] Yeah. Whatever. All right. Well, let us know what your experience of NBU is. If you have questions as well, I had to merge conflict that FM and Frank will answer all of them for you. Cause he's an now you master, so cool.
Frank: [00:44:56] Thanks. Thanks. Um, yeah. Totes going to [00:45:00] do that. James finds it's so hot in my room right now. 
James: [00:45:03] Because you turn off your air conditioning. So go turn back on your air conditioning, Frank, and enjoy the evening. And I will talk to you later and that's gonna do it for this week's merge conflict. So until next time, I'm James Monson Magnum 
Frank: [00:45:14] and I'm Frank cruiser.
Thanks for listening.