4. The jQuery Foundation Is...
• A non-profit organization
• Funded by
o Conferences
o Donations
o Personal and Corporate Memberships
http://jquery.org/join
5. jQuery Foundation Projects
• http://github.com/jquery
• jQuery Core, UI, Mobile
• Sizzle selector engine
• QUnit unit test framework
• jQuery Migrate plugin
• TestSwarm CI testing
• Documentation
6. jQuery Foundation Initiatives
●
●
●
●
●
Support jQuery development
Support web developers
Support web standards
Advocate for developer needs
Participate in standards process
○ W3C
○ ECMA 262 (JavaScript)
7. jQuery Team - World Wide
Not shown: Brazil, Australia
15. The jQuery Core Plan
• jQuery 1.x vs. 2.x
o jQuery 1.x still supports IE 6/7/8
o jQuery 2.x supports modern browsers
o Both are maintained by the team
o Deprecated features removed
Still supported jQuery Migrate
o Same API
16. We're Ready to Ship!
• Released jQuery 1.9 in January
• Released jQuery 2.0 in April
17. What We Learned (the Hard
Way)
are using "latest"
versions in live sites!
NEVER HOTLINK:
http://code.jquery.com/jquery-latest.js
http://ajax.googleapis.com/ajax/libs/jquery/1/jquery.js
19. jQuery Migrate Plugin
• Identifies things your code is doing that
jQuery 1.9+ doesn't support anymore
• Actually makes older code work
• Lets you use newer jQuery with older
code that hasn't been upgraded yet
22. The Moral of the Story
In jQuery, every change is a breaking change for some poor developer.
23. jQuery 1.10
• Relatively minor changes from 1.9
• Brings 1.x into alignment with 2.x line
• Simplifies cross-version comparisons
o 1.10 --> 2.0
o 1.11 --> 2.1
o 1.12 --> 2.2
24. jQuery 2.0 is a good fit for
• Chrome or Firefox plugins
• node.js apps (jsdom)
• Windows 8 Store apps
• PhoneGap / Cordova
• Embedded UIWebKit or WebBrowser
• Intranet applications
AND
• Public web sites that support only
modern browsers (not IE 6/7/8)
25. Which version to use?
• The jQuery team supports both 1.x and
•
2.x; there isn't a problem of using an
"unsupported version"
Since 1.x/2.x APIs are the same, there is
no problem in using 1.x exclusively on a
public web site -- it's recommended
26. jQuery 1.11/2.1: Next Version
• Asynchronous Module Definition
• AMD takes care of internal dependencies
• You can choose the modules to load
• More flexible and granular than previous
custom grunt build process
27. 1.11/2.1: Just-In-Time Detects
● Previously: jQuery runs feature detects
all at once, on page load
○ Impacts page load performance
● Now: Feature detect runs the first time
the feature is used
○ Defers the (layout) impact until needed
28. jQuery 1.11/2.1: Still Simple
• You don't have to use Bower
• You don't have to use npm
• You don't have to use AMD
• Just include from a <script> tag
• You'll still get the performance boost
29. 1.11/2.1: When?
• Beta is out NOW
• Give it a try
• Tell us when you think it's ready
• Which means you have to try it
o http://code.jquery.com/jquery-git1.js
o http://code.jquery.com/jquery-git2.js
31. Why $.browser Deserves To Go
• Based on the unreliable userAgent string
• Often assumes future browsers and
versions will be broken the same way
• Horribly misused and misunderstood
32. Browser Name is Only a BRAND
Opera's future products will be based
on WebKit, not their Presto engine.
34. Disclaimer
•These are general stats collected from a
wide variety of different sites
•Always look at the actual stats for your
sites before making decisions about what
to include or exclude
42. What it All Means
• Desktop is still king
• Chrome ahead, but not massively
• IE share actually grew in 2013
• IE 6/7/8 demise will accelerate
o XP support ends in April 2014
• IE 9+ is on the auto-update path
o But maybe the next business plateau?
43. You Need to Test Multiple IEs
• Emulation is not the real thing
• http://modern.ie
o Free VM images
o Free BrowserStack 3-month subscription
o Free compatibility scan
This is IE11 running in
IE7 emulation -- not
the same thing as IE7!
44.
45. Web Devs Take Note
● jQuery ...
○ simplifies/shortens code
○ hides browser differences
○ doesn't try to hide the browser model
● You still need to Know JavaScript
● You still need to Know the Browser
○ Especially the layout engine
52. Example: Loops and jsperf.com
Slowest looping style still only
takes 1.4 milliseconds to do
100 iterations of a loop!
Simple, straightforward for
loop turns out to be the fastest,
no trickery needed!
53. Know (and Use) Your Tools
● Understand the browser
● Know the components of performance
○ Asset loading
○ Page rendering
○ Script execution
● Learn how to find bottlenecks
● Measure them in your app/page!
54. Plenty of Free Tools and Info
• http://calendar.perfplanet.com
• Webpagetest.org
• YSlow
• Google PageSpeed Insights
• Fiddler
• Built-in browser dev tools
55. Learn to Love the Browser Model
Two heads (threads) are better than one.
56. Most Browser Work is 1 Thread
• Few things happen in other threads
• JavaScript runs on the UI thread
• Don't block the UI thread!
o Long-running scripts
o Synchronous XMLHTTPRequest
o Forced Layouts
57. Make the Most of Parallelism
• Start network requests early
o Use the browser's HTML asset scan
o AJAX before the HTML page is ready
(or generate on the server side)
• Image downloading
• Image decoding
• Web Workers
58. Some Performance Guidelines
● CSS at the top, scripts at the bottom
● Define <img> tags in initial HTML
○ allows speculative fetching
● Non-essential assets after page load
○ "above the fold" should have priority
● Minimize use of $(document).ready()
● Don't make the browser recalc layout
Saw the attendee list, imagine audience as a box of kittens
I am Dave Methvin, President of the jQuery Foundation and also the lead developer of the jQuery Core library. The organizers of the conference wanted to choose a speaker who is known around the world for his expertise in computer technology and has experience in all aspects of data processing. They found an American who would be perfect and he is now here in Russia..
Most of you are familiar with the jQuery JavaScript libraries, but perhaps not as many know about the jQuery Foundation. The Foundation is a non-profit organization founded in March 2012. It coordinates the work that is required to maintain the libraries, documentation, and events surrounding jQuery. Anyone can support the foundation by making a donation or becoming a member.
Most of the jQuery Foundation's work is done on GitHub. That includes both the code and the documentation. Content from our documentation sites is also kept on GitHub, and the sites themselves are driven through WordPress using server and bandwidth resources donated by Media Temple.
However, the jQuery Foundation does much more than just maintain code and documentation for the JavaScript libraries. We support and advocate for the needs of web developers worldwide. Organizations such as the W3C and ECMA create the standards that we all use, but they are primarily controlled by the large companies that make web browsers and platforms. The jQuery Foundation provides a voice for developers in this process.
And the jQuery Foundation is truly a worldwide organization. We are proud to have team members contributing from all over the globe, including Russia. We have landed pull requests from contributors on every continent except for Antartica. We are very disappointed in Antartica.
We are always looking for new people to help with the work that needs to be done. If you are interested, go to contribute.jquery.org.
If you want some evidence of jQuery's popularity, go to builtwith.com. Right now the library is used by more than two-thirds of the top 10,000 web sites.
I am proud of the way our team has made the library smaller, faster, and more reliable over the past few years. We have very few new bugs being reported.
At the beginning of this year, the Core team released jQuery 1.9. A few months later, we released jQuery 2.0. Both versions clean up the API, removing things that are considered very bad development practices like browser sniffing. Both versions are being supported, and they have the same API. The only difference is that the 1.x versions support Internet Explorer 6, 7, and 8.
The team understands that there is a lot of older jQuery code that may break when version 1.9 or 2.0 is used. That is why we created the jQuery Migrate plugin. In most cases you just need to add this plugin to your older project to get it to work. But the jQuery Migrate plugin also generates console messages that help you find and fix the problems in the code. We do not recommend it as a permanent compatibility crutch, but instead as a diagnostic tool for your web sites.
We are currently working on a new version of jQuery that uses AMD internally. It provides much finer control over what can be included or excluded from a custom build. This is especially useful for web applications. Although both branches of jQuery support this feature, users of the 2.1 branch will probably find it to be the most useful.
We also took a fresh look at performance for this upcoming version. Feature detection is the right way to apply browser-specific patches, but in previous versions we ran all of those tests when jQuery loaded. This could cause the page load to be slower than necessary, especially on mobile devices that are slow anyway. Now we only run the feature detects the first time the functionality is needed. If your code doesn't ever use a method such as .offset(), you will never need pay the price for its feature detection.
With all these changes to the way jQuery is built, we still wanted to keep things simple for the average web developer. Yes, we will be supporting a lot of new things, but jQuery will still be available from the standard CDNs as a single file, included by a script tag. And, you will still get the performance benefits that we provide, since the new code will wait for the first use to do feature detection.
We released the first beta of jQuery 1.11 and 2.1 last month. Please do go and try it, and let us know if you have any problems. Nothing saddens us more than having a long beta period where we give developers a chance to try the code, and getting several bug reports the first day of the final release.
Perhaps you're wondering how long we'll need to support jQuery 1.x, and of course that depends on how long IE 6/7/8 hang around. So let's look at browser trends over the past year, to see where things might be headed.
Programmers coming from native client development world, or from server environments, often see the browser as if it were a runtime library of methods they call to get something done. That is, their JavaScript code is still controlling the browser and it is clearly the most important thing in the system.
But that is not the case at all!
In reality, the browser is doing most of the work. All of those words in red are just a few of the things that the browser takes care of without your JavaScript being involved at all. If you ask it to, the browser will call your code at various times so you can do something. But the browser is running the show.
To make it clear how important JavaScript is to the browser, remember that there are many perfectly good web pages that don't have any JavaScript in them at all. JavaScript is completely optional. When it comes to performance, all you can do is make things worse. :-)
To put it another way, programmers often focus on the wrong things when it comes to performance. They can see that it makes a difference in some benchmark test they create, but they don't realize that in a bigger system the difference is unimportant.
Here is a simple example using jsperf.com to compare several different ways of doing a loop. As you can see, there seem to be significant differences in the performance.
However, even the slowest looping style is incredibly fast for most needs and loop sizes. And it turns out that the simplest method, a for-loop, is the fastest anyway. Worrying about loops like this is a waste of time until it's proven to be the bottleneck. Premature optimization is the root of all evil, but also a waste of your time.
To avoid making things worse, you need to understand how the browser works. In particular, understand the steps a browser takes to load a page and all the assets such as images, CSS, scripts, frames, and the like. When a performance problem does arise, you must understand how to use the browser's tools to find it and fix it.
Let's look at how the browser works. A good way to solve a problem quickly is to get more than one person working on it. We can use a similar strategy to improve the performance of a web page.
Unfortunately, most browser work happens on just one thread, the UI thread. This is the thread responsible for calculating styles, redrawing the screen, and running JavaScript. So, the worst thing you can do for performance is to create more work for this thread to do, with nothing going on in parallel.
Of the things that the browser can do in parallel on other threads, the most common is network requests. When images and scripts are in the HTML of the original page, the browser can "see" and request them very early in the load process. It turns out that modern browsers also use a separate thread to decode images once they are received -- for example, to convert a JPEG file into a bitmap that can be displayed by the graphics processor. Finally, the new Web Workers spec lets you run JavaScript in a separate thread, but it is restricted in what it can do.
The page won't render until the external CSS has been loaded, so put those references in the head of the document near the very top. Scripts in the head will block rendering, so use them sparingly there. The browser will be able to "see" images and other assets in the HTML, so put them there for best performance. Put most scripts at the bottom of the HTML page.