You cannot write the entire application (or even most of it) in JavaScript for many reasons. The largest of which have always, for me, remained performance and - most of all - security.
Even if you don't care about performance, you'll most likely want some authentication and authorization in your app at some point, and JavaScript in the browser (by design) gives you neither. Someone can easily open up a debugger, or even just view the source, and change the way your client-side application behaves. JavaScript obfuscation does nothing other than add a few minutes to the reading of the code, and shrinking the size of the download.
Unfortunately, for the developers (and those paying developers), this means developing a server-side application and an almost completely separate client-side application on top of that. This has certain benefits for larger, more complex web applications, but it does mean having a server-side MVC and a rather different client-side MVC. For more reading on this, I recommend starting with OWASP.
As far as SproutCore goes, it looks promising and tempting, but until it matures enough to handle the customization and accessibility requirements I have, I don't really have any desire to look any more into it (as such, I haven't a clue as to how it scales or performs).
For everything on which I've worked long-term, I've only used custom frameworks for both client and server, so I can't really speak to how well any particular framework integrates with any particular client-side framework. I think if I wanted to do so, I'd probably start my search by looking at the recent work on the Zend Framework and Dojo Toolkit integration, though.
by Shawn Lauriat — Aug 02
Even if you don't care about performance, you'll most likely want some authentication and authorization in your app at some point, and JavaScript in the browser (by design) gives you neither. Someone can easily open up a debugger, or even just view the source, and change the way your client-side application behaves. JavaScript obfuscation does nothing other than add a few minutes to the reading of the code, and shrinking the size of the download.
Unfortunately, for the developers (and those paying developers), this means developing a server-side application and an almost completely separate client-side application on top of that. This has certain benefits for larger, more complex web applications, but it does mean having a server-side MVC and a rather different client-side MVC. For more reading on this, I recommend starting with OWASP.
As far as SproutCore goes, it looks promising and tempting, but until it matures enough to handle the customization and accessibility requirements I have, I don't really have any desire to look any more into it (as such, I haven't a clue as to how it scales or performs).
For everything on which I've worked long-term, I've only used custom frameworks for both client and server, so I can't really speak to how well any particular framework integrates with any particular client-side framework. I think if I wanted to do so, I'd probably start my search by looking at the recent work on the Zend Framework and Dojo Toolkit integration, though.