The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Ajax: Returning formatted data vs. raw data

Good Morning,

Just a quick question. I'm designing my first "ajax" enabled web app.

Generally speaking, should i be returning HTML from my ajax calls, having done the formatting server side, or should I return XML and do the formatting client side?

I'm sure there is no exact answer, so it comes down to what do you wish you'd done after you're finished with the app.

Does anyone have any advice that might apply here?

Shane Harter Send private email
Monday, October 30, 2006
To be honest, I think the name AJAX is wrongly labeled, because you can return either HTML or XML or an image if you want.

Depending on your application, if you are displaying some dynamic "visual" display, then yes, you can use AJAX for HTML, but if you are strictly displaying data, I would move towards returning just XML.

Another thing to think about is that if you are going to pull and display HTML across the wire, make sure it isn't huge amounts of code. Keep it small across the network.

Hope this helps.

Jonathan Danylko Send private email
Monday, October 30, 2006
I would say that if the user interface is likely to change radically in the future then consider returning XML. Otherwise, I think it's fine to return HTML. You'll want to make sure that your server-side HTML generation is nicely decoupled though, so it's easy to swap out with an alternative implementation if you need to.
John Topley Send private email
Monday, October 30, 2006
if you're returning html, and adding it to the page with innerHTML then you might run into problems if you need to manipulate the DOM of the inserted bits.

if your data isn't in XML on the server, then there's going to be effort put into making the XML there, and then parsing it on the client, this is a bit messy when in all likelihood you don't need the verbosity of XML.

JSON is lighter than XML, and is nice to access from your javascript (just use eval() and you've got yourself an object or an array), but will depend on your server language and the size of your data as to how easy the encoding is.

Creating js code on the server, returning and eval'ing is another option that can be used. It will result in DOM-editable content, but will be slower on the client than using innerHTML.
G Jones
Monday, October 30, 2006
FWIW, I dislike the term 'ajax' as much as the next guy, but it is a widely-used term. Obviously, returning HTML would not be ajax per se, but we all know what it means. Ajah just isn't as... clean =)

Thanks for the input... the reason I liked returning HTML is it would make it easier to create a noscript version that returns static HTML. Two seperate views (one for script, one noscript) could derive from a base class that provides a lot of the functionality needed.

However, if people with some ajax behind them still have nightmares about returning HTML, it would be worth the extra time to learn from their mistakes.
Shane Harter Send private email
Monday, October 30, 2006
Do you have server side code that formats the data into HTML when the page is first loaded?  If so, you have all the code needed to take care of the formatting, so just grab the new HTML from the server.  Otherwise, you're writing client side code that mimicks your server side code, and we all know that duplication is not a good thing.

Of course, if *all* formatting occurs on the client side, then the same argument applies -- just watch out for duplication.
Derek I
Monday, October 30, 2006
I prefer to return the raw data. As someone noted above, manipulating content you've stuffed into the page with innerHTML via the DOM can have hidden pitfalls. Also, it helps keeping your data and your display separated - continue generating all your formatting server side, and provide places within that to insert the new data. If you end up needing to manipulate the data client side, you're ready for that, too.

And a big +1 to JSON. It's lighter than XML and incurs less processing time client side (at least until browsers all have decent XML handling built in.)
Monday, October 30, 2006
Also, the rule of thumb is never to put HTML into your source code. It just gets messy when you need to recompile and relaunch your servers when simply changing a String in your Action.  Its much cleaner and easier to simply use XML, and then render appropriately.
Monday, October 30, 2006
Return JSON
hobit Send private email
Monday, October 30, 2006
I return Javascript code and execute it with eval().
This is more than just JSON. The scripts I return modify the DOM.

You should see the crazy scripts I have that generate dynamic Javascript. Some of it is truly nuts.

This technique probably isn't very maintainable, but it was fun to try on some side projects.
RandomNerd Send private email
Tuesday, October 31, 2006
The day somebody makes a template toolkit compatible javascript library, I'll be in heaven.  Then I can return a template + all the data and let the client render the mess.

While I haven't really "standardized" on an approach yet, I always return JSON spat out of Perl using JSON::Syck.  I never put it in the response header, always in the body.  Any HTML I wish to inject will be stored somewhere in the hash, never in the raw.

Right now, the client side javascript is a pile of functions with very little structure.  Every new feature sends back a response with a slightly different data structure and calls slightly different client code.  This is bad news for many obvious reasons.  I'm still learning all the javascript idioms so odds are good I'll find a better way.

Is it me, or is javascript a slick language?  I'd sure like to give it a whirl server-side some day.
Cory R. King
Wednesday, November 01, 2006
Cory King: I haven't used it, but I stumbled across this a while ago:

When I was digging for that URL, I also stumbled across Jemplate (uses Perl's Template Toolkit):

And, yep, Javascript is a slick language. The more I use it, the fonder I get. I've been struggling with the "how to structure things" aspect as well. The flexibility encourages you to shoot your foot off,

I found Douglas Crawford's site has some helpful bits on classical inheritance in Javascript that I found very useful in figuring out a way to structure things. see
Wednesday, November 01, 2006
One problem I had with transforming to HTML on the client was performance. Essentially, we were returning a large text result that needed to be formatted as HTML and the transformation on the client killed performance. What took 2 minutes on the client took less than 1 sec on the server to do. This may not be a typical situation but it is something that needs to be taken into account and tested
... Send private email
Thursday, November 02, 2006
+1 for returning javascript.  _very_ useful technique.
Sunday, November 05, 2006
JSON has it's place. It *can* be very useful. What you really want is a framework that uses the exact same code to render the html on the server side on an ajax call that renders the html on the first request.

Rails handles this in it's fashion with partials. Other frameworks have a similar fixture. This is a good way to do things. If you find that you're sending json back to the client just to build a bunch of html - you're probably doing the wrong thing.
Andrew Murray
Monday, November 06, 2006
There are libraries avialable to convert server objects to JSON objects and parse JSON objects on the client side.

These libraries should simplify the work:
Narasimha Send private email
Tuesday, November 07, 2006
If your question is so simple. I would suggest you to return XML.
Thursday, November 16, 2006

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz