 Performance matters. Remember that, remember we used to say that, Perf Matters, but only when it matters. There's another thing I've been thinking about, how people think about optimization and performance in general. And I've been- Do they think about it? That's the thing. I feel like at some point on the web you're bound to think about it because it's sometime it is too easy to just do it wrong and get horrible performance out of it and people will start yelling at you. But I feel like people falling into like three camps of how they think about it. The first camp is the snake oil camp. Just apply snake oil generously to areas. Like you heard, scrolling is slow, I must- will change everything and it will get faster. Oh right, yes, yes. So that kind of project just here. It's basically rules, not tools. Yes, okay. Where people just hear something, like you shouldn't be using async functions because they're slower than functions and they're just here rules, they don't question them and just use them. That's obviously not a good pattern to be in. I still see code where instead of using string concatenation it's an array of strings that's joined because that was faster in IE6. And I still see code like getting published and it's like you question it in a code review and it's like oh it's faster this way, it's not for six years. And even if it was, is that- We want to get to that. Yeah, okay, okay. So the second tier I see and that's- I want to say the majority. I don't want to call anyone out or point fingers but I feel like it's what I see the most on Twitter is people who do benchmarks. Okay, look for numbers and if a number is smaller then that must be better. So they say like oh if I arrow functions are smaller or for off loops are slower than old school for let I blah. We caught this recently in the project we were working on like we had, I was using matrix objects for like pinching effects calculator because it for me read really well and I think the question came it's like well why don't we just do this with maths and say well number A I don't know the maths but more importantly it would be harder to read afterwards. So let's just use the objects that are there and it's more maintainable. It is probably slower. Well probably slower. So people often tunnel on the micro benchmarks are feeling like oh if you use this thing it's slower and in Safari it's even more slower than in other blogs and like I hear you and you might probably correct but and I think like people should strive to be more on a third camp because the answer usually is it depends. Context is so important on the performance and the performance always depends on what you're talking about and it's always a trade-off. Exactly. So you always trade-off readability or reusability or scalability or something is to trade-off for switching the technique and you might gain performance on a micro benchmark but it might not actually help you. So there's just two things there on one hand people like to optimize things that are not their bottleneck. Yeah it's the inside of the loop not the outside of the loop that's the problem. Exactly so people I think the first rule is always measure like see if you're optimizing and the time you spend on optimizing a bit is actually giving you any notable advantages. If I make my for loop over 10 objects faster by using a for-let loop instead of a for-off loop sure it might be faster we're talking microseconds and nobody's going to notice or have any benefit from it. That's the first thing. The other thing is like readability is very important for example and I lost my trade-off thought. Readability is important. It is. And it's more important. It's performance matters. Remember that? We used to say that. But only when it matters. Oh my example back. If you're still if you're still hitting your frame budget. Exactly. So I think thinking in budgets is super helpful because as you might know I've been looking into using workers more moving off the main thread. And so when I hit a button I now have to send a message to the worker and do my logic there because my logic is now in a worker without the DOM the other thing and then update the DOM by sending a message back. So if you measure that yes the response to a button tap will be longer because there's an actual round trip and thread hops involved. And so people there were some people who said you shouldn't do that it's slower. Right. And it's not a good pattern because it will make you up slower. And they're like well my reaction time to the button press went from eight milliseconds to 16 milliseconds. Right which is. And according if you use some guidance for example rail I have 100 milliseconds to react to a tap so I'm very much still within my budget. Yes. So the question is yes it's slower but what did I gain? And you gained if it is expensive. If for some reason yeah the worker gets expensive API response to parse or the device is super slow and totally busy or something something it's resilient to all these little side effects and will keep the main thread for the user can scroll and doesn't even notice that something is going on under the hood. And also it gives me a nicer pattern so that I can actually have a separation of concerns and don't have a tight coupling between my UI framework and my logic in the worker. So there's many aspects to it and I feel like people need to be more after the context so whenever somebody asked me which is something that I feel like should I be using this or this because I heard this is faster and like I was like what's the context what you're trying to do and what you're working on because that is that makes and breaks the decision. Yeah. That you're working on. Right. Yeah. So double topic. So what's your conclusion. It depends. It depends. Good. I took a conclusion that is the correct conclusion from those things. Okay so. Oh you tried something different. That took me off guard. Okay. Okay. Okay. Well. Okay. I had a university lecturer who used to say we used to keep a tally of how many times they said okay. And they would stream them together and that was the most satisfying ones. And you know if you look at this this is how it should be. Okay. Okay. Okay. So we've got three in a row. Three times combo. There you go.