My last entry The AJAX response generated a few interesting comments, as well as a thoroughly non-scientific and non-representative poll on the use of the various output formats.
In the rest of this article I'd like to reply to some points that were made: the name "AJAX", rendering speed, error handling, the "evilness" of
innerHTML and some other remarks.
Therefore, the fact that "AJAX" has an X for XML doesn't mean anything. In fact, this whole discussion is meant to see if the X is useful or not.
The comments also contain an interesting discussion (comments 10, 30, 32, and 51-54) between Dave Johnson and Jim Ley, where Jim says that JSON is "orders of magnitude faster" than XML, while Dave maintains that XML is faster than JSON, provided you use XSLT for processing it.
Since I haven't done any benchmark testing I cannot comment on this debate: I simply don't know who's right. What I do know is that I'd very much like to see the test scripts Dave and Jim have used to come to their conclusions. Without actually seeing them it's impossible to find out if one of them is wrong, or that both are right under the right conditions.
Dave, Jim, please publish your test pages, ideally including a quick introduction to the scripts you're using.
Other commenters said that even if there is a clear speed difference, the average visitor isn't going to notice the difference between, say, 100 and 500 milliseconds of rendering time. That's of course true, but it's possible (though unlikely) that future AJAX applications will have to format thousands of XML nodes/JSON objects, and in that case the speed difference may become important.
Another important point is that XML documents or JSON strings may contain errors, and that a script that doesn't allow for such errors could encounter serious problems. Although this is undeniably true, I feel that any XML/JSON error that might exist is the responsibility of the server side programmer. In my case this is an important distinction, since I never create the server side programs that send the XML data to my scripts.
Even if you're creating both the client and the server side programs, though, an error in the XML or JSON means that there is an error in the templates that create the XML and JSON, and this error should simply be solved on the server side. Besides, I don't have the faintest idea how to solve an XML parse error or a JSON syntax error on the client side. One mistyped character may make an entire XML or JSON file unreadable, and that's something to take into account when you create the server side scripts.
HTML snippets is the single output format that has some error tolerance, since browsers have been able to handle broken HTML throughout their history. If error handling is of supreme importance, you're almost forced to exclusively use HTML snippets.
A few other remarks deserve an answer.
What I wonder is: What is the best way for handling separation of concerns when using AJAX? How does a (CSS-) designer know which HTML is generated or how does the (HTML-/JS-) client developer know what CSS to use or what HTML to generate?
A good point. Fortunately the answer is simple. The HTML/CSS developer is responsible for creating the HTML structures, since that's part of his/her job. If the script is being written by someone else, the HTML/CSS developer should deliver templates that specify which HTML is used where.
<span> element for CSS reasons, it's not that hard to add it later on.
if you leave the rendering process client-side, what about mobile? Is there a way they can render XML themselves?
Is it possible to use HTML snippits without using the innerHTML property?
Theoretically, yes, but it kind of defeats the main advantage of HTML snippets. And it's hard to code.
PPK, is the HTML method at all useful for instances where you want data from the server that will change how multiple parts of the current page will be displayed?
Not really. You could split the HTML snippet into two and add the two parts to different parts of the page, but the format works best when you can grab the HTML and put it into some element's
One of the less pleasant surprises was that some people still feel that
innerHTML are "evil". This is pure nonsense.
It's true that
eval() may serve as a crutch for lazy programmers, for instance:
var formField = 'name'; var value = eval('document.forms.' + formField);
In this example you don't need
eval() since there's a better solution to the problem:
var value = document.forms.elements[formField];
However, in the case of JSON output from the server
eval() is very useful, and any technique that doesn't use it would run into the dozens of lines, and would be more error-prone to boot. I don't see any reason to avoid
innerHTML, it's an extremely useful and extremely powerful property, and I use it often. If you don't want to use it, be my guest, but please don't wax ideologically about it. It's there, it works fine in all browsers, it can add complicated DOM structures much more elegantly than pure DOM methods. Besides, it's faster.
If you like this blog, why not donate a little bit of money to help me pay my bills?
Comments are closed.