Reasons not to use native XMLHttpRequest - why is

问题:

I'm writing an app that:

1. absolutely relies on sending data to server via Javascript
2. must not have JQuery library included in code.

(I don't know if my code will be included in web pages that already have jquery lib, I do not know if there's gonna be right version, I do not know if there is gonna be JQuery conflict and so... )

I must relay on native JS functionality XMLHttpRequest(ActiveX for older IE's) methods, which is simple but than I saw warning:

"Without jQuery, AJAX coding can be a bit tricky!

Writing regular AJAX code can be a bit tricky, because different browsers have different syntax for AJAX implementation. This means that you will have to write extra code to test for different browsers. However, the jQuery team has taken care of this for us, so that we can write AJAX functionality with only one single line of code."

What is 'tricky' about that? What am I possible doing wrong? As far as I know

var xmlhttp;
if (window.XMLHttpRequest)
  {// code for IE7+, Firefox, Chrome, Opera, Safari
  xmlhttp = new XMLHttpRequest();
  }
else
  {// code for IE6, IE5
  xmlhttp = new ActiveXObject("Microsoft.XMLHTTP");
  }

is only extra code for different browsers and my xmlhttp var should be from now on ready to do the job in IE5, IE6, IE7+, Firefox, Chrome, Opera, Safari.

Is above cross-browser code adjustment all I should do or is there anything else I should take care about when using native XMLHttpRequest object?

回答1:

That's the only thing necessary for cross-browser support unless you need to support really old IEs (which apparently use a different ActiveXObject).

However, using e.g. jQuery provides a bunch of additional advantages:

• Single function call, no unnecessary variables cluttering your scope.
• Automated serialization of objects into GET/POST arguments. Why do that manually (you need to encode the values properly!) when you can simply pass an object?
• Automated parsing of the response, e.g. in case of JSON you get an object and not just a string you need to parse manually.
• Nice callbacks for common events (success/failure/finished)
• Pluggable architecture to support e.g. XDomainRequest for CORS in IE.

Since you mention that you cannot use jQuery because your app will be embedded in another site that might conflict with it: You can avoid this by including jQuery and then using $.noConflict(true) to restore both the old $ and jQuery variables. To use it in your code you then write it like this:

(function($) {

})(jQuery.noConflict(true));

回答2:

The XMLHttpRequest object is defined as a W3C standard here:

http://www.w3.org/TR/XMLHttpRequest2/

and thus the API itself should be consistent across browsers.

The only change should be, as you mentioned, how you obtain the XMLHttpRequest object. See here:

http://www.quirksmode.org/js/xmlhttp.html

for a cross-browser, non-jQuery way of doing it (obtaining the object is done in his XMLHttpFactories array.