045 AiA Performance with Gleb Bahmutov

Download MP3

Check out Ruby Remote Conf!


02:19 - Gleb Bahmutov Introduction

03:21 - Perceptual Performance

07:09 - Getting User Feedback

12:15 - Profiling, Tools and Techniques

16:45 - Performance Optimization

20:38 - Benchmarks

22:20 - Extracting Value from Profiling

26:11 - Top Performance Problems

  • Two-Way Binding
  • Keeping Up-to-Date with Versions
  • Minimize the Number of Expressions in Template Elements

28:44 - Performance Lessons

34:30 - Public Opinion on Performance in Angular

40:57 - Drive-by Optimizations

42:26 - Angular 2 Performance Predictions

The CodeNewbie Podcast (Chuck)Ruby Remote Conf (Chuck)Wait Wait... Don't Tell Me! (Chuck)Ask Me Another (Chuck)Ruby Rogues (Chuck)JavaScript Jabber (Chuck)The Freelancers’ Show (Chuck)The iPhreaks Show (Chuck)RailsClips (Chuck)Car Talk (Gleb)Colorsublime (Gleb)


CHUCK: Greetings earthlings![This episode is sponsored by Hired.com. Every week on Hired, they run an auction where over a thousand tech companies in San Francisco and New York and LA get on JavaScript developers providing to put the salary and equity upfront. The average JavaScript developer gets an average of 5-15 introductory offers and an average salary of over $130,000 a year. You just can either accept an offer and go right into interviewing with the company and neither with that any continuing obligations. It's totally free for users, and when you're hired, they'll also give you a $2,000 signing bonus as a "Thank You" for using them. But if you use the Adventures in Angular link, you'll get a $4,000 bonus instead. Finally, if you're not looking for a job but know someone who is, you can refer them to Hired to get a $1,337 bonus if they accept the job. Go sign up at Hired.com/AdventuresinAngular.]**[Does your team need to master AngularJS? Oasis Digital offers Angular Boot Camp, a three-day, in-person workshop class for individuals or teams. Bring us to your site or send developers to ours -- AngularBootCamp.com.]**[This episode is sponsored by Wijmo 5, a brand new generation of JavaScript Controls. A pretty amazing line of HTML5 and JavaScript products for enterprise application development. Wijmo 5 leverages ECMAScript 5 and each control ships with AngularJS directives. Check out the faster, lighter and more mobile Wijmo 5.]**[This episode is sponsored by Digital Ocean. Digital Ocean is the provider I use to host all of my creations. All the shows are hosted there, along with any other projects I come up with. Their user interface is simple and easy to use. Their support is excellent. And their VPSes are backed on solid-state drives and are fast and responsive. Check them out at DigitalOcean.com. If you use the code “angularadventures” you'll get a $10 credit!] **CHUCK: Hey, everybody! And welcome to Episode 45 of the Adventures in Angular show! This week on our panel, we have Lukas Reubbelke. LUKAS: I bet yah, boy! CHUCK: Ward Bell. WARD: Hello! Hello! CHUCK: I’m Charles Maxwood from DevChat.tv. Quick announcement, go check out Ruby Remote Conf if you're doing stuff with Ruby backends on your Angular apps. Or, if you're interested in learning stuff about that, then go check it out - rubyremoteconf.com. I've got some terrific people lined up and that's going to be great! We also have a special guest this week, and that is Gleb Bahmutov. GLEB: Hi guys! Thanks for inviting me. CHUCK: Thanks for coming! LUKAS: Whoa! Whoa! Whoa! Whoa! Whoa! Sorry, it's Dr. Gleb. CHUCK: Doctor. The doctor's in the house, huh? LUKAS: PhD. GLEB: Yeah, not MD. LUKAS: Yes. WARD: He has a Master's Degree in Science? GLEB: Yeah, Doctor in Computer Science. WARD: I'm sorry that was a bad joke to Doctor Science, which was in radio show in which the guy says, "Doctor Science, I have a Master's Degree in Science." LUKAS: So Gleb, are you ever afraid that all of the computer knowledge that you have is going to like ever tip over and crash somebody? GLEB: Oh, no, no, Lukas. The more I learn, the more I find out how much I don't know. LUKAS: Ohh. GLEB: You know, Impostor's Syndrome. LUKAS: [Laughs] CHUCK: That's right. The more he pulls out of the box to count it, the emptier it gets. GLEB: Exactly. LUKAS: Wow! We just got our money's worth. Let's go to the picks. CHUCK: [Laughs] Alright. Well, we brought you on to talk about "Angular Performance". GLEB: Excellent! I think it's good. Everyone is kind of keeps asking if Angular has Performance problem. Everyone compares it to React, to some smaller libraries, all these complaining. So, definitely good topic to discuss. WARD: Yeah, do you have sort of a general beef about people talking about Performance like I do? It just seems to be a word that you can smear something with securities, in other way, it doesn't perform well that you can just smear something with. I just wonder how you sort of cout Performance? How you get people to think about what they really mean or even care about Performance? GLEB: It's excellent question. I think Paul Irish, was it Fluent, the last conference, he talked about "Perceptual". CHUCK: Perceptual? GLEB: Yes, Perceptual. The way users perceive your website's Performance, might not necessarily be what you measure. One quick example, if you stroke a user a loading indicator where users will perceive your website as being more Performance as opposed to just simply waiting with no visual feedback. So it's a big change for just measuring end to wall loading time. We kind of talked about not doing the responsive design, but Incremental Improvement Design where you show something to the user and then you progressively add more features. I think you can do pretty much everything we do today and they usually perceive a website as being much faster because we incrementally or progressively enhanced the functionality. And Angular, I think, is incredibly well suited for this. WARD: Right. So you're keeping your eyes on the prize here in terms of who benefits from what level of Performance instead of getting lost in Microbenchmarks which is where, I think, a lot of us ends up. GLEB: Absolutely. If you read my blog post in Performance, I always argue against using Benchmarks or Microbenchmarks. I mean they're good for some things, but in terms of a real world application website, I think, they're useless pretty much. CHUCK: Well, I found that users use really highly-quantifiable and scientific terms like "slow". GLEB: [Chuckles] Exactly. We do use quantifiably slow. CHUCK: Yup. And not as slow sometimes. WARD: They usually have a point. They've got some workflow in line, some scenario that they're trying to get through. And they perceive getting through that scenario as being important to them and too slow. To me, that's the starting points; that I can get out my stop watch and start looking at the scenario and see what it is that we're doing that gives them that perception, and that I like the work from that user back. And I have a feeling that's your point, too, Gleb. GLEB: Yes. Recently, I actually spoke to Web Performance Meetups at Boston, and a person from the audience asked exactly the same question: "How do you know when you should optimize Performance? And how do you know when you should stop optimizing Performance?" because it can keep going on forever. And I always go back to the user and ask, "Well, if you go for this particular scenario, how long do you finish a take was acceptable to you? Is it 5 seconds to the sort? Is it 1 second? Is it hundred milliseconds?" If a user tells me 5 seconds is acceptable, usually I'm done. If a user asks for 2 seconds, then optimize until it hit 2 seconds. It's always up to the user to tell me what's acceptable and what's the Performance target should be. CHUCK: I think that's really interesting. But, how do you get that kind of feedback? Because most of the time, at least in web applications, your users are somewhere else in the world, they come to your website, they load it up, they do their thing and they disappear. I don't see it like a slamdunk place for them to say, "Hey, this was slow!" GLEB: It's about the question, and it varies. I'm lucky to work at a company where we have internal users of our web app and different people who usually approach me and they tell us, "Hey, can you speed up this particular thing?" or "Hey, we have more date than hours, so this particular app that used to behave very well now seems sluggish." So, we have this in-house feedback constantly. We are always surprised, actually, when we actually show to outside users, but they don't find our Performance problems to be an issue. We actually tried it ourselves harder than outside users do. If you have a completely different case, if you have users worldwide, then you probably can look at [incomprehensible] and their metrics like how many users started in something and then closed their browsers out letting it finish like it kind of drop off? CHUCK: How many people give up? GLEB: Exactly, gave up. And Google always kind of post this numbers saying, or Amazon saying, "Every 200 milliseconds in waiting means 5% drop off". So in general judge, basic metrics like offsite loading. WARD: If you're building that kind of site. GLEB: Exactly. WARD: If you're building a shopping site. But if I'm building an internally facing app -- and a lot of Angular apps are kind of like I'm-trying-to-get-work-done kind of apps -- GLEB: Exactly. WARD: And then we know those numbers are kind of meaningless and you don't have to worry about them walking away because it takes longer to load because they are in it anyway, that's where they're going to be sitting, this isn't an option for them. So you're trying more to optimize whether they can get their work done, right, Gleb? GLEB: Right. Absolutely. A lot of apps that we write, web apps that replace desktop software. So on one hand, let's say as a web developer, you're sometimes a hostage to clients' demands like [incomprehensible] support for example. But at the same time, the client is a little bit of a hostage to your application. So sometimes a little bit of waiting and putting premium features rather than Performance is the right thing to do. CHUCK: So how do you make that call? GLEB: You have to ask the user. Let's say we are startup -- I'm a startup that's less than 2 years old. For us, the number of features is definitely number 1 priority; finding with features that the customer 'are willing to pay for. Now, being from multiple alterations, we started getting recurring revenue, and now we're hitting larger data sets, and now we're hitting Performance problems. In a sense, we always put the future for us and we approach Performance optimization lazily. That means, we're not going to do anything until it becomes a problem - kind of stop premature Performance optimization. CHUCK: Let's say then that we have a scenerio where our users are coming to us and they're saying, "This process is really slow." GLEB: Right. CHUCK:"I try and load up this page, it's really slow." Or, "I entered data in this form and it's really slow." What do you do? Where do you start? GLEB: I'd try to absorb and perform the task first. I don't even look at any metrics, I'd just try to figure out what they're trying to do. Usually, the user will do something that will surprise you. You assume but we all look at like, let's say, 10 items. And also you noticed that they try to load the whole world, for example. But for a user, its experiencing might be completely differnet from what you expect them to do. Second were two categories of Performance Problems. One is common to every HSTP website, and that means you have to download JavaScript, you have to download CSS, you have to download HTML, all the resources, fonts, and render things. And this is interesting problem because we're trying to optimize milliseconds, for example. But for common HTTP problems in the order of seconds, so it's not Angular-specific, being able to deliver your scripts for CSS, or fonts for CDN, it's common to every application or library framework. So that is where I would start, and Tools like Pagetest or YSlow are great at this Performance audience, and these are not Angular-specific issues. Where Angular-specific issue is coming to play is probably the secondary stage where a user is actually trying to use for web app and do specific scenario. At that point, I would bring up my little collection of code-snippets. So Angular is actually a good framework for Profiling. You can get into the scope, you can graph any scope method in a time measurement code, you can accurately record starting like end-to-end timings, you can also control Chrome CPU Profiler and get accurate pictures of all your bottlenecks. It's a little bit more involved, but if you know what you're doing, Angular gives you great amount of information or allows you to get into great detail via DevTools Profiling. So that's my goal to step for Profiling Angular apps. WARD: Do you have some kind of link that we can put in the show notes to sort of get people include in to the techniques and Tools you use? GLEB: Absolutely. I have a whole repo of Chrome code-snippets. If you search for GitHub Chrome snippets, you'll find me as second link there. I'll definitely send you a link to a repo. I also have blog post that describe how to do this in detail, what code-snippets are. A lot of people actually don't know about the Chrome snippets. I only found out about them accidentally a few months ago. These are little owns I bookmarked with, but we have permanent restored -- yes, that's the one -- permanent restored in a Chrome DevTools, they store inside the local storage there so you can write a whole bunch of code that's syntax highlighted, you save, you can execute it in a contacts to a page, it has full access to all the libraries, the DOM, everything. It's almost as if you passed it with code into a browser console. In my collection of code-snippets, I have general ones and I also have Angular-specific ones. For example, getting a scope of an element and then wrapping a method on that scope in a Profiling code, and then whenever you skip that method, it actually Profiles just that method. So really, getting specific information about a particular feature of your model or of then clicking Profiled button going to your code or going to your app, clicking a button, going back to Chrome DevTools, hitting Stop which makes your measurements a lot less accurate. WARD: That sounds really cool. I got to go check that link up. CHUCK: Yeah, definitely. GLEB: Yeah, I've been using them very successfully to optimize the performance. Funny thing, and I always say this, whenever I try to profile my application and I look up to the list of heavy funtions right at the bottlenecks, like all the functions arranged in amount of time that it take to execute, 9 out of 10, the top couple bottlenecks will not be Angular code, will not be the digest cycle, nothing. It will be my own application code. Maybe I implemented some weird search or any kind of root force method. I always find this to be the first problem. So a lot of people blame Angular, but the Profile what actually executes go find their own code as the top of the list. WARD: Right. And so React wouldn't have fixed that or anything else wouldn't have fixed that or might not have fixed that. And if they switch over to it and say, "Look, how that cured my problem!" they actually rewrote the algorithm and they weren't giving themselves the same problem in the first place. GLEB: Absolutely. I'm not picking on React. React is a fine library and there are lots of fine libraries for optimizing the DOM updates. But most of the time, the amount of code that you write, the custom code, that's not really Performance tested. It's far, far greater for your particular application and dominates the performance rather than fine tune, battle tested, battle hardened framework like Angular or React even. WARD: Yeah, yeah. I want to just clarify and agree with you there. But what I'm seeing, and probably you've seen it, too, is that people getting the Performance problems and they think it's the framework so they jump from one framework to another and they say, "See how that framework was better than the earlier one?" and then they get the problems with that whenever they jump to another one and say they do all of these Performance-driven framework jumping instead of looking to see what they did [chuckles]. GLEB: Exactly. The first rule of Performance Optimization is measure and find what you have to optimize. Find the true bottleneck. Without measuring accurately your application, any type of Editing, Refactoring will be in vain. That's why I always try to Profile accurately, and code-snippets is one useful Tool. But also I usually concentrate on the top bottleneck because anything but very top one or two bottlenecks will probably not give me the biggest bang for my time, and also if I remove a top bottleneck, it usually changes the order of hour functions and how long it would take. So usually, I concentrate just on the lowest part of my code. WARD: You know, that sounds so simple but so few people do it. They go for the easy fix that were down low because they don't know how to fix it.. GLEB: Right. WARD: That is just such wise advise, Gleb. CHUCK: Well, the other thing that strikes me is, do you know what Pareto Principle is? GLEB: I think so. Can you remind me of that. CHUCK: It's any percent of your -- it's the 80-20 rule, basically. So 80% of your problems cause by 20% of your code. So when you're saying the top 2 or top 3 things that are making the difference, yeah, the 20% of the things that are slowing things down right there are causing 80% of the slow downs. GLEB: Right. CHUCK: And so you get rid of those and the other things that may not even make enough of a blip for you to worry about them right away. GLEB: Absolutely. And if you think about framework jumping -- For example, you can save using a mutable data, optimize it at a Performance, escpecially in Angular it kind of eliminates the dirty checking in the digest cycle, which is great. But imagine how much effort it will actually take to rewrite your application to use immutable data. And at the end of the day, you might find that it hasn't actually spell out your application because it wasn't the true bottleneck. That's the effort wasted right there. We always say that we cannot measure per activity over developer, that's what we claim whenever someone tries to measure us. But Performance, it's all about measuring for us like this is the one thing that developers can measure accurately and that's the one thing they usually don't measure at all before starting Refactoring. WARD: [Laughs] That is so true! I can't tell you how often I've had exact same experience and then there's some manager behind them who comes beating you over their head and tells you it's not performing, too. Too funny. GLEB: It's only funny because it's almost like gallows humor, right? It's funny because it's true and it's a problem. But the Chrome DevTools -- and as much as I love Firebug before -- I'm absolutely astonished by how good of a Chrome DevTools are and what features they put in including Layers and frame by frame painting and Memory Profilers, it's astonishing. It's the best Debugger for Performance that one can have. CHUCK: I just think it's funny, too, you talked about the manager bringing down your neck. About half of the jobs that I've had over the last, I don't know, 8 or 9 years that I've been a professional developer, the only machine that it really mattered how it performed on was the CEOs. GLEB: [Chuckles] Exactly. Right. CHUCK: And if it was slow for him or if he ran into a Hiccup, the thing was broken and you ought to convince him that you fixed it. GLEB: Right. Right. And usually, CEO has this underpower kind of light MacBook Air Machine... CHUCK: Right. GLEB: And maybe not the latest browser.. CHUCK: Yup. GLEB: So it's always a problem. The only piece of advise I can give there is that, as a good programming practice or as a good software engineering, we know that we have to write the Unit Test. We know that we have to have a Version Control System. We know that we have to have Continuous Integration Build system. I think we should add four step and that is automatic Performance Benchmarks like measuring application performance. Service like Angular Benchpress -- there are other Tools but we should make it a part of our build process. CHUCK: Yeah, but you just said that the Benchmarks don't mean as much because people perceive speed than actually measuring it. GLEB: Right, but not the Microbenchmarks. Imagine almost like a protractor end-to-end test and measuring how long it takes in reality or measuring most critical features of our application, that kind of Benchmarks not from Microbenchmarks or something [inaudible]. CHUCK: Yeah, and I guess if you can measure someone's perception so you're getting a wide sampling of this page or this feature as really slow, and then you have a benchmark that goes along with it, then you can say, "[Incomprehensible] this." GLEB: Right. Right. And we always say that first step is measuring Performance or measuring the relevant metric and maybe the second step should be automating and making this measurement as simple as possible. Again, like the Chrome DevTools snippets are just excellent because they're there so anytime you want to measure something, just open and run the script; you don't have to type anything, you usually can just store it. And they can also auto-update themselves so it can kind of have a company-wide private repository with code-snippets that are specific to your application and you can just auto-update and pre-allocate so every developer will be able to Profile your application easily. CHUCK: So if you're profiling the speed of your application automatically like that, how do you extract value from that? GLEB: As in like simple numbers? CHUCK: No. So you have the measurements on how long it takes to load on average, each piece or each at least critical piece of your application. So how do you take that and actually make decisions based on those numbers? GLEB: Now that's a judgement code. Let's say that your Performance budget has been exceeded. You went to the user and the specific feature has to take 5 seconds and it takes 10. Right away you have to look at bottlenecks, you have to take a look at maybe amount of data. But the next thing you can do is actually solve the problem. Let's say you removed your own bottlenecks in your own code so the top bottleneck is no longer your code, it's proabably something Angular-related or Angular-specific. WARD: I want to put pressure on that because sometimes I find that the problem is the UI is inappropriately designed for the task.. GLEB: It could be. WARD: Yeah. And so there's not a chance like somebody thought that this is the way that UI ought to be and there's not a chance in the world that you can actually implement that UI in an effective way and it's not serving the user in the first place so you can make big gains by simply saying, "Hey, what are you doing?" It's like hitting yourself in the head by a hammer. What's the answer to that? Stop hitting yourself in the head. GLEB: Right. Again, it's all about measurement so you can measure -- Let's say the UI has lots of items and they all have semi-transparent background and all have shadows and stuff like that that makes painting the screen just a chore in the Performance software. You can profile the paint, you can bring this result back to your team and say, "Hey, just a sure amount of data or repainting because of all the visuals styles does not allow us to achieve the magic 60 frames per second. Maybe we can drop the semi-transparency? It's a nice feature to have, but it really slows us down. Or, maybe we can drop the shadows. Maybe we can have fewer items on that page using pagination or having just a few items in the DOM but are visible, and if I use the Scrolls, we can bring more items." And one thing that's real nice about Angular is that you can do a lot of these Performance Optimizations while staying inside of the Angular application ecosphere like updating DOM and only keeping visual things. What is the Angular plugin for that called? angular-vs-repeat, just keeps a list and only the visible items will be in a DOM so you can have a list and regular engine Repeat with 10,000 items but have like 50 frames per second because only how many items are actually visible while being in a DOM. So you can do a lot of things without going to third party tools. WARD: What was that thing again that you're just describing, Gleb? GLEB: It's called "angular-vs-repeat", which is kind of cool Angular directive. It keeps only the visible items in the DOM, and as you scroll, it adds new items before View reach to the end, and whatever scrolls outside is removed. Yes, that's the one, you have the right link. LUKAS: So you can do things like this? GLEB: That's what we're hitting Performance problem at my company. I've been kind of solving each bottleneck and there is a blog post that kind of kept growing and growing and now has maybe 11 or 15 separate sections and things that I optimized. WARD: If you think of the dragon that you slayed at your company, what would be the top things that you keep running into? They may or may not be Angular-related, what are the top things that you just keep seeing over and over again that are kind of reliable-go-to-fix-that kind of things? GLEB: Unfortunately, the top 2 are definitely Angular-related, but they are very easy to fix. One is Two-Way Binding. As the number of items on the page grows -- let's say you have a table and you used to handle maybe a hundred items, now you have 20 columns and 10,000 items as you found on those cells. The Two-Way Binding is really expensive. Luckily, Angular has One-Way Binding now, you can just switch to that and your Performance will increase dramatically. So best for most common thing that we did and it optimized the performance slay of a dragon right away. The second one easy Angular dragon to slay is keep updating your version. So between 1.0 and 1.2, there's a huge performance improvement. And also between version 1.2 and 1.3 or 1.4, there's another huge performance jump. So by just keeping up to date with the latest Angular version, not that we're going to Angular.2 or beta, you can get Performance improvement for free. So best probably I was number 2 solution. And number 3 with also pretty easy to solve is minimize the number of expressions in each template element. Angular makes it very easy for you to apply functions to your template expressions. You can take a number, style it, format it, and it's very easy to add those things. But everytime the page [incomprehensible], it has to go through every filter, every expression and this is expensive as you have more items. But it's incredibly easy to actually move that code into the Controller and not run it on every digest cycle. So basically, precompute all the values in new model and have maybe one-way or two-way very simple data binding. This solves a lot of problems. WARD: Yeah, that's one of my favorites. Every time I see people literally are those filter pipes in the template, I know they're inside an engine repeat, I know they're in trouble. GLEB: Exactly. I kind of base on my experience with improving Angular. I've written Angular Performance lessons and it all includes like 8 or 10. Do you mind if I share those? CHUCK: Yeah, go ahead. GLEB: Well, we've talked about that Microbenchmarks do not matter. So some people will argue that writing 4 loops everywhere around rather than using array for each is better performing. But don't even try optimizing those parts. You have to learn how to accurately profile your code, and Chrome DevTools is an excellent resource. Upgrading your framework using Performance Improvements, minimizing number of watchers by using pre-computed expressions, or minimizing Two-Way Binding expression is the key. Now the interesting thing is that Angular makes it very, very easy, in my opinion, to use web workers. You can write a little factory to create web workers on demand. What is that excellent project called? Ng-webworkers, I believe, that makes using a function, a stand alone function, in a separate web worker just a snap. So if you have computation, upload it to a web worker. Pre-compute all the values before you put it in your model and onto the scope in the separate thread. That's an excellent, excellent idea. And you can batch hop large work into smaller chunks and just paralyze it easily. You can get on a typical laptop up to the factor of 3 or 4, speed up if you have a lot of data computation. So, work in batches. WARD: What's the browser support for web workers like? GLEB: It's like 95% right now. It pretty much everything supports it. And the cool thing about Ng-webworker project, it creates web worker on demand so dynamically. So if it doesn't find support, you can still use that function in-line in the main thread. So it's not neither/nor preposition or either/or; you can use both. But I think, web workers are really what support it by now. WARD: What kinds of calculations are you talking about that might, that everyday, people would have heard about? I don't mean the weather or the shortest route to getting home by way of the customers have to visit, those things are out there. But what kinds of things or garden variety of things that people would understand that would go well on a web worker? GLEB: Aside from my kind of standard example for showing web workers like finding triumphs or factorials, which I know everyone does everyday.. WARD: Right, exactly. GLEB: We do a lot of formatting and chart pre-processing and computing the standard deviations and pinning in Instagrams before we show the charts and graphs and tables on the data we receive from the server. So for us, uploading but pre-computation to a web worker is very, very simple. Other people might think of problems like applying image filters or doing any kind of image manipulation as an excellent candidate for working in a separate thread. Right now, the last thing that I optimized was a heck of a project from AirBnB that I've seen. It takes any image and converse it into a lego, write map so you can buy a bunch of lego pieces and make your own portrait. So that's an excellent candidate for working in a separate thread. In general, I think, we're not using the multiple threads in a browser. It's been a little bit too hard to actually set up communication and past data. But the current web worker technology, especially with transferrable objects where you don't have to even marshall things into JSon, is super fast. And I think, in the future, we'll take a great advantage of this browser technology. As far as Angular is related, I even have a project where I ran, I think, Angular 1.4 inside a separate web worker like the whole framework. And my goal was to optimize the performance, the Dave Smith's talk Angular+React=Love from ng-conf. If you seen the presentation, basically, imagine you have a little of stuff, wouldn't it be nice if you could run the digest cycle in a separate thread and be able to use your application, and then once the model is updated, then you get results back. You can do this but -- WARD: Did that actually pay off? GLEB: It's funny you should ask. No, it does not pay off, and I'll tell you why. Angular is really tired to a DOM. Think of your link function or your directives, you can grab the element itself, the DOM element and attach listeners and do all sorts of interesting stuff, you can access attributes and that's how you link scope and so on. If you run Angular in a web worker, you don't have DOM so you have to use the synthetic DOM like JSDom. And now, those things are really slow so you can do your MVC and digest cycle very quickly. But because the whole Angular set up and bootstrapping happens to be tied with the DOM because of synthetic DOM, that's the part that slows things down. Just running a calculation or digest cycle is very fast. But the initial bootstrap, it's still terribly slow. So it's still a work in progress. I'm sure with Angular 2 will actually work much better. Or, at least I hope. We live in exciting time, I think. WARD: What's your general sense? Is it that Angular apps are generally fast enough and that people are having Performance problems with the edges? Or, are people just hyperventilating about how dangerous it is? Or, what? What's your sense of the true state of Performance characteristics of Angular apps? That is a broad question for you. GLEB: It's a broad question and it's definitely I'm not being in question. I would say people complain because there is a reason to complain. And it's a good reason actually. Bunch of frameworks never even hit Performance problems because the usage and the adaption rate is so small. The real world examples that's been around on pretty much to do MVC examples, we have a couple of items. Angular, because of its wide adaption, is actually used in so many applications today that the real world usage shifts the edge cases with where you have to show a lot of data, you have to have data, a lot of data. So the people complain because the real world usage of Angular forces Performance problems or spotlight is on. On other hand, I don't think that complain Angular slow is fair. Angular is almost like a guitar amplifier; it has a knob. So if a knob is set to 1, it's really easy to take a static page, add a couple of tags, and you have a live web app. It's ridiculously easy. That's why we love Angular; it's great for prototyping. I can take a static mockup page and I'll make it under app in a couple of minutes, hours, doesn't really matter. And your UI designer can take.. well, can create a static mockup, can make an Angular app out of it. This is knob one, But then, people started using it more and more, and also having problems. Well, you can turn the knob and remove two-way binding, kind of restrict the app, maybe target it better to specific used case and you get much better performance. So people complain, you turn them up, you solve the complain. People complain a little bit more because now they have more data, more users, and more edge cases. And you can turn the knob even more, you can [incomprehensible] the date, you can minimize the number of watchers. You can stop using JQuery plugins to give extra behavior. You can really tie down your application to your specific used case and make it very, very fast again. So when people complain with a slow, yes, it can be slow because you started from a static page, you added behavior, now you're using that behavior with lots of data but it's ridiculously easy to turn the knob and solve the Performance problem at a cost of a little bit of programming. That's my broad answer, if you can accept it. WARD: That makes sense. And of course, with a guitar knob, I always turn to 11. But that's just me. CHUCK: [Laughs] GLEB: [Laughs] Yes, 11 would be kind of going to a mutable data structure, maybe swapping two-way binding for something else, maybe dropping things and going to Angular 2. That's the 11. But again, the cost of a lot of programming, Angular is ridiculously easy to pick up. If you're a designer, if you start with HTML and CSS and then add Behavior, I can teach pretty much any design to do this very quickly. Now, trying to explain to design on how to start with even GSX or React or something like Backbone or Amber is a lot harder. I might get better Performance from the start, but it will take me a lot longer to train and to write the app. If you're a startup and you're hunting for a feature to sell, I belive of Angular 2 to actually deliver very quickly a working application and then being able to show it to prototype, to change it before you actually worry about Performance knob and turning it into 11. To me, it's the killer feature if this is like progressive Performance. WARD: That end, trying to keep the UI simple, which by the way I think gives the users a break, too, because having everything flashing all over the place were giving them a table that's a thousand rows by 50 columns; it's not doing the user any favor, that's just abdicating. GLEB: Exactly. You should do a better job probably when designing your application and strung by use of the important stuff. If we follow this alloted visual design instead of telling the user, "Here 10,000 items, find what's important to you," we'll try to show 10 items with the thing that might be important and led the user focused. But that means you have to know your app, you have to know your audience, and you have to be good at what you do. WARD: Yeah! I really think that there is no getting around that. In some sense, that giant grid is the weighing which people have tried to runaway from the fact that they actually have to understand the user and understand the application. GLEB: Exactly. WARD: And playing that at the feet of Angular or hoping that some framework is going to rescue from that is going to end up with a design that actually is slow for the user not because the app can't perform, but because the user can't move through the app in a [inaudible]. GLEB: Right. And let's talk about a little bit about mobile and tablet. The world is moving towards mobile. Limited real state on your screen, you do have to be an expert as a designer or application programmer. And being an expert means you can make a judgement call -- what is important and what you want to show on that limited screen space. To me, the mark of a good mobile application or tablet application is not that I fit everything and show the same behavior as my desktop app. No. The mark is that I'm showing only the most important stuff out of making conscious decision that this is important to my user and everything else can just be here and not showing at all. I think that's where you have to move to, and a framework makes it really simple to do this. CHUCK: This is awesome. GLEB: Thank you guys. I also do what I call "Drve-by Optimizations", Sometimes, I look at someone's library or project and I will say, "Hey, this kind of feel slow. Let me take a look." And you open it in Chrome profiler or you take a quick look around, you look at the bottlenecks, you see if it's a framework (could be Angular, could be something else), you see if it's the algorithm, or you see if it's the JavaScript engine, which is something we have not mentioned. A lot of stuff can now be optimized by just-in-time compiler in JavaScript, and with another huge source of Performance Improvements. For example, every time you use a try catch blog, that function will be slow then Chrome Profile will show a big warning sign there, but you have to know the rules for JavaScript Engines. And again, Profiling gives a nice feel for it. WARD: You're talking try catch in a hot loop, right? I mean, it's generally -- you have to have a lot of iterations before try catch gives you trouble. GLEB: Yes. But if for example Profiler Angular app, because the try catch is inside the digest cycle (sometimes you see it somewhere in the middle of all the list of functions) -- I usually don't pay attention to the digest cycle try catch, but you should just know that it should not be inside the hot function. WARD: So are you really expecting Angular 2 to make big difference with Performance for people? Or, pretty much the tradeoff there would be the development ease. What's your feeling about Angular 2 and Performance? GLEB: No, I've been looking at Victor Savkin's blog post about change in structure in Angular and the last weekend's ng-vegas has excellent talk by Minko Gechev from Bulgaria, I believe, who showed very nice, immutable data structure and how it can actually be integrated into Angular. It remains to be seen. Angular 2 is a huge moving target right now so we don't know what's going to happen. At my company, we're kind of looking long term and we have decided, we're going to adapt ES6 syntax, we probably will stay away from TypeScript for now, and we probably will not jump onto Angular 2 anytime soon. We're still going to use Angular 1 for quite a while. So in terms of Angular 2 Performance, it remains to be seen. I think the best parts of Angular 2 will be brought back into Angular 1, honestly, just like ngRouter and things like that, maybe Dependency-Injection. So I think, some kind of maybe Performance Optimization like immutable data structures probably will be ported back to Angular 1. But it remains to be seen. CHUCK: Well, I don't have any other questions. Do you, Ward? WARD: I don't, not at this level. I mean what I'd love is to watch the lab at work tearing into something. Well, I always find that fascinating. But I think, you've really covered something important ground here, and I really appreciate it. GLEB: Thank you, Ward. It's been a pleasure being here and we can share a couple of my blog post where I take a specific application and I Profile it and then I remove bottleneck one at a time. I have a couple of blog post like that so that kind of gives an idea how I do this. We can definitely share it to our audience. CHUCK: Oh, that's great. WARD: That's gold. That's gold. CHUCK: Yeah. Seeing it in the real world that just takes it from that place where it's -- that's a nice theory to, "Oh, I have this exact same problem in my application," or "I have code that looks a lot like that, boom!" GLEB: Yes, yes. It's definitely a learning experience. You have to look at what other people are doing right and learn from them. It's hard to optimize your application in production. You have to practice on other projects, I think. CHUCK: Yeah. WARD: One of my favorite Performance techniques, which is videoing the user at work [laughs]. Just watch him go, when you have the luxury of doing that, and watch them use the interface until it accomplish a task the way they think they're doing it, the way they always felt that should be done is mind boggling. They do stuff, you just wonder how you set it up so that they did it that way and you start getting all kinds of great ideas about how you could make a difference there. I'm sure you've had that experience, Gleb. And I think there's also a misunderstanding about the difference between designing a UI for the newbie or casual user and then for the person who's sitting in front of it all day long. GLEB: Right. WARD: And there's no reason to inflict the same View for the task on both of those people at the same time. So if I'm doing payroll entry and it's a headsdown keyboard thing, that's a completely different user interaction than if I"m going in to make a configuration adjustment, which I never do. GLEB: Right. Anytime you have a chance to absorb your user and interact and actually see them, use the application. You should jump on that chance and see and be as nice and as polite and -- almost like a sponge - Listen, Absorb, and Learn. It's a great chance. CHUCK: Even if they're doing it wrong. GLEB: Even if they're doing it wrong. They do it wrong for a reason, right? CHUCK: Yup. GLEB: It's not their fault that they're doing it wrong. WARD: Unless you're Steve Jobs, then you're holding it wrong. [Laughter] GLEB: Oh, that's right, that's right. No, no Steve Jobs here. CHUCK: Alright, well, let's go ahead and get to some picks. Ward, do you have some picks for us? WARD: Oh, man, I'm sorry I'm pick-less today. CHUCK: No! That means I have to do like 10 zillion picks to make up for everybody being gone. WARD: Well, what can I tell you my friend. This flu I've got has completely erased my brain. CHUCK: Oh, wow. That's a real virus. Alright let's see, I do have some picks actually. The first one is a podcast whose by a friend of mine, Saron. She host a podcast called "The CodeNewbie Podcast". Despite what it sounds like, she talks to some pretty experienced people about some pretty deep stuff, and I highly recommend (if you're a developer) to go listen to it. There's just all kinds of great stuff. I"m right in the middle of the March ones which were March is for Makers so she's talking to people who do hardware hacking, Raspberry Pi, Arduino, that kind of stuff. Great stuff. And she just talks to all kinds of people. Scott Hanselman has been on there a few times. I just can't say enough good things about that show. It's just awesome. I want to remind everybody that I am doing the Ruby Remote Conf. If you're wondering what I'm going to get around to at Angular Remote Conf, stay tuned. And then, I'm going to pick a few others that are just kind of favorites. There's a podcast "Wait, Wait... Don't Tell Me!" by NPR, which is freaking hilarious. GLEB: Yup! CHUCK: They make fun of all kinds of news-related stuff and it is just funny. Another one along the same vein is this kind of word-puzzles and stuff. It's "Ask Me Another", and that's also NPR, and that one's a lot of fun. And then, I'm just going to plug real quick. We do have other shows on this network. There are 4 other shows, and then I'm starting up a video series on Ruby on Rails. The first one that we started was actually Ruby Rogues and the next one that we started after that was JavaScript Jabber, which I think is pretty relevant to this. Joe Eames is actually on that show as a regular. JavaScript Jabber incidentally accounts for half, about half of the podcast downloads between all of the shows that I'm involved with. And then, obviously, we do Adventures in Angular, and then I have a show on freelancing called The Freelancer's Show, and iPhreaks which is about iOS development. So if you're interested in any of that stuff, go to DevChat.tv and check it out. And then, I am going to be launching RailsClips, which is going to have its first videos coming out next week, which is going to be this week or a week ago because we're few weeks ahead. Anyway, it should be out by the time the show comes out so go check it out - railsclips.com. That will also take you to DevChat.tv. That should give you some idea on some of the things we do around here and some of the things I'm involved with. So, thank you, Ward, for letting me toot my horn. Gleb, what are your picks? GLEB: First of all, I love Wait, Wait... Don't Tell Me. It's a great podcast, I listen religiously. On a similar vein, if you've never listen to "Car Talk", it's unbelievable. It runs for long time in Boston. It's just 2 brothers discussing car problems and answering people's questions. Hilarious. CHUCK: Didn't they got nicknames like Click and Clack, or something? GLEB: Exactly, yes. WARD: Click and Clack, and one of them just died and it's a sad thing. GLEB: It's a sad thing. They were like right here in Campbridge down the street from Harbor Square. I have a pick and that's my kind of collection of learning resources. Basically, newsletters, books, whatever I receive curriculary to keep me up to date. And then the second -- CHUCK: I know you got podcast that should be on there. GLEB: It should be, right. I don't listen to a lot of podcast to be honest so I apologize. But actually, when I work, I prefer music with no words. I cannot concentrate on typing and thinking and listen to podcast. It might be English as a second language kind of thing. But the tool I highly recommend, I love Sublime, and I recommend installing "Colorsublime". It allows you to literally flip through any color theme like at a push of a button and find a new color theme right away. What I usually do to get my creativity going, whenever I switch between different projects, even like in the middle of the day, I will pick a new theme. I honestly believe that switching colors kind of help me reset my internal clock. So I highly recommend this for Sublime users. WARD: Oh you are so funny. [Laughter] WARD: I thought that my clothing was funny, but that's funny. GLEB: [Chuckles] No, I honestly like sometimes, when I start a project, I will move to a new desk, kind of roam around the office, even literally I have to kind of find yourself in a new environment, look at the different font size, maybe font color to kind of start fresh. And before I forgot, Kent who has Angular formerly project, asked me actual question to answer to this podcast. You have to kind of delay when loading lots of forms and you have excellent project, but it generates forms. One performance where they found to be a problem in Angular just as a last tip is: If you have a long promise chain, whenever you bootstrap, it's actually creates a noticeable delay because every step in a promise chain has the way to stern, kind of do it on the next iteration of a rent loop. So whenever you use a lot of promise chains, do not use them inside your link function or maybe controlling installization; use them in the normal methods, but not at the startup. CHUCK: Alright. WARD: That's a good one. GLEB: So these are the only 2 picks, I guess, I have. CHUCK: It's all good! Yeah, I forgot to ask Kent's question. GLEB: Yeah, I just remembered. CHUCK: Kent, if you're listening to this, I owe you lunch. Alright, well, let's go ahead and wrap up the show. Thank you for coming, Gleb. GLEB: Oh, thank you, Chuck. And thank you, Ward. I appreciate talking to this. CHUCK: If people want to follow you on Twitter or get in touch with you, what are the ways to do that? GLEB: Follow me on Twitter @bahmutov. I also have a website with all my open source tools. Basically, if you search under my name, you'll find me right away. CHUCK: Yup. And if you're wondering how to spell that, you can come find it on the website. GLEB: Yes, exactly. WARD: I take you, Gleb, that you're busy all the time. You're not farming yourself out, are you? GLEB: Farming in terms like -- WARD: Consulting for people. GLEB: I do sometimes, but it's very pure hours. So mostly, just Performance reviews. CHUCK: Alright, well, let's go ahead and wrap up the show. Thanks again! And we'll catch everyone next week![This episode is sponsored by Mad Glory. You’ve been building software for a long time and sometimes it gets a little overwhelming; work piles up, hiring sucks, and it's hard to get projects out the door. Check out Mad Glory. They are a small shop with experience shipping big products. They're smart, dedicated, will augment your team, and work as hard as you do. Find them online at madglory.com or on Twitter at @madglory.]**[Hosting and bandwidth provided by The Blue Box Group. Check them out at bluebox.net]**[Bandwidth for this segment is provided by Cache Fly, the world’s fastest CDN. Deliver your content fast with Cache Fly. Visit cachefly.com to learn more.]**[Do you wanna have conversations with the Adventures in Angular crew and their guests? Do you wanna support the show? Now you can. Go to adventuresinangular.com/forum and sign up today!]**

Sign up for the Newsletter

Join our newsletter and get updates in your inbox. We won’t spam you and we respect your privacy.