Log in

No account? Create an account
June 2018   01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30

What you need to realize about LJ's "Improvements"

Posted on 2011.12.24 at 08:35
It took me a while to figure this out, but the coin finally dropped last night.

Never mind the crap you're hearing about "Making LJ more like Facebook," "removing clutter" and "improved tools for..."

What LJ is really doing with their site update is this:

They're moving processor load off of their servers and onto our computers. All these kludges with their dancing baloney and visual stuff you see -- ever so slowly -- are scripts that LJ feeds to your computer, so that you are doing the donkey-work of data processing instead of LJ.

They're stealing your CPU cycles, is what they're doing.


megajessness at 2011-12-24 19:25 (UTC) (Link)
I would love to see some proof of this. Hard data, the scripts themselves, where they would be stored, etc. I'm sure everyone would like to know how to counter this method by either deletion or modification.
Jonathan Andrew Sheen
leviathan0999 at 2011-12-24 20:31 (UTC) (Link)
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.
megajessness at 2011-12-26 11:48 (UTC) (Link)
The reason I ask is because that's apparently how AJAX works, with the auto-updating. I'm wondering if the client has to send the update request first, or if the new packets are automatically sent to the client upon the page itself updating. It would be faster and more efficient if it were the latter case, therefore seems more likely to me. The former case requires some kind of script or add-on to be installed, like the add-on 4chan has if you don't want to keep refreshing the page manually. It refreshes for you in certain intervals.

Thing is, the auto-update feature that AJAX has doesn't work for me. I can be logged in and it still wouldn't work. I either don't have something that's required, it's just that buggy, or (even better) my firewall is blocking the port the software is using to send the information. I'd love it to be the third reason, so then I can find out which port and spread the word :3
Jonathan Andrew Sheen
leviathan0999 at 2011-12-26 15:26 (UTC) (Link)
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.")
megajessness at 2011-12-27 02:02 (UTC) (Link)
Heh, almost makes me wish I took more networking classes. I do a little better with some actual code in front of my face. (Ah, UNIX, what wonderful servers you make. Wish I took more than one class in that, too.)
The Darker
mindways at 2011-12-27 01:33 (UTC) (Link)
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)
megajessness at 2011-12-27 01:52 (UTC) (Link)
I see! Thanks for the details. I know for sure I have Javascript enabled, it's stupid these days not to because the script is used for even something as simple as a timer or scrolling text with a link on it.

Hm. With all AJAX can do, I bet it's safe to assume that the developers in charge of programming have yet to work out all the kinks in writing something new and completely from scratch, on top of utilizing new software. It's no wonder LJ is running so slowly despite the update. They really should have taken more time with this, or at the very least cleaned up the old code before utilizing AJAX.
The Darker
mindways at 2011-12-27 01:35 (UTC) (Link)
"...and telling your browser to do the laborious work of the screen redraw instead of LJ having to re-send the whole page"

If the server re-sends a whole HTML page to you, your browser has to re-render *that entire page*. With a well-designed AJAX solution, your browser only needs to redraw a small part of the page, which with modern browsers is nearly always much faster.

The only way in which AJAX intrinsically taxes an individual user's PC more than a full-refresh solution is when it's used to periodically ping the server, asking "is more data available?" every so often: that polling is an intrinsic - but small - cost.

Poorly written Javascript (the stuff which modifies the page based on returned data) can certainly result in painfully slow/clostly re-renders, but those aren't inevitable: simply the result of poor coding, or coders who haven't figured out how to make the DOM (Document Object Model - how you alter an HTML page using Javascript) do what they want efficiently.
Jonathan Andrew Sheen
leviathan0999 at 2011-12-27 20:53 (UTC) (Link)

Seriously, thanks so much for that really thorough answer! You're a veritable Ghod among Gweepdom!
alloy_ at 2011-12-26 21:39 (UTC) (Link)
It does make more sense to load share over thousands of pc's than through only a few servers.

I'm not sure I disgree with the methodology in principle.
Jonathan Andrew Sheen
leviathan0999 at 2011-12-27 01:25 (UTC) (Link)
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.
alloy_ at 2011-12-28 05:39 (UTC) (Link)
I do agree with you there.

I personally think we should be looking at a solution which removes our data entirely from a third party server.

Our friends are our friends.

I'd like to see a solution whereby we all absorb some of the overhead.

A social networking solution which relies on peer to peer data transfer.

Secure, insofar as your friends are secure, not subject to corporate whims (or vulnerable to centrally issued court writs) and devoid of ads, or data mining

Individuals decide how much data to store, and data is subject to some sort of recall by original poster.


Some of us with resources to spare might add some o
Previous Entry  Next Entry