success and error are being deprecated in jQuery 1.8. You should start using .done() and .fail(). See the documentation.
– FibreChipsJul 7 '17 at 20:45

2

What are being deprecated are the callback-manipulation functions (e.g. .error, .success) not the parameters to the ajax method. See the comments in this thread. stackoverflow.com/a/10931891/4490454
– EGSJan 2 at 9:21

You can store your promise, you can pass it around, you can use it as an argument in function calls and you can return it from functions, but when you finally want to use your data that is returned by the AJAX call, you have to do it like this:

promise.success(function (data) {
alert(data);
});

(See updates below for simplified syntax.)

If your data is available at this point then this function will be invoked immediately. If it isn't then it will be invoked as soon as the data is available.

The whole point of doing all of this is that your data is not available immediately after the call to $.ajax because it is asynchronous. Promises is a nice abstraction for functions to say: I can't return you the data because I don't have it yet and I don't want to block and make you wait so here's a promise instead and you'll be able to use it later, or to just give it to someone else and be done with it.

UPDATE (2015)

However jQuery Promises in the upcoming version 3.x will be compatible with the Promises/A+ specification (thanks to Benjamin Gruenbaum for pointing it out). Currently (as of May, 2015) the stable versions of jQuery are 1.x and 2.x.

What I explained above (in March, 2011) is a way to use jQuery Deferred Objects to do something asynchronously that in synchronous code would be achieved by returning a value.

But a synchronous function call can do two things - it can either return a value (if it can) or throw an exception (if it can't return a value). Promises/A+ addresses both of those use cases in a way that is pretty much as powerful as exception handling in synchronous code. The jQuery version handles the equivalent of returning a value just fine but the equivalent of complex exception handling is somewhat problematic.

In particular, the whole point of exception handling in synchronous code is not just giving up with a nice message, but trying to fix the problem and continue the execution, or possibly rethrowing the same or a different exception for some other parts of the program to handle. In synchronous code you have a call stack. In asynchronous call you don't and advanced exception handling inside of your promises as required by the Promises/A+ specification can really help you write code that will handle errors and exceptions in a meaningful way even for complex use cases.

For differences between jQuery and other implementations, and how to convert jQuery promises to Promises/A+ compliant, see Coming from jQuery by Kris Kowal et al. on the Q library wiki and Promises arrive in JavaScript by Jake Archibald on HTML5 Rocks.

Of course in this example you could use just promise.then(alert) because you're just calling alert with the same arguments as your callback, but the arrow syntax is more general and lets you write things like:

promise.then(data => alert("x is " + data.x));

Not every browser supports this syntax yet, but there are certain cases when you're sure what browser your code will run on - e.g. when writing a Chrome extension, a Firefox Add-on, or a desktop application using Electron, NW.js or AppJS (see this answer for details).

@AlexG In place of promise.success(function (data) { alert(data); }); in my example you can use promise.success(function (data) { alert(data.users[0].id); alert(data.prices[x]); }); or something like that. If you get the data in the success callback (or then callback, if you're using the Promises/A+ API) then you get the data with all of its properties.
– rspJun 27 '16 at 6:27

You solution is perfectly valid. I just want to emphasize the importance of not returning the value right away inside the success callback, but outside of the .ajax function call. Otherwise you will get undefined.
– anar khalilovJul 11 '13 at 11:56

is there any way to use this function with async:true ?
– VivekMar 14 '15 at 8:45

14

async: false is now deprecated in whatwg spec for most use cases. Google Chrome already warns about this in its console when a call occurs with async: false. w3c spec does not seem to have deprecated it yet.
– FrédéricApr 30 '15 at 19:45

So the main idea here is that, by adding async: false, then you make everything waits until the data is retrieved. Then you assign it to a static variable of the class, and everything magically works :)