Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Andere mochten auch (7)
Ähnlich wie State of jQuery - AspDotNetStorefront Conference
Ähnlich wie State of jQuery - AspDotNetStorefront Conference (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
State of jQuery - AspDotNetStorefront Conference
- 1. The State of jQuery AspDotNetStorefront Conference November, 2013
- 3. Dave Methvin President, jQuery Foundation Lead Developer, jQuery Core
- 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
- 10. jQuery Core Bug Trend
- 11. jQuery UI - builtwith.com
- 12. jQuery UI Bug Trend
- 13. Visual Studio 2013 -- ASP.NET
- 14. jQuery in 2013
- 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
- 18. jQuery 1.9: Users Loved It!
- 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
- 20. jQuery Migrate Console Output
- 21. jQuery Migrate Warnings • Shown in the uncompressed version • Problem and solutions documented
- 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
- 30. • Removed $.browser • Removed .live()
- 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.
- 33. Browser Directions in 2014
- 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
- 36. Desktop vs. Mobile - US/Canada
- 37. 2013 Trend - StatCounter.com IE ~30%
- 38. 2013 Trend - W3Counter.com
- 39. Chrome Versions - Clicky.com
- 40. IE Versions - Clicky.com
- 41. IE6 is Dead! (Except in China)
- 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!
- 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
- 46. How the Programmer Sees It JavaScript Browser
- 47. How the Programmer Sees It JavaScript Browser
- 48. Web Developer's Reality Content caching HTML CSS Network requests Screen paints Browser Layout calculation Image decoding Keyboard Touch Focus management Mouse JavaScript
- 49. Web Developer's Reality Content caching HTML CSS Network requests Screen paints Browser JavaScript Layout calculation Image decoding Keyboard Touch Focus management Mouse Optional
- 50. Programmers often worry about the performance of things that don't really matter.
- 51. Example: Loops and jsperf.com
- 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
- 59. Questions? Twitter: @davemethvin GitHub: @dmethvin IRC (Freenode): DaveMethvin #jquery-dev Email: dave@jquery.com
Hinweis der Redaktion
- 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.