Leviathan's Boring Sorta-Blog

I'm not geek enough to dig it out of the code, but I do know that a web browser is not a "window" that displays what's going on on the server you're reaching. The server sends stuff to your computer, and your computer then displays it for you.

(I remember, ten or so years ago, I was working tech support for an ISP that also offered web design services, there was one customer who was outraged when he learned that "his" pictures were being downloaded to people's computers. I had to very gently ask him, "How do you think they can see them, if they don't get downloaded to their computers?")

So with the "More visual icon chooser," for instance, with its animation as you scroll through your icons -- now returned to the order in which they were uploaded as a default, and then re-arranging themselves to put the recently-used icons first -- that has to be running all this visual baloney on our computers, because that's where it's being displayed.

Likewise, the thing they claim is more convenient than reloading your list of comments on a comments page is clearly some script that's sending small bits of data down and telling your browser "Now re-draw this screen to include this, that and the other link on the page in certain specific locations." I've seen plenty of web pages with pleas on them, "Please don't reload this page, it puts too much load on the server." From this, I deduce that their "You don't need to reload the comments page" kludge is sending small instructions to your browser, and telling your browser to do the laborious work of the screen redraw instead of LJ having to re-send the whole page.

The internal logic seems quite persuasive to me.

Ah, okay, I get you.

I'm not high-level enough a geek to know the answer to that, but I have geekier friends to whom I'll pose the question. (My level of geekdom is "Doesn't break into a sweat at the sight of a unix prompt.")

Yes, the client has to send the update request first - the web is still fundamentally request-only, but AJAX allows a web page to use Javascript to quietly make a request to a web server in the background.

A well-designed page using AJAX to keep data current will be better on virtually all counts[1] than a page requiring full manual refreshes:
* It will reduce server load, because the AJAX request can ask for a small, specific piece of information ("the rest of the summary paragraph for this movie") rather than every single bit of HTML on a (probably large and complicated) page
* It will display information faster, because the user won't have to wait for a full page refresh / redraw (and because the page may be periodically updating every N seconds without user action required)

A poorly designed AJAX solution can manage to avoid virtually all benefits, however, and hammer the servers into the ground to boot. ("I know! Let's have all pages check for updates to anything every 0.5 seconds!" <self-DDOS follows>)

I can't speak to the new LJ stuff; I've barely used it at all, and know literally nothing about its design.

[1] = "Working without javascript enabled", however, is often an area where it falls down.

Edited at 2011-12-27 01:36 am (UTC)

DUDE, YOU RAAAAWK!!!!!

Seriously, thanks so much for that really thorough answer! You're a veritable Ghod among Gweepdom!

It makes sense for LJ. I'm not convinced it makes sense for the users to have LJ push their workload onto my system.

I am sure I don't like being forced into this vastly inferior usability by a company that's telling me it's an improvement.

As I've said elsewhere, I can't stop them from serving me a bowl of shit, but I'm not letting them tell me it's candy.