Programming Social Applications

Why Use Caja?

Some readers may be wondering why to use Caja at all since it seems more restrictive for developers. And they’re completely correct—Caja does restrict the actions and implementations of developers who are building code on top of an existing site or application container. Developers will have to go through extra steps and stick to a set of good programming practices when building out systems to run under Caja.

But the simple fact is that any developer worth his salt who wants to build something, will—especially in a stable rewriting environment such as the one Caja provides. And developers should not be the main concern for this implementation, anyway; rather, the focus should be on the people who are using the site or application, who don’t have the background, knowledge, or inclination to protect themselves from malicious attacks from outside sources.

This is the main reason to implement Caja—to protect your end users from the potentially malicious code and sources that you are exposing them to by allowing third-party content to be hosted on your site or container. When it really comes down to it, the success of a product relies on the trust relationship between that product or company, and the people who use it on a regular basis. A user who doesn’t trust a product will be far less inclined to use it.

Another clear advantage to Caja is that it enforces web standards. Sloppy development, corner cutting, and potentially malicious code that was employed to save time and ...