Skip to content

Instantly share code, notes, and snippets.

@paulirish
Last active August 4, 2016 11:29
Show Gist options
  • Star 5 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save paulirish/43b68a2b6a38ceaaf345 to your computer and use it in GitHub Desktop.
Save paulirish/43b68a2b6a38ceaaf345 to your computer and use it in GitHub Desktop.
jQuery 3.0 Ideas

Just some early draft thoughts

Increased modularity is a long-standing request of jQuery. 3.0 should deliver on that. Many authors will use jQuery 3.0 in ES6 codebases, and often alongside frameworks that have overlap in functionality.

That said, a majority of developers will use a monolithic build. jQuery 3.0 must aggressively remove API surface area and functionality from this core build to protect developers from performance footguns. The jQuery team has reasonably voiced concern that removing modules means it's less likely for people to upgrade. While some users do attempt jQuery version upgrades, many freeze their version and never revisit it. I'd like to get more data on this phenomenon as I think we're optimizing API deprecation policy for a small audience.

Lastly, it's 2015 and the gap between JavaScript developers and jQuery developers has never been bigger. Let's bridge that gap. We should encourage the developer to use modern DOM APIs (that don't suck) and polyfill as neccessary.

Removals

  • Remove animation & effects modules from core.
  • Remove any event binding shorthands (change() dblclick() etc).
  • Remove bind(), delegate(), etc, migrating folks to on(). (#2288)
  • Remove support for custom pseudo-selectors entirely
    • Remove positional selectors. (#293)
    • Remove :visible and :hidden.
    • Remove :not, migrating folks to to not()

Defer to standards

  • Remove jQuery.ajax() and provide a polyfill for window.fetch.
  • Remove jQuery.Deferred and provide a polyfill for window.Promise.
  • Remove jQuery.proxy() and recommend Function.bind()

Performance

  • Add a public-facing read(),write() transaction model for DOM (a la FastDOM) to protect against layout thrashing and spurious invalidations. Use it internally, fixing the thrashing from jQuery.support checks and others.
  • The cleanData() cycle shouldn't have to run on every element removal.
  • Event.fix shouldn't be at the top of profiling results. Do the normalization for event.{which target pageX pageY} lazily as a getter.
@paulirish
Copy link
Author

A few more notes:

jQuery team has some great tickets closed for 3.0 already: https://github.com/jquery/jquery/issues?utf8=%E2%9C%93&q=is%3Aissue+milestone%3A3.0.0+

Today I discovered selector-native.js which IMHO should be the default in 3.0 instead of Sizzle.

I think animations should be removed from the default build of jQuery. Transitions and keyframe anims satisfy many use cases and have great developer ergonomics. For more complex animations, GSAP and Velocity have good authoring stories. At this point, the use cases best served by jQuery.animate not served by CSS or standalone animation libraries are few.

@jdalton
Copy link

jdalton commented Jun 10, 2015

🔊

@jdalton
Copy link

jdalton commented Jun 10, 2015

I can dig it! I could see this also doable though something like a jQ labs.

@SlexAxton
Copy link

New jQuery™ and jQuery Classic®

@stucox
Copy link

stucox commented Jun 23, 2015

Good stuff. May well have already been discussed elsewhere, but what about browser support? Evergreen only?

@docluv
Copy link

docluv commented Sep 22, 2015

Good thoughts, I support you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment