You know, I would feel a lot better about this technology if someone had fixed basic problems with the way browsers handle JavaScript, about JavaScript policy specifications and compliance testing, and if there were good, usable and mature static analysis tools that could detect cross-site scripting vulnerabilities (Pixy by Jovanovic et al. comes to mind as a promising open source tool), and if people used them.  These problems have been known for a long time.

1. Same origin policy and shared servers.  So, my home page is http://homes.cerias.purdue.edu/~pmeunier/;  if I put a nasty javascript there, it can access or change the contents of other CERIAS home pages if you follow a link from my page, or if my page opens another home page for you.  I made a demo which for Safari users displays Adam Hammer’s home page url but with contents of my choosing (with apologies to Adam).  Firefox is a bit smarter and the url displayed is instead that of my page, which could clue attentive users to the fact that the content really comes from elsewhere.  Adam doesn’t actually have a home page there.
2. Modern browsers still can’t survive a visit to this site (WARNING!  Your browser will likely crash or become unusable when you click buttons on that site):  Nasty Javascript Bombs (I didn’t try all browsers, like Opera, but Safari died horrible deaths)
3. Modern browsers can still be captured:  Firefox users visit (WARNING!  you won’t be able to return) the jail, do not collect $200.
4. Searching for JavaScript-related vulnerabilities in 2006 in the National Vulnerability Database gives 124 matches (and the year is not even over).  3 of those are accidental hits (because “javascript” was part of a file name or such).  About 50% are cross-site scripting vulnerabilities, that could include the above Javascript (and likely worse code than changing your choice of hero). About 40% are coding errors in the JavaScript implementation.  About 10% are still issues with the enforcement of JavaScript default security policies, or things that should explicitly be stated as part of default policies (e.g, CVE-2006-2900 and CVE-2006-2894, abusing Javascript keystroke events to trick users into typing where they didn’t mean to).  Cross-site scripting vulnerabilities are hard to avoid because scripts can be embedded almost anywhere inside HTML.  The separation between code (JavaScript) and data (HTML) is flimsy and complex.  I predict that XSS vulnerabilities will be to AJAX applications what buffer overflows and format string vulnerabilities are to C:  a real pain.  There is no sign that browsers have matured enough yet to be trusted in handling JavaScript safely, and this will likely continue for many years.
5. Perfectly compliant JavaScript and browsers can be used to scan internal networks and even perform limited exploits.
6. JavaScript seems to be used most of the time to perform tasks that are user-unfriendly (hide user interface elements and generally remove control from the user, create pop-unders, show ads, track you by history, etc…).  So, I should expose myself to these, and the above and future vulnerabilities, so you can program something that’s a little slicker, or poorly duplicates the functionality of executables on my system?  Huh.

So, tell me again;  do you really want to build castles on that foundation?  It sounds like a bad idea to me.  We can always hope that eventually, AJAX horror stories (to come) will drive security improvements, but I’d rather not be in the crowd of early sufferers.  At least, please do me a favor and honor the principle of graceful degradation, so that if I visit your web site with JavaScript turned off, I can still make some use of it.