What is the difference between jquery 2.x and jquery 3.x

What are the major difference between jquery 2.x and jquery 3.x.


JQuery 3.x support for the widest variety of browsers including IE8, Opera 12, Safari 5 where JQuery 2.x supports from IE6 and IE+ etc and JQuery 3.x released on October 2014. It's slimmer, faster version of jQuery (with backwards compatibility in mind). JQuery removed all IE workarounds and taken advantage of some of the more modern web APIs where it made sense.

Major changes in JQuery 3.x are

jQuery.Deferred objects have been updated for compatibility with Promises/A+ and ES2015 Promises, verified with the Promises/A+ Compliance Test Suite. This meant we needed some major changes to the .then() method. Legacy behavior can be restored by replacing any use of .then() with the now-deprecated .pipe() method (which has an identical signature).

An exception thrown in a .then() callback now becomes a rejection value. Previously, exceptions bubbled all the way up, aborting callback execution. Any deferreds relying on the resolution of the deferred that threw an exception would never have resolved.
Example: uncaught exceptions vs. rejection values

  1. var deferred = jQuery.Deferred();
  2. deferred.then(function() {
  3. console.log("first callback");
  4. throw new Error("error in callback");
  5. })
  6. .then(function() {
  7. console.log("second callback");
  8. }, function(err) {
  9. console.log("rejection callback", err instanceof Error);
  10. });
  11. deferred.resolve();

Previously, "first callback" was logged and the error was thrown. All execution was stopped. Neither "second callback" nor "rejection callback" would have been logged. The new, standards-compliant behavior is that youÂ’ll now see "rejection callback" and true logged. err is the rejection value from the first callback.
The resolution state of a Deferred created by .then() is now controlled by its callbacks—exceptions become rejection values and non-thenable returns become fulfillment values. Previously, returns from rejection handlers became rejection values.
Example: returns from rejection callbacks

  1. var deferred = jQuery.Deferred();
  2. deferred.then(null, function(value) {
  3. console.log("rejection callback 1", value);
  4. return "value2";
  5. })
  6. .then(function(value) {
  7. console.log("success callback 2", value);
  8. throw new Error("exception value");
  9. }, function(value) {
  10. console.log("rejection callback 2", value);
  11. })
  12. .then(null, function(value) {
  13. console.log("rejection callback 3", value);
  14. });
  15. deferred.reject("value1");

Previously, this would log "rejection callback 1 value1", "rejection callback 2 value2", and "rejection callback 3 undefined".

The new, standards-compliant behavior is that this will log "rejection callback 1 value1", "success callback 2 value2", and "rejection callback 3 [object Error]".
Callbacks are always invoked asynchronously, even if a Deferred has already been resolved. Previously, these callbacks were executed synchronously upon binding.
Example: async vs sync

  1. var deferred = jQuery.Deferred();
  2. deferred.resolve();
  3. deferred.then(function() {
  4. console.log("success callback");
  5. });
  6. console.log("after binding");

Previously, this would log "success callback" then "after binding". Now, it will log "after binding" and then "success callback".

Important: while caught exceptions had advantages for in-browser debugging, it is far more declarative (i.e. explicit) to handle them with rejection callbacks. Keep in mind that this places the responsibility on you to always add at least one rejection callback when working with promises. Otherwise, some errors might go unnoticed.

Answer is