While working with asp.net, I came to an approach that uses asp.net services for the data/business logic layer and html/javascript/jquery for the UI layer, because I could not reach the needed level of customization of the user interface with asp.net web controls.

While I've seen plenty of books describing usage of asp.net web controls and their integration with asp.net server side technology, and of html/js/jQuery client side web development without connection to any server side technology, I haven't seen any book dealing with combination of asp.net server side + html/js/jQuery client side.

My question is, is this approach acceptable, or have I overlooked some widespread technology which is better suited to accomplishing such tasks? My constraint is that it has to be based on asp.net/mvc server side technology, because my management urges that.

2 Answers 2


I work in a .NET shop that has historically used Webforms. We're in the process of migrating our software to MVC, however I have some personal experience with the idea you're describing. I'm assuming you're using Webforms, not MVC, given that .NET MVC regularly utilizes javascript for the UI layer. If that's not the case, feel free to disregard.

The simple, straight-forward answer to your question is that the approach is definitely acceptable. However, it does come with a variety of headaches. The basic problem is that things like HTML (particularly HTML5) and Javascript/JQuery take an opposite tact from .NET Webforms when modeling a page. Javascript recognizes the fundamentally stateless nature of the web, whereas .NET Webforms tries to pretend that a given page has a state (like a Winform application would) and leverage means of disguising the stateless nature of the presentation.

In other words, using .NET Webforms on a new project is going to give you any number of headaches for more than the most basic, casual usage. On the other hand, I would wholeheartedly endorse using a .NET MVC backend with HTML/Javascript/JQuery for the UI. Those two technologies fit together quite nicely, and are designed with the stateless nature of the web in mind. Having .NET MVC for the business logic and HTML/Javascript for the front-end is pretty ideal, in my opinion.

Alternate approaches would be to use another framework entirely (such as Ruby on Rails, some form of PHP, etc.), however since you're familiar with ASP.NET, I'd say to give MVC a try. It still uses the .NET Framework and Feature set, just with a more logically conceived toolset to interact with when it comes to the web.

All of this goes out of the window if the application you are making is small-scale, such as for a company intranet servicing dozens of employees. In that case, the speed and simplicity of Webforms might be exactly what you're looking for - though you'll find that, as mentioned above, doing much in the way of consuming web methods and updating partial pages will be an onerous chore.

For variety, here's a couple of contrasting views:

  1. Pro-MVC
  2. Pro-Webforms

Well I found out that the technology best suited for it is ASP.NET Web API, and they developed templates for Single Page Applications here


it figures out that better to use angular.js then knockout.js though.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.