Is JQuery more suited to MVC than WebForms or it doesn't matter? I am planning to use JQuery heavily.
views:
145answers:
7It is much more suited to MVC because the framework allows stricter control of the generated HTML, which allows you to have real, clean and custom IDs for your dom elements. Rather than the automatic ones ASP.Net gives you. This itself also gives performance improvements as it is much faster for jQuery to find element by ID than class.
Also with MVC you can use AJAX much easier because the whole set-up of MVC (controller action, rest paths) are much more suited to jQuery. You can call an action via a URL and that action could be designed to respond to GET requests, POST requests or both! All of this is built into the framework. MVC controller actions can return data more suited to jQuery as well, There are built in JSONResult and JSON helper objects.
Finally, to highlight jQuery's compatibility with MVC. The jQuery library is included by default with MVC :) If you plan to use jQuery heavily then use MVC, it's no contest.
The key point is that by using WebForms you are allowing WebForms to have a lot of control over the HTML that gets rendered and the DOM. The more you use jQuery the more you'll need to have total control over those otherwise it becomes more and more difficult.
jQuery can be used anywhere there's javascript needed, I would like to say it's more suitable to use it in .net MVC but that's simply because I like the way you can interact more easily with ajax and whatnot in MVC.
If you're at the cross roads between choosing .net MVC and web forms, I really, really, really suggest you take the MVC route.
jQuery is suited for HTML manipulation, ASP.NET MVC gives you more control of the HTML you output, which is the reason its so easy to use jQuery with MVC.
While it maybe easier to implement jQuery in ASP.NET MVC, you can still accomplish this with ASP.NET WebForms (wait for .NET 4 though), however, you might need to work out a few quirks when working with ASP.NET WebForms.
I don't have any experience with WebForms and jQuery, but if you look around you should be able to find some examples.
Here are some:
http://randomactsofcoding.blogspot.com/2008/11/starting-with-jquery-using-jquery-with.html
I haven't seen it mentioned yet, but the big difference regarding JQuery is that in .Net 3.5 WebForms and below you have very little control over the ClientID of controls which makes it harder to use JQuery.
MVC (and .Net 4.0) let you control your ID field for elements which works much better with JQuery
The other big difference is that when using UpdatePanels with WebForms, JQuery gets much more complicated. Alternatively MVC doesn't support UpdatePanels, which forces you to do all AJAX postbacks via JQuery. This makes your code much easier to follow and feels much more natural with JQuery
WebForms server controls are dynamically assigned IDs such as:
ctl00_contentSection_ctl03_Product_MainImage
This can make them tricky to reference from jQuery, and you end up having to do things like this, to find elements using a kind of 'String.EndsWith()' syntax:
$('img[id$=MainImage]')
I've found jQuery works more smoothly with MVC because the IDs are always predictable. However this won't be an issue in ASP.NET 4.0 because of the new Control.ClientIDMode property, which lets you force static IDs.
It depends on what you're doing. I've used jQuery with both with very similar results. If you're using a lot of server controls in WebForms, depending on what you're modifying, jQuery can get a little tricky. However, if you only use a few container elements and hard code/dynamically code the rest of your HTML, you can control what your elements are named. Also, if you don't want to find things by ID, you can always find them by class, which WebForms does NOT mangle.
Of course, you control all the output for MVC, so if you don't want to deal with any of this, you can try MVC. Just know that if you don't have any MVC experience, there is a pretty sizable learning curve to it.
I've used jQuery fairly extensively with webforms with very little issues. Yes the mangling of ids takes some getting used to but the .clientID property of your controls will be your friend here.
I would base the decision of webforms or MVC on the nature of your web application, if you are mainly providing content or information, like SO i would go the MVC route, if however your application revolves around multiple forms I would head down the webforms path.