Diaspora re-writes its front to Backbone: why and what it means

The way that this post describes porting and existing interface from server-side/ajax rendering to client-side rendering is particularly interesting -- I imagine that there aren't many apps that have made that jump <i>after</i> first being built around server-side templates.<p>The speed benefits that Diaspora is seeing from distributing their HTML rendering is probably only the first step. There are <i>so many</i> more interesting interactions you can accomplish once your data is being modeled in the browser.

This is the biggest win for Diaspora? Really? Sounds like they've been deluded by all those NYU CS professors who think knowing how to add 32 bit floating point numbers is the key to success.<p>Just dump everything, spend 1% of your time rewriting everything in PHP, and the rest actually doing some marketing, not imaginary work.

Maybe this is a really stupid question, but wasn't Diaspora supposed to be decentralized? In the sense that anybody could set up their own hub? (so people would not have to accept features pushed by some big corporation and things like that)<p>Then what is this whole database backend for? Is it like the "main" Diaspora hub? And could anyone set up their own secondary one? Would they run into the same difficulties they're trying to solve here?<p>Though I get the feeling I'm probably misunderstanding the entire Diaspora project, here.

Sorry, I don't know what "Backbone" is. I see links to New Relic and Pivotal Labs, but no links to anything called "Backbone".<p>I guess this blog post was maybe not meant for purely technical people, but it would be nice to understand what "Backbone" is, and exactly why it would solve their problems.

500ms+ for rendering a template seems ridiculous. Were they just Doing It Wrong, Ruby-wise?

It sounds like they were jumping to conclusions regarding the templating being responsible for creating a large number of objects.<p>ERB, Haml (which is what Diaspora uses), and any other templating engine I've seen use either concat or &#60;&#60; when rendering a template. These never create a new object, they mutate (and perhaps resize) the original string.<p>Maybe next time they should profile better before following their gut feeling and rewriting their front end ;)

I'm coming from a Python perspective; no idea if this is easy/possible in Ruby.<p>Maybe this is a really stupid idea, but what if we <i>gasp</i> disabled the GC during the course of each request and did a collection run after the request is completed and before the next one is accepted? With a sufficient number of workers, wouldn't this solve some of the problems they were having?

This post made me curious to learn more about new relic and their architecture. I found this post pretty interesting: <a href="http://highscalability.com/blog/2011/7/18/new-relic-architecture-collecting-20-billion-metrics-a-day.html" rel="nofollow">http://highscalability.com/blog/2011/7/18/new-relic-architec...</a>

Does it mean they won't blow away all their user accounts when they get bored and start again? No? Well that is why Diaspora is a joke.

Is there a main deployment of Diaspora somewhere? Or is this a purely academic project?

okay <a href="http://i.imgur.com/jHu1N.png" rel="nofollow">http://i.imgur.com/jHu1N.png</a><p>this is from webkit nightly after I clicked a user name and got a "you messed up" 404 page and went back

Rewriting the front-end using Javascript and Backbone won't fix the backend problems necessarily. How about reducing the objects creation and tuning the backend too?

Rad! That graph is awesome!<p>Also cool that the source is public on Github. thanks for that. Always fun to peek in on source.