This is what programming for the web should be called. We need to keep piling on buzz words until no one knows what any of it means. Just when those of us out in the world that support web-based applications get an environment together that can be properly supported and checked for accuracy, then comes along things like client-side javascript. We have always been able to test the health of applications by interacting with web pages via standard query/post/response methods. Things like this are very easy to capture in tools like jmeter and deploy as health checks. Client-side code execution is starting to pop up all over the place rendering this approach moot. When testing the outcome of a piece of client-side code, an entire rendering engine must be employed to process it. This causes enterprises to drastically increase monitoring capacity to handle application testing. Tools like Selenium are available that allow us to replicate actual browser sessions, not just rendering engines. The folks over a labnotes.org built Zombie.js, which is a headless browser designed specifically for testing client-side javascript. These tools are becoming essential. Major vendors such as Citrix have been building their applications with so much client-side code that now a full stack application check is the only way to verify functionality. Not counting the countless mess of security vulnerabilities, the work involved to re-architect these health checks is pretty hefty. Time for me to get to work.