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 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.
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.
But that is not the case at all!
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.
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.
Transcript of "State of jQuery - AspDotNetStorefront Conference"
The State of jQuery
President, jQuery Foundation
Lead Developer, jQuery Core
The jQuery Foundation Is...
• A non-profit organization
• Funded by
o Personal and Corporate Memberships
jQuery Foundation Projects
• jQuery Core, UI, Mobile
• Sizzle selector engine
• QUnit unit test framework
• jQuery Migrate plugin
• TestSwarm CI testing
jQuery Foundation Initiatives
Support jQuery development
Support web developers
Support web standards
Advocate for developer needs
Participate in standards process
jQuery Team - World Wide
Not shown: Brazil, Australia
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
We're Ready to Ship!
• Released jQuery 1.9 in January
• Released jQuery 2.0 in April
What We Learned (the Hard
are using "latest"
versions in live sites!
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
jQuery Migrate Warnings
• Shown in the uncompressed version
• Problem and solutions documented
The Moral of the Story
In jQuery, every change is a breaking change for some poor developer.
• 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
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
• Public web sites that support only
modern browsers (not IE 6/7/8)
Which version to use?
• The jQuery team supports both 1.x and
2.x; there isn't a problem of using an
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
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
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
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
• Beta is out NOW
• Give it a try
• Tell us when you think it's ready
• Which means you have to try it
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?
You Need to Test Multiple IEs
• Emulation is not the real thing
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!
Web Devs Take Note
● jQuery ...
○ simplifies/shortens code
○ hides browser differences
○ doesn't try to hide the browser model
● You still need to Know the Browser
○ Especially the layout engine
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!
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!
Plenty of Free Tools and Info
• Google PageSpeed Insights
• Built-in browser dev tools
Learn to Love the Browser Model
Two heads (threads) are better than one.
Most Browser Work is 1 Thread
• Few things happen in other threads
• Don't block the UI thread!
o Long-running scripts
o Synchronous XMLHTTPRequest
o Forced Layouts
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
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