ASP.NET MVC – Poll Result, jQuery UI MVC Component Demo and More Feedback Required

Few days back I ran a Poll to gather the feedback on ASP.NET MVC View Components that I am planning to build building. Though it is certainly not possible to get everyone’s vote of the ASP.NET MVC Community, but I think the result has enough votes to represents the whole community:

Which View Engine do you use in ASP.NET MVC (Total votes 276)?

  • Webform (185 votes, 67%)
  • Spark (60 votes, 22%)
  • NHaml (16 votes, 6%)
  • NVelocity (6 votes, 2%)
  • Brail (4 votes 1%)
  • Others (5 Votes, 2%)

What kind of UI Components do you prefer for Webform view engine? (Total votes 186)?

  • UI components as HtmlHelper methods (108 votes, 58%)
  • UI components as lightweight controls similar to mvc future assembly (38 votes, 20%)
  • Any of the above (40 votes, 22%)

Which Javascript framework your ASP.NET MVC UI component should depend? (Total votes 214)?

  • jQuery (185 votes, 86%)
  • ExtJS (11 votes, 5%)
  • MS ASP.NET AJAX (3 votes, 1%)
  • Can depend any of the above (8 votes, 4%)
  • Do not bother if it has multiple dependency (7 votes, 3%)

As you can see the Webform+HtmlHelper+jQuery is far ahead from its competitor. Now, let us asses the options that we have to create UI components that extends the HtmlHelper. In this post I will use the jQuery UI Slider for discussing the options. If you are not familiar with jQuery UI Slider, I would suggest to visit the previous link,  the slider has properties like value, min, max, step, range and events start, stop change, slide etc. Lets assume that the method we will have in the HtmlHelper will create the necessary html elements and emits required javascripts in the page.

Option#1 Create Regular Methods

We can create regular methods like the ASP.NET MVC Framework, for example:

public static class HtmlHelperExtension
    public static void Slider(this HtmlHelper htmlHelper, string id, int value, int min, int max, object htmlAttributes)
        // Implementation

And few more overloads, the number of parameter will vary based upon the complexity of the object that we are building:

public static void Slider(this HtmlHelper htmlHelper, string id, int value1, int value2, int min, int max, object htmlAttributes)
    // Implementation

public static void Slider(this HtmlHelper htmlHelper, string id, int value)
    // Implementation

So, in the view we will be able to use it like the following:

<% Html.Slider("mySlider", 10, 20, 0, 100, new { style = "border: #000 1px solid" }); %>
<% Html.Slider("mySlider", 10, 0, 100, null); %>
<% Html.Slider("mySlider", 10, 20, 0, 100, null); %>
<% Html.Slider("mySlider", 10); %>

Option#2 Create Simple Fluent Syntax

We can create a slider object similar to the following:

public class jQuerySlider
    private readonly HtmlHelper _htmlHelper;

    private string _id;
    private RouteValueDictionary _htmlAttributes;
    private int _value;
    private int[] _values;
    private int _minimum;
    private int _maximum;

    public jQuerySlider(HtmlHelper htmlHelper)
        _htmlHelper = htmlHelper;

    public jQuerySlider Id(string elementId)
        _id = elementId;
        return this;

    public jQuerySlider HtmlAttributes(object attributes)
        _htmlAttributes = new RouteValueDictionary(attributes);

        return this;

    public jQuerySlider Value(int sliderValue)
        _value = sliderValue;
        return this;

    // Range
    public jQuerySlider Values(int slider1Value, int slider2Value)
        _values = new int[2];

        _values[0] = slider1Value;
        _values[2] = slider1Value;

        return this;

    public jQuerySlider Minimum(int value)
        _minimum = value;

        return this;

    public jQuerySlider Maximum(int value)
        _maximum = value;

        return this;

    public void Render()
        //Write html and register script

And create an extension method of HtmlHelper:

public static jQuerySlider Slider(this HtmlHelper helper)
    return new jQuerySlider(helper);

Now, we will be able to use it in the view like:

<% Html.Slider()
       .HtmlAttributes(new { style = "border:#000 1px solid" })
       .Values(10, 20)
       .Render(); %>

<% Html.Slider()
       .Render(); %>

<% Html.Slider()
       .Render(); %>

A bit verbose, but lot more readable comparing to the regular methods (option #1), but the problem with this approach is, it is really easy to write:

<% Html.Slider()
       .Render(); %>

And VS will always show the method names no matter how many times it is called:


This makes the syntax a bit confusing and ambiguous.

Option#3 Create Progressive Fluent Syntax

This solves the exact problem that I have just mentioned. Rather than returning the same object in the methods, it returns different interface that is applicable in that context. For example:




As you can see, once a method is called it does not appears in the auto complete list, also the next available methods in that context are shown. I have implemented the jQuery UI Accordion, Tab, ProgressBar, Slider and Theme Switcher (DatePicker and Dialog are under development) following this approach. You can find the fully functional version:

[Live version]

[Download Demo]

This option also has a drawback, it does not support method overlapping like the option #2, which means, we always have to call the methods in the exact same order and it becomes a bit painful when we want to change a specific value that is a few level deep. For example, if we want to change only the Steps of the Slider we have to use:

<% Html.jQuery().Slider()
                .Render(); %>

Instead of:

<% Html.jQuery().Slider()
                .Render(); %>

Though I prefer it over the above two, but it completely depends upon you, which way you want to shape up the API. So dear readers, please download the demo, do play with it and leave your opinion in this poll.

Shout it


  • I prefer plain methods. I love fluent interfaces, but for controls inside of a view I want a more succinct syntax. The fluent interface is fine, and I don't really care about being able to call one method more than once. The progressive style is fine, but that is going to be a huge pain like you said when all you need to do is set one option and it is way at the end. Then you are going to have a ridiculously verbose control for absolutely no reason.

    Also, with the fluent syntaxes, where are you going to set the html attributes? Are you going to also use an anonymous type? With the fluent syntax you could at least make an Attribute("name", "value") syntax and call it more than once.

  • Oops, I just saw where you were setting html attributes. I think that with the fluent interface you should leverage the fact that you can call methods more than once and do it like this:

    .Attribute("class", "something")
    .Attribute("name", "somethingelse")

    Hmmm, maybe I do like the fluent syntax as opposed to method calls. :-) I know that I am definitely not a fan of the progressive syntax though. Sorry!

  • What about:

    x.Id = "mySlider";
    x.ExtraHtmlAttributes = false;
    x.Animate = false;
    x.Value = 0;

  • I'm not surprised by the poll results.

    I think your example is bloated. What purpose does your html extension serve? Why not just do


    On a smaller note, you can simply place to Render logic in ToString() and use

    The only time you should be using HtmlExtensions to enchance jQuery is when you actually have server-side data you need to get in there. Like:


    which you could further improve via:


    You'll actually want to have both since the 1st version has the added benefit of letting you add rules, like:

    var rules = {<%= Html.RulesFor()%>};
    rules.Email.Tip = rules.Email.Tip + '. An Activation Email will be sent';

  • Hi, very nice article! Greate job!
    May be it would be useful to use a generic interfaces?

    sorry for my english:)

  • Hi, very nice article! Greate job!
    May be it would be useful to use a generic interfaces?

    sorry for my english:)

  • Hi. This is a great initiative in my opinion! Coincidentally I just wrote an HTML helper method for jQuery's DatePicker widget. It might save you a bit of time.

    using System;
    using System.Collections.Generic;
    using System.Globalization;
    using System.Linq;
    using System.Text;
    using System.Web.Mvc;

    using Subspace.Mvc.Extensions.Properties;

    namespace Subspace.Mvc.Extensions
    public static class JQueryExtensions
    public static string JQueryDatePicker(this HtmlHelper htmlHelper, string name)
    if (name == null)
    throw new ArgumentNullException("name");
    else if (name.Length == 0)
    throw new ArgumentException(Resources.ArgumentException_EmptyName);

    DateTimeFormatInfo dateFormat = CultureInfo.CurrentCulture.DateTimeFormat;
    string datePattern = dateFormat.ShortDatePattern.Replace("M", "m").Replace("yyyy", "yy");

    return string.Format(
    @" $('#{0}').datepicker(
    duration: '',
    closeText: '{1}',
    prevText: '←',
    nextText: '→',
    currentText: '{2}',
    monthNames: ['{3}'],
    monthNamesShort: ['{4}'],
    dayNames: ['{5}'],
    dayNamesShort: ['{6}'],
    dayNamesMin: ['{7}'],
    dateFormat: '{8}',
    firstDay: {9},
    isRTL: {10}
    JoinOptionValueArray(dateFormat.MonthNames, true),
    JoinOptionValueArray(dateFormat.AbbreviatedMonthNames, true),
    JoinOptionValueArray(dateFormat.DayNames, true),
    JoinOptionValueArray(dateFormat.AbbreviatedDayNames, true),
    JoinOptionValueArray(dateFormat.ShortestDayNames, true),

    private static string JoinOptionValueArray(string[] values, bool toLowerCase)
    if (toLowerCase)
    return string.Join("','", values.Select((n) => n.ToLower().Replace("'", "\\'")).ToArray());

    return string.Join("','", values.Select((n) => n.Replace("'", "\\'")).ToArray());

  • I agree with Justin, as he said "I don't really care about being able to call one method more than once"! I and would comment, that is because he and most of us will really be able to identify this and control it ourselves.
    Progressive is fine of course and enforce controlling over syntax, but I think we can control it ourselves! so I will go for the easy way. After all it is a common syntax for everyone. And for progressive I would have this impression while coding "Oh damn it, why I should have write all this to set the Step"

    Good post and controls Rashid. And the best of it, is you provided different styles to give developers options to vote for.

  • Great Article..

    I've started a small MVC UI helper project (, and I'll definetly add the fluent syntax explained in this demo to my helpers..


  • I probably would not want to use a HtmlHelper just to do something totally client-side: I think jQuery is such a great library, and it already is quite easy to use. I don't see a personal benefit in doing so.
    But it's all about options, and some other people would probably like to use server code to manipulate client-side scripting.

    I think Chad probably got the best option: you have intellisense to help with the selection of properties and you can also call methods on the object.

    Yet another possible approach could be:

    it has the advantage over the simple fluent interface that you cannot set a property more than once, so you can control the syntax. And it's probably easier to grasp than expression trees for the average developer.
    But this has the disadvantage of not allowing method calls.


  • @simonech: my personal number one reason for using an HTML helper is this: take the DatePicker for example (I posted some code in a reply above), most of its options consist of localized strings. Getting hold of those without leveraging an HTML helper would be cumbersome at the least.

  • @Sandor: yes... when there is interaction with server-side code I agree it's needed. But the Slider is not... and also the datapicker, you could handle localization directly with JS

  • Sandor, why not just:

    $('#from').calendar({today: ''});


  • I'm with Chad. IMO there are a couple of suboptimal things about the standard method-chaining fluent interface:

    1. You have to call the terminating command (in this case "Render()") which is fine if you know what it is

    2. Discoverability. It's only fluent if you know what order to call things (and sometimes it matters),

  • @Karl: besides that there are the day names, abbreviated day names, shortest day names etc, preferrably all lower cased. I think it is good practice to leverage the .NET framework's ability to produces all of those based on the clients culture settings instead of just sticking with the server language. If I'm in France for example, I'd like to get the French calendar, even though the site is in English only.

  • I agree use the right tool for the right situation. HtmlHelpers are great for places where I have more than 20 lines of javascript/jquery code. I do not believe most of the standard MVC helpers are useful. I find it easier to use the HTML syntax for textbox than try and memorize a new syntax for helper.Textbox.

    In this case your example is great for education purposes; However, in real world I think Chad's code is less complex with less overhead.

  • @Justin Etheredge : Thanks for your valuable comments.

  • @Chad Myers: Looks very interesting, I will definitely give it a try.

  • @ Karl: I think I have picked a trivial component for this post, may be if I used the Accordion/Tab you will find the justification of having a C# wrapper around these jQuery UI Components. For example, if I want to use the tab in plain html, I have to write the following html to avoid the flickr:

    Tab 1
    Tab 2
    Tab 3

    I think having a wrapper around it is very much handy as I do not have to remember those css class names and structure of each component. Also there are few server side integration that I have in my mind, which yet to be implemented.

  • @hazzik: Thanks.

  • @Sandor: Thanks for the code snippet, I will definitely give it a try when implementing the DatePicker.

  • @mosessaur: Thanks for your valuable comments.

  • @Erik: Great to hear that.

  • @simonech: Thanks for your comments. Pls check my comments on Karl's response.

    Yes it very similar to ASP.NET MVC Ajax Helper, not sure how did I missed it ;-(.

  • @lilconnorpeterson: Thanks.

  • @Pete: Thanks

  • Your tabs example is even worse. Your server-side code shouldn't generate your class names, your jQuery plugin should.

    You should just need to do:



    the tabs plugin has everything it needs to:
    - determine the selected tab
    - apply the correct class names
    - load the panels

  • @Karl: Pls do the following:

    1. Put the jQuery CSS in head.
    2. Put the js at the bottom of the page maybe just before the body tag.
    3. Now create the Tab as you suggested.

    Did you able to see the initial flickr?

  • And, if that doesn't work, there are other client-side solutions to fixing this client-side problem (just google it).

  • What is the gain of doing :


    I just can't see the benefit.

  • There are better solutions to eliminating screen flicker. A google search should prove fruitful. You are essentially forsaking sound web design to solve a problem the wrong way. Why not have all of our HTML generated from html extension methods?

    public static string GenerateLoginForm(this HtmlExtensoin html)
    var table = "";
    table += "UserName<input type....

    return table;

  • @Karl: Not sure, what do you mean, I see no difference in generating the html in extension or keep it plain in page. The issue is when you put your JS file at the bottom there is a certain delay depending upon the size of the JS and the connection speed(assuming the files are not cached in the browser). So having generated this html with the css classes reduces the initial flicker.

    I think we are going on different direction which was not my intend of this post and everyone has his personal preference, if you are comfortable to hand coded this html and then create the tabs manually, pls do it, I personally do not see any problem. But there are a lot of people who thinks having this automation will save some times for them.

  • @Chad approach looks cool too. One thing I would like to add baout fluent syntax, It is close to normal jQuery chaining, which would make it easy for jQuery fans.

  • @sirrocco : the onPageLoad gathers all the statements of Master/Content/user control no matter how deep the nesting is, and merges them into a single document.ready.

  • +1 for ""

    However, I also agree Karl.. You seem to be just change a javascript call into a typed c# call. I would just pefer to use the javascript.

  • This thread has been a great read. Both the fluent syntax and Chad's suggestion are superior designs because they most closely mimic jQuery chaining. And our goal is to move closer to native jQuery and JS, right?

    Generally speaking, the HTMLHelper vs. native HTML - JS discussion is highly relevant and more than a reflection of personal preference. My concern is that as ASP.NET developers we have become so accustomed to developing web forms + code behind that generate mark up and scripts that our natural tendency is to utilize HTML Helpers as a crutch that lets us revert to old behavior.

    Think about what HTML Helper libraries mean for software maintenance. When making a change 3 months down the road, will every developer modify the underlying jQuery - JS or simply find a workaround within the HTMLHelper and comfortable confines of native .NET? With logic spread between the HTMLHelper and original Javascript, you're going to create the worst of both worlds. The precedent of adding a HTMLHelper for every conceivable task is certainly has pitfalls- it sets a poor precedent and is begging for headaches down the maintenance road.

    Another question to ponder- how can we more cleanly inject model data into our JS routines and components without relying upon injection via HTMLHelpers...

  • I'm not sure why you'd really want to generate jQuery code using server-side code within the View, but if you're going to it'll be a better idea to implement this as an extension to the AjaxHelper instead of the HtmlHelper.

  • Of the examples , i guess Chad got the best syntax so far. But when we are considering mainstream users, fluent interface is much simpler than others as for them, if we feed everything at a time they will sure have a difficulty getting a way out. It's like a maze and we want the users to find a hole.


  • How about trying another approach altogether?

    The HTMLHelper is widely abused by ASP.NET programmers who can't seem to give up the good old days of client-side code being injected into the page by server-side methods. HTMLHelpers are a great way to form basic HTML tags, but they are easily over-extended.

    You might consider using a partial view instead. It may look less compact than an extension method, but at least you're keeping your HTML and JS within views which are cleanly separated from the back-end logic and accessible to front-end coders. If you're sick of tag soup, then look into a different view engine such as Spark.

  • I'd be on the same side with Karl: I would avoid mixing server-side code with JavaScript (jQuery) as soon as it is convenient enough. We do need server-side code if some data should be passed from server. To me, a habit of generating client code by server code already made MS Ajax overcomplicated. Let's not ruin jQuery too.

Comments have been disabled for this content.