The document summarizes the keynote presentation at the 2012 jQuery Conference about recent and upcoming developments with jQuery. The presentation discussed: 1) The role of the jQuery Foundation in supporting the jQuery project and community. 2) Recent releases of jQuery Core, including version 1.8 which focused on modularity, performance improvements, and deprecating unused code. 3) Plans for upcoming major releases, with jQuery 1.9 continuing to clean up APIs and jQuery 2.0 removing support for older browsers to simplify the codebase.

2. jQuery Conference 2012
San Francisco
Dave Methvin
President, jQuery Foundation
Lead Developer, jQuery Core

3. Just a few things going on…
• jQuery Foundation
– Gives us a way to organize support for the jQuery
project and community efforts
• Software development
• Documentation and training
• Conferences
– Tomorrow morning's keynote by Richard Worth
• jQuery Core, UI, Mobile

4. jQuery Core Timeline
• jQuery 1.0: January 2006
• jQuery 1.1: January 2007
• jQuery 1.2: September 2007
• jQuery 1.3: January 2009
• jQuery 1.4: January 2010
• jQuery 1.5: January 2011
• jQuery 1.6: May 2011
• jQuery 1.7: November 2011

5. jQuery Core Timeline
• jQuery 1.0: January 2006
• jQuery 1.1: January 2007
• jQuery 1.2: September 2007
• jQuery 1.3: January 2009
• jQuery 1.4: January 2010
• jQuery 1.5: January 2011
• jQuery 1.6: May 2011
• jQuery 1.7: November 2011

6. jQuery 1.8: July 2012
• Only major release this year
• Fix bugs, make things faster (of course!)
• Add some nice things (CSS vendor prefixes)
• Dump unneeded code (Safari 2 for example)
• Deprecate "trip hazards"
– E.g. $.browser
• Set the stage for future work

7. jQuery 1.8: Modularity
• New grunt build system (yay @cowboy!)
• Intended for advanced users in 1.8
– You must understand your project dependencies
• Exclude parts you don't need
– ajax, css, dimensions, effects, offset, deprecated
• Simple option in the jQuery build
– Documented in the README file
– Blog post to come

8. jQuery 1.8: Modularity
• Theoretical example: Small mobile app
– Uses classes for CSS styling and animations
– No third-party plugin dependencies
– Only needs JSONP, using jaubourg's jsonp.js
– jQuery 1.7.2: 32.8KB min-gz (full jQuery)
– jQuery 1.8: ~24KB min-gz (including jsonp.js!)

9. THIS is why it can't be simple

10. jQuery 1.8: Closure Compiler
• Experimental branch, not yet available
• Supports CC's ADVANCED_OPTIMIZATIONS
– Renames variables and property names
– Eliminates dead (uncalled) functions
– Inlines function calls
• Intended for really advanced users
– obj.name vs. obj["name"] confuses optimizer
– Code annotations act as optimizer hints
– All your code needs to be CC AO safe
– Difficult to debug

11. The Future of jQuery

12. The Future of jQuery

13. jQuery 1.9: Early 2013
• Continued API cleanup
– Better modularity and speed, smaller size
– Remove some deprecated APIs
• Compatibility plugin
– Includes most of the APIs we remove
– For the times you just want to "make it work"
• Support and unit tests for all major market-
share browsers (including IE7/8)
• IE6 serious-regressions-only policy

14. This is the exciting part

15. jQuery 2.0: Early 2013
• Same API as jQuery 1.9
• No major feature additions

16. jQuery 2.0: Early 2013
• Same API as jQuery 1.9
• No major feature additions

17. jQuery 2.0: Early 2013
NO SUPPORT
FOR IE6, IE7,
NOT EVEN IE8

18. Why This Approach?
• OldIE workarounds permeate jQuery
– Refactoring to a plugin isn't practical
• We have a solution for oldIE – version 1.9
– Remember, it's the same API

19. Shunning oldIE: Advantages
• Jettison all the oldIE hacks
– "Attroperties"
– DOM-vs-JavaScript memory leaks
– innerHTML serialization quirks
– HTML5 shimming
– Spontaneous tbody in empty tables
– Opacity via filters, causes grainy text
– Incorrect case sensitivity on attributes
– Non-W3C attachEvent model
– Can't change type property of inputs
– Link href attribute returns absolute URL
– No bubbling on change and submit events
– Unreliable offsetHeight on table elements
– Thrᵒ exceptions on invalid CSS values
ws
– Appended checkboxes lose their chec√s
– Broken try/finally – there's G0T to be a catch
– Host objects, please NOT hosT objects
– It comes it cOmes cannot fi​ght it com̡e̶s, ̕
– ̵Un̨ho͞ly code destro҉ying all enli̍̈́̂̈́ghtenment,
– JScript lea͠ki̧nᵒ fr̶ǫm ̡yo​ r eye͢s̸ ̛l̕ik͏e liq​uid pain,
g ͟u
– ALL IS Lo ̩͇̗̪̏̈́T ALL I​S LOST
– MY CODE MY CODE ᵒh noNO NOO o

20. Simplify, Simplify, Simplify
• Removing oldIE improves the code base
– Faster
• Fewer feature detects required at load time
• Fewer tests needed at run time
– Smaller
• Especially when combined with modularity!
– Revisit design decisions warped by oldIE
• E.g., attach data directly to DOM elements

21. Not Just Mobile – Modern
• Yes, oldIE is just a "desktop" concern
• But "mobile" is not just iOS/Webkit
– Poster boy: Microsoft Surface Tablet
• Not just one screen size; not Webkit
• Mouse, touch, stylus, maybe even Kinect?
– Responsive design to the rescue?
• jQuery 2.0 will support modern browsers
– Not just a Webkit subset of browsers
– We don't want to break the web

22. "IE8 can't use my site?"

23. Breaking the Web?
• jQuery Core team will support two versions
– Version 1.9 works with IE 6/7/8
– Version 2.0 does not
"But Dave, my web site still
needs to support IE 6/7/8 but I
want to use jQuery 2.0!"

25. jQuery 2.0: "Tears of Joy" Policy
• Include jQuery 1.9 only for oldIE:
!--[if lt IE 9]>
<script src="jquery-1.9.0.js"></script>
<![endif]-->
<!--[if gte IE 9]><!-->
<script src="jquery-2.0.0.js"></script>
<!--<![endif]-->

26. jQuery Core Future Growth

27. jQuery Core Future Growth
• Improve browser features or solve issues that
exist everywhere (e.g. CSS vendor prefixes)
• Beyond that, emphasis on plugins
– Don't make everyone pay for platform-specific
features and needs
• You can still use a CDN jQuery but compress
all your plugins and site code!

28. Why We Plugin: Touch Events
• Two non-standard implementations
– Webkit touch events
– Microsoft MSPointer
– No sign of a W3C standard (Apple patents)
• Can we normalize like we did with oldIE?
– Maybe … but to which implementation?
– Webkit: de facto; MSPointer: flexible, unproven
• Should we include this in core?
– Way too early for that. Plugin for now!