On Sun, Apr 30, 2006 at 01:06:02PM +0100, Timwi wrote:
Chad Perrin wrote:
As Brion Vibber and Christopher Budnick pointed out, each in his own
way, I think the concern here is that you're adding needed functionality
in a manner that makes good sense -- and that you're not throwing AJAX
at it just because AJAX is buzzword-compliant. I, for one, am perfectly
happy with unadorned static (X)HTML when it solves the problem quickly,
easily, and fully. It runs faster and imposes less server load, too.
Where AJAX provides actual measurable benefits, though, it's certainly
an option to explore without prejudice.
Although I largely agree with you (especially the "buzzword-compliant"
bit, heh!), I must state that AJAX often does run faster and save server
load. Imagine there was an AJAX-y way of adding a language link to an
existing article. This is just an example. In the traditional way, you
have to (1) load up the edit page, (2) submit it, and (3) re-render the
article page. Even a separate mechanism to add language tags would have
those three steps. With AJAX, however, you would have JavaScript create
the UI to enter the tag *and* update the page in-place, client-side.
Only the submission step would be an actual server hit.
True -- there are ways to leverage AJAX and similar technologies to
reduce server load. It requires care and good planning to implement
them, though, and it's of critical importance in a project like
MediaWiki to ensure that it degrades gracefully so that everything still
works even if the client doesn't allow Javascript. Like I said, if it
adds positive value, it's a good idea. You just have to know what
you're doing and why you're doing it.
--
Chad Perrin [ CCD CopyWrite |
http://ccd.apotheon.org ]
"The first rule of magic is simple. Don't waste your time waving your
hands and hopping when a rock or a club will do." - McCloctnick the Lucid