[MUSIC]

Loading a web app into the browser is very different from launching an installed app.

Your users for good reason expect web apps to be as responsive as installed apps.

So that means we need to make the delivery of your app code as fast as possible,

and that means keeping your JavaScript lean.

Remember our performance budgets?

Before we get into optimizing JavaScript, I wanna take a second and

talk about polyfills.

Polyfills are small libraries that fill a gap in browsers that don't support

the features we need them to.

While they are a great resource, they are also a performance killer.

Many developers take an easy way out and simply bundle all the code for

all the users.

But this is a disservice to users who don't need the overhead.

To really optimize their experiences,

we need to be smarter about loading polyfills.

There are a number of ways we can do this.

But to read more I linked to an article in the teacher's notes.

It's a comprehensive overview of the problem and a well thought out solution.

When building UIs, it's not uncommon to see developers using large library

tools like jQuery and jQuery UI.

While jQuery is a widely used and respected and

well known Java Script library, opinions are changing.

They're all alternative solutions for

many of the things that we used to use jQuery for.

Let's imagine that we are working on a project and

have been asked to add a day picker with a calendar UI feature.

We all know that browsers by themselves do not support this interaction natively, and

let's not forget about the mobile experience as well.

Let's also imagine that we currently do not have jQuery in our application,

and are being extremely responsible about our performance budget.

Let's build a simple view that only loads jQuery resources.

To keep this a fair fight, I have already downloaded a customized build of jQuery UI

to only the day picker widget and supporting features.

But don't forget jQuery UI has a dependency on jQuery itself and

a host of other files you see loaded here in the head of the document.

Loading this into the browser locally without gzip compression

we see 206k of data.

Thinking about say our 800K budget, that's significant was we haven't

even started to write any code yet to support this feature.

Instead of using jQuery,

let's build this feature using only resources we need to accomplish this task.

Let's also see if we can keep this below 50K initially and

less than 20K when g-zipped.

For this project we will make use of the native HTML5 input type date.

A date picker specific library called pikaday and another date picker specific

library called moment that helps us normalize the JavaScript date object.

Let's set up a view that loads only these resources and see where we weigh in.

For only loading the raw resources and the necessary DOM for the new feature,

we are at 68K.

Before we get into feature development there is one thing we can do to

optimize this for mobile users right away.

There's no reason for sending the pikaday library to mobile users since

they will not be using this widget UI.

So let's update our code so that the header request is removed for

mobile users.

Now for mobile users, we are around 46k.

Just for clarification, document.write may not be the best solution here but

it works for our example.

Please see the teacher's notes for robust solution on writing down elements.

Now the JavaScript feature itself, we have a new JavaScript file called feature.js.

In here we have a handful of functions to support the design spec.

I won't go into full detail here about the functions in the feature file, but

it is included in the course and it is well commented.

Loading this into the browser we see that we are at 76K for

a fully developed feature.

We are well below the 200K we started with and we can even make this smaller.

In the next lesson we will look at some common yet powerful compression

processes that will really drive down the total weight of this feature.

By breaking this feature down to its essential parts,

we have really scaled back the amount of code needed to deliver this feature.

So far we are looking really good, but we can do better.

In the next video, we will improve on this by introducing some

really powerful code compression steps, and a Gulp build pipeline.