Hey everyone, welcome to Developer Tea. My name is Jonathan Cutrell and in today's episode we're talking about getting fast first. In today's episode we're talking about speed and specifically the speed of your user interfaces. Speed is something that is basically non-negotiable in our jobs. I'm not going to bore you with the stats but in pretty much every single industry where technology is involved the faster your application is the better it is. This is not just for you eyes but that is probably the most relevant for our discussion today. And it's probably the most relevant for those of you who are listening because a lot of you are working on some kind of front end rendering interface. So whether you are a front end developer for web or maybe a native application or even if you're a back end developer creating the services to send to the front end systems the speed of the UI is one of the most important frontiers in engineering today for everyone in the whole chain. The UI is everyone's responsibility ultimately. And this can apply to game development as well. I have very little experience when it comes to game development. So I'll let you guys take from this what you can. Hopefully it will be valuable to you as well. I personally have been working on refactoring the front end of a project at whiteboard. It's a web project and there's some e-commerce involved in while the project has been largely a success over its lifetime. The simple choices we have made in just a few days of working on front end performance have increased conversions nearly 300%. Now we've been working on this project long enough now that the early parts of the project we didn't realize how important performance was because it was performing well enough in the beginning and we didn't make performance a priority in that in that early stage. Today I'm going to give you reasons why you should be getting fast first. You know we talk about mobile first in the web industry. I'm going to talk about fast first performance first and creating a fast interface. This is the magical part of this creating a faster interfaces ultimately in line with the primary goals of writing solid, maintainable code. It's an incredible thing that just kind of occurs when you write fast interfaces when you write the code to support fast interfaces. You ultimately end up with much more maintainable readable code and we've talked about what it means to write good code in the past. Those are two of the most important things that your code can be if you want to call it good code, maintainable and readable. So I'm going to give you these two reasons today about why you should be getting fast first. Number one, getting fast first forces smaller thinking, getting fast first forces smaller thinking. We are talking about limiting your vision here. I'm not talking about dreaming small rather than dreaming big. That's not what I'm saying. But rather forcing your code structures to be organized into smaller composable pieces. We talked about the value of thinking small in multiple scenarios including thinking small for your side projects, but also thinking small in your code. Generally speaking, the smaller the code, the easier it is to maintain. And this is natural, right? Because the smaller the code, the easier it is to comprehend. Of course, given that you have created that piece of code as a standalone kind of modular piece, right? That can be reused and moved around. That's what we're talking about when we say small pieces of code, just separating your code out into multiple files is not all that we're saying. If you separate your code out into a separate file, that file should be comprehensible on its own. So small pieces of code are ultimately much more maintainable as a result. Think about it this way. If you create a user interface that has 12 different modular elements, call them whatever you want to, widgets, interactive sections, in the interface. If you intermingle the code that defines those 12 sections, for example, if you mix the CSS on a front end web development project in a way that won't allow for decoupling, you effectively end up with one big section that looks and acts like 12 sections, but is ultimately much harder to maintain because you're essentially creating one large section. All of that code is intermingled. It's difficult to separate it mentally. So here's how the fast part works into the equation. If you want to dynamically load one of those modules at a time, let's say that the first load of that page only shows two of those 12 modules. One of the most efficient way to do this is to allow only the necessary styling information for those two components to be loaded in. Only the necessary code for those two components to be shown. In other words, all of the extra CSS that you need for the other 10 sections, all of that is unnecessary and we'll take longer to load. So to make that particular UI faster, one technique you can use is to isolate only the necessary code for the initial load in and then asynchronously or lazy load the rest of that information, the rest of that code. This is typically called critical CSS in web development, but the same concept can apply in other areas as well. The concept of lazy loading is very popular. Again, this is particularly useful concept for front-end web developers. So if you need to isolate that code for those two modules out of the 12, it's far easier to isolate and compose if you modular files together as needed. Then it is to try to untangle one big mess of code and create your own secondary mess of code. That secondary mess representing what it means to have only those two modules show up. The problem with this is that you have to do that for every iteration of these modules showing up. Let's say in the next page that you're using two different modules from the original 12 and you need the code that represents those two. Well, now you have to dig back through that tangled mess of code that you originally had. So it's far easier to create maintainable code when it's small and it just so happens that it's far easier to make your code fast when it's small because you have modular code that you can load as you need. This concept of composability is absolutely revolutionary for your programming career. Grab a hold of it and use it as often as possible. Composability is incredibly powerful, not just when you're talking about front-end resources, but all across your programming career. You'll see composability come up over and over. Number two. So going back to number one, getting fast first, forces smaller, thinking. Number two, getting fast first, enforces constraints during the process of creation rather than imposing them later in the process of refactoring. Let me say that one more time. Getting fast first requires that you think about fast, that you think about performance, it imposes those constraints in the process of creation rather than imposing them later after you've already built something in the process of refactoring. You go down the road, you create a large behemoth of a application and you realize that the performance of that application is slowing down over time. And so you gather the team up and you say we need to refactor this and make performance a priority. And the reality is it is much harder and much more expensive and time consuming and generally is going to be less productive and less valuable to retrofit a project to be a performance later on down the road. That is much less valuable than if you were to institute that from the start of the project. When you start with speed as a priority in your user interface, whether you use something like a performance budget or maybe another metric set, you are required to be more intentional about your choices throughout the project from beginning to end. You're much more likely, for example, to invest the time in a framework that helps with in-memory loading, for example. You're much more likely to institute that framework earlier rather than trying to retrofit that framework to an existing system. Having constraints and performance as a fundamental part of the design requirements ultimately leads to a minimum cost as it relates to the user's patience. In other words, you're going to lose a whole lot less because of people getting frustrated with your user interface. And ultimately, it's going to be cheaper in the long run than trying to retrofit tools and processes to try to speed up a slow system. By setting a performance goal as a priority from the very beginning, you start with reasonable constraints on the project. For example, the design may be impacted from the very beginning of the project. You may also realize constraints of, for example, server resources at the beginning of the project. And realizing these things earlier rather than later is ultimately going to be much more cost efficient. If you need a metaphor, think about the fast and lightweight system that we're talking about building from the beginning as a sports car. In the retrofitted machine, the old and cludgy long running behemoth of an application that you've built over time, that you're trying to retrofit and make faster, that's like a heavy old muscle car. At one point, it performed properly and it did everything that you wanted it to do. But now it's gotten old and you're trying to put an oversized engine and maybe a custom exhaust on that old car. Now while they both may end up performing at relatively the same speed, the old muscle car, despite its charm and its history, will end up being more expensive. While the sports car will be much cheaper to maintain as long as it's taken care of properly. So I recommend you take some time to think about how you can get fast first. Make performance a priority from the beginning of the design process. This is not something that you tack on at the end of the design process or at the end of the development process. Instead, it's something that you start thinking about from day one. Thank you so much for listening to today's episode of Developer Tea. I hope you enjoyed it. And if you did, there's two things you can do. Number one, share it with someone that maybe you work with or you think would appreciate this content. You sharing this content with other people is much more likely to spread it to the people who need to hear it than me sending out a tweet or posting it on Reddit. So go and share it with people that you think will appreciate it. Secondly, you can leave a review on iTunes. This is basically the same thing as sharing the show with your friend, but it's with other people who actually tend to trust your reviews on iTunes. So leave a review on iTunes. It helps the show immensely. Thank you so much for listening. Make sure you subscribe and until next time, enjoy your tea.