[MUSIC]

The, the reason I call this jQuery's kill Hitler features is

because there's that joke about, you know, if you had a time machine.

Would you go back in time and kill Hitler?

Would that be the first thing that you did?

And if, if I had a time machine and

I was tasked with the job of tweaking jQuery to work better in 2014 these

are the features that I would change in one way or the other.

Or just totally remove, totally kill to make jQuery a better thing for

web development today.

And you know, I, I don't mind saying that jQuery is not perfect.

No language design is perfect.

JavaScript isn't perfect.

I, I think JavaScript gets a bad rap.

That people say, oh you know, it's a horrible language.

But it's really a pretty decent language.

And it's kind of like the rep that Visual Basic used to get back in the 90s.

People did quite a bit of useful work in developing

in developing things with Visual Basic and they have the same with JavaScript.

but, there are things that we can do better.

And, there, there are features in JavaScript that you shouldn't

you shouldn't depend on.

Like things like automatic conversion from string to integer that's a really kind of

a dangerous thing to wat, that you need to watch out for.

And in the same way, jQuery's API has some things seem like a good idea at the time,

turned out they weren't such a good idea.

And to give you an idea of how far we've come, this is,

this is browser market share in 2006.

So in January of 2006, jQuery was announced and released.

And at the time, IE six was 85% of the browsers out there.

Firefox was somewhere around 10-ish%.

And then, you know, even,

there were even browsers like Netscape out there still that people were using.

So, you have to real, you know, think about it,

well browsers have changed a lot in that time and jQuery has had to change as well.

Really the main strength back in 2006 was the browser,

the ability of jQuery to really simplify the act of

writing a web page that worked across all the browsers that were out there.

And really there were two browsers out there.

IE six and Firefox it's around Firefox one or two at the time.

And even when you look at the DOM api's that Firefox was starting to provide.

JQuery made that work easier with this API.

So, even if you liked the DOM APIs that were there, you had to admit that,

gee, jQuery makes it a lot easier to write that code.

Even if I didn't have to worry about cross-browser compatibility,

the ability in jQuery.

To simply do, you know write one line of code and get it

to do what 20 lines of bare JavaScript code would have taken, is a big plus.

Now the other thing that really marks the difference between 2006 and

2014 is Everything was slow back then.

We just weren't doing things anywhere near as ambitious as we

are doing today with JavaScript.

I, I don't think anybody would have expected that you

were writing a high performance, high frame rate games with java script In 2006.

We were mainly using for simple animations.

For, form validation, you know,

in most cases back then the page worked even if JavaScript was disabled.

I, you know there's just no way that 2014 web

pages work with JavaScript disabled most of the time, but back then.

They did work with JavaScript disabled and,

and,part of that was because we were just weren't doing that much with.

But today is very different.

JavaScript is very fast, you don't really have the problems that you have with,

with slow JavaScript anymore.

It's rarely the bottleneck.

You can do things in JavaScript to make your web page or websites or

applications slow.

But it's usually not because you're running too many lines of JavaScript.

And CSS element selection, which is again one of those things that people used to

debate over endlessly, you know.

Is it better to select by class or by ID?

Those kind of things are rarely the bottleneck today either.

So but still we have problems where webpages, especially when loading,

are, are very slow.

Why is that?

Well the main problem is that our pages are flabby, very flabby.

This is a graph composed of information from the http archive.

That shows really a three year period 2010 to 2013 showing what's happened.

And you'll notice actually the green line here which is scripts has started to

flatten out around 200k.

If you look at the size of jQuery it's actually less than 100k.

And so, what's happened is all of the, the,

data that we're transferring is taking longer and longer for the page to load.

Now I have a little more information about that.

This is the data directly from http archive and

this is the most recent data, so this is looking at this year.

And you can see the total transfer size now is up to 1.8 megabytes on,

on the average page.

The total number of requests are hovering just under 100.

So, you know, if you wonder why it's taking so

long for pages to load, here's your answer.

And again if you look at JavaScript.

Were creeping up on 300k of transfer size in 18 files.

And jQuery is just a tiny little piece of that.

And to give you an idea of what the trend is for

jQuery, here's jQuery's growth since 1.2.

And, if you look in this area, this blue line is actually the uncompressed size.

So you really don't wanna look at that because that includes things

like comments.

And you know, like back in the 1.4 days we said gee,

we really should document this stuff better, and we added a bunch of comments.

And that's why it got better.

But once you minify the code, you can see that the growth is much less steep.

But you can also see you're in jQuery 2.0.

We pulled that support for IE six, seven and

eight and we cleaned up the code in general.

And you could see that we got the size down quite a bit.

It's actually minified about a, minified is about 83k.

And minified in G zipped,

which means it's coming over the wire that way is less than 30k.

So the problem with pages getting larger isn't really a jQuery problem.

In fact, we've been going the opposite direction of the trends that we see in

the http archive.

So, the main reason why

our pages are getting flabby is because they're doing very ambitious things.

We're writing full applications and games in browsers as I said.

We really couldn't have imagined that back in 2006 that

we would be doing those kind of things in a webpage or a web app.

And when you do that, some jQuery features that were built back for those days when

we were just kind of dressing up the page, don't really work that well.

But we have to be careful because even if we think something is a bad idea,

if we change it too much we'll break the web.

And, it's a little different than the there,

there's the term break the web there that the browser makers use.

Their problem is that every time a browser automatically updates, if they

break the way something works, the user is facing this problem where they have no

choice, the browser updated they can't go back to the old version they're stuck.

It's a little different with jQuery,

with jQuery, you always have the ability to stay with the old version.

There's a thing with a lot of developers, where psychologically, they don't

like the idea that they're not using the latest version, but they also don't wanna

take any time to actually update to the latest version to fix problems.

Having to do with compatibility issues.

So you can't have both.

You know, with jQuery the good news is if you specifically include a,

a version of jQuery, your code will not break because jQuery updated.

If you decide you wanna use the latest version.

Then you have the, the possibly that you will break your page.

So it's a choice that you get to make.

If you decide you wanna make that choice and update your page.

We love it.

We like everybody using the most recent version.

But, we also realise that.

There's no reason to, if you've got a working set of code,

there's no reason to upgrade just because there's a new version out.

[BLANK_AUDIO]

Now here's some of the patterns I'm gonna go into in

depth in this presentation about, things that you should look out for

when you're writing jQuery code, things like unnecessary reflows,.

Code in critical event paths, browser sniffing,

changes to the global behavior of jQuery, and script injection by HTML.

So let's, let's take a look at each one of these.

One of the most critical things about performance in a webpage, especially once

everything has actually been loaded, is the issue of reflow, or layout.

This is when you make a change in the page, in the HTML and

CSS of the page, that requires the browser to do some redrawing, some re-layout.

If you're not careful about managing that you can cause what's called jank, and jank

is when for example you might be scrolling your page or moving your mouse across

the page, somehow interacting with it and you'll see that things kind of are jerky.

They don't work the way, they don't work smoothly.

There's, there's jumpiness in the animations or

in the scrolling that is generally just makes the user feel like, hey,

something's wrong here because things aren't moving smoothly.

There's a few things that we've done forever to minimize reflow.

In your jQuery code you want to try to minimize changes to the page and

when you do make the changes try to batch them up.

One of the things that's been recommended for years is the idea of detaching.

If you have a lot of changes to make detach those elements from the DOM.

For example let's say you're ent, inserting 1000 elements into a table.

Insert those elements into the table where the table's not in the page and

then append the table to the page rather than inserting each

row into the page one by one where there's the chance that the browser will

actually want to layout the page before the whole table is inserted.

The other thing is classes are best used only for styling.

I see some people who want to use class names to indicate programatically what's

going on in the code, and

the danger there is when you change the classes on elements.

The browser may believe that it, and it may be right, that it

needs to redraw based on the new classes that have been changed independent.

So if you need to make changes that require that you

essentially saving information for example on a plug in, use jQuery's data.

Method to save that type of programmatic information rather than

use classes to do that or you can use data attributes for example.

Now of all the kinds of reflows and layouts, forced ones are the worst.

And this is a case where you make a change to the pay,

you make a change to the page and immediately ask the browser a question

that requires it to recalculate styles and or redraw a page.

And I've got a really simple example here.

The first line of code here is marking comments in an inactive section as hidden.

Might be something you do.

The next thing that it does is it uses the visible selector.

I'm going to assume that, you know,

the first thing this ad class does hidden probably sets display none.

But regardless when you ask whether elements are visible and

you've changed classes in the document the first thing the browser has to

do is go whoa wait a minute.

Something could have changed here.

So it needs to stop what's going on.

Remember the browser in many cases is just single threaded, so

it stops whatever's going on.

JavaScript isn't running, but it yield's control back to the,

to the browser to calculate which elements of class comment are actually visible.

And then I'm applying some text appending some text.

In a real-life situation, this would probably buttons or

some other more complex HTML.

But it's really here, the key thing is that I've used the visible selector.

The alternate way to do this, which we're,

which avoids the forced reflow, is notice the first line is the same.

I add a class, but second line's different.

Instead of actually asking the browser whether that element is visible to it.

It simply asks the browser are there any elements that are of class comment that,

that are not of class hidden.

And if so, I wanna append something to that.

So that prevents the browser from having to do those calculations right in

the middle of my JavaScript.

And that means that in eventually it's going to re, wanna do that calculation.

But it can do it at a more convenient time and

it can also do it when other changes have been made to the doc.

So in short the hidden

invisible selectors which are specific to jQuery, are kind of Kill HItler features.

As, as cool as it seems to say, gee, I'd like to select all the visible ones or

the hidden ones they really don't turn out being as useful,

because they do cause this type of behavior, where the,

the browser needs to recalculate styles and reflow the page.

It's much better to use classes and in general avoid things like hide,

hide and show and then still just add and remove classes to hide and

show things because of that, because of those very issues.

Now another thing that can trick you up is

high-frequency events like mousemove and scroll.

For something like click, it's nearly not very critical.

If you're using if you're clicking on a button,

whatever is going to go on after the click.

It doesn't really matter that if it happened it probably isn't going to

happen for many seconds later.

So those are not time critical.

However, things like mouse movement scroll.

Mouse move every time the mouse moves even a small distance across

the screen it's calling your JavaScript.

Same with scroll every time this page is scrolled even a little

bit it's calling your code.

So you have to be careful what you do in those types of event handlers.

Especially if you attach those event handlers at the document level.

Sometimes people will attach for

example, a mouse move handler at the document level.

That means every time the mouse mouse moves anywhere inside the browser.

On your window you're going to call JavaScript.

And that can be a real performance killer, if you're not careful.

Let me give you an example of things that can really kill performance.

When you, when you are doing things like scrolling, and

your scrolling is going to cause some reflows,

scrolling can actually happen more frequently than every 16 milliseconds.

The browser attempts to maintain about a 60 frame per second rate, which

equates to about every 16 milliseconds, it wants to redraw the screen.

I always find it pretty amazing when you think about how much stuff is

going on that it can redraw the screen in 16 milliseconds.

But it does.

And changing HTML and CSS in a scroll event usually whatever you do in

that scroll event handler should be able to happen in less than a millisecond, and

that leaves 15 milliseconds for

the browser to do ever, whatever it needs to do.

But if you're not careful, for

example if you do something that requires the page to be redrawn.

And let's say the scroll event is being delivered to you three or

four times in a frame.

Then you're making the browser completely recalculate the page three or four times.

Even though it's only going to draw it once.

Now there's a technique with request to

animation frame that allows you to avoid those unnecessary, redraws.

And it goes something like this.

The core, the core thing to remember here is

you want to move the time consuming work outside of the handler, so

the most common thing you would want that people do is, okay when the window

scrolls and then you'll see a big long multi-page piece of code.

That does a bunch of complex things include, including, for

example maybe it's trying to make a little thing you know, stay in the window so

it repositions a window all the time it's maybe a navigation toolbar.

And I didn't show that because it gets really complicated and

it's not relevant to this specific example but a better way to do that is

every time the window scrolls then just set a flag saying we need to redraw and

then when we do need to redraw,

you call requestAnimationFrame and that one times every

16 milliseconds when the browser asks you hey do you need to do anything to draw?

I'm about ready to go to the screen here.

We do your jo, document changes there.

That saves you the three or four unnecessary, redraws, or

recalculations that you would have made the browser do in the meantime.

Now the result of that is better performance, better battery life,

especially in mobile devices.

You know all, all the pluses that you have from avoiding unnecessary work.

Now, I mentioned here that this needs to be shimmed on older browsers if

you’re trying to make your code work for IEA.

The pressed animation frame is not available, so

you’d usually use something like set time out.

But the, the basic logic here would be the same.

There's a great article in the,

HTML5 rock site that goes through how to do this in more detail [SOUND].

So, let's look at another feature that is one that you should definitely avoid.

Especially since we've now taken this out of jQuery as of, version 1.9.

But people still want to do it.

They, people still believe this is necessary and

no matter how hard we rack them they still wanna do it.

But we've just recently seen some changes to browsers that make it

even more crazy to see what, what browsers have to go through because

developers who use browser sniffing try to do things that they shouldn't.

These are four browsers.

The first three are a desktop browser.

And the last one is a mobile browser.

Notice they all say they're Mozilla/5.0.

And that's for compatibility.

Notice that the first three there say they're running under Windows NT

6.3 on WOW64.

That's the user agent way of saying they're running Windows 8.1 and

it's a 64 bit version of Windows.

The first browser string is actually Chrome.

But you notice how many things it says it is, it's Apple webkit, it's KHTML, but

it's like Gecko and it also is Safari.

The second one is Internet Explorer 11, notice that this browser string

does not have MSIE in it, it doesn't have Internet Explorer anywhere in it.

And the reason is because there is so much bad code out there that

does erroneous things when it says, when Internet Explorer identifies itself.

That they found it was better that the browser spring,

string did not say it was Internet Explorer.

But it still says it's like Gecko.

The third one is actually Gecko's engine, it's Firefox.

And again it says it's Gecko and that it's Firefox.

But the last one I think is the ultimate sadness for for browser sniffling,

and that is the most recent update to the Windows phone browser.

And that's how bad it is.

The Windows Phone browser has to say that it's trident, it has touch.

That it's IEMobile, that it's Android.

But it's an iPhone that's like WebKit, like Gecko, that ru,

that is actually Chrome and Mobile Safari.

And you may be thinking, why would it say that?

What possible reason would have to say that?

Well the reason is, because the IE team started doing some triage of mobile sites.

And what they found was,

that unless they put specific strings like mobile Safari into their browser string.

It would not deliver the mobile experience for Windows Phone users.

They also found that, I believe it was

40% to 50% improvement in the Windows Phone experience, if they just lied.

And, they said that it was an Android mobile Safari device.

So it's unfortunate,

this, just thinking about performance this string is more than 200 characters.

But they need to get all these tokens in there so that the code out

there that's written for the mobile web will work properly on a Windows phone.

And, and, that I, I think is really sad.

So, we don't wanna be a part of that.

So there used to be a feature, dollar.browser,

that was actually deprecated pretty long ago, more than four years ago.

That we said, you know, we are gonna deprecate this.

People should not use browser sniffing.

And, in 2009, 2010, every time we'd talk about removing this,

we would hear wails of protest, that there was just no possible way anybody could

do certain things unless they did browser sniffing.

But, obviously, this is the kind of problem you run into when people do

browser sniffing.

So, which problem is worse?

What we did is in jQuery 1.9, we just removed the feature.

So that's about a year ago.

We said, you know, we don't wanna be a part of this and we,

it's been deprecated for four years, so we don't feel bad about removing it.

We still get people who are using the jQuery comp, the compatibility plugin that

we have, jQuery migrate, so that they'll be at dollar.browser.

And I think that's sad.

It'd be much better for people to move away from that.

In particular browser sniffing just doesn't solve a lot of the modern

problems that you have to deal with as a 2014 developer.

And that includes things like, if you're asking a question like,

is this a phone, a tablet, or a desktop?

You may be asking the wrong question.

What if it's an Xbox?

What if it's a Kindle?

What if you're not used to the screen dimensions,

you essentially responsive design, where you build based on the size of the screen,

may be a better way to make decisions than trying to sniff the browser user agent,

where, when you guess wrong, you get a completely bad experience.

Like, if you're trying to sniff to include only mobile devices, then if you're wrong,

you get a desktop experience on a brand new Firefox phone.

That's not a good thing to have happen.

Asking questions like, does this device have a touch screen by looking for

those touch elements or looking for iPad or something.

That's not a good idea either, because probably what you want to know is,

does this device support touch events the way that iPad does.

Or does it support pointer events for touch the way a Windows phone or

a Windows 8 desktop device does.

So, you should be asking if it supports the features that you need to

use in JavaScript.

Not trying to sniff it via the via the browser user agent string.

And if you try to figure out if it has a certain bug or

feature and that bug still exists in the most recent version,

then your code is gonna be wrong when that finally gets patched.

Or changed in behavior.

[BLANK_AUDIO]

So the best solution is feature sniffing.

Modernizr, is a great way to do that.

Some people complain that Modernizr is too big.

They're custom builds.

If you only need three features of Modernizr,

you can build just the pieces you need and not pull in all the feature to text.

And in, specifically you should be doing that,

you shouldn't be using all of Modernizr.

Just use the pieces you need.

It's very easy to create a custom build there,

just with the feature detects you need.

And quite often, it's easy enough to build your own feature detects.

If you want to know if something supports pointer events,

you can look at navigator.max touch points.

And, that tells you if it supports without even having to

use the modernizer.

Now, another feature that seemed like a good idea at the time is

global $.ajax settings.

If you look at what, what the code what this code does,

it looks pretty straight forward, right?

it's, if you know a little bit about AJAX you'd probably would guess this would get

data.text in the same location of the HTML file that the Ajax call is located in.

It will on success, alert the data.

It's just text.

What possibly could go wrong here?

Does anybody have any ideas about what could go wrong?

Well, what could happen is jQuery has some very sane defaults for

all of that stuff that makes a simple case, like the one we look at here, work.

It says when I get data and I pull it in

if I'm gonna look at the headers that come in off the browser off the server and

if it says that the application type is text.

Then I'm going to treat it as text and

I'm gonna then deliver that back to you on success.

Well unfortunately for you it's possible for

someone to change a lot of things about the way an AJAX post is made by default.

So in this case I have completely messed up everyone.

By setting the type to be a post, and the data type to be JSON.

And I've set a very short 100 millisecond timeout.

So, you would think, well who would possibly do this?

Well it happens, a lot of times people say,

I don't wanna have to type all of this stuff every time I make an AJAX request.

So I'll just put it in AJAX setup.

And then they include some third-party plug-in that

expects the defaults to be what they normally are in jQuery.

And then this is the problem they run into.

These are pretty insidious bugs.

You'll occasionally you'll see people coming across this when they

are asking on stack overflow why is my AJAX all hu, hosed up.

And one of the reasons why it's so hard to determine is,

you may have been the person to make these AJAX setup changes, or

it could be a plugin makes these AJAX setup changes.

So, either way, there are going to be places where there are very

straightforward AJAX requests that look very much like this that have

very weird behavior that unless you knew that AJAX set,

setup had been called, it's not gonna behave the way you expected.

In particular the timeout is scary because if you'd

think about how that might work sometimes this request might succeed.

If you just had the timeout change, sometimes this request would succeed but

if, like for example, if the request was cashed, other times it would fail.

But it would seem really random.

Or it might succeed for you, because you're really close to the server.

But it would fail for people who are using your website.

And the basic problem here, is that global AJAX settings don't work.

There really should be no way that, when you're making a request that these

actions at a distance occur, because it makes it

extremely hard to understand what's happening when you make an AJAX request.

Really, it would, it's much better, even if it requires a little more typing, for

people to say exactly what non-default settings they want when

they make a request.

And so that puts AJAX setup in that Kill Hitler category, I think.

But then people say well, then how do I change AJAX, so

that every time I make a request I don't have to type all that.

Well that's really easy, just write your own little function.

And that little function can extend whatever options that you pass in to, for

example, put in the data type of JSON, and a timeout of ten seconds.

So those settings will always be there in your own requests.

But if somebody else calls $.ajax, they get the regular defaults.

You're only gonna change your defaults and not anyone else's defaults.

Another reason to avoid AJAX setup is sometimes people will try to make,

they'll say, oh, I want a global error handler, any time any error happens in a,

in an AJAX request, I wanna know by having this error handler in AJAX set up.

Doesn't really work that way.

What that does is it says by default if no error handler is

provided then this will be used as the error handler.

But that may not be what you want at all.

You may want to say any error on any AJAX request.

We specifically in the documentation say not do this because it

general won't be what you expect.

Instead, we have a really good mechanism already existing to be able to

attach errors on all AJAX requests.

And, those are events, AJAX events are fired for each request.

The first mechanism here is one way to do it.

If you want to be able to add and remove them, I would suggest you use on and

off, and use the AJAX error event name.

And in this case I've added a names base called autocomplete,

with the idea that if I was writing an autocomplete handler autocomplete plugin,

I would be able to attach an AJAX error that had a name space of autocomplete.

And then if somebody wanted to remove it,

I'm only removing the AJAX error handlers for autocomplete.

Anyones that the user added outside my plugin would stay.

So those, that way you can have as many listeners as you want,

and they're all independent of each other.

And you won't have the problem with some other user clobbering your event listener.

So the next point,

the next one is the next Kill Hitler feature is injecting HTML into documents.

We all know that it's great to be

able to use jQuery to create some HTML and just pop it into the document.

There's a, looks like HTML Rule that we use to

determine whether something is HTML or a selector.

And the reason why this is so

important is and I'll show you some examples in just a second.

Any script tags that are inside a document,

will be run when jQuery injects the HTML into the document.

And this is a feature,

unfortunately, that we added pretty early in the evolution of jQuery.

because, there's a lot of situations where you might accidentally inject something

as script, and there's enough people who see it as a feature,

because now I can inject something that's both HTML and script.

The HTML goes into the document and then the script executes after it.

So it's kind of like a templating and

module system, but we've made it easy, maybe too easy.

Let me give you a really simple example here.

And this something not specifically related to jQuery, it can be done,

you can make just as many mistakes in some ways with without jQuery.

We just make it, we just make it so

that the guns pointed directly at your foot immediately.

Here's a simple example if, if you were to wanna get some information off the URL,

you might do something simple like this.

The URL has a, after the hash my name.

And so I'm going to pull that off window location hash and

then I'm going to append that information that I got onto the document.

Here's what the developer had hoped for.

But imagine if it's really a script.

Well when I append to this,

when I append this to the document, I actually run this script.

And that script can do anything that it wants to do.

I mean it can be a giant JavaScript that can steal the cookies off

the current document.

It can send you, redirect you to some bad place.

There's a whole bunch of bad things that can happen here.

And so a developer that assumes that whatever they get from the URL, or

even from information typed in from the user, if they don't guard against it

being HTML and they just append it to the document, bad things happen.

Here's one thing you can do to avoid those cross eyed scripting problems.

And that is I'm going,

I'm still getting whatever the content is and that could have HTML in it.

Or what looks like HTML.

But instead of just dumping it directly in there as a string.

I'm going to find, I'm going to inject kind of a space holder span here and

then I'm going to use the text method rather than the HTML method.

So anything that looks like HTML will simply be rendered as looking like text,

so it's going to convert GTs to greater than symbols.

So we've solved our cross site scripting problem that way.

So jQuery can help you here as well as hurt you.

You just need to be careful when you're doing something with jQuery.

Remember that anything you get from a source outside your own

JavaScript could have scripting in it, and you want to avoid that being executed.

So we made some changes in jQuery 1.9 to

try to make it less likely that you would hurt yourself this way.

The old rules were this,

if a string was passed as a parameter to the jQuery constructor.

JQuery looked to see if it had tags somewhere within the string.

Otherwise it said, well this must be a selector.

So let's look at some examples to get an idea what that meant.

Okay, if I pass this string, that's HTML.

And if I pass this string,

because it does have tags somewhere within the string, that's HTML.

Now this?

That looks like a selector.

And it is a selector.

But look at this one.

Okay, so if I have a title that has something that looks like HTML in it,

the old rule said it was HTML.

And the same, the same thing for this number 6 here.

if I have something that's start and it looks like it might be a selector, but

it turns out it has some stuff in it that's HTMLish, it was HTML.

So, we tried to make it so you are less likely to hurt yourself that way.

A good example of when this could,

could come to bite you is I have a really simple piece of code here.

And, the way I've written the, the variable names,

I seem to be assuming that a selector is coming into the do good function.

And I'm selecting it.

I'm assuming that I'm gonna select it here, and

then I added a class of good to all the elements that I selected.

But, what if I pass in a paragraph?

Then this do good function performs no useful function,

no use at all You know, this is like, well what good does that do?

I've, I've created some elements, I add a class to them, but

I didn't inject them into a document or anything, so basically that was worthless.

So we did some stuff to try to make that a little less likely.

It turns out that the example I just showed you would still occur, but

we've eliminated the cases that we think are more obvious error cases.

The new rules say, okay this is HTML.

But this which starts with text is not HTML.

This is, this is, it'll be interpreted as a, as a selector.

Now it's not a selector.

So you'll get an error immediately saying, hey, you tried to do something here.

Didn't look like HTML to us.

We thought it's should have been a selector, but it wasn't a valid selector.

So you see that all of these bizarro cases here are not selectors anymore.

Well, this case actually is a selector and it would be a valid selector.

But some of these other ones like.

This which has Redskins in it, is not a valid selector, and

you're gonna get an error message here.

This, number four, actually is a valid selector.

But now at least you know.

When you see cases like number two or number six.

Those are not valid selectors you'll know when you get there.

Now what we've done, if you want to parse something as HTML and it's kind of one of

these unusual cases, you can now do it explicitly with a method called parseHTML.

Note that this does not completely solve the cross site scripting issue, because it

is still possible to run HTML fragments via tricks like an On Air attribute.

If you had an HTML that had an On Air attribute, it will run.

So again, still never just blindly inject user or URL input into your document.

That's a recipe for cross-site scripting.

jQuery.

Even when jQuery's not involved something like the on air attribute will,

will cause a problem.

[BLANK_AUDIO]

So I've started, I used the term kill Hitler on this in particular because

it is tempting to think about going back and changing the way things work.

And, you know,

would jQuery be a better library if we took some of these things out.

And actually there's, the joke kill Hitler comes from the URL I've,

I've shown here about someone who actually invents a time machine and

goes back and kills Hitler and he's supposedly posting to a forum.

Constantly people are posting to a forum saying I went back and

I killed Hitler, and then people are going back and

I'm saying, the people who are on the forum frequently.

Users are going back and saying finally I stopped this guy from killing

Hitler because, as you see, no Hitler means no Third Reich.

No World War II.

No rocketry, no electronics, no computers, and therefore no time travel.

So as tempting as it is to think about what it would be like to change jQuery.

It could be that a lot of jQuery's popularity came from some of

these features that at the time seemed like a good idea.

But in 2014 are not such a good idea.

The key is that as a 2014 developer, it's pretty easy for

you to work to avoid those bad parts of the API.

Now that you know what they are.

So you can go and know don't use the hidden invisible selectors.

Don't inject, blindly inject the HTML into your

page from sources that you're not you're not familiar with.

So, you have the ability to make sure that those features that aren't so

good are ones that you avoid, and still be able to get all the benefits of jQuery.

My voice seems to have given up, so that's good because I'm at the end.

I've got plenty of time for questions, and I'd love,

I know there's some questions that people wanted to expand on some things.

That I had shown in the slide so [COUGH] I welcome your questions.

>> Very fast a little, little while ago while you were going over feature

detection and Modernizer if you had any examples with Modernizer.

>> The the Modernizer site has quite a few good examples.

I also would recommend if you're using modernizer and

don't already have a good template, use HTML5 boiler plate.

Modernizer feature detects are pretty simple.

You go to modernizer.com.

Let's see.

Get this out, oops get this out of my way.

[NOISE] And you have the ability to you can build your own copy of it.

You just check off the things you want.

And then build.

And then the documentation shows you everything about,

you know, how it works for example.

So. [BLANK_AUDIO]

It's really it's pretty straightforward to use and

like I said, don't download the whole thing.

I mean when you're in development mode, just include the whole thing.

But when you come to wanting to do it for production,

if all you need is to see whether the old style flexbox and

index db is supported, you can you can include those.

And again, for ones like index db, those are really simple.

I mean you can go look at the, the source for modernizer and

see how simple those feature detects are.

You don't even need to include modernizer for some of these.

Just, it's a one liner to detect, some of these features.

[BLANK_AUDIO]

>> Questions for

Dave, I didn't see any scrolling back to the chat that we didn't cover.

So if you have any other questions for Dave, please enter them in there.

>> Fire away, guys.

What's next for jQuery, Dave?

>> What's next for jQuery.

We are making some changes.

We're looking at actually introducing a new API for doing AJAX-like things.

If you look at if you look at the way AJAX is, I'll go there.

[BLANK_AUDIO]

If you look at the way AJAX is in jQuery.

It's a really co, it's the most complex API we have.

I mean, it goes on and on and on and on.

And one of the reasons why that is,

is because we try to start doing the simple things for you.

And said oh well, most of the time, we can try to figure out what the data type is.

And we can handle this special case and we can handle this special case.

What happened is we all,

we ended up internalizing all of those things and turning them into options.

And that makes it kind of difficult to approach jQuery AJAX,

as just like, if you're lucky it does just what you ask it to,

just like that example I showed in the presentation.

But when we're trying to do certain things,

all of these special cases that are baked into AJAX get in the way.

I mean it, it's not just XML HTTP requests.

It actually handles JSONP and script and all these other things.

So we decided we wanted to create a very tight tiny AJAX request engine.

That tries to avoid a lot of these pitfalls that AJAX has.

And we're hoping we can make it into the next version that'll be out this Fall.

So that if you just want to do a simple AJAX request,

especially if you're doing a custom build you don't even need to

include the full AJAX you can just include the XML HTTP request interface.

We are gonna try to keep everything very tiny and tight still.

So you saw we made some great strides with cutting down the size of the library, and

we still wanna try to do everything within the budget of the bytes that we have.

And we've also already announced that we're dropping support for IE 6 and

IE 7 in the upcoming version.

There just aren't enough people using it.

If you need it, the old versions of jQuery are out there.

>> Cool. Awesome.

A couple of questions came in while you were talking.

Francois asked what do you think of HTML conditional contents that IE added, and

I think they've recently taken them away haven't they?

>> They have I If you look at how conditional comments are used.

If they’re used judiciously I think they’re not a bad way to include for

example to include a special style sheet that works just on IE7

when they’re used the wrong way like if IE and

you’ll see I believe Tumblr still does that.

You know, you'll see ones where they're saying if IE, which is wrong.

Because IE 10, isn't the same as IE 7.

And for that reason, starting with IE 10, they just start ignoring HTML comments.

So I10 I11 if you put them in.

Anything in, in the comments is ignored.

Which is probably the right way to go.

It never was a standard feature.

[BLANK_AUDIO]

>> a, Asimo asks do you see the use of jQuery reduced by NBC frameworks like

Angular or Ember, that already implement a jQuery-like feature and

native features to manipulate the DOM.

>> Actually I think jQuery will still be the foundation of

a lot if not most of the frameworks that are out there.

The Angular team decided to do their own JqLite.

But there are still like the angular

ecosystem really isn't rich enough yet to have the kind of things like jQuery or

UI widgets, and then you want to end up including jQuery.

Also, they're not fully compatible, they built a subset that was enough for

what they needed to do.

Ember, Backbone.

Most of the rest of them use jQuery.

Either they have a hard dependency on jQuery or they are,

you know they're expecting people to include jQuery because they

don't provide any of those types of features.

So, eventually, maybe if things

like web components become common you'd see a reduce use of jQuery but

right now jQuery is used by more than two thirds of the top 10,000 websites.

So it's pretty much all jQuery