"Prior to 1.9, an ajax call that expected a return data type of JSON or JSONP would consider a return value of an empty string to be a success case, but return a null to the success handler or promise. As of 1.9, an empty string returned for JSON data is considered to be malformed JSON (because it is); this will now throw an error."

That one is gonna cause some headaches, I've abused this behavior for years, as recently as yesterday.

So your server returns an HTTP 200 with an empty response, and you process the `null` in your success handler? Do you really want a `null` returned? Is this a server you control, or is it some third-party service? Just curious about the use case and how widespread it might be.

I was probably in control of all of them at some level but I either didn't think about it or didn't care enough. Sometimes I suck. Today I can start sucking a little less.

This confused me for a minute but I think I get it now -- it's referring to a response with zero length, not a response of two quote characters right?

Yes, but two quote characters on their own isn't valid JSON either so that'll error too, though I assume it already did.

This stuff never works happily. I don't really trust jQuery to handle JSON/JSONP properly.

It is easy enough to drop back down to calling XMLHttpRequest by hand. Sample code is here, and changes to jQuery won't break it: http://stackoverflow.com/questions/5395118/jquery-1-5-json-e...

Why did you not just specify the dataType in your ajax call?

http://api.jquery.com/jQuery.ajax/#data-types

Because was working with jQuery 1.5, and data-types showed up in 1.5.1

It sounds like you knew it was bad practice, and yet you did it anyways...?

Since so very very many things changed in backwards incompatible ways, why didn't they just go with calling it 2.0 rather than 1.9? I mean, the changes are huge and most versioning schemes increase the major version number on backwards incompatibility.

> so very very many things changed in backwards incompatible ways

jQuery has always made feature changes/additions on .x releases. We're saving the 2.0 moniker for removing oldIE because that is a much more significant change than these API cleanups.

At this point the jQuery installed base is so big that any change, however innocuous, is a breaking change for someone. Even fixing bugs, conforming to W3C standards, or making API return values consistent can cause trouble because someone depends on the old way of doing things. We try to be respectful of people's existing work but also want to make forward progress.

Like the intro at the top of the upgrade guide page says, this list seems a lot more scary than it really is. We're just trying to call out every change that we think may cause issues, so people can assess and address them in advance.

The jQuery Migrate plugin is designed to make it easier to find any compatibility problems, and can be included with jQuery versions as old as 1.6. Add the plugin to your current code, run it, and view the console to see if there are warnings.

because 2.0 will be 1.9 with dropped <ie9 support.

jQuery 2.0 (early 2013, not long after 1.9): This version will support the same APIs as jQuery 1.9 does, but removes support for IE 6/7/8 oddities such as borked event model, IE7 “attroperties”, HTML5 shims, etc.

Our goal is for 1.9 and 2.0 to be interchangeable as far as the API set they support. When 2.0 comes out, your decision on which version to choose should be as simple as this: If you need IE 6/7/8 support, choose 1.9; otherwise you can use either 1.9 or 2.0.

http://blog.jquery.com/2012/06/28/jquery-core-version-1-9-an...

There is nothing I would love to see more than for jQuery 2.0 to be modularized so people can pick and choose the modules they want/need.

It would also be nice for them to adopt semantic versioning with 2.0. i.e. move to 2.0.0

If you're not targeting old browsers there's no reason to use JQuery. Plain JavaScript offers you the same features.

Sure, if you want to build it all yourself in JavaScript, but that's the point of a library isn't it?

And as far as "not targeting old browsers" there are plenty of places where modern browsers differ and jQuery normalizes their behavior. Chrome doesn't support mouseenter, Firefox doesn't support focusin, Safari's String.trim() doesn't trim zero-width spaces, their CSS uses prefixed properties, etc.

Also, talking about jQuery in isolation is like talking about C++ without its runtime library. One of the strengths of jQuery is its ecosystem such as plugins.

I'm certainly not a jQuery fanboy, but jQuery's DOM-manipulation functions are certainly more concise and abstract away some of the funky internals (NodeLists, etc.).

That said, I've always found jQuery's function naming to be particularly ambiguous. There's no indication that "find" searches an element's descendants for a matching CSS selector based on its name. On the other hand, vanilla JS's element.getElementsByTagName is so much more verbose. Back in the day I found PrototypeJS [0] to be much better organized and offer the same feature set, but it's largely fallen out of use since Rails dropped it. mootools is nice but the docs, while comprehensive, are arranged in no logical order. Every time I try to pick up mootools I end up running around the docs in circles.

tl;dr jQuery is overblown but I think there's room for improvement over vanilla JS.

Plus there's always the (literally) hundreds of plugins for every possible application of jQuery.

[0] http://prototypejs.org

I actually like long verbose names. Unfortunately, plain JS names are often long, verbose and unclear, so that's not a win. (e.g. document.querySelectorAll - that should have made some reference to css; and "all" should be implicit as it is the norm in CSS).

I'd love to see a JS library that doesn't try to add a lot of functionality, but only decruftify the browser API.

The right aim would be to end up with a complete API that might actually replace the normal JS api (DOM+otherwise) in actual browsers.

What do you think of Zepto?

It's not necessarily a bad thing that DOM-manipulation functions are a bit annoying to type. Verbose names means that you are more likely to do:

    var elem = document.getElementsByClassName('foo')[0];
    elem.fooBar();
    elem.foo = 'bar';

rather than

    $('.foo').fooBar();
    $('.foo').foo = 'bar';

even if you don't know anything about writing optimized JavaScript code.

But sadly, beginners these days learn "jQuery" before they learn JavaScript.

This is a little bit silly. I agree if you're not beholden to support old versions of IE then there may be some overhead in full jQuery, so it's worth pointing out there some lightweight alternatives that have a similar API, e.g.

* http://zeptojs.com/

* https://github.com/mythz/jquip

Zepto doesn’t support any version of IE.

If by "features" you mean the ability to achieve the same result... Well, obviously.

However, jQuery's main feature is having a nice interface that is much more consistent and usable than many of the native APIs. The "fluent interface" or "method chaining" style is especially nice.

Sometimes the API is more convenient. Also, it's so widely used that it's often easier to find samples and documentation on how to do something with jquery than it is without using jquery, even where the plain javascript solution isn't really that much more complex.

A modern, more minimalist alternative would be a nice thing, but at the moment I think jQuery is probably still a good bet for simple cases.

If you think you can write a better wrapper than jQuery, you are most likely wrong.

I'm still finding that JQuery makes for much more concise and readable code, especially for chaining operations on groups of elements or xhr.

Technically, even if you are targeting old browsers, you don't need jQuery; it's written in Javascript, after all. There's nothing they do that you can't do with vanilla JS.

You can also mow your lawn with a pair of scissors, which is about like doing anything non-trivial in the browser without jQuery.

Sort of agree but instead of "old browsers" I'd say "multiple browsers" which is ...actually that's a big difference. For me, the moment I have to look at anything more than one browser on one platform, then jQuery becomes a valid choice. Which is pretty much all the time lately.

Even if DOM normalization isn't needed, the method chaining and implicit iteration jQuery/other frameworks provide sure makes working with the DOM a lot nicer.

I've recently been experimenting with some HTML5 mobile app programming, and since that saves you from the problem of IE8 I've been doing it without jQuery. So far I've found I don't miss it at all, to my own surprise. I wrote a few short convenience functions for XHR etc but it's nothing at all like mowing a lawn with scissors.

This is true for a lot of apps and functionality, but you’re ignoring the large library of jQuery plugins out there. Just as a basic example I needed a slider on a recent app I built. Sure, there’s <input type="range"> but if you want it to work in IE or Firefox you’re better off dropping in a jQuery UI Slider.

The beauty is that <input type="range"> works in any browser. Some just render it as text input.

A fair point for a standard form, but try telling Firefox and IE users that they have to type in their audio volume manually on the jukebox I built.

Are you aware of a good jQuery -> Javascript guide? I learnt jQuery years ago, as I was advised to avoid the mess which is browser configurations, in particular there was problems attaching triggers. Given I would count IE9 as a "new" browser...

Maybe if you're only building a simple app, but I suspect most people at some point need other components like date pickers, format masks, form validation, table filtering/sorting etc. of which many require jQuery anyway.