Sunday, April 18th, 2010>p>
(Live blogging notes.)
* User clicks
* Sends ASync request
* Insert/Replace some content
So the team set up elements like this:
<a href=”/ring.php rel=”dialog”>…</a>
- new Dialog().setTitle().setBody().show();
would be output by a PHP script, and then evaluated in the browser:
- $response = new DialogResponse();
- $response = new AsyncResponse();
- $response->setContent("#elem_id", $new_content);
- $response->appendContent("#content .stories", $new_story);
And they are using a convention: “ajaxify=1″ on an element indicates it’s … Ajaxified.
At this point, the team had now Ajaxified a bunch of features, but people were still skeptical about more complicated features. For example, would setting status be too hard with the same techniques. So after some research, Makinde came back with an epiphany: the humble form. Whereas the previous async requests were effectively information-less – just a simple directive and maybe an ID – the requests would now include content too. And of course, most of these things look nothing like forms due to styling. But underneath, they’re still forms, e.g. the entire comments block is a single form.
Nowadays, most of Facebook runs without complete page refreshes, by dynamically flipping the content and the fragment ID. (What Facebook calls page transitions.)
Ongoing, Makinde says performance optimisation requires ongoing vigilance. Every engineer has their special case, but in the scheme of things, it’s better to say no to new features unless they can be strongly justified. For example, we can live with user submitting a form that hasn’t yet been hijacked; a complete page refresh is fine on occasion. We don’t like it, but we don’t want to make it a special case just for the sake of it.
UPDATE: And here are the slides …