I think you’re being too dismissive. It’s a fair question to ask, and the answer is not obvious and probably not the same for everyone on every project.

Frameworks like jQuery became popular for good reasons, including easy DOM manipulation, AJAX, and event management, and in particular for offering these tools within a single, widely tested, cross-browser API.

However, using native APIs instead is easier than it was a few years ago, unless you really still need to support very old browsers, and we’ve learned to use polyfill/shim strategies to fill in most gaps when we need to. We’ve also learned a lot about how to write better plain JS in that time, for which the folks developing popular JS libraries like jQuery deserve a lot of the credit. In effect, the major reasons for using jQuery have all become less important. Almost no-one really needs to write code like your “bad” example today, and even if they do, it’s the sort of thing you only do once and wrap up in your own library so you can reuse exactly the ideas you need and optimise it using the same tools as any other JS you write.

On the other hand, jQuery has a number of potential disadvantages. There are run-time performance questions that can only be answered by profiling, but they are fair to ask. In any case, fetching jQuery means more download bandwidth and more HTTP round-trips, which is definitely a real problem for performance, particularly with mobile networks. The obvious counter is to say everyone should load jQuery from a CDN like Google’s, but now you have a third-party dependency that is a potential risk to reliability, security and privacy, and in any case not all web sites/apps run on the public Internet, so that choice won’t be for everyone.

The thing that is increasingly bugging me is the universal dependency problem. Most of the little JS libraries I’ve looked at recently, things that do one simple job well, seem to depend on jQuery even if it offers no real advantage at all. jQuery has become the God Object of client-side JS development, and having one of those is rarely a good sign.

So while I certainly wouldn’t go as far as to say that jQuery is no longer useful, I don’t think we should take it for granted that using jQuery should somehow be the default choice.

If you're going to do that, it'd be good to open source it so other people can take advantage of it. Maybe abstract out some other cross browser stuff as well. Also, it would cool if it made the DOM api nicer to work with.

  $(document).ready(function() {
    $.ajax({
      url: "test.html",
      context: document.body
    }).done(function() {
      $(this).addClass("done");
    })
  });

  var oReq = new XMLHttpRequest();
  oReq.onreadystatechange = function() {if (this.readyState === 4) {
     window.document.body.className += " done";
  }};
  oReq.open("GET", "test.html", true);
  oReq.send();

without jQuery: http://browsershots.org/http://evening-harbor-8654.herokuapp...

with jQuery: http://browsershots.org/http://evening-harbor-8654.herokuapp...

And good luck using your new ajax function :)

It will take time though as many people aren't even familiar with the native APIs.

    $.get('test.html', function(r) {
        window.document.body.className += " done";
    });

    url: "test.html",

    var age = document.getElementById('age').value;
    var wpm = document.getElementById('wpm').value;
    var sex = document.getElementById('sex').value;
    var queryString = "?age=" + age + "&wpm=" + wpm + "&sex=" + sex;
    ajaxRequest.open("GET", "ajax-example.php" + queryString, true);

The first piece of code is GET'ing an arbitrary, presumably static webpage and injecting the word "done" into the body, while the second piece of code appears to be pulling data from a form, sending it to another webpage, and then displaying its response into a specific div.

As for the try/catch statements, I think the OP's point is that we don't need to worry about XMLHttpRequest failing anymore. The decision to support IE6 is up to you, but I think most web developers are willing to draw the line these days.

    $.ajax({
      url: 'ajax-example.php',
      data: $('#myForm').serialize(),
      success: function(data) {
          $('#ajaxDiv').html(data);
      }
    });

An interesting side note here is that the Rails analogy remains somewhat apt, in that much of the execution time in web applications is spent in the data store.

1. IE7 and above support the native XMLHttpRequest object; the code example is code is probably much longer than it needs to be (it can be trivially reduced by %50).

2. There is nothing to stop you from creating your own API. I had to do this because jQuery didn't interact well with a custom ASP.NET framework[1]

Here is how I do Ajax stuff using a small library that I wrote[2]:

    var xhr = new $xhr(SOME_URL, function (data) { /* do stuff */ })
    
    xhr.post(document.getElementById('form_id'));

[2] https://gist.github.com/noblethrasher/5383649