?

Log in

No account? Create an account
Friends page in JavaScript - brad's life [entries|archive|friends|userinfo]
Brad Fitzpatrick

[ website | bradfitz.com ]
[ userinfo | livejournal userinfo ]
[ archive | journal archive ]

Friends page in JavaScript [Sep. 12th, 2005|10:49 pm]
Brad Fitzpatrick
[Tags|, , ]

In my copious free time, I've "ported" the LiveJournal friend's page algorithm from Perl (running on the server), to JavaScript (running in the browser).

So instead of making one huge friends page request and getting back a rendered document with 95% duplicate stuff that your client has already downloaded 15 seconds ago when you habitually hammered refresh, your client instead makes dozens of tiny requests, easily cachable on both the client and server, all the way up to the BIG-IP where I can later just instruct it to 304 any If-Modified-Since request on certain immutable URLs. (ala /userpic/ requests)

Plus it can have a background thread polling the last updated times of your friends page, deciding when to refresh itself, just doing the minimum work necessary to update fully. And even if you hit shift-reload to cache-bust, that only cache-busts the pages necessary to onLoad() the document. After that, javascript takes over so the browser goes back to caching. (Had to do some an old-school work-around to make Firefox cache, but IE behaves.... I wish XmlHttpRequest's caching behavior was specified and consistent.)

Anyway, works in IE/Safari/Firefox. Been reading my friend's page in it the past couple days. Pretty addictive.

I'll post a URL when it's beautified a bit and it's not lacking 75% of its future feature set.
LinkReply

Comments:
[User Picture]From: brad
2005-09-13 07:16 am (UTC)
Not gonna happen. Doesn't scale. The friends page algorithm is finishes in 's' steps, where 's' is the number of items to view. The ?start= would require way more indexes (beyond being worth it) and/or an algorithm that runs in 'f' steps, where 'f' is your number of friend, which also won't happen.

However, bookmarkable URLs are totally doable, encoding in them the content of the page, and where you're at in time. Then the previous/back links can be optionally shown, if the time you're viewing the page is within the 2 week scrollback period.

As for solving the "I was away on vacation for 3 weeks" problem where you want to catch up going forward in time, that's more of the always-talked-about-but-never-done ESN system, which is actually now on our roadmap after Scrapbook improvements, but since I'm not so involved with Scrapbook, I might work on ESN a bit earlier.

In fact --- much of my work on this javascript friends page is to make ESN integration a lot easier in the future.
(Reply) (Parent) (Thread)
[User Picture]From: taral
2005-09-13 07:24 am (UTC)
Okay, bookmarkable URLs is all I wanted to start with. :)

What is ESN?
(Reply) (Parent) (Thread)
[User Picture]From: mart
2005-09-13 07:27 am (UTC)

Event Subscription/Notification. Everything triggers an event, and you can subscribe to given events with given notification. Possible notifications could be your new friends page or email, IM, etc.

(Reply) (Parent) (Thread)
[User Picture]From: nothings
2005-09-13 09:19 am (UTC)
Ok, I can't quite infer what the ?start= would be, but I guess bookmarkable URLs would address the "going forward in time, you'll miss entries if anyone updates" issue?

Topic #2, nothing to do with the above: isn't the fact that shift-reload is only going to reload the javascript loader code actually a bad thing, not a good thing, since it breaks the actual point of shift-reload (which, for me, at least, is "hey browser, some of this stuff didn't load right for some reason, uncache it and try again")? I'm not clear what the use case is for where you want shift-reload to do less (well, from a user's standpoint, it's obvious from an LJ-load standpoint).
(Reply) (Parent) (Thread)