Video details

Day 3 Keynote | Igor Minar | ng-conf: Hardwired


Igor Minar

Watch ALL the talks from ng-conf: Hardwired 👉
ng-conf is a three-day Angular conference focused on delivering the highest quality training in the Angular JavaScript framework. 1500+ developers from across the globe converge on Salt Lake City, UT every year to attend talks and workshops by the Angular team and community experts.
Follow us on twitter Official Website:


Everybody's staying healthy and you enjoying this very unexpected edition of a conference. Before we begin, I would like to actually give a big shout out to the UKIP organizers for pulling off this virtual gathering on such short notice. Thank you. Thank you. Thank you. You people are so freaking awesome. We couldn't do this without you. And we are so grateful to have you. Thank you. For those that don't know me. My name is Igor Minar. I'm a software engineer at Google. And I'm Angular Uber TL. Today, I would like to share with you some insights from behind the scenes of making an angular specifically I would like to dive into. Attention that we see between the needs of developer experience or DX and user experience and UX. And talk about how we balance these two and angular in order for you to be able to build applications that users love to use. I'm sure that many of you I, too, am a strong believer in the Web platform. It's a platform that is ubiquitous. It's available almost everywhere. It's a sect. It's accepted, accessible. It's accessible to everybody, regardless of their skills or means. And it's malleable, which means that we can build very interesting user experiences on the web. But it's also a platform does ever evolving. It's not stagnant. It changes. It improves. And it does so in a very stable way. So we don't need to deal with breaking changes very often. On the other hand, if you look at the Web ecosystem, the ecosystem of loosely groups, tools, patterns and libraries, it often feels like we're dealing with a house built of cards for the longest time. I wondered why, where there is so many tools, libraries and patterns seemingly doing doing the same or very similar thing. And I don't know if I got the answer quite right, but something tells me that maybe this tension between the developer experience and user experience and the tradeoffs, different solutions make results in a big variety and diversity of solutions we have on the Web. Often, but not always. The requirements and tradeoffs that result in a good developer experience worsens the user experience. The opposite is often true as well. And. You might wonder how does this manifest in the real world? What are what is the common symptom? The one I see very frequently is waiting. Who here loves waiting? Please raise your virtual hand. Well, I hope you you're raising your hand because I can see you. But I do have to personally confess because I do love waiting for certain things. I love waiting for sunsets or sunrises. What I done. Love waiting for. And growing very impatient is when the application is taking too long to load. Similarly, I often have a hard time focusing on work. When a program I'm working on is taking a long time to build, rebuild or test. Nobody likes waiting. Especially when you are trying to do something. And waiting is in the way. But waiting is real. And way too common for both users and developers. And as we develop develop our tools and applications, we often make tradeoffs between who's going to wait a bit more. These tradeoffs do exist. We should accept them and we should treat them as a necessary evil or find perfect, imperfect world. We should focus on finding the right balance between making the tradeoffs that impact the delivery experience and user experience and finding the middle ground between the two. We should also, however, acknowledge that building awesome experiences requires a lot of collaboration and it requires a lot of collaboration because it's a complex task. We often cannot do it by ourselves. And the more people involved, the more people start to make tradeoffs. Now, if you look at the Web, we see that there are lots of people involved at different levels. We have what platform engineers that are making their tradeoffs. We have library authors that are making tradeoffs. We have component authors, reasonable, competent authors that are also trading certain things for others. And lastly, we have Web developers that are building applications by assembling all the species and running them the Web platform. We should also not forget about the end users that get to use. The end result is work. However, I have to point out, though, this light is slightly outdated because in today's comit 19 age, the proximity of the users is not very safe. So let's let's fix up. Oh, OK. That's much better. Stay healthy, everybody. Please stay healthy. So as we saw, there is a lot of people making tradeoffs. Different layers of building experiences and these tradeoffs add up. They often affect developers, but also users. And rather than seeing this as an obstacle. I wonder if we could change a perspective. And so things slightly differently or actually quite differently. What if user experience and developer experience, we're friends and we're helping each other. What if they were in reinforcing each other? How could that work? Well, I strongly believe that a great user experience meets the user where they are, regardless of. Who they are. In fact, I'm often fascinated by watching someone who hasn't used a modern UI so much and gets to use the cell phone for the first time. For example, a young child or an elderly person. A great study subjects. These people have no preconceptions about how modern you are. You guys should work and all they know is the real physical world. They know how to interact with it. They know how it should behave. And they have expectations around that. The great DUI is one that is easily understandable buttons people because it behaves like a real world. A poor user experience, on the other hand, is one that is Janki uses odd UI interactions, breaks user expectations around grass, no grass above gravity mass in their shop and other essential loss of the real world. Great, you guys feel real. Great. You guys feel alive. It feels like you're touching it. And it just is one with you. They feel right. And they are. A lot has been said about the speed. I don't want to go into details, but there are studies upon studies that tell us that fast you AIS result in better user experience. They result in better user experience because people feel more immersed in the experience. And this results in more interactions and more conversions and then more satisfaction that people are interacting with the applications, how often the speed can be approximated by the size of JavaScript bungles that we shipped to a clients. We're going to talk about that in a bit. But before we get there, let's talk about how to actually build these great yards, because building great ice requires mastery, just like learning to use an instrument, musical instrument or any kind of form of art or sophisticated engineering. There is a mastery that is required to achieve great results, and mastery requires practice. Mastery also requires iterations because you want to go over many things, many failures. And of course, failure is a part of the success because the more you fail, the more you learn about how to do something. But the way you want to fail, you want to fail fast and you want to fail safely. You want to learn from that and move on. Unless you are interested. In which case all bets are off. But for the most users, iterating quickly enables us to explore more options, more variations. Fail very often and quickly. Incremental improve and end up with a much better result than the first thing that we got working and was just somewhat working. But if we optimize just for the duration cycle and faster duration cycle without consistent consideration for the impact of the user experience, the results could be disastrous. Balancing these two needs is challenging, but it's a challenge that is worthwhile. I bet that many of you had an experience where you were able to get the balance just right, you fine tune your application stack and you optimized dual user experience and application, which is just list to work with. And users loved it and everything was awesome. This is great. But the problem arises when such applications need to scale and grow. Balancing the Delp experience and user experience at scale is what changes the dynamics. The stakes are much higher. Doing it repeatedly and sustainably takes the challenge to a new level. And this is what Angela's trying to do. Angela goals is to make them a little more successful in developing great user interfaces. And don't get me wrong, I don't think that we found the right balance yet. We ourselves are still iterating. We made a lot of progress in this area and I'm going to share some of that. But we still have a lot of work to do and we invite you to be part of the. Good example of of what we've already accomplished. If you're starting a new project today, you can start it by running a command engine. You this command will generate a new project with reasonably good deals. You have reasonably fast deflation cycle. You have a set of built time checks that tell you when there are bucks in your code that you should fix. And you also have a production optimization pipeline that shrinks your application to create as good user experience as possible. Well, how much better how much does this optimization pipeline affect the application? Well, if you take a simple example of angular IO, which unsurprisingly is angular application, a look at the total sum of all of the JavaScript code that we iterate on during development, including all the libraries, including all of the least loaded chunks. It's about five megabytes. With the optimization pipeline, we can reduce that size by 87 percent. And this is before the Gipp, Joseph or Brockley compression even kicks in. So it's very significant improvement. And in fact, one of our former team members, Hun's, used to joke that if we keep on improving optimization, pipeline will soon end up with a negative payload sizes. This doesn't quite happen. But over the last few years, we actually made a lot of improvements and gradually improved the user experience of all the applications built with angular. And we actually accomplished improvement of a magnitude or 110. But we're not done yet. If we look at applications that are being built with Cingular today without any advance tricks, you usually see a small applications in the neighborhood of one hundred and fifty two to one hundred kilowatts. This is OK, but it's not great. And we know that theoretical current to theoretical minimum for Angela is about an order of magnitude lower than that. So we will keep on chipping away, making things better. But we are also balancing that with other priorities like improving ergonomics. So far, EPRI is adding features, fixing bugs. Now that we made so much progress in this area of optimizations and shrinking the payload size, we feel like we have all more space to focus on other things in other areas of the platform. As Kyra mentioned yesterday, V nine and I, we have been a big milestone for us. We delivered a significant user experience, improvements to all of the angular applications that upgrade to angular version nine. But it wasn't just the users that benefit from version. It's also developers because developers will benefit from lots of improvements that the 9:00 is packed. We improved build times, testing times, rebuild times, localization of the application. And I'm excited about many more improvements that are still in the pipeline that haven't been released yet. And you'll see in the future releases. Well, Angela tries really hard to steer away from trouble and and keep you safe. Accidents do still happen and these accidents can result in Puri's experience. But there is a good news. You can help us prevent many of these disasters. I'm going to share four tips with you on how to improve user experience for your application. But surprisingly or rather unsurprisingly, what we see and hear from developers that apply many of these tricks that often yields the developer experience improvements as well. And this is because the less and less, fewer dependencies are in the system, the faster the system can operate and they can process all of the code and result in the small occupation. So tip number one. This one is relatively simple. Learn how to analyze your application and specifically learn how to analyze the application. This might be simple for many of you, but for others it can be very unapproachable and scary. And in fact, just a few weeks ago, I ran this experiment at an enterprise summit we were hosting in our office. When I challenged the crowds to share their applications with me and I will take a look at them and quickly analyze them and point out the biggest issues in those applications. And I guaranteed that I would improve the user experience and developer experience for those applications with only minor changes to the application. This experiment was so successful that I actually wanted to share some of these basic steps with you as well. Please install source my explorer. This is a tool that will help you analyze the output of your production builds. You might be familiar with another tool called about Peg Bundle Analyzer, which looks similar, but operates on a different level and often results in very misleading results. So I strongly suggest that you use sort of an explorer as your first tool when exploring these these issues and use weapons analyzer only if you are debugging very specific issues. This is because work like analyze a dozen, see and understand what tercer the medication step at the very end of the pipeline does. And in this step, we death called element in eliminate a lot of code that would pick analyser still considers us retain, which is incorrect. Turn on source maps, new production builds. There is just a simple command you can run. This will make a change to Uncle Jason and your source maps will be produced when you fill the application. Next, run your production build. And the last step is run source MV Explorer on the output of all of you production build, what you'll see is something like this. I know that those screenshots is very small and might be very difficult to read, so don't worry about it. But the point is that you see these boxes and these boxes represent how the application is composed and what it is composed of. In this particular case, we're looking at outputs from a very small application that I'm building from my dear wife. She she needed a tools to build, so I built it. It's not very complex application, but it uses material design components which have a lot of nice features and accessibility features. So it's not a trivial application either. So if you look at this, this output, what I typically do is I go through a series of steps. I look at the diagram and try to interpret what I see. I point out what doesn't look right. I focus on the biggest issues first, and then I hypothesize about the root cause and try to confirm it. Then I go and fix it and verify by re measuring. And then I just repeat the whole process again where I build production, builds, rerun source, map, explore and see modified improved results in this part of case. We are dealing with the obligation, those relatively small it's three hundred eighty kilobytes. That's for angular standards. That's actually pretty good. But I know that if we better in a big production applications, you will see a much higher number. Don't be too worried about that because as you go through this process, you will see easy ways how you can improve on the application. So in this case, the biggest box and you can probably you can probably read it is attributed to code that comes from Angela Core Angular Framework. There is not much me as an application developer in this case can do all this. So I'll leave that to PEMRA and other people to do with this part and make it smaller. And are actively working on. The next thing that is quite big is this box of the ball on the bottom. And that's a box that represents stylesheets. This establishes the comfort material design. It's actually surprising that just for me to have Nilles nice, stylesheet defaults. There's actually quite a lot of code that is associated with it. I'm not sure if I can do anything about this as an application developer. Maybe I can try removing it and see what my application looks without the theme and the stump sheets. But maybe the right thing in this case would be to talk to Jeremy or file an issue against angular components and say, hey, this stoush, she's actually pretty big. Pardon me. Would you do anything about that? The next the next big box is Animation's is the angular animation's is called the power single animations in my particle application. I'm actually surprised that I see that animations have been pulled into my application because I don't really have any animations as far as I know in my application. So maybe I should look and see. Am I accidentally importing animations when I don't need them? And if I don't need them, remove them. The next one is down here, the polyphenol zone, G.S., The Zone Jesus is is a library that allows us to trigger change election automatically in my application. The application is actually so small that if I wanted to shave extra thirty five kilobytes, I could actually do without sangrias and trigger zone or change direction manually. I don't know yet if that's what I want to do in my application, but that's something that should be on my list. And the last one is forms, in this case, it's surprising that much code is being pulled into forms. But if I look at my application, there's actually a lot of UI patterns in my application that require accessibility for dances. And I know that the forms library provides those. So that seems like a good tradeoff in order for my application to be accessible. With this list, I can then go and explore and tweak my application filed by the Bucs against ANGULAR or are fixed issues in my application. If you try this on the application, you'll probably see much higher numbers because my application is very small. And what I bet you will see is that most of the callers will actually come from their party libraries. And we'll talk about those in a bit. Well, before we get there, I just want to quickly some summarize the tools that performance analysis and testing. So we already talked about Source My Explorer, which is invaluable when it comes to analyzing what actually gets shipped into the browser. The next one I really like is Lighthouse and its online variant with the slip slash measure. This is a tool that runs lots of reports and audits on application and allows me to get lots of insights. And the last one I use quite frequently is what page does the org slash easy? This is a precocity reconfigured version of a page test that allows me to test my application on a real devices, on real networks, which is super, super handy. Let's move to tip number two. I already mentioned they're part of libraries and them being the common source of problems. So I really advise you, if you start taking on dependencies on third party code, do it very wisely. You might, however, be kind of stuck and not know what wisely means and which libraries are good. So I give you one simple, too. If a library that you want to depend on in your browser code ships in common, G.S. or empty format as the default or the primary way and the iOS module format is not available. Do not use it. This will cause lots of optimizations in know build pipeline and make your application much bigger as well as make your application build much slower. Instead, prefer libraries that are bundled and published to NPM in the year module format. This is easily recognizable. If you just look at the code or if you look at the package just on and in the future. I see. I think that we'll see more and more libraries using the module format as the default. Tip number three lays a load everything or almost everything. These days, it's actually quite easy. You can use that to make imports. You can lisel images. You can visit other assets. Please do so in Angola. Application is the only current treat. Sticking point is lazy loading of components. And they'll mention that as something that we're actively working on. Tip number for the last tip, stay up to date. I already mentioned that staying up to date helps you get all the benefits. Very quickly, very easily, we'd put a lot of effort into not breaking application and making the updates very automated. And to do that, we actually have Engy of the command, which does several things. It updates your dependencies. It runs automated migrations that either migrate you over from the brigade is to new API eyes or even improve your configuration of your project to be more aligned with better details and help you catch issues, whether they are bugs or performance issues. And lastly, it's also pointed to migration docs so that you know what happened to project whenever we make changes to project. Some people still wonder if any update works. The good news is it does. And we know so because from elementary as well as from surveys, we see that most users either on the latest or the last two versions of angular energy up that really works and makes this easy. Please use it. It's going to make such a big difference. Recovered quite a bit of stuff in a short time. There is still one more thing that I want to mention. We're continuously working on more improvements. We can't commit to timelines or exact specifications yet. But I can tell you what we're exploring. And what you might see coming in the future is. So some of the ideas we're exploring are better stricture defaults, say, and strict very carefully, because we don't want to break applications, we don't want to make it difficult for you to get to the new version of ANGULAR. So we are evaluating every stricter default or better default and the impact on applications. And coming up with strategies how to make it easier for you to get on this better default. The next one is highly requested first class support for dynamic component laser loading. This is currently possible in ANGULAR. I've made it much easier. But there are still few gunshots. So we're not documenting and asking you to do in one particular way. This is one of the top three requests that I hear from developers. And we're quite aware that this is something that you would like and we explore in the next one is warning errors when we detect common performance issues. The good example of this is third party libraries. Wouldn't it be nice if you started spending on a library? But the library ships all in common, just format. And we told you this is one of the things that we're exploring. We definitely want to let you know that that is happening. We're just trying to figure out how to do it in an ecosystem that is currently full of libraries that are shipped and published in less than. Great format. I'm looking at both the libraries and the English system, as well as the wider ecosystem, because there are many, many commonly used libraries that are still ship informants that are not great. And lastly, we have a lot of under the hood the cleanup to do in England, especially now that I've done a lot of code that we can remove and that will make improvements both in the user experience and. So we covered quite a lot. I hope that this is going to be useful for everybody. So let's just quickly summarize. I strongly believe that great, you guys make people's life better. And that's why we should care about news, experience and news. Experience really matters. I do believe that great user experience is a fast and feel real. We have ways to measure this. We should do so. We should analyze them. We should optimize for metrics that prove improved user satisfaction and improved user experience. We also know that to build a great user experience is meant to a choice quickly, and we need to safely fail very often. The more we fail, the quickly we can more the more quickly we can iterate to foster will find a better user experience that users will be really happy with. But to do so, we need to improve developer experience as well. Angular tries to balance these two user experience and that experience. But trust it doesn't trust, do it at scale whether you're working on a large project, on a large team and a larger organization. We're trying to improve the defaults and guy do it in a way that will result in great developer experience, but also user experience. And lastly, there's just one thing that I want you to remember from this talk is please stay up to date with ANGULAR because we're improving the platform, the framework, the Seelye, everything is getting better and you'll be getting all these improvements. With that. Thank you very much for listening. Stay healthy, everybody. Hi.