The AHAH! Moment
By my faith! For more than forty years I have been speaking prose without knowing anything about it, and I am much obliged to you for having taught me that.
Molière
We have been doing AHAH for a few months and now I know! The thing definitely makes sense, especially as the app gets more complicated and every bit of code shaved off the client side saves us a bit of our lives.
The performance still requires investigation. For now I assume that transparent gzip compression can make HTML snippets just about as small as compressed JSON responses.
Burton 11:56 pm on 2010-03-09 Permalink |
codeibstro.com, how do you do it?
Sasha Ovsankin 10:53 am on 2010-03-11 Permalink |
Well the main advantage here to avoid duplication (DRY). Imagine a web page which is both rendered by the server (for SEO) as well as dynamically, via AJAX. Something like Twitter. If you do the AJAX rendering the usual way — get the data via JSON and then “dress it up” into HTML, you end up with 2 totally different pieces of rendering code which should be synchronized, a headache.
Using AHAH, you render both of them using the same code on the server side, transfer the rendered piece via AJAX and then the client-side JavaScript would only stick it at a proper place in DOM. Makes sense?
However since the time of this post things changed a bit: the HTML has become more “semantic” so the rendering magic shifted to CSS which can be safely reused by both sides. Also, we made some sort of browser-side templates: we put template in HTML with “display:none”, then for rendering we copy it, populate and make it visible. Still a bit of duplication but not really a big problem. So AHAH is not used that much any more.
Anton 6:40 pm on 2010-06-28 Permalink |
wikipedia link got deleted, that one worked fine for me
http://microformats.org/wiki/rest/ahah
codebistro 11:29 pm on 2010-06-28 Permalink |
Thanks, fixed the enry