When I started Sampa, I thought that most content would be traditional page GET/POST. But then I went back and checked a family tree that I did for my personal site in 2000 that used AJAX. It made sense to use that technology on Sampa and I went overboard. I created my own AJAX framework (in 2005 there wasn't anything solid that I could use) and used AJAX everywhere on the system.
Later AJAX started to become a pain, because a page after being loaded required 3 or 4 AJAX calls to get the additional content. Bad design for the user. The good part is that Sampa used a combination of Frames that allowed us to cache content on the browser, so the AJAX calls to the server were minimized.
From a development standpoint, AJAX is a pain because it requires you to parse the returning XML and do something with it, usually generate some HTML or data structure. This is where AJAH and JSON come in hand.
If you need a piece of HTML to sitck on the middle of the page, you can generate that HTML on the server and send it on an AJAH call. Once you get that is just a matter of setting the innerHTML on an element.
JSON does the same thing, but for data structures and its data in Javascript. Get a JSON response, eval-it, and you have data and 'classes' ready for use, instead of parsing the XML and putting into a data structure.
So, of the 4 technologies above (in-page, AJAX, AJAH, JSON) which one should you be using on your web-based service? All of them! Each one solves a different problem and they need to be used in combination.
This is my non-comprehensive list of tips on those technologies:
in-page: Use that to minimize server calls when the page is first loaded. The same way you should have few CSS, JS and Images file on a page, you should try not to make any JSON, AJAX or AJAH call once the page is loaded at the first time. Everything should be embedded on the HTML you send to the user.
AJAX: Great to take action on the server ("delete this record") without needing to refresh the page, or when you need pagination ("contacts 1-50 of 1750").
AJAH: When the HTML generated is smaller (or faster) than sending an AJAX response and creating the HTML in Javascript. It's also good because you can keep all the HTML generation routines on the server. Like AJAX, you should only use it when you can't have the content embeded on the page directly on the first page request to the server.
JSON: When the results of an AJAX call will be parsed into a data structure, you probably should consider JSON. Size of the response and parsing time are important considerations. Remember "eval" can be very very very very (add 17 more 'very') expensive at runtime. You don't want your user's browser freezing every time it clicks on something.
I'm a big advocate of using 1 or 2 letters field names. Instead of "Username" just use "n", and that goes both to JSON and AJAX. Put the comment on the code to what it means, but save a lot on response size.
I'm surprised to hear your claim that eval is very^n expensive at runtime. That's not my experience at all - the javascript engines in modern browsers are WICKED FAST. It's usually poorly written code that can freeze a page. Just parsing a JSON payload is going to be very fast (unless you're talking about a mult-megabyte JSON object - which would be extremely rare).
If you have benchmarks to back up your claim - I'd love to see it. Even IE 7 has been improved to make the "string concatenation" problem suck much less (in my torture test, IE 7 can take almost 0.2 ms to concatenate a string - if done naively; where FF is at a blazing 0.016 ms for even long strings):
You got me, I never did any testing to measure eval perf, but every book that I read, including MSDN documentation, tell us to avoid using eval due to perf impact.
My thought is that people might include not only complex data structures in JSON, but also functions and code. XML and HTML are very fast to parse, while Javascript is a whole language and no matter how fast, it will be slower than parsing an XML response. The second problem with JSON is that browsers cannot optimize the code if it's the second time is being called, while a Javascript function on a static JS file could even be "compiled" if the browser wanted to (don't know what the ECMA/JS spec say about this optimizations).
"JSON" per-se is a more restrictive spec than "JavaScript Object Initializers" on which it is based. JSON cannot have functions, or even Date objects embeded in it:
http://json.org/
You can object heirarchy - but not classes other than Array and Object. This is about as much as you can do if you're pure "JSON".
But I think what you're talking about is sending more arbitrary javascript - so, yes, you can "go to town" and need to be careful.
I'm building a JSON-based persistence layer for PageForest, that can handle arbitrary object classes, Date datatypes, and circular references. I think it will be really fast even for moderately large object graphs.
Subscribe to this Site
Comments (3) for "What's best: JSON / AJAX / A...
- 7/9/2008 2:06 AM
December, 2007