State of jQuery - AspDotNetStorefront Conference

Editor's Notes

• #2: Saw the attendee list, imagine audience as a box of kittens
• #4: 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..
• #5: 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.
• #6: 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.
• #7: 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.
• #8: 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.
• #9: 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.
• #10: 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.
• #11: 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.
• #16: 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.
• #20: 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.
• #27: 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.
• #28: 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.
• #29: 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.
• #30: 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.
• #34: 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.
• #47: 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.
• #48: But that is not the case at all!
• #49: 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.
• #50: 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. :-)
• #51: 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.
• #52: 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.
• #53: 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.
• #54: 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.
• #56: 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.
• #57: 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.
• #58: 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.
• #59: 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.