Keeping JavaScript Fast

[MUSIC] 0:00 Loading a web app into the browser is very different from launching an installed app. 0:04 Your users for good reason expect web apps to be as responsive as installed apps. 0:09 So that means we need to make the delivery of your app code as fast as possible, 0:15 and that means keeping your JavaScript lean. 0:20 Remember our performance budgets? 0:24 Before we get into optimizing JavaScript, I wanna take a second and 0:26 talk about polyfills. 0:30 Polyfills are small libraries that fill a gap in browsers that don't support 0:32 the features we need them to. 0:36 While they are a great resource, they are also a performance killer. 0:38 Many developers take an easy way out and simply bundle all the code for 0:42 all the users. 0:46 But this is a disservice to users who don't need the overhead. 0:47 To really optimize their experiences, 0:51 we need to be smarter about loading polyfills. 0:53 There are a number of ways we can do this. 0:56 But to read more I linked to an article in the teacher's notes. 0:58 It's a comprehensive overview of the problem and a well thought out solution. 1:02 When building UIs, it's not uncommon to see developers using large library 1:07 tools like jQuery and jQuery UI. 1:12 While jQuery is a widely used and respected and 1:14 well known Java Script library, opinions are changing. 1:17 They're all alternative solutions for 1:21 many of the things that we used to use jQuery for. 1:23 Let's imagine that we are working on a project and 1:27 have been asked to add a day picker with a calendar UI feature. 1:29 We all know that browsers by themselves do not support this interaction natively, and 1:34 let's not forget about the mobile experience as well. 1:39 Let's also imagine that we currently do not have jQuery in our application, 1:43 and are being extremely responsible about our performance budget. 1:47 Let's build a simple view that only loads jQuery resources. 1:52 To keep this a fair fight, I have already downloaded a customized build of jQuery UI 1:56 to only the day picker widget and supporting features. 2:01 But don't forget jQuery UI has a dependency on jQuery itself and 2:04 a host of other files you see loaded here in the head of the document. 2:08 Loading this into the browser locally without gzip compression 2:13 we see 206k of data. 2:16 Thinking about say our 800K budget, that's significant was we haven't 2:18 even started to write any code yet to support this feature. 2:23 Instead of using jQuery, 2:26 let's build this feature using only resources we need to accomplish this task. 2:27 Let's also see if we can keep this below 50K initially and 2:32 less than 20K when g-zipped. 2:36 For this project we will make use of the native HTML5 input type date. 2:38 A date picker specific library called pikaday and another date picker specific 2:43 library called moment that helps us normalize the JavaScript date object. 2:48 Let's set up a view that loads only these resources and see where we weigh in. 2:53 For only loading the raw resources and the necessary DOM for the new feature, 2:58 we are at 68K. 3:01 Before we get into feature development there is one thing we can do to 3:03 optimize this for mobile users right away. 3:06 There's no reason for sending the pikaday library to mobile users since 3:09 they will not be using this widget UI. 3:13 So let's update our code so that the header request is removed for 3:15 mobile users. 3:18 Now for mobile users, we are around 46k. 3:20 Just for clarification, document.write may not be the best solution here but 3:24 it works for our example. 3:29 Please see the teacher's notes for robust solution on writing down elements. 3:31 Now the JavaScript feature itself, we have a new JavaScript file called feature.js. 3:35 In here we have a handful of functions to support the design spec. 3:41 I won't go into full detail here about the functions in the feature file, but 3:44 it is included in the course and it is well commented. 3:49 Loading this into the browser we see that we are at 76K for 3:52 a fully developed feature. 3:56 We are well below the 200K we started with and we can even make this smaller. 3:59 In the next lesson we will look at some common yet powerful compression 4:04 processes that will really drive down the total weight of this feature. 4:08 By breaking this feature down to its essential parts, 4:14 we have really scaled back the amount of code needed to deliver this feature. 4:17 So far we are looking really good, but we can do better. 4:21 In the next video, we will improve on this by introducing some 4:25 really powerful code compression steps, and a Gulp build pipeline. 4:28