Join 3,562 readers in helping fund MetaFilter (Hide)


The Magic Dollar Sign
March 5, 2012 5:52 AM   Subscribe

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.
posted by ignignokt (71 comments total) 24 users marked this as a favorite

 
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.
posted by DigDoug at 6:02 AM on March 5, 2012 [5 favorites]


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.
posted by DigDoug at 6:05 AM on March 5, 2012


s/Michal Migurski/our own Michal Migurski
posted by tmcw at 6:06 AM on March 5, 2012 [1 favorite]


[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.
posted by GenjiandProust at 6:07 AM on March 5, 2012 [19 favorites]


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.
posted by Kid Charlemagne at 6:07 AM on March 5, 2012


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.
posted by DU at 6:08 AM on March 5, 2012 [11 favorites]


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.
posted by DU at 6:09 AM on March 5, 2012


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?
posted by Abiezer at 6:17 AM on March 5, 2012 [9 favorites]


It’s not immediately clear to me what ___________ is doing for Metafilter.

You could replace this with anything.
posted by desjardins at 6:17 AM on March 5, 2012 [15 favorites]


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.
posted by Horace Rumpole at 6:18 AM on March 5, 2012 [2 favorites]


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.
posted by azpenguin at 6:27 AM on March 5, 2012 [9 favorites]


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.
posted by Panjandrum at 6:27 AM on March 5, 2012 [7 favorites]


jQuery does the fadeout on stuff like removing posts from your Recent Activity.
posted by smackfu at 6:27 AM on March 5, 2012


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.
posted by helicomatic at 6:30 AM on March 5, 2012


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.
posted by delmoi at 6:33 AM on March 5, 2012 [5 favorites]


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.
posted by Jimbob at 6:34 AM on March 5, 2012 [2 favorites]


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.
posted by yeti at 6:42 AM on March 5, 2012 [2 favorites]


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.
posted by Nothing at 6:43 AM on March 5, 2012 [2 favorites]


I wonder how small a Twitter page, before they shoveled-on all the "suggest you follow" social bullshit, would be?
posted by Thorzdad at 6:48 AM on March 5, 2012


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.
posted by Benny Andajetz at 6:49 AM on March 5, 2012 [2 favorites]


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.
posted by Nomyte at 6:51 AM on March 5, 2012 [17 favorites]


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.
posted by CheeseDigestsAll at 6:57 AM on March 5, 2012


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.
posted by skymt at 7:00 AM on March 5, 2012


Any advances in a technology will be burdened by features that bloat it and slow it until it reaches "just-tolerable" level.
posted by Xoebe at 7:00 AM on March 5, 2012 [8 favorites]


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.
posted by CheeseDigestsAll at 7:02 AM on March 5, 2012 [1 favorite]


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.
posted by verb at 7:07 AM on March 5, 2012


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.
posted by narcoleptic at 7:10 AM on March 5, 2012


And the answer is probably that it makes implementing the "add favorite" feature much easier.

You are right, according to the commenter number three.
posted by hat_eater at 7:11 AM on March 5, 2012


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.
posted by weston at 7:11 AM on March 5, 2012


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.
posted by device55 at 7:15 AM on March 5, 2012


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?
posted by Popular Ethics at 7:17 AM on March 5, 2012 [2 favorites]


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.
posted by schmod at 7:25 AM on March 5, 2012 [1 favorite]


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?
posted by Reasonably Everything Happens at 7:28 AM on March 5, 2012


Is this what it sounds like to be old and out of touch?

yeah daddio, usability's for squares.
posted by device55 at 7:46 AM on March 5, 2012 [2 favorites]


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

posted by symbioid at 7:51 AM on March 5, 2012


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.
posted by brennen at 7:59 AM on March 5, 2012 [5 favorites]


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.
posted by Aquaman at 8:03 AM on March 5, 2012


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.
posted by verb at 8:12 AM on March 5, 2012 [2 favorites]


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.
posted by mcstayinskool at 8:24 AM on March 5, 2012 [1 favorite]


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.
posted by brennen at 8:25 AM on March 5, 2012


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.
posted by migurski at 8:33 AM on March 5, 2012 [10 favorites]


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?"
posted by cortex at 8:53 AM on March 5, 2012 [5 favorites]


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.
posted by brennen at 9:09 AM on March 5, 2012


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.


MetaFilter: We work hard so you don't have to.
posted by RikiTikiTavi at 9:18 AM on March 5, 2012 [4 favorites]


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.
posted by wcfields at 9:29 AM on March 5, 2012


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.
posted by Artw at 9:46 AM on March 5, 2012


I am not, btw, seeing jQuery as seperate files within that, though there could be some form of file combiner at work.
posted by Artw at 9:48 AM on March 5, 2012


...and checking from console it is certainly there.
posted by Artw at 9:49 AM on March 5, 2012


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.
posted by Artw at 9:58 AM on March 5, 2012


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.
posted by Artw at 10:39 AM on March 5, 2012


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.
posted by migurski at 10:51 AM on March 5, 2012


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.
posted by cupcake1337 at 10:53 AM on March 5, 2012 [1 favorite]


Grumble grumble ASCII grumble back in my day grumble get off my lawn etc.
posted by Celsius1414 at 11:18 AM on March 5, 2012 [1 favorite]


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.
posted by Artw at 11:20 AM on March 5, 2012


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.
posted by migurski at 11:30 AM on March 5, 2012


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.
posted by delmoi at 11:45 AM on March 5, 2012 [1 favorite]


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?
posted by weston at 11:49 AM on March 5, 2012


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.
posted by GenjiandProust at 11:54 AM on March 5, 2012


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.
posted by migurski at 11:55 AM on March 5, 2012


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.
posted by Artw at 12:07 PM on March 5, 2012 [3 favorites]


But then, I'm a rare book librarian…

Perhaps we should start a breeding program.
posted by zippy at 12:19 PM on March 5, 2012 [2 favorites]


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.
posted by migurski at 1:39 PM on March 5, 2012 [1 favorite]


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.
posted by verb at 1:45 PM on March 5, 2012 [1 favorite]


[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
posted by Godspeed.You!Black.Emperor.Penguin at 2:40 PM on March 5, 2012


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.
posted by verb at 3:41 PM on March 5, 2012


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.
posted by Artw at 3:54 PM on March 5, 2012


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.
posted by bjrubble at 5:42 PM on March 5, 2012 [2 favorites]


No one's flushing their cache between tweets.

I have a greenhouse beneath a birch tree. You are so wrong.
posted by srboisvert at 2:36 AM on March 6, 2012 [4 favorites]


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.
posted by delmoi at 12:27 PM on March 10, 2012


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.
posted by verb at 6:30 AM on March 12, 2012 [1 favorite]


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.
posted by verb at 6:31 AM on March 12, 2012


« Older Counting Stars...  |  Compared to some species, huma... Newer »


This thread has been archived and is closed to new comments