views:

175

answers:

2

Not strictly a programming topic but input is appreciated. I've been developing a lot lately with YouTube APIs and I started with PHP code, using SimpleXML, then actually skipped AJAX and went straight to using native JSON and doing everything client-side.

While it "feels" faster, I wonder if it's ready for primetime yet. Even with the multitude of frameworks, CSS limitations and variations in event propagation handling between browsers still make me wary of over-using Jacascript in my applications.

One disadvantage is actually that sometimes, JavaScript moves TOO fast, and without delays it's possible for it to feel jumpy.

These are just my thoughts. I've actually not yet really delved into XHR as JSON just made so much sense, but I'd be interested in knowing what seasoned programmers prefer and why.

EDIT:

To be clear, I am talking about whether it's safe enough to use/rely on callbacks loaded after making calls directly to a JSON API (JSON-P) or whether you really should rely on an insulatory server-side layer(XHR) between you and a third-party API, if nothing else - for caching purposes?

+6  A: 

XHR:

  • Gives you access to HTTP headers
  • Gives access to error codes
  • Lets you define action to take if the service errors
  • Doesn't require a global callback function

JSON-P is a fire and pray approach.

You can't compare XHR and JSON though. XHR is a way of making HTTP requests. JSON is a data format. You can use them together. JSON-P involves generating <script> elements to fetch JSON instead of using XHR.

David Dorward
So I guess , my main question is really whether using a pure JSON-P based API and processing with jQuery is robust enough for heavy traffic, or it's necessary to have that added insulation of data-processing on the server side, not to mention the other benefits.
FilmJ
+2  A: 

I think it's a good idea to define what each technology you mentioned is, because you seem to be comparing XHR and JSON which are on two different levels and uncomparable.

XHR (XMLHttpRequest)

Description of the XMLHttpRequest object at MDC
This is an object used in JavaScript to perform HTTP requests to the server. While the name of implies that it requests XML, it can receive any type of data (for example, JSON.)

JSON (JavaScript Object Notation)

Definition of JSON at json.org
This is a data format. It can be used to represent a structure of data much like XML, but in a more concise way. It's also directly compatible with JavaScript and is easy to convert to a JavaScript object.

JSONP (JSON with padding)

Definition of JSONP by Bob Ippolito
An extension to JSON that injects a <script> tag that executes a piece of JavaScript directly from the server it is requested from. The additional callback parameter is the global function to call on your page to delegate the data. Useful for requesting data from an external service in JavaScript.

AJAX (Asynchronous JavaScript and XML)

I can't really give an accurate description of this one because it can mean so many things. Have a look at the Wikipedia entry instead.


I'd say it's definitely ready for prime time. If it feels "too fast" it's easy enough to make the transition from one state to another smoother/slower.

With today's frameworks you can get JavaScript to behave the same in 99% of visitors' browsers. It's even pretty safe to assume that everyone has JavaScript enabled (consider for example YouTube, which does not play video unless you have JavaScript enabled.)

It's still a good idea to have a simple static fallback version of your site, though, to cater for that last 1%.

Most of my recent private web projects have been implemented mostly in JavaScript, using XHR requests to the server to fetch data. One such example is my collection of JavaScript libraries, which has the concept of separate pages, but navigates entirely using the hash part of the address. It does have this jumpy behavior you spoke of (but it can be worked on.)

Blixt