Comments on: The Magic Dollar Sign

The Magic Dollar Sign

ignignokt — Mon, 05 Mar 2012 05:52:06 -0800

The page for a single tweet is 2.0 MB and 80% javascript. Michal Migurski profiles the sizes and compositions of typical pages from popular web sites, MetaFilter among them.

By: DigDoug

DigDoug — Mon, 05 Mar 2012 06:02:45 -0800

This seems to miss the fact that JS doesn't have to download every time. The CSS and JS files can be fetched from cache. No one's flushing their cache between tweets.

By: DigDoug

DigDoug — Mon, 05 Mar 2012 06:05:17 -0800

Stretch that to 10 consecutive 'page views'/articles read on the site, and the bar graphs will really change shape. I'd do it, but my boss seems to think he's paying me for other things.

By: tmcw

tmcw — Mon, 05 Mar 2012 06:06:09 -0800

s/Michal Migurski/our own Michal Migurski

By: GenjiandProust

GenjiandProust — Mon, 05 Mar 2012 06:07:10 -0800

[Metafilter] it's one of the few social sites on the web that's organized 100% around the principle that You Are Here To Read. Well, and argue. And snark. And be helpful. And pout about favorites. And ask for ponies.

By: Kid Charlemagne

Kid Charlemagne — Mon, 05 Mar 2012 06:07:17 -0800

I wish he'd have summarized these in one graphic that had everything on the same scale. At first I thought that Metafilter looked kind of script heavy until I went back and compared it to everything else. Then, not so much. And being a data anlysis / synthesis freak, I'd like to see this such that I can look at the sites sorted by the different types of bandwith usage. And then I think that doing that in one seven dimensional graph would be really cool and then.... ...then I get a headache and have to lay down for a while.

By: DU

DU — Mon, 05 Mar 2012 06:08:16 -0800

It's mind-boggling to me that with the high overlap between web developers/designers and iPhone users on AT&T's network, there isn't more and smarter attention paid to the sizes of the things we're slinging around the network. My mind is completely unboggled. Whenever my boss or I do back-of-the-envelope calculations of bandwidth, size, memory usage or CPU time, everyone around us just looks on in confusion. "What are you saying all those numbers for?!" Then they send a Java-generated XML message literally 3 orders of magnitude bigger than it needs to be and ask if it "looks OK". Sure, if you only want to send one of them, which is likely all you have time to generate with your awful code anyway. But if you want to send the hundreds of thousands you are going to get per day, maybe trim it down a little.

By: DU

DU — Mon, 05 Mar 2012 06:09:55 -0800

Oh and on Twitter specifically: They may be slow and constantly broken, but at least they also ignore usability standards. I'd like to see a similar graph on Identi.ca, which seems to be largely the same, only slightly faster.

By: Abiezer

Abiezer — Mon, 05 Mar 2012 06:17:17 -0800

It's not immediately clear to me what jQuery is doing for Metafilter. Isn't he one of those overnight mods we took on recently?

By: desjardins

desjardins — Mon, 05 Mar 2012 06:17:56 -0800

It's not immediately clear to me what ___________ is doing for Metafilter. You could replace this with anything.

By: Horace Rumpole

Horace Rumpole — Mon, 05 Mar 2012 06:18:13 -0800

Boy, I sure wouldn't have guessed that the Google homepage was bigger than MeFi's. But then, I'm a rare book librarian, so what surprises me about web design probably isn't worth a ton.

By: azpenguin

azpenguin — Mon, 05 Mar 2012 06:27:03 -0800

I run on older machines at home, since new ones cost, ya know, money and stuff. (My desktop is 8 yers old and my iPod Touch is pushing 5. They still work, but they're slow.) MeFi is probably my most visited site, not only because of the content, but because it loads very quickly. Twitter, on the other hand, has gotten so clunky that I hardly ever use it. It's always made me wonder why a medium that is based on being succinct has a mainpage that is anything but.

By: Panjandrum

Panjandrum — Mon, 05 Mar 2012 06:27:12 -0800

It's not immediately clear to me what jQuery is doing for Metafilter. Isn't he one of those overnight mods we took on recently? I think it's actually Cortex's PUA persona.

By: smackfu

smackfu — Mon, 05 Mar 2012 06:27:25 -0800

jQuery does the fadeout on stuff like removing posts from your Recent Activity.

By: helicomatic

helicomatic — Mon, 05 Mar 2012 06:30:46 -0800

One of my favorite things about Metafilter is that no matter how old or underpowered the device I'm browsing with is, the site loads quickly and works flawlessly. This does wonders for my overall productivity.

By: delmoi

delmoi — Mon, 05 Mar 2012 06:33:19 -0800

This seems to miss the fact that JS doesn't have to download every time. The CSS and JS files can be fetched from cache. No one's flushing their cache between tweets.

Right. Anyone who doesn't understand this is kind of missing the point.

It's not immediately clear to me what jQuery is doing for Metafilter. Isn't he one of those overnight mods we took on recently?

jQuery has a lot of useful functions the most obvious being selectors, You can 'query' an HTML element using the same syntax you do in a CSS file. There's a new document.querySelector() function included in most browsers now, but it doesn't work in IE6 or 7. And that's the major selling point of jQuery, even if it doesn't do anything you can't do with 'pure' JavaScript in Firefox 143 or Chrome 4384 (or whatever version they are on now) you can write code that's concise and will run on every browser. At least I think that's the point. When it first came out there were probably things it could do that would have required a ton of code on your own. And Think it can even handle weird stuff like IE6 transparency, which uses a totally bizarre syntax based on COM/ActiveX Interface names. The other thing is, jQuery is so standardized now that I think there are probably people who don't even know how to code without it. Like if you look at some of the JavaScript questions on stackoverflow, sometimes the answers will be like "oh, do this with JQuery", and no one bothers to explain how to do it without it.

By: Jimbob

Jimbob — Mon, 05 Mar 2012 06:34:31 -0800

Yeah, Twitter has been annoying me quite a lot lately - loading up the page for an individual tweet should, to my mind, be almost instant - the same kind of time taken to view an SMS on my phone. Instead, it's generally in the order of 5-10 seconds. Seeing that profile of the actual data in the content on a tweet page depresses me further. The same goes for Google - makes my decision to switch to DuckDuckGo seem even nicer. Bullshit expands to fill the space provided.

By: yeti

yeti — Mon, 05 Mar 2012 06:42:33 -0800

This explains why when our internet is slow at work, the only website on the whole entire web that will still work for me is Metafilter. And all this time I thought it was divine intervention.

By: Nothing

Nothing — Mon, 05 Mar 2012 06:43:27 -0800

Demoli, I don't think the point of the commend about jQuery was due to not understanding what jQuery does in general, but what it does for a site that uses very little javascript. And the answer is probably that it makes implementing the "add favorite" feature much easier. Yes, things are cached, but scripts have to run every time, so there are CPU resources to consider as well. Twitter is a nightmare - I have not idea what they think they are doing. I never click on links to twitter because they take so long to load. It's stupid that a screenshot of 140 characters of text loads orders of magnitude faster.

By: Thorzdad

Thorzdad — Mon, 05 Mar 2012 06:48:29 -0800

I wonder how small a Twitter page, before they shoveled-on all the "suggest you follow" social bullshit, would be?

By: Benny Andajetz

Benny Andajetz — Mon, 05 Mar 2012 06:49:31 -0800

It's not just the size of the page, it's how you do it. I'm designing a photographer's site right now that's very image heavy (naturally). My average page consists of text and a jQuery lightbox setup showing thumbnails that can launch full-size images. Each page is over 1mb, but they load extremely quickly as far as the user is concerned. The pages are huge because, at page load, I dl all the full size images to hidden divs at the end of the page. That means the images load after the text is displayed, and when the user clicks on a thumbnail they don't have to wait for each individual image to load. Obviously, make pages as small as possible, but always consider the user, too.

By: Nomyte

Nomyte — Mon, 05 Mar 2012 06:51:49 -0800

But then, I'm a rare book librarian... I knew that book librarians were dwindling. I didn't realize it was as bad as this.

By: CheeseDigestsAll

CheeseDigestsAll — Mon, 05 Mar 2012 06:57:43 -0800

Google started adding JS to the home page in quantity when it added search as you type. Definitely worth it I think, especially as noted above, it gets cached.

By: skymt

skymt — Mon, 05 Mar 2012 07:00:18 -0800

I exclusively use [Twitter's mobile site](https://mobile.twitter.com/), even on my desktop. According to Chrome's web inspector the main feed is 115 KB, while a single tweet is 53 KB.

By: Xoebe

Xoebe — Mon, 05 Mar 2012 07:00:24 -0800

Any advances in a technology will be burdened by features that bloat it and slow it until it reaches "just-tolerable" level.

By: CheeseDigestsAll

CheeseDigestsAll — Mon, 05 Mar 2012 07:02:34 -0800

Speaking of caching, if you use jQuery (or a few other libraries) you can get cross-site caching by using Google APIs instead of hosting them yourself.

By: verb

verb — Mon, 05 Mar 2012 07:07:04 -0800

Yeah, I'm not sure I get the jQuery hate, other than the fact that it's an easy scapegoat for the growing practice of building full client-side apps in JS and using the page request as the delivery mechanism for the app. jQuery didn't start that trend, or even accelerate it -- the tools that came before it were orders of magnitude worse, including full client-side widget and design pattern libraries, etc.

By: narcoleptic

narcoleptic — Mon, 05 Mar 2012 07:10:35 -0800

Way too little importance is placed on page size and loading time. Not all of us live in the modern world, I have a decent connection at home and work, but my mobile connection is abysmal. I had AT&T, and EDGE was the fastest. Now I have Verizon, and it is even worst. Their '3G' (EV-DO) isn't, and most of the time I have 1xRTT.

By: hat_eater

hat_eater — Mon, 05 Mar 2012 07:11:06 -0800

And the answer is probably that it makes implementing the "add favorite" feature much easier. You are right, according to the commenter number three.

By: weston

weston — Mon, 05 Mar 2012 07:11:32 -0800

Came in to say what skymt said. Particularly when I'm traveling and I can't count on connection speeds, I've started using mobile versions of sites a lot more on my laptop. *Particularly* Twitter. There's something in the air right now where a lot of developers are talking about or even outright abandoning progressive enhancement, assuming JavaScript as a feature, relying on large (if optimized) JS payloads, and even substituting client-side templating server-side markup rendering.

By: device55

device55 — Mon, 05 Mar 2012 07:15:59 -0800

I'm not sure I get the jQuery hate I don't understand that either - jQuery is a really efficient and very powerful library. It's built around a philosophy of progressive enhancement. Sure, it can be used badly, but if you want to see some JavaScript bloat, check out Ext JS. Twitter.com is terrible though. I only use twitter via a desktop or native phone app.

By: Popular Ethics

Popular Ethics — Mon, 05 Mar 2012 07:17:37 -0800

or even outright abandoning progressive enhancement, assuming JavaScript as a feature, relying on large (if optimized) JS payloads, and even substituting client-side templating server-side markup rendering. Is this what it sounds like to be old and out of touch?

By: schmod

schmod — Mon, 05 Mar 2012 07:25:59 -0800

The worst sins of the Flash years are coming back with a vengeance, in the form of CSS Frameworks and the magic dollar sign. There has seriously got to be a better way to do this.

Bootstrap and jQuery barely take you over 100kb, and are cached between pages. This isn't the problem. Both frameworks are probably a bit bigger than they need to be, but provide enough functionality to justify their size. (On the other hand, modular micro-frameworks look like they might be the way forward...) Also, bandwidth isn't as big of a constraint as it once was.

By: Reasonably Everything Happens

Reasonably Everything Happens — Mon, 05 Mar 2012 07:28:19 -0800

Twitter has about a 15,000-to-one ratio of garbage to content...the aggressive anti-performance and apparent contempt for the web by Twitter's designers is probably the thing that gets me most irrationally riled-up on a daily basis I'm a total noob on this, but could this be Twitter conspiring with those that charge on data plans?

By: device55

device55 — Mon, 05 Mar 2012 07:46:54 -0800

Is this what it sounds like to be old and out of touch? yeah daddio, usability's for squares.

By: symbioid

symbioid — Mon, 05 Mar 2012 07:51:33 -0800

 -----
|     |
 -----

By: brennen

brennen — Mon, 05 Mar 2012 07:59:14 -0800

assuming JavaScript as a feature ... yeah daddio, usability's for squares. I say this both as someone who loathed JS from its introduction and surfed primarily with text-only browsers until a few years ago, and as someone who does web development for a living: It's pretty much time to assume JavaScript as a feature and work for usability from there. That doesn't mean that everything needs much (or any) JS, or that progressive enhancement should be abandoned. There's plenty of pointless re-implementing of basic web features going on. But it's 2012 and we now know that robust client-side scripting is a good and useful feature, and we may as well act accordingly.

By: Aquaman

Aquaman — Mon, 05 Mar 2012 08:03:54 -0800

Twitter's website is an abomination. Every time I click on a twitter link for 140 characters of text, I'm instead treated to a slow-ass loading webpage with more cruft than content that serves the actual text I'm looking for DEAD LAST. And DO NOT get me started on the utter abortion they somehow produced from from the elegant bones of Tweetie for the iPhone.

By: verb

verb — Mon, 05 Mar 2012 08:12:52 -0800

That doesn't mean that everything needs much (or any) JS, or that progressive enhancement should be abandoned. There's plenty of pointless re-implementing of basic web features going on. But it's 2012 and we now know that robust client-side scripting is a good and useful feature, and we may as well act accordingly. Yeah, client-side JS is definitely a feature that we can (generally) rely on. The problem is that you can implement functionality using client-side scripting in a way that is accessible and considerate of bandwidth constraints. Just as an example, I do some international travel for work and swapping in another SIM card is generally the best way to go. That often comes with very constrained , load speed is less worrisome to me than the raw payload size. Accidentally clicking a link to a single tweet is enough to eat about 5% of the data allocation on a cheap SIM card. Even using the iPhone client app can easily burn through 500K doing a timeline refresh, in part because it pulls in full-size photos for every one of your followers, scales them down, and doesn't cache them. These aren't show-stoppers, but it can make things frustrating. On the other hand, I pay nothing for Twitter and this architecture lets them push more and more of the work onto the client side, so I can understand how the decisions are made. It's not simply old-timers shaking their canes, though.

By: mcstayinskool

mcstayinskool — Mon, 05 Mar 2012 08:24:07 -0800

A little voice in my head is telling me that all that cruft on Twitter is intentionally put there to annoy the user into not using a desktop browser as their interface to Twitter. If true, that would seem like a really stupid decision on Twitter's part, but I've been in meetings with tech marketing people where much more ridiculous things have been decreed as gospel.

By: brennen

brennen — Mon, 05 Mar 2012 08:25:50 -0800

These aren't show-stoppers, but it can make things frustrating. On the other hand, I pay nothing for Twitter and this architecture lets them push more and more of the work onto the client side, so I can understand how the decisions are made. It's not simply old-timers shaking their canes, though. Yeah, I get the griping re: Twitter specifically. I'm lucky not to have to worry much about bandwidth these days, but the ways they're working to obscure the central utility of the application/medium are frustrating. Why does, say, clicking on a username not just take me to that user? Who thinks "let's be more like Facebook!" is a good strategy? What is this "Discover" asshattery? Also, the official client for Android is complete shit now for some reason, when it used to work more-or-less flawlessly. I think they have a tough row to hoe, though. Money has to be made somehow and it's a huge platform with all sorts of temptations to exercise influence. Perils of something that's essentially a protocol implemented as a one-corporation site, and all that. I'm still consistently surprised by how much I like what Twitter actually does despite this stuff. And they are doing useful technical work. I don't exactly like Bootstrap, but its utility is pretty obvious.

By: migurski

migurski — Mon, 05 Mar 2012 08:33:40 -0800

Oh hi everyone. Some replies:

The other thing is, jQuery is so standardized now that I think there are probably people who don't even know how to code without it. Like if you look at some of the JavaScript questions on stackoverflow, sometimes the answers will be like "oh, do this with JQuery", and no one bothers to explain how to do it without it.

Exactly. Rebecca Murphey explains this dynamic in her jQuery Divide talk from 2010: "we have an obligation—and it is in our interest—to help these newcomers understand where jQuery ends and JavaScript begins".

Yeah, I'm not sure I get the jQuery hate, other than the fact that it's an easy scapegoat for the growing practice of building full client-side apps in JS and using the page request as the delivery mechanism for the app.

That's about the meat of it right there. Twitter considers their site an application, with "states" instead of "pages", so they're operating from a consistent approach toward a single page interface. In theory this is fine, but in practice my once or twice-daily visits to the site and Twitter's continuous updates to the code counteract any advantage that client-side caching offers. Personally I think it's ridiculous for a site Twitter to get on board with hashbangs and other application-style features when their service is so obviously a web page with words on it.

A little voice in my head is telling me that all that cruft on Twitter is intentionally put there to annoy the user into not using a desktop browser as their interface to Twitter.

I thought about that too, but 2MB is a lot of energy to spend throwing something under the bus.

Bootstrap and jQuery barely take you over 100kb, and are cached between pages. This isn't the problem. ... Also, bandwidth isn't as big of a constraint as it once was.

jQuery-UI is another 200KB on top of that. Also, regarding bandwidth: AT&T. Smartphones. Roaming charges. Bandwidth now is more of a constraint than it's ever been in the past decade.

I wish he'd have summarized these in one graphic that had everything on the same scale. At first I thought that Metafilter looked kind of script heavy until I went back and compared it to everything else. Then, not so much.

They're just screenshots of Safari's built-in page size inspector, but you're right.

By: cortex

cortex — Mon, 05 Mar 2012 08:53:39 -0800

I think it's actually Cortex's PUA persona. "No, baby, I love that your SEO is so wonky. The way your keywords are all over the place, some guys might have a problem with that but I think it's charming. Can I refresh your tab?"

By: brennen

brennen — Mon, 05 Mar 2012 09:09:35 -0800

Personally I think it's ridiculous for a site Twitter to get on board with hashbangs They're apparently working on undoing that particular bad decision, at least.

By: RikiTikiTavi

RikiTikiTavi — Mon, 05 Mar 2012 09:18:49 -0800

By: wcfields

wcfields — Mon, 05 Mar 2012 09:29:07 -0800

I honestly believe the only people out there doing anything about streamlined JavaScript (and Flash) are those in the advertising industry. I used to work for the largest independent rich-media agency (hint: Their name is the same as an international police group). One of our constraints was size of our ad unit. I believe the max JavaScript was 20kb-30kb, and the Flash had to be under 300kb as well. Though after load we were allowed to request additional KB for videos, this really depended on the network that we were putting the unit on. So in that 20kb we had to code a cross-browser compliant system that would launch a Flash payload, correct for a number of scenarios of placement in CSS, make sure ours was at the top of the DOM for expendables (but at the same time, go to the bottom to allow the main sites JavaScript menus expand over our units), load tracking pixels for every single event, and in the event of No Flash load the animated GIF instead. The flash was a work of beauty in doing things that worked as animations that required next to nothing in payload. Though, I can't tell you how many late nights I had to spend making sure Renee Zellweger's smug mug properly expanded on the AOL home page.

By: Artw

Artw — Mon, 05 Mar 2012 09:46:31 -0800

Hmm. After clearing cache I get 543.2 KB for a single tweet view. About 400k of that is Javascript. Then I clicked through to Home and got a further 600k, which is a little puzzling as i would have guess it would have been done loading the bulk of the JS that make up the app. Further clicking around of the page is extremely lightweight as it's all pretty much very light AJAX calls and repopulating the same page. If I close that tab then revisit it 450k of the pageload comes from cache.

By: Artw

Artw — Mon, 05 Mar 2012 09:48:10 -0800

I am not, btw, seeing jQuery as seperate files within that, though there could be some form of file combiner at work.

By: Artw

Artw — Mon, 05 Mar 2012 09:49:03 -0800

...and checking from console it is certainly there.

By: Artw

Artw — Mon, 05 Mar 2012 09:58:50 -0800

Looking at my current project one of the more complex pages is 600K, revisiting it or a similar page 530K of that gets called from the cache. That's basically the shape of the web these days.

By: Artw

Artw — Mon, 05 Mar 2012 10:39:24 -0800

OK, this is weird, using firebug I am getting consistently lower sizes than this guy across the board. Metafilter: 86.5 KB (On reload 58K comes from cache) Google homepage: 214 KB (On reload 193K comes from cache) OpenStreetMap: 300K (failed to load all it's images), reloaded and got 330k with 120K from cache) New York Times: 2.5MB (On reload 2.3MB, though most of that is probably images that will not reoccur on other pages. I hit a story and it;s 1.1Mb with very little from cache, I hit another and it;s 500K with 400 from cache. It's all over the place, but generally fairly heavy) Github: 390K, 370k from cache) mike.teczno.com: 850k, largely images, 600k of which caches, though if that's largely images that will not recur it's questionable what the gains are there. Twitter I looked at above. Oh, and this article from the comments is pretty interesting: Stop paying your jQuery tax, though the title is a bit misleading (It;s more of a load and execution order thing than anything specific to jQuery) and TBH I find the solution he suggests unwieldy.

By: migurski

migurski — Mon, 05 Mar 2012 10:51:52 -0800

Artw: the effect of caching is real, and when (for example) Metafilter uses a consistent, static URL for jQuery the browser doesn't need to expend a bunch of bandwidth transferring once you're visiting for the second time. Sites that bundle their Javascript and release continuously counteract the benefits of caching over time.

By: cupcake1337

cupcake1337 — Mon, 05 Mar 2012 10:53:32 -0800

this is another one of the reasons why i'm not too interested in jumping on the iphone/smart phone band wagon. the trend is to make pocket computers "user friendly" i.e. impossible to tweak. but since data plans are priced by usage, and since so many websites (and apps) are so wasteful with bandwidth being able to tweak what you want to load and what you don't want to load could be really useful.

By: Celsius1414

Celsius1414 — Mon, 05 Mar 2012 11:18:17 -0800

Grumble grumble ASCII grumble back in my day grumble get off my lawn etc.

By: Artw

Artw — Mon, 05 Mar 2012 11:20:14 -0800

the effect of caching is real, and when (for example) Metafilter uses a consistent, static URL for jQuery the browser doesn't need to expend a bunch of bandwidth transferring once you're visiting for the second time. Well, yes...? Sites that bundle their Javascript and release continuously counteract the benefits of caching over time. Maybe. Though in the short term if you hit, say, Twitter repeatedly then you're not likely to reoccur that upfront bog JS hit if I come back and hit it again tomorrow maybe I'll need to grab the big JS files again, though TBH it's questionable how much of a problem that is. I am surprised that hitting the individual tweet page doesn't reuse the same JS as the main twitter feed, on the other hand all individual tweet pages should be hitting the same JS and utilising caching. Anyhow, these are the sets of tradeoffs that you have to make when designing a website. They are certainly something to consider, and I've certainly had things like file combing go wrong on me and produce results that don't hurt rather than helo, but I think the last paragraph of your article there is a leap into crazytown TBH.

By: migurski

migurski — Mon, 05 Mar 2012 11:30:11 -0800

if I come back and hit it again tomorrow maybe I'll need to grab the big JS files again, though TBH it's questionable how much of a problem that is. ... I think the last paragraph of your article there is a leap into crazytown TBH

I wouldn't be writing about it if interacting with Twitter.com wasn't such a consistently slow and broken experience. Whatever it is they're doing, they're clearly doing it wrong. I don't think it's crazy to suggest that paying attention to transfer sizes and code performance on the web is a worthwhile exercise. Twitter just happens to be a particularly egregious example because the ratio of code to content is so distorted. It was fine before #newtwitter by the way, and as brennen says above they're walking back some of the wasteful missteps of the past two years.

By: delmoi

delmoi — Mon, 05 Mar 2012 11:45:28 -0800

or even outright abandoning progressive enhancement, assuming JavaScript as a feature, relying on large (if optimized) JS payloads, and even substituting client-side templating server-side markup rendering.
Is this what it sounds like to be old and out of touch?

I don't know why you'd want to do anything on the server in the first place. The site I'm working on now is going to be entirely client side. In fact, It won't even need a server at all, you could just put static files up on S3. Think about it though: No server, no scalability issues! Obviously you would have a pretty weird URL if you did use S3. Plus you'd be coding against a propriety API. But really, why do anything server side if you don't have too? Rather then static files with no server at all, putting up a system almost nothing but static files makes a lot of sense. It would take an enormous amount of traffic to bring it down You don't need to be a data hog if you don't need to either. A JSON file, interpreted with code you already have in the users' cache can be a lot smaller then a pre-rendered HTML page.

I'm a total noob on this, but could this be Twitter conspiring with those that charge on data plans?

Listen to what people are saying in the thread. They're all using twitters mobile app. That's what they want. Mobile apps can probably be monetized a lot better then websites. I guess. As far as the page goes, I don't notice anything too bad whenever I click a link someone posts to some funny feed or whatever. But it's very, very rare that I'll ever visit. Some twitter feeds are funny, but I don't really feel the need to spend a lot of time reading one-off context-free jokes Other then that, what's the point? People might tweet a link to something interesting? They might also post it to Metafilter, or a bunch of other message boards where I can also get useful commentary about it (which you obviously can't get on twitter) That said, two things really annoy me about twitter's implementation specifically: The first is their incredibly annoying URL syntax with the #! URL thing. It's just ridiculous. It's also totally unnecessary because of the HTML5 history API You can still do things dynamically in JS without screwing up the regular URL syntax for everyone else.

Demoli, I don't think the point of the commend about jQuery was due to not understanding what jQuery does in general, but what it does for a site that uses very little javascript. And the answer is probably that it makes implementing the "add favorite" feature much easier.

I don't know why you say that, all of the features have javascript enhancements: Posting comments (live preview) Favorites, and flags. What else is there to do? There's a pretty decent sized chunk of JS involved. Two files: this one(2.7k), which seems to handle favorites and this (4.96k) which does more, and seems to handle flags and removes links to and this page, which is what the links for flags and favorites go to when you first load the page.

By: weston

weston — Mon, 05 Mar 2012 11:49:32 -0800

Is this what it sounds like to be old and out of touch? Is this what it sounds like when someone wants to make some kind of response but can't seem to muster an actual case?

By: GenjiandProust

GenjiandProust — Mon, 05 Mar 2012 11:54:38 -0800

But then, I'm a rare book librarian... I knew that book librarians were dwindling. I didn't realize it was as bad as this. Mr. Rumpole is still alive; that is rare as you can get, really. He's not cooked at all.

By: migurski

migurski — Mon, 05 Mar 2012 11:55:08 -0800

I don't know why you'd want to do anything on the server in the first place. The site I'm working on now is going to be entirely client side. In fact, It won't even need a server at all, you could just put static files up on S3. Think about it though: No server, no scalability issues!

That is awesome. To be clear, though, there are still scalability issues, they're just being pushed out to the client. We made Where Does The Money Go? using this technique and once all the stuff is loaded it runs like a champ, but you do have to collect all the assets upfront. Some stuff just makes a lot more sense to do on the server, from indexed databases with server-side templates. Like Metafilter, for example.

By: Artw

Artw — Mon, 05 Mar 2012 12:07:28 -0800

Except that a bunch of stuff does happen on Mefi without a page load, thanks to the evil jQuery, and TBH the site is much better for it in desktop and mobile. all howling from people who don't like change asside, Twitter probably does make a lot better sense as an app-like site updating itself via JSON rather than a pageload based site, and I wouldn't expect to see them going back on that. That does leave the individual tweet link with no prior caching as the absolute worse case, of course, but pretending the individual tweet is the only case 9or even that common a one) is pretty silly.

By: zippy

zippy — Mon, 05 Mar 2012 12:19:51 -0800

But then, I'm a rare book librarian... Perhaps we should start a breeding program.

By: migurski

migurski — Mon, 05 Mar 2012 13:39:23 -0800

Twitter probably does make a lot better sense as an app-like site updating itself via JSON rather than a pageload based site.

You're not wrong; there are a lot of things that make sense as single page sites. The issue with Twitter is not that they've decided to go single-page, it's that they've made such a hash of it.

By: verb

verb — Mon, 05 Mar 2012 13:45:19 -0800

Some stuff just makes a lot more sense to do on the server, from indexed databases with server-side templates. Like Metafilter, for example. Yeah, I do a lot of work with Drupal, which is 110% on the 'do it on the server' side of things. I build my personal site with Jekyll, though, which is 110% on the 'generate static files and push them to a dumb host' side. If you want to do dynamic stuff, you do it on the client side. They're very, very different ways of approaching things and they each have pros and cons.

By: Godspeed.You!Black.Emperor.Penguin

Godspeed.You!Black.Emperor.Penguin — Mon, 05 Mar 2012 14:40:09 -0800

[Metafilter] it's one of the few social sites on the web that's organized 100% around the principle that You Are Here To Read. Well, and argue. And snark. And be helpful. And pout about favorites. And ask for ponies. tl;dr

By: verb

verb — Mon, 05 Mar 2012 15:41:23 -0800

A little voice in my head is telling me that all that cruft on Twitter is intentionally put there to annoy the user into not using a desktop browser as their interface to Twitter. Actually, it's a lot easier for them to monetize browser access than API access through desktop clients. A lot of the work on the browser-based interface has been an attempt to duplicate the functionality of desktop client software inside the browser.

By: Artw

Artw — Mon, 05 Mar 2012 15:54:32 -0800

I wouldn't call it flawless, and the single-tweet case is actually fairly awful, but TBH I'm not seeing the main twitter app as being all that oversized considering the scope of what it does - it's basically 90% of Twitters functionality in one page load that's less than a newspaper frontpage and pretty much all caches. TBH most of my complaints about the twitter site would be more about design preferences - "Home" "Connect" and "Discover" being obtuse labels covering up former functionality, the bizarre new placement of the post window, lists now being two clicks away now, etc... It being basically an app has meant I haven't really seen hashbangs as a huge problem that they are on, forinstance, the Gawker redesign which left blog URLs useless.

By: bjrubble

bjrubble — Mon, 05 Mar 2012 17:42:59 -0800

The other thing worth mentioning with regard to jQuery and other frameworks is the use of CDNs -- even if you're only using a fraction of the library, the CDN will have copies nearby if not already in the local cache, so getting the full thing through a CDN can easily be more efficient than delivering a pared-down version all the way from your own server.

By: srboisvert

srboisvert — Tue, 06 Mar 2012 02:36:22 -0800

No one's flushing their cache between tweets. I have a greenhouse beneath a birch tree. You are so wrong.

By: delmoi

delmoi — Sat, 10 Mar 2012 12:27:46 -0800

Actually, it's a lot easier for them to monetize browser access than API access through desktop clients. A lot of the work on the browser-based interface has been an attempt to duplicate the functionality of desktop client software inside the browser.

Only because no one downloads native clients. If twitter did have a desktop client there are a lot more monitization strategies, depending on how evil they wanted to be. They could modify your browser so every link to a site with an affiliate thing could be replaced with their refer code. At the very least they could include their own browser, so that when you clicked links in twitter, you'd view the link in the built-in browser, and twitter could replace ads in them with their own.

By: verb

verb — Mon, 12 Mar 2012 06:30:24 -0800

Only because no one downloads native clients. Errrr... Even two years ago, 75% of their traffic was coming via API calls rather than their web site. If twitter did have a desktop client there are a lot more monitization strategies... Errrr... They do have a desktop client, at least for the Mac. And they have their own official clients for all the major smartphone platforms. And they bought TweetDeck. The core problem is that people are "trained" to see and accept advertising on web sites, not native apps. Especially given to the constrained real estate in smartphone apps -- there's nowhere to put ads of any consequence, and their entire "promoted tweets" initiative is an attempt to work through that problem.

By: verb

verb — Mon, 12 Mar 2012 06:31:57 -0800

Also, their much-reviled "use t.co as the link shortener for every link" change was generally understood to be an attempt at getting better and easier-to-monetize metrics, while introducing the (possibility) of interstitial ads on click. They haven't actually done that yet, but I can't imagine that it's not in the cards.