Most web developers start their career coding user interfaces using an imperative approach. You have some code that has access directly to the DOM and you execute a series of commands to change the state of the user interface. If you are using jQuery to update your UIs you are doing this. Imperative UIs don't scale well as applications grow. There's a better approach: declarative UIs.

What's up internet, Tom Friedhof here, a Solutions Architect here at ActiveLAMP. What does it mean to code imperatively? Well, this is what Wikipedia says: Imperative programming is a programming paradigm that uses statements that change a program's state. We'll break that down in a second. What does Wikipedia say about declarative UIs: Declarative programming is a programming paradigm--a style of building the structure and elements of computer programs--that expresses the logic of a computation without describing its control flow.

Okay, let me break this down. What is the difference between imperative and declarative programming? I'm going to use two of my favorite places to eat to illustrate the difference between imperative and declarative programming. Subway and Jimmy John's. When you go to Subway to order a sandwich you typically find a sandwich off their menu board and place an order with the sandwich maker saying something like: "I'll take a turkey, avocado with swiss cheese, lettuce, tomatoes, bell peppers, pepperoncini's, mayo, mustard and oil, and vinegar". The sandwich maker listens to all of your statements and in the end, you get exactly the sandwich you want. When you go to Jimmy John's the experience is completely different. At Jimmy John's you tell the person at the register: "I'll take a number five: The Veto". That's it. You don't say anything else and you still get an amazing sandwich without having to go through the whole process of making individual statements of what you want on the sandwich. In fact at Jimmy John's you're most likely not even talking to the sandwich maker. The order taker is not the sandwich maker. This is a functional programming concept. The controller code is not the code doing the business logic.

So which, which is better, just kidding. I've digressed. We're only comparing two sandwich chains today. Subway and Jimmy John's both produce equally delicious sandwiches, but only one of the sandwich chains sports the slogan "Freaky Fast" -- and that's Jimmy John's. Jimmy John's can work faster because there isn't a variation in how a sandwich is made. It is made the same way every time. Jimmy John's is a declarative sandwich place in that you say what you want. the sandwiches have already been defined and you get the output of that request without discussing the steps of how to produce the output. Subway takes an imperative approach. You talk to the sandwich make the whole time they are making your sandwich.

Let's review our definitions. Imperative programming is a programming paradigm that uses statements that change a program's sandwich, I mean state. Declarative programming is a programming paradigm that expresses the logic of a computation without describing its control flow. You don't get to talk to the sandwich maker you just get the sandwich. Now as you can imagine, if you are catering to an event with five thousand mouths to feed which paradigm would you choose? The answer is obvious, the declarative style.

So how does this apply to UI development? think of UI elements as Jimmy John's sandwiches. You don't get to say how to make the sandwich or in a UI app an element. You only get to say "I need a turkey sandwich" or if you are building a chat app "I need an online status indicator". UI elements are like pure functions in functional programming. They get passed the information that it needs to be useful. Let me give you a more concrete example of an online status indicator. In your chat app say you have a div element next to usernames that show whether or not a user is online. Rather than using something like jQuery to find the status indicator div in the DOM and turn the indicator to green when a user comes online or goes offline. It'd be better if the status indicator element took a parameter of whether a user is online and if so- show a green indicator and if not- show a hollow gray indicator. The controlling application just declares an online indicator element in the app and it passes some application state and that's it. Whether the indicator is green or hollow gray is up to how the online indicator wants to handle the state it was passed.

At Jimmy John's you can also pass in a parameter with your order. If you ask for a turkey sandwich and say "Jimmy it up" the sandwich maker knows how to handle that request. They'll add onion, sauce, peppers and oregano basil to the sandwich. The logic for Jimmying it up is baked into the sandwich. You didn't have to explicitly say each statement. The logic for how a UI element behaves should be completely encapsulated in the UI element code and only react based on a parameter being passed in. In the UI world, this is typically a state object. The state object has no control over your UI element. It doesn't make any commands or statements on your element. It only provides data to your element. Your UI element should be coded to react to the data if necessary. This is what function reactive programming is. We'll dive a little bit deeper into that in a future video.

This difference in approach may seem trivial but it's huge when you're building large applications. Here's an example of creating an imperative online indicator element. Okay, so here's an example of the online indicator done imperatively. So you can see here when the window loads we're looking for the bob status indicator div element and we're toggling the class to online if this value here is true. Now the declarative way of doing this is separating the application logic from the actual element that is shown the online status. So the declarative way of doing this would be something like this. We would have the application that would still do the window dot load or some sort of event, but it would write to some sort of state system so here we're using the local storage and we're basically setting the bob online to true in there. So now this application isn't actually controlling the online indicator. It is indirectly but it's not imperatively controlling the online indicator and so the online indicator what that would do is that's actually reaching out to local storage and grabbing the value and then based off of that value here it will actually toggle the class to either online or not show it. And so this is declarative programming because all of the logic of whether that online class is on, this indicator is all encapsulated within this file. It's not part, it's not being controlled outside of this element.

Now I showed both of these examples using jQuery for simplicity's sake, but the online indicator element really needs some sort of control flow logic to trigger another read from local storage. That's where something like RXJS comes into play. With RXJS you can make your app true to functional reactive programming. This declarative style of building UIs is the essence of how you should be approaching UI development. Building elements that have no outside influence from other parts of the application other than the state passed into the element ensures that all UI logic is encapsulated only within the element. Your time as a UI developer should be spent developing individual UI elements that are completely decoupled from each other and only appear to work with each other because of the state object being passed into each element. Declarative programming or functional programming may seem like a lot of unnecessary complexity, but like with anything, once you change the way you think about how elements behave in your UI you get a tremendous amount of value from this paradigm.

This is what front-end frameworks such as Angular helped me do out of the box. The next thing I would recommend you look into is RXJS. If you liked this video make sure to give us a thumbs up and subscribe to our channel. See you next time.