On 4/30/06, Chad Perrin perrin@apotheon.com wrote:
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.
Ok but I'm not a ajax expert so I'd probably reuse stuff from script.aculo.us. Would that be ok? If not I think I'll apply for the External Editor helper app.