http://qs321.pair.com?node_id=516045


in reply to Re: AJAX-based Perlmonks.com?
in thread AJAX-based Perlmonks.com?

I'm not sure I agree with any of your cons except the "More code to maintain", actually.

More code to maintain
Yes, certainly, though the most obvious applications would be pretty easy to keep decoupled from the main body of the Everything code (since they'd be Javascript—I doubt very much would need to be changed on the server side).
Higher load on the server
I simply don't see it. Certainly if you made every page reload the chatterbox at a fixed interval, it would probably increase the load—but why would you do that? There are plenty of ways to use XMLHTTPRequest without using setInterval, and most of them decrease the load, since actions that change one 15-character span (or, in the case of the chatterbox, one 10-line table cell) wouldn't force a reload of the entire page.
Can Perlmonks really benefit?
A valid question, certainly. I think it could, though whether the benefits outweigh the maintenance and security auditing costs is a question worth asking. Calling it a "con" in an initial evaluation seems to me to be prejudging the situation, though.
Does this limit the browsers capable of viewing Perlmonks?
I don't think it would have to, if implemented right. Let me make that more explicit, actually: under no circumstances would I consider it a good idea to add AJAX capability as a requirement for viewing any part of the site. Simply a terrible idea, and you're absolutely right to raise the point. But the kinds of functionality that other monks have mentioned as possibilities elsewhere in this thread already exist in standard-HTML form (no pun intended): unless very broken code or very broken browsers got involved, that functionality would be silently replaced with the JS-based implementation when (and only when) the browser being used had the necessary functions enabled.

All of that leaves aside the question of whether it should be done: if the benefits (which so far are largely minor convenience upgrades and a possible trivial server-load reduction) don't balance or outweigh the costs in code complexity and maintenance hassle, then the idea is a non-starter. That said, there seem to be a number of monks with some interest in the topic—if a few of those are both pmdevils and familiar with the problem domain, we could probably at least investigate the idea, and try to get a solid answer to that question.



If God had meant us to fly, he would *never* have given us the railroads.
    --Michael Flanders