In the REST routing discussion, joachim referred to a talk Larry gave where Larry referred to serving up block content via AJAX.
Let's discuss what happens if we take that concept and run with it much more completely.
Before that, however, let's look at an example. Go view this video about my.fcc.gov. The builder of this Drupal site (Mike Reich) had several challenges with this site - not the least of which was that major parts of the content were NOT going to live in Drupal. So he needed a way that separated page content from it's structure.
To do so, Mike's team took the approach of pushing a lot of the work onto the browser, and having the browser get much of it's actual page content via JS callbacks. Essentially, he turned Drupal into a publisher of content via an API, using his newly-written content API modules, which is essentially a purpose-specific wrapper around the services module. This totally inverts the normal way Drupal builds a page. I note that the my.fcc.gov subsite essentially builds entire pages this way, though the main fcc.gov site only uses this partially. Refer to my comment in the context UX group to see what I think the interesting elements of the video are. (Oh, and something I didn't say there: the JS stuff is actually built using backbone.js.)
If we take this concept and run it to the max, we turn Drupal into an API engine and push much of the work to the browser. The immediate reactions you'll have are:
- Argh - performance hit! Displaying sites this way makes Drupal's bootstrap run each time you go get content via JS.
- Argh - backbone.js? I've got to learn another tech component?
- Argh - unsearchable! Search engine crawlers won't index AJAX content.
Valid points. Here are some of the benefits of the approach:
- Scaling may actually be better. For those sites with big traffic, it's conceivable that much of the content that would be fetched via JS could come from some sort of cache - similar to Akamai's edge side includes. And for the vast bulk of Drupal sites, the performance impact is modest at best.
- A mixed approach preserves indexability. The main fcc.gov site (in this example) actually returns the node body in the (HTML) page, so it can be indexed. I'd assert that most other page content - e.g. other blocks on the page - are actually either a) content that lives on another page, and would get indexed from there, or b) is merely supporting content that doesn't need to be indexed (and maybe is even distracting the search engine from focusing on what the page is really about. This mixed approach seems ideal.
(I note that search engines are going to have to deal with this AJAX problem in general, though. An increasing number of websites are furnishing all their content via AJAX. So search engines are going to have to start pulling javascript. It might be that they suggest some kind of HTML/CSS identifier outside of the JS that indicates to the crawler that this JS should be followed.... Who knows how, but they're going to have to solve the problem at some point, so the non-indexable argument is going to disappear at some point.)
- User interface design flexibility. It's entirely possible to come up with a really great UX-builder around this concept. Though it doesn't show it on the video above, there's another user interface in the admin back-end that's more site-builder (or even expert-content-creator) oriented, completely changing how easy it would be to empower people to make better changes in page layout.
- A new approach to user-based content display. As I said in the UX discussion, this approach enables content to be "personalized", because the client can be sent JS that embodies a query based on context (using the general meaning of the word context). E.g. get the client to send back a browser-based cookie that contains information about the end user (or his / her identity) as part of the content API request, and get back / display content that's different in block A for user 1 than the same block for user 2. This might be a way to get conditional, per-user content without paying the full price for handling an authenticated user.
(Note also that backbone.js doesn't have to be the JS toolkit used. It was simply the choice of the team who built the site. There might be ways to pull this off using jQuery (I don't know). Even if it does require another tech component, look how much better a website builder you were once you learned jQuery. :-))
I'm not a core dev, so I can't make recommendations on technical implementation. But I do know enough to recognize the general benefits of this approach, and also enough to recognize that there are Drupal implications that need discussed somewhere. This group seems to be the right place.
Comments
That's the plan
Hi Jay.
Yep, that neatly sums up the idea. :-) The reason it doesn't look like we're working on that yet is that Drupal is fundamentally incapable of serving that use case in a good way. That means we have to rearchitect a LOT of stuff before we get there.
However, that's what Phase 4, block-centric rendering, is all about. In order to support that sort of workflow, we need to:
1) Drastically reduce the weight of bootstrap through heavier reliance on class autoloading. That's what this issue starts us on, with a more robust autoloader. Currently the only thing that's waiting on is Dries to get around to commiting it. (Someone want to ping him to do that?)
2) Eliminate all globals and replace them with a request-derived injected context system, so that we can render blocks in isolation. That's what the Context API currently in progress in the WSCCI sandbox is all about.
3) Make returning non-HTML content, like just a JSON string, a first-class citizen. That's what all the rest routing Phase 3 stuff is about.
4) Eliminate the "one big page" concept that the Render API forced on us, and replace it with a "collection of independent blocks" model as demonstrated by Panels. Each block must be independently renderable (thanks to point 2), so that a block and an Ajax-loaded block are the same thing.
There are already existing efforts outside of Drupal to do this. Actually, the Symfony framework is WAY ahead of us in this department. They're already doing this sort of layered approach for exactly that reason. The VIE effort is also trying to standardize exactly the concept you describe. See:
http://bergie.iki.fi/blog/decoupling_content_management/
http://bergie.iki.fi/blog/vie_2-0_is_starting_to_emerge/
Drupal is far behind the curve in the area you describe. The WSCCI initiative itself is, essentially, focused on trying to resolve these issues so that we can do exactly what you describe. :-) But doing that is going to require fundamental changes to Drupal, changes that we are trying to work through now.
The macro-level we've figured out. The roadmap has been sorted out for over a year now. We just need to get it implemented, something that is proving challenging due to limited time and human resources. If someone wants to help on the micro-level, let me know or stop by one of our bi-weekly IRC meetings. I will also be at BADCamp this weekend if anyone wants to get involved.
We've got a lot of catching up to do. :-)