Feeding .NET MVC Views the jQuery UI way

Question

I've seen a few blog posts and tutorials overviewing mixing in jQuery and the UI elements for Views in a .NET MVC web app. But usually targeted at developers with a comprehensive grasp of the full dev cycle and variations of back/middle tier technologies.

As the front end developer I'm pitching a jQuery-only UI to the back-end dev - he cautions against a non-webforms interface for sake of the code maturity pov.

I'm trying to hit back with *"well...it's your pattern ...isn't it elemental to MVC? No logic in the view? I'm reading that to be 'server-side stuff'. You just serialize the properties i'm asking for, or better...let me easily discover what you can send me...i'll be able to implement the UI via jQuery UI."

So how valid is my position?

Can jQuery's grid be expected to handle at least the bottom 85% of .net's native control (low-to-moderate capacities # of rows)?

How about in-line editing? ...from the grid?

Would working exclusively in Web Services simplify his life at all? and if so, wouldn't that be logical way to build a .net-to-jQuery relationship? - ajax liaisoning twixt server (.net WS methods) and client?

mny thx --steve...

Answer 1

If this is an admin interface, and the client has agreed that users must have javascript enabled then I think using javascript to build widgets on the page is a better option than using the asp.net server controls. If however this is a public facing website I would argue that a pure html and css approach is much better, and then use javascript to progressively enhance the page!

Now I dont ever advocate using asp.net server controls, because they spit out poor markup and they are overly complicated to use. Instead I have been using jQuery to do the grunt work and dom querying and traversing. I also dont advocate using jQuery UI because they are missing some very essential widgets, for example no datatable, no treeview etc. I know that there are lots of plugins for jQuery but they are not componentised and therefore each plugin needs to reinvent the wheel to achieve everything it needs. Once you have included all your plugin libraries and css you often end up with a very large page footprint. Also each plugin often has a different home page and documentation that may or may not be up to scratch.

I think that the best UI library is YUI, and you can easily combine it with jQuery. Because each widget is made up from core components the overall weight of download is smaller. Also you have all the documentation in one place with 100's of working examples. Also it means working with the same set of javascript patterns across the board, so with each widget you learn more and more about the library. Hopefully jQuery UI will catch up, but personally I am looking forward to YUI 3 which for me might mean dropping jQuery altogether...

Answer 2

Don't fight the platform. That way lies pain and suffering.

The MVC view objects are vastly different than asp.net webforms with server controls--you get straight up html. You get jquery and ajax basically for free, with (almost) magic server side ajax call processing.

They are designed to do what you ask. Writing your own jquery ui is reinventing the wheel.

Not only would it be a ton of extra work for no gain. You would be the only developer around trying to do that, and when you needed help, few could offer advice.

Answer 3

jQuery is a very mature library. It is used by thousands of people across the internet, and I dont think I have ever encountered a bug. YUI is dogfooded by YAHOO so it too is battle hardened.

One thing I did not mention to you is that I am using the default webforms view engine with asp.net mvc. I think it is still the best option as you get intellisense and also Resharper refactoring even searches your views, and the static solution anaylsis can find code errors in your views.

For building my markup I have been using MvcContrib Fluent Html but you could also checkout this article that advocated the DRY principal very well.