I'll be talking about GUI architecture's history present and the web we're basically going to make a dive into what the history of graphical user interfaces has been worried. It was started in how it developed and will happen. And then we're going to take a look a bit at what happens on the web, what we're doing today. Well, we are probably going to do tomorrow. I don't know. So anyway, just a bit about me, as I said, my name is [inaudible]. I've been I'm from Bulgaria Sofia. I've been a developer for almost 15 years now, actually more than 15 years doing primarily PHB, what I'm trying to do out of languages as well, done some jobs in the near past had some studying going on. I am currently a contractor at my company, which is called toy software.

So trying to make ends meet in the contracting business. And I was the organizer on Bulgari beach, big conference, 2019. I mean, tri software was the organizer. And hopefully once this pandemic thing is done, we're going to be organizing another edition of Bulgari VHB conference. But we'll see about how this develops for throughout my career. I've been working for quite a diverse number of projects and things I started out with I said medicine, voice services. We did a lot of work for production companies. We did some online video for more particularly, we tried to be able to video portal kind of like YouTube, but before YouTube was cool, I've done some animal games have been dealing with local positioning systems being involved in healthcare projects, connected projects, yada yada, yada, all sorts of stuff.

It's been really a wild ride and continues to be. So, yeah. So a little intro from why I feel like this job is important. Hopefully. Interesting. So one thing I've noticed we, we as developers and as people, of course, but there's developers need to know our past, why do we need to know our past? Well, pretty much through, I want to know there's through all the years that we're really willing to reinvent the wheel with every single new technology that comes out, we're all hyped about it. So for example, PHB, when it came out, we reinvent the wheel of how we should develop that one. Javascript became like a real thing, not a browser scripting language. Then the JavaScript community started to reinvent the wheel microservices when they were the hype thing, they also reinvented the wheel. So whatever small step of progress we do which is based on on something that has been around for decades to us, it seems like fundamentally game changing invention.

And this is because we don't know our history and we have done the thing, the game changer, the, the best and the most new thing, yada yada yada. And yeah, it is some sort of an advancement, but it's steps on something that has been usually around for decades, but we don't know that. So we need, you know, our best in, in order to avoid that in order to stop, to stop reinventing the wheel. Another thing I want to do with this doc is I would like really like to mitigate some confusions about what NBC is, what a model is, what a controller is, how we should do software, just so many interpretations of those terms. It's, it's, it's insane. It's insane. And, and one of the things that we need to do as engineers, because after all we're engineers, we need to agree on a certain language that we're going to speak.

We need to use the same terms for a particular thing. And for example, we model view controller and this is what we're going to start with. We need to agree on what a model is. Is this business rules, or is this a database table mapping? Or is there some sort of a functional, or what is this? And what we're going to do in this dog, except for GRI controllers, a good controller, sorry, we're going to architectures what we're going to see if those concepts of buoy are applicable to the web, how are they applicable to the web, how we map the graphical user interface to the web, isn't really the same thing. So on and so forth. So we're going to explore those concepts. And we're going to try to answer the question. What's a controller anyway, and what's a controller anyway, by the way, is the title of an essay written by Kyle Brown.

And this is a book, basically, it all resembles around this question. What's a controller anyway. So let's get started with some history. We're going to get back to the very, very beginning, starting with NBC NBC being model view controller. Now I believe that everybody has heard this acronym. I believe that everybody knows what stands behind it in terms of words, model and controller. I believe that quite a lot of us, if not everybody has done well, we consider, we see with PHP with any sort of MVC framework. They basically all frameworks that we currently have. Our MVC frameworks is this really? So we'll see later, but, okay, so let's start, let's get back to 1979 and on the picture on the slide, this is a, oh, I've got, I believe he was finished a finished guy named now I'm going to butcher his name.

Although I practice this is St. Vet rinse calc, and he's basically the inventor of model view controller. So he invented it back in 1979 while he was working with Excel and rocks or Xerox. I'm not sure while they were trying to come up with nice architecture. [inaudible] About how did you graphical user application for the diamond book? Now the diamond book was a device, a computer that mostly resembles we'll. We will now go a laptop or a tablet, so it'd be something in between. So it was a mobile the device and it was supposed to be a personal computer for children of all ages. Wow. The most important parts of the, the most important things that the dinosaur was trying to achieve. Well, it was supposed to be easy for every user. No, every user will be a person of any age to actually create programs for.

So they were also important feature of the of the Dynabook was that it supported graphical user graphical user interface applications. So it, Sarah, the team that was behind the Dynabook was trying to come up with a way to make graphical user interface programs is for development, pretty much anybody. So yeah, well is NBC was conceived at a general solution to the problem of users controlling a large and complex dataset. Yeah. Okay. One little note also that the Dynabook was using small joke, small joke, a object oriented language, and that was using small joke version of it. So on the slide, you can see a picture of, of cows maltose, graphical user interface looks like if you get, if you're able to see the screen, you will notice that on the right there is a I believe that's called nut and a boat in English wiper to kill it this well.

Well, the, as far as I remember the main application that they were trying to develop at the time was a graphical user interface for cat system cat system stands for computer aided design system. So that will be a system that helps you draw machines. And the parts for machines were basically physical stuff. So it has some, well, it has basically windows. It has a calendar widget, it has a clock widget. It has a stuff that is basically menus. It kind of, well, we pretty much resembles what we now know is a graphical user interface. Although it looks like well, oldish and it's monochrome, but it's still a legit graphical user interface. So now I'm going to bore you a little, but for the next three, slides were four bleeds. Bear with me. Then it's going to get more graphic going more interesting. So the concepts for model view controller, we need to dig into this.

So, sorry again, bear with me for a couple of minutes. So first big Britt rains cow came up with the worst thing. So what is the thing? A thing can be basically anything it's. I think it can be simple. It can be one part, or it can be a system of parts. It can be more complex. It can be huge. It can be electronics. It can be a circuit element. It can be a wire, it can be a knot, it can be anything important part anything. And it doesn't matter how complex or simple with this is a thing. And then we come to the bottle. So what is a mother? Oh, a mother is a description of a think. If you look at the general, the the general definition of a model, you would see that it will tell you that basically a model is a description of something which description feeds some particular needs.

And the case of a computer program, a mother will be obviously some computer code that describes a thing. It can hold information about the size of the thing, if it's physical or the dimensions or the colors or any physical properties it has. So it can be basically just a data structure, or it can be more complex. It can describe the way a thing behaves. So it can be a function representing something that will happen to this thing. It can be a mix of both. It can be an object or a system of objects. It can be anything that models a think next concept of you. So basically a view is the visual representation of a model. So we're talking model view, controller concepts. The view represents this plays on the screen. The view is this part of the program that displays and draws on the screen, what the model is describing.

Now, it's important to point out that there may be multiple views that, that present one and the same model. So for example, we can have a view which will describe the, which withdraw the cow, a nut looks, or we can have a view that will list the, or describe the materials of which a nut is made. So if it is more complex, for example I don't know a house. We can have a view that can present how the, the house looks on the front. And then we can have a view which represents how the stairs of this house look or where their book or something like this. So we can have multiple views drawing on the screen, the same model, the same instance of a moment. And finally, we have controllers. So the controller basically is the link between a motto and a view.

The controller is the program that will care about where a view stands on the screen. The controller will be the pro the, the, the program that would track your mouse and decide whether a click has been made that will monitor your keyboard. And we'll decide whether a key has been struck, which key has been struck and so on and so forth. Once the controller knows about some input, then it will manipulate the view that is associated to the control. Sorry, not the view, but the modern medicine associated with the controller. And then the view will draw the respective updated version of the model that it represents. So there are some rules. One of the rules is a controller should never implement the view. And the, a view should never know about user input. And then a model should never know about any of those.

A model should not know, never about controllers, nor about mottoes of you may know about a motto, but not really about controllers. And the controller knows about both models, views. So how did those communicate on the screen? You will see someone maybe familiar, I believe scheme how the communication goes. So basically it goes like this, the user uses the controller, which manipulates the view of the model. I'm sorry, the controller manipulates the model, and then the model updates the view, and then the view sees, and then the user sees what the view is displaying. Now, this is a pretty famous slide. I can't remember when I got it from, but I've seen it quite a lot. And it's a bit confusing because this is really not how, exactly the communication between the model and the view and controller goals, at least not in the very first iteration, the very first version of model view controller, or more accurate diagram of how this communication goes is like this.

So the controller maps and user actually to model to a motto, the motto update. So the controller updates, the model, true, calling some sort of a methods or setting appropriately or something like that. Now the model executes, whatever act whatever logic there is or just set it's a property or maybe a implement, or maybe there's something more complex doesn't really matter. But once the model was finished, updating its state, it notifies the view, how true some sort of an event, it just says, yo to whomever is here interested. My state has changed. The view picks up this Yule moment. This event, that exam is the motto that is associated with it. So basically queries it, it can, the methods are, can read some properties, whatever the view is interested in. And then in this place, on the screen, whatever is whatever it needs to render it updates itself.

Oh, good. The view may update the controller about zoom, user gestures, vere events of some sorts. And the controller decides which view to display on the screen, where to display it and so on and so forth. Now it is important to note that Dan, the idea behind this triad model view controller, it does not necessarily display. We did not necessarily have a single trier of a model view controller for our whole application. Modern can be something as simple as a piece of text or just the data structure or something more complex, and one controller can navigate. Yeah. And can use multiple model, multiple triads, multiple MVC triumphs below it. So it's not one single thing, it's it gets bad like a tree. And an example for this is not, this is, this is obviously not from the 1790s sounding 70, 1979.

This is a screenshot from our desk. But the point is that if this were made with a standard model view controller, every single button that we have on this top, it would consist a model view, try it, model view controller, try it. Each of these buttons, what happens on view it's own model associated to it, its own controller. This goals, the same for the screens that are displaying this building. For example, this view stays this place, a staircase part of the building from the upside, and it has a model and a controller associated to it. The next view is the same on the left. We have a list of properties and materials and this whole thing, this whole window that we're showing is controlled also by models, views, and controllers. So NBC had some shortcomings and when people started working with it or implementing it more, more than assistance, well, the game to them.

So first problems in 1993 while trying to develop visual works, which was a cross-platform implementation of smoke smalltalk by park place, the team was trying to create to recreate the original NBC. Bob had problems. The problems were that they had no place to put the presentation logic. So what that means. So let's say we have some sort of these cream that displays the name of a song we're currently listening to this screen, depending on whether the song that we're listening to, it has a copyright or not. So for example, a classical piece or something by lady Gaga, what this play, who the owner of the copyright is, if any, now where do we put the logic that we, that then decides whether the display of the copyright should be on the screen or not? Well, the solution for that roast, you modify the MEC, try it, then add something golden application model.

So basically the application of wall Moto will communicate with the model that represents our app. Sorry, you have occasional communicate with the model that represents our app. It will intercept the changes come from the model with will notice the updates of the state of the model and then the controllers and the views that are on the screen would communicate with this application model. Y well, now we have a place where to put this additional logic, like what will be the color that will represent the particular state of the model? What will be the language in which we display a particular message? Should we display something on the screen or not stuff like this because you see the original views, they were tied to the model and they could represent only information that the model would work with, but the model would not necessarily hold information for for, for additional display displays.

So that was very nice, but there were more problems. So in 1995 object arts was trying to develop a smalltalk for windows and that was called dolphin smalltalk. So they were, again, trying to implement a version of model view controller, how ever they, so two problems, one of the problems was that the controller does not communicate directly with the view. So what does that mean? If you want to do something simple, things can get really complicated. So let's say that we want to select a color that will change the display of other views. So for that to happen, we would need to change the color. On the view, the corresponding controller will pick that off. It would update the application model that it communicates with, with the respective color. Then the obligation model would need to far in event. And then this fi this event would need to get picked up by other views that are interested in this particular color.

And then they would need to render this, this on their own screen. So this was really not, not optimal. I mean, yeah, you could do that. If you were following the if you wanted to do the, this, this NBC stuff, you can do that, but it was like really clunky that we're not having with this way of work. So they needed something else. They needed some, some way of the views to communicate directly with the controllers. That view could just say, something's going on here. I'm not a problem that they have. They were dealing with windows and windows already had white of this widgets models, views, controllers, things kind of build in like windows already had the widgets for but menus labels, thanks box. So on and so forth. So it was like partially implemented. They didn't know what part to implement what not to implement, how to make it communicate with windows.

Like it didn't really fit in that way. So one of the solutions they found level, they did not found, but they were post by the way, this is they just, right. There's the burdens that they have in solutions in a, in a paper called twisting the triad by Andy Bauer and Blair my, my blush. And I believe they described this problem in more detail. The solution that they learn about was the so-called model, you presenter. And then that's what we're going to talk about. And the next slides, the model you presented.

So most of your presenter was basically a S programming motto for C plus plus, and Java developed by tangent. So delegate, it was a subsidiary of IBM, fully owned, and they were developing a next generation programming motto for the C plus plus Java programming languages. So they call it motto would be presenter. And it was based on a generalization of the classical NBC Provo programming model off smalltalk, but they twisted it a little and by little, I mean, a lot, basically they dropped the bump. So what they were doing is basically they were implementing a framework for simplest plus and Java that will allow developers to create a graphical user interface programs easily in any sort of a environment operating system. So on and so forth the paper for the modal groupers eight, there was a Rican by Mike in 1996. So model who presenter, well, I have to say my Patel, you really did this stuff. Okay.

We're going to focus on this a bit more because this is what we're still using. This is very, very interesting stuff. So first of all, the model view, presenter divides our gold and the model view controller. The, the, the original model view controller triadic looks at it in two parts. On one hand, we have the controller and the view, and they w w they make up the UI, the user interface. And this are the barns of the program that deal with how the user interacts with the data or the program and the D and the data. And then we have the model, which is responsible for actually managing the data, the state, and what the program does. So controlling the view, responsible for the UI model, responsible for the so-called business logic.

Great. So it will look at the model. We can break it down even further. So it answers the model is responsible for us for answering pre questions. First, what is the data we're dealing with? Second? How do I specify my data? And these are colds selections. So how do we select the data that we're going to work with in dirt? How do I change my command, my data, and this is what we go commands. So the commands basically select some of the data, change it, updated, do something with it, and the motto is the data. Okay. So there are three more questions that arise when we break up the con the UI part. And now you see, we have not a, sorry, I'm going to go a slide back. If you know, this, the controller is an uncle with a present. Her why? Because we broke up the user interface.

So now we ask the questions, we break down what we asked her, how do I display my data? And this is what the view is responsible for you before displaying the data. This is the ask the question to which the view answers is, how do I display my data? Then we have something called interactive that indirectly is responsible for answering the question, how do events map into changes in my data? And then the presenter is the one that puts it all together. Now, an important part to notice is that the view has now get, this is really no this played here, but with an important part of you to notice is that the presenter in the view being part of the UI, they're no longer required to communicate through events in this whole cycle. They can communicate on their own without reaching the model, necessarily, of course the view can still query the motto.

The motto can still sense events to the views, but they can also communicate through the presenter, truly interact their true, true commands, true selections, and so on and so forth. So the full picture is that we now have a way more flexible way of communicating views for presenters promos. And why is this breaking the triad into sub questions? So interesting. Well, let's remember that this is happening into 1996 in 1996, especially with Javas, but with C plus plus, and the web starting to be a thing. It is very important that we now be able to do applications, which could communicate over a network and still present a graphical interface to their users. Remember that prior to that graphical user interfaces that were in the context, I mean, 1979, obviously not the internet, obviously not all, not some server that was running, you will be basically just running it on a single piece of machine.

Now we have to go further. We have to be able to communicate over the over a network and over the internet and over the web, because in 1996, the web was already kind of a thing. So client server motto of the model view presenter. So easiest part would be the client would be responsible for presenting for presentation on D'Amato. So we would have the presenter interactor and the view on the client side. And on the server side, we will have part of the presenter as well, because something needs to communicate to handle the communication between client and server. And we will have the command selections and motives, and again, the motto and the view would be able to communicate for some sort of distributed notifications or to remold the DOCSIS. Well, thinking about it, this is starting to look kind of familiar. And if we go back to 1996 and think about what obligations having mind that there is no JavaScript rich stuff, there is no single page applications.

Yet 1996, we get kind of see how a browser can act as a presenter. And then there are during the view of why, because the browser is responsible for drawing the view on the user's screen, then the browser is responsible for picking up the user and direction. So for example, clicking a button or clicking a link or entering some text is the browser that will handle this. So it acts as an int director, and then the browser is responsible to send the appropriate data, for example, a, for a get or whatever, request to a server. And this would be true. The presenter, the presenter of the browser will talk to the presenter to the server. And then the presenter of the server will execute some commands, which will do some selections, which will query some models. And it will go back to the browser, which in turn will display a view. So you can see how this is starting to be a thing. Now, if we're talking outside of the reality of the web, basically whatever some other sort of network obligation, 1996, we can do other stuff, but we'll talk about this and this slide, the next slide. So this is a very nice breakdown of what can happen, where, and the different levels of communication. So if you know this, we have those yellow lines that are crossing each and every stage of the communication and the process.

So basically yeah, the, I'm sorry, the yellow lines that we're seeing representing where the client starts going, where the server begins. So below the yellow line here, here below the yellow line, on the right rail lines, we have what is happening on the client side. And then on the right side, again, we have what is happening on the server side. So let's go through some examples we can have on the client. We can have a really simple application that will be responsible solely for this plane purposes. It will only act as something that will draw on the user's crane. What would that be? Well, it can be, I'm trying to handle obligation. It can be X window server. It can be a screen-sharing application that will just allow you to see what the other person is actually doing. Well, the server is rendering, and if we're screen-sharing, as a matter of fact we have those streaming services almost streaming through the internet, but if you just, if you play a game, for example, in your computer, and you can stream it through your TV while the TV would act in this way, would just display a view that is coming through the network.

Now, if on the client we have view and an interrupter, then we're talking about regular web applications. Why would give me more than that? But we're web developers. So regular web obligations, they will do what we described that will display they would render the view and they will pick up some clicks. And for example, as a matter of fact, I haven't used I believe it was called Livewire. I haven't used library yet, but as far as I know, this is kind of what it does. It render something that the browser renders, some HTML, partial, HTML on the screen. Then when the user clicks, the browser worked actually propagate the click to the server where the server will do its magic and give some HTML back to the browser to render. So there you go. Now, the only regular web obligations, we have Mulder, applicator, web applications working like that.

And then we have the whole stack of presenter in director view. We would have something like, Hey, Joe, and then web application Java enabled application. Well, we'll let me sit in 96. That would be a Java applet running in your web browser. So on the server side of things, well, if the presenter that is on the client, we actually have the possibility that it will just execute commands on the server. So that that can be some store the store program, database, transaction, server collaboration. Okay. Those are rather old examples, but some sort of RPC, for example, we have the ability to call our RPC remote procedure code. If we call a function on the remote server, well, pretty much that would be it. First thing that comes into mind is from the Mauler world is AWS Lambda functions. For example, now, if the server only holds the parts of the selection as well, we can, we can talk about relational databases.

I mean, we can have a client that just connects to a database and send some queries. And then all of the commands, all of the logic, if the reside to the client and the server will be just there for giving us database, my SQL server will be an example of where that, you know, you can connect to it without having an application a PHP application, but more common example. I'm thinking of Firebase, maybe like you would have your web application and you're running in your browser and then connect to Firebase and we'll just do selections. And finally, we can have the server just holding a model. So that will be basically a file server, for example, or, Hmm, I don't know. Okay. File server, I guess I can think of another example. So let's say your a file server. Okay. So let's talk about web applications and graphical user application.

I think there faces, there are some differences, so classical graphical user interface obligations. They have a long run duration. They have continuous inputs and they have continuous outputs because you will be continuously monitoring mutual rink, user input, and it will be continually continuously updating this cream and web applications. Well, the duration of the run there is very short. It's why responding requests, why response? We had one time timing boots. We have one time outputs, but still their apps still. They presented graphical user interface to the user, but what was happening on the web during the nineties and the beginning of the two thousands, then we have any of this nice stuff. Well, Nope. We had this monstrosity, that's a borough gas book. You don't need to write the, to read it. It's just an example of terrible goals, some borough code with some HTML. Then of course, we have a BHB guest book and looks pretty much the same. And then we have a JavaScript JavaScript, but the Joel server page, and here we go, same stuff.

So this was really not optimal. So some came out with the Java server pages model too. So basically that would try to abstract the view from the business logic and what they would do is they would have this thing called serve lead that will only hold some logic and it would query a model that will be a Java being of some sorts. And the Java being will connect to a data source. It's basically what we know is of NBC, but they go to JavaScript, I'm sorry. No JavaScript. The Java server pages modeled to what was more than one. The other one was the big ball of mud that we just saw. So music without borders without borders was a, an article by a guy who was, whose name is [inaudible].

It was published in Java world in 1999, jar world was a magazine. And it was an article about understanding Java server pages model to architecture and this article well, it was the term NVC point. Why? Well, because it kind of looked like, and he see to Devolver, I really don't share this opinion, but okay. Because there are tree parts of it. It's on NBC. Now a bad thing about his article was that the goal that was displayed there, for example, workspaces was very, very, very bad. And unfortunately, when we show an example for something everybody's, usually everybody starts using the example starts cropping. The example is that of getting into good idea that the example was showing. And in this case, when we show a terrible example, well, people started doing terrible cold, and this is the actual gold of the example.

So basically that's a sort of a method or a class that will handle a post, which has some sort of a request response, injection dependency, injection, and it has some something to do with session. It would send a redirect, maybe it based on the parameters, it would do some actions. This is all happening in one place. And the model is basically just a vector. The vector is type of kind, kind of a Mary in Java, a type of an area. So really, really terrible stuff. So this is what's took around point is we started doing our business logic thing, do controllers and later, and these are two thousands. The so-called MVC. It was already the web NBC was called NBC two because it was Java server, a Java Java server pages motto to NBC combined came up with ABC two. And this is what's the struts project coined NBCT.

So it was trucks. That's a batches products. It's an open source web application framework for developing Java enterprise edition web applications. So there we go. Now we have the mess and the mess this way, what NBC is, what a motto it is because now models are just Java beans. Java bean is basically just a simple class. It falls some conventions. It's not a complex system of things. Having the problems that we had. Well, w NBC two, we have with web NBC, I would like to call it a web NBC. We have very poor separation of go service. We have business logics that, that lives in the controller. The controller does quite a lot of things. Everything around that is super stupid. The controller has a lot of dependencies comes really flat and is hard to maintain thing. It's basically a golf class, thankfully it's not all that bad because if we do our thing, we can extract all the domain logic and some sort of command or use case or obligational service.

Then we can use the serve lab or the controller action as a presenter presenter, as it was meant to be in the model is enter. So it will hold presentation logic. Only if we do the MVP way there, we can just USA because actually they got the view, right? I mean, with templates and stuff. And if the presenter gets too fat, we can just break it into smaller AVP components because you know, maybe component can hold smaller components. Now, a quick look at mortar. So single page applications what we have in the morning in a situation with a single page application, the presenter is fully built into the client. It's the server that holds them auto parts. The, the, depending on the, the, the, the way we communicate with our server, we can execute the commands and the rest of the stack downwards.

If we're using some sort of an RPC or a soap or quite open one, we create our own custom API that will communicate to our own custom frame from pens, or we can make the front end be extra smart, and it will use the backend sort of like just data selection, data storage. This is the other, the lower part of the the, the selection part of the MVP breakdown. So that will be, for example, rests that will be graph QL, did this will give us that DHTP Jason XML, doles, or just data transfer Cracow formats. We don't, this, this would be some part of the presenter that needs to be on the server, because you always have some sort of be present or the server, like, depending on which part of the obligation, you're looking at you, gab model view presenters here and there.

So, so we don't need any sort of complex stuff going on with the server, depending on what we're doing and what we're doing on the server. Final few words, but not little the server, I'm sorry, on the clients. It is what we go. What do you want to, but the predecessor of model view, view model, what is the presentation Waldo and presentation motto was, well, it was Martin foller who came up with my presentation motto. It was somewhere in the mid of the two thousands. I think it was somewhere around 2001 four. So the cool thing about the presentation model is that there is no controller, not a presentation model. What it actually is. It is the part of your program, the deals only with presentational logic. It does not deal with the model. So there is no controller because there is something else to the candle, the work of the controller force, for example, a browser or a operating system, or some sort of button, not our environment.

So it's basically a variation of the visual works application Waldo, but part of the presenter is gone that the, the part that, again, the environment can handle for us. So basically with the presentation motto, we would have a presentation that drove on the screen and we would have a motto. Well, that will keep the logic of what should be drawn on the screen. Again, the model is motto for the presentation for the, for what should be drone on, on the screen, not the model of our whole application. So what one thing foller will do is he would die the model two events coming from the environment that will update its properties. And that will be, that will notify the view to re-draw itself. And this is where it fell short because the synchronization between the presentation model and the view, it's simple, like the Mo the motto updates, it tells the view like redraw, but you have to do it for every single thing.

That changes is really boring and it's really repetitive. So he actually predicted the day, this will be somehow automated at some point. And this is that's exactly what happened when the model view view model. So in particular view, motto view, view model came about. So the view view motto it was designed in micros for Microsoft in 2005 by John grasper. So it follows exactly the presentation model. We have a model that is connected to a view, and the model was responsible for well, the view presents. So that's why it's called the view model. The thing is that we have some machine every behind it's a magic that would actually automatically, we built this connection between the view model and the motto. So when the view model updates, the view out automatically refreshes itself, and this was built for a windows presentation form, a foundation, it was also implemented the silver, white, and currently all of our front end frameworks, knockout react view, et cetera. This is what they use. So this is pretty much it. We came to modern times. This is a very quick slot with the resources links that you can look into that I used to build this presentation. I'd like to thank you. This is my context information. If you have questions, I'll stick around. If you don't catch me here may on me at me at Twitter, the slides link is this light. So thank you very much for your time and for your attention.