Diaspora re-writes its front to Backbone: why and what it means
devblog.joindiaspora.com
devblog.joindiaspora.com
The speed benefits that Diaspora is seeing from distributing their HTML rendering is probably only the first step. There are so many more interesting interactions you can accomplish once your data is being modeled in the browser.
Easier implementation of otherwise difficult features. Doing a client-side autocomplete of people's names is trivial when you already have all of the other accounts in your organization modeled in JavaScript ... but not as fun when you have to ajax for server-rendered HTML for it.
Live updates of pushed data. When another reader +1's a post that you're currently looking at, if the server pushes that data to you, and you have a model for that post -- it's easy to increment the counter. If the server has to push the re-rendered HTML for the entire post, it's much more difficult.
... and those are just the tip of the iceberg.
There are probably tons of security issues, but for some read-only cases it might be useful.
I don't think there necessarily are, since CORS allows cross-domain communication to be done in a safe, controlled way.
My imagined use-case is where your friend on a different server posts an event, it gets put into your feed, and when you view your feed you're able to see an updated list of people attending by directly querying the friend's server. Would be pretty slick.
Personally, I've rewritten a bunch of code at work to go from server-side rendered templates (in Jinja) to client-side rendered templates (using a Jinja-to-JavaScript compiler I wrote, https://bitbucket.org/djc/jasinja). Add some WebSockets magic and we now have a very fluid real-time application page.
The model is obviously very powerful. The one problem I have with it is JavaScript-the-language. Using it makes me love Python so much... I know it's not that bad and there are good parts, but it's still nowhere near Python.
There are challenges of this approach.
PS: Lots of downvote when it comes to Java and GWT eh...
Just dump everything, spend 1% of your time rewriting everything in PHP, and the rest actually doing some marketing, not imaginary work.
[1]: https://en.wikiquote.org/wiki/Donald_Knuth#Computer_Programm...
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?
Though I get the feeling I'm probably misunderstanding the entire Diaspora project, here.
But doesn't that mean that the problems the Diaspora team has to solve now will also pop up for other hubs as they grow in scale?
Or is the solution to create loads of smaller hubs and have them communicate? Then why don't they do that?
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.
The first link is to a javascript library widely known in the web development community.
Which gave me the first hit of www.backbonemedia.com/
In fact, backbone.js is no where on the first page for that search.
That's amazing it comes up first for "backbone". I did actually find that link eventually, and try out the "example" todo list, but that gave me no information about how this would fix a garbage collection problem. Does anyone know how it fixed their GC problem?
1. Dispora is slow, why?
2. Requests take a long time on the server, why?
3. Most of the time is spent in ruby doing processing.
4. Why is ruby slow?
5. Ruby is slow because of the garbage collector.
6. How can we get around this ruby being slow problem?
7. Reduce calls to server side by writing replacing server side calls with javascript rendering of templates and whatnot.
Perhaps more importantly, here are some examples of what sites are doing with it: http://backbonejs.org/#examples
It's entirely possible that you don't get the same search results on Google as I do if we're logged in because of what Google 'remembers' as our browsing habits and interests.
REE and Ruby 1.9.3 both offer GC tuning parameters, which let you instruct Ruby that you're going to shove a huge app at it and to not garbage collect every time someone sneezes, which can have a pretty massive impact on response times.
ERB, Haml (which is what Diaspora uses), and any other templating engine I've seen use either concat or << when rendering a template. These never create a new object, they mutate (and perhaps resize) the original string.
Maybe next time they should profile better before following their gut feeling and rewriting their front end ;)
Maybe this is a really stupid idea, but what if we gasp 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?
It's a good idea (and older than the diaspora project) and kudos to them for pushing forward, but I really hope someone else implements this idea correctly.
Public content is indexed by Google, like the 'cake' tag: https://joindiaspora.com/tags/cake
this is from webkit nightly after I clicked a user name and got a "you messed up" 404 page and went back
Also cool that the source is public on Github. thanks for that. Always fun to peek in on source.