There is something to be said for simplicity. When writing custom web application for CRM you can get fancy with Infragistics or Telerik controls and do all kinds of interesting and fun things. There are situations where using third party controls is certainly warranted. In the past I've always leaned towards using third party controls because they can make my life easier. I like being able to just throw a grid on a web form and update a few properties and have most of the work for display of data taken care of for me. As of late I have seen the value of bare bones custom web applications for CRM. As always it just depends on what you are doing and what you need to accomplish as to the need for the overhead of third party controls. But if possible it can be better to try and use vanilla HTML, JavaScript and CSS to accomplish your goal.

The benefits of using vanilla web development technologies is fairly obvious.
  • If you can accomplish everything in standard web tech you can include everything as web resources in your solution.
  • If you don't need third party controls you don't have to worry about the dependency of having those controls installed on the CRM servers. If you are implementing a server farm then you have to install the same controls X times based on the number of servers in your farm.
  • If you aren't using third party controls it makes it easier implement a custom web application as I will explain shortly.
The Hush Hush Way to Implement a Custom CRM Web Application
 
The official documentation states that when implementing a custom web application that it should be a separate web site and that the ISV folder has been deprecated. I understand where Microsoft is going with this because obviously they don't want your unknown code to be running within the same application pool and potentially cause issues with the CRM web service. The documentation also mentioned that this method of custom web application also takes into consideration that cross site scripting will not be an issue.
 
The interesting thing is that even thought the official documentation says create your apps externally depending on who you talk to at Microsoft the back door way of doing it is using an IIS virtual directory. There can be situations where certain things need to done using cross chatter between custom web apps and the CRM form. Microsoft consulting is actually using virtual directories themselves but it's more of a hush hush thing. They don't want to go and tell everyone to do this but it can be done.
 
The way to do it properly is when you create your virtual directory underneath the CRM web service you set it as an application and create a seperate application pool for it. This way you still avoid causing problems for the CRM web service while still being able to run your applications in the same "domain". The biggest things that this buys you is that you don't have to worry about cross site scripting so you get the ability to talk directly to the parent form in your web application. One thing to remember is that even if you include the ClientGlobalContext.js.aspx in your web page that it will not have the context of the form being that your app is running in an iFrame. You get the context of the organization but you can do things like ask the Xrm object what the Id of the form you are on. You need to go ask the parent window thing of that nature. Being in the same context as the parent window you can run any JavaScript method in the parent form too.
 
This method of creating custom web applications had worked out well. Even though it's sort of the undocumented way of doing it, I don't see off hand any real danger doing this. Yes things will change when updates come out but this seems to be a valid back door way of making web applications work with CRM.