As usual with AJAX, the hardest part of using the technology is the configuration. But once you're past that it's easy, since we're really not doing anything new. You just call a method in your script client side, and write .NET code server side. So here's how to get started:
Another bonus is speed. AJAX-enabling your UI improves user experience by not forcing them to watch a waving flag or a spinning green circle. However, it's all perception; nothing's actually faster. With JSON, you are not only circumventing all of the overhead involved in SOAP services, but also all the reflective mess involved with web service proxy classes. It is FAST.
Keep in mind, however, that there are some drawbacks. The main one is that this is not a replacement for Update Panels. This isn't as much a drawback as it is a reality check. It seems as though these web services cannot handle hardcore server processing as well as code-behind on a page can. I've seen random errors, including stack overflows, when calling recursive methods and doing other processor-intensive things behind a web method.
Although I feel that Update Panels are a poor-man's AJAX, that's not to say that they should be replaced across the board with JSON. If you want to do async postbacks, for example, wrapped around a GridView that does all kinds of server-side data binding to other parts of your page, then yeah, add four lines of HTML to your page (Update Panel and Content Template tags) and blow your user's minds! All I'm saying is this: don't think that you can completely do away with postbacks and offload all UI logic to the client; use discretion and only do it where it makes sense, and even then, use the appropriate method.
The next issue is the JSON max serialization length. Remember, behind the scenes, all JSON object are serialized and sent across the wire. There is a web.config AJAX setting that holds the maximum length of each string that contains the object. I've found if you're using beefy objects with dozens of properties and child collections, you'll exceed this length fairly quickly. I'm not sure if I feel this is a hack, but you can set your own value like so (or just blow it away, like I did):
The third issue is that your app and your JSON web services will not be able to communicate via standard session. Here's probably the only downfall to using .NET web services; they are (even more so than a page) stateless, and are designed only to "exist" during the scope of the current call. This is a bummer regardless, since the most common thing I've been doing with JSON is manipulating session objects from the client.
We can get around this by using the application object, since both the app and the web service are "in scope" here and can exchange information this way. Of course, keep in mind that all users' sessions share this same application object, so you'll need to key things off of guids and/or make sure to release these variables as soon as possible. I would recommend looking into the Cache object and setting expirations on your in-memory variables. Have fun!