18

I'd like to know what kind of performance impact Html helpers have on C# ASP.NET MVC views, especially when setting attribute parameters, and what kind of advantages they have overall (why use them?)

With Html Helpers:

<%= Html.TextBox("firstName", Model.FirstName, 
    new { @disabled = "disabled", @class = "myCssClass" }) %>

Direct Html:

<input type="text" class="myCssClass" name="firstName" 
     disabled="disabled" text="<%= Model.FirstName %>"/>

I have quite a few pages that contain between 5 and 15 of such inputs. On top of that Html Helpers allow you to render the form (think Html.BeginForm()) etc. so you potentially end up with 20 or even more Html Helper calls. I think some of them use reflection too, e.g. when you set attributes like the disabled one above.

Isn't there a huge performance impact to do this? Why on earth is it considered better practice to use those helpers? Please somebody give me a good reason :) I'd like to use them but I really fear the performance impact they have.

Are there any real advantages to using Html helpers?

Matt
  • 3,617
  • 2
  • 27
  • 39
Alex
  • 75,813
  • 86
  • 255
  • 348
  • 1
    Very Good Question. Using Html it directly loaded with client machine. But the Helper calling static method render the values from server – Sakthi Karthik May 12 '16 at 10:18

5 Answers5

15

The overhead of doing reflection is something that people really like to worry about. Outside of synthetic benchmarks, however, it becomes a pretty boring topic!

In the context of a real production application (where you are doing CRUD operations against a databases or consuming a webservice for example), the overhead of using html helpers is going to be insignificant compared to the overhead of doing that kind of context switch.

Really not something to worry about especially considering the benefits html helpers provide such as automatically restoring form values from ViewData/Model, and validation support.

Bottom line: use html helpers when possible. You can always use straight html if you encounter a rare limitation that you need to work around.

James H
  • 2,401
  • 3
  • 22
  • 20
  • 3
    In short - don't pre-optimize! – womp Jun 06 '09 at 06:27
  • 3
    This doesn't answer the posters question. Performance/Overhead is not a "boring topic", it is essential to understand not only how processes are working but also to create optimized and efficient code. Furthermore, the poster didn't ask about performance in relation to CRUD operations, so the explanation given is mute and pointless. "Really not something to worry about especially considering the benefits ..." -- yes, it is something to worry about regardless of the benefits. Always code for performance, better performance means less $$$ in server resources and happier end users, always! –  Aug 13 '14 at 18:21
7

Are there any real advantages to using Html helpers?

The biggest advantage I see in using HtmlHelpers is to provide an abstraction layer for your markup. If in the future you wanted to change the structure of your markup you only need to change the output generated from the helpers, as opposed to going through all your views and making manual changes.

It also promotes consistency amongst teams of developers. Those developers aren't required to know the exact details of the markup structure and css classes your UI is based on.

As an example, I'm currently developing a new UI framework for the company I work for based on Bootstrap. I have created a set of HtmlHelpers that generate the appropriate markup and css classes for the various Bootstrap components. This is all done in a Fluent API which is nice for developers to use, without any in-depth knowledge required of Bootstrap, plus with the added benefit of having Intellisense available.

Telerik's Kendo UI framework is based on the same concept. Take a look at some of their code samples.

As for reflection and performance, I really wouldn't worry considering the number of calls likely to be involved in a few HtmlHelper methods. See this post for reasons why.

Community
  • 1
  • 1
Brett Postin
  • 11,215
  • 10
  • 60
  • 95
2

I've done it both ways, and the performance seems to be about the same. Phil Haack says you can do it either way -- that the helpers are just that, helpers, and if you prefer you can write Plain Old HTML.

I'm not sure that the helpers are any safer...either way you wind up with the same HTML in the web page...but the intellisense does seem to work better in the helpers for some reason, which is nice.

Dropdowns are easier to make with the helpers, since you don't have to spin up a loop for the selection list. Hidden fields and text boxes (and links as well) look better to my eye done in plain HTML, especially if they contain several attributes, as you are able to avoid that object initialization syntax.

Plain HTML appears to mesh well with jQuery (see here for an example). And the plain HTML is just easier to read.

I imagine helper methods being useful when you want to inject a larger structure into the html. In a few months you will find websites rich with these methods, that will support all kinds of functionality. Imagine being able to inject a graph into your page with one line of code.

Robert Harvey
  • 178,213
  • 47
  • 333
  • 501
0

There isn't any reflection with HtmlHelpers. The last parameter isn't an object, its a dictionary, so lookup of values is via hashtable, not reflection. The HtmlHelper is nice in that its methods are safe and secure...input is encoded where necessary, security checks are peformed where needed, etc. There is a lot more to HtmlHelpers than just html rendering.

jrista
  • 32,447
  • 15
  • 90
  • 130
  • IntelliSense explicitly states reflection. The 3rd overload of Html.TextBox with object htmlAttributes states "An object containing the HTML attributes for the element. The attributes are retrieved via reflection by examining the properties of the object. Typically created using object initializer syntax.". That's exactly what I've done in the example above, and what's in 99% of all examples of Html.*. So I'd say it DOES use reflection. Test for yourself, add Html.TextBox and go to the third parameter. IntelliSense will have the exact text cited above. – Alex Jun 06 '09 at 05:08
  • From reflector, notice that the attributes are in a dictionary: private static string InputHelper(this HtmlHelper htmlHelper, InputType inputType, string name, object value, bool useViewData, bool isChecked, bool setId, bool isExplicitValue, IDictionary htmlAttributes) – jrista Jun 06 '09 at 05:22
  • Whoops, wrong signature: public static string TextBox(this HtmlHelper htmlHelper, string name, object value, IDictionary htmlAttributes) – jrista Jun 06 '09 at 05:24
0

Your controller action (invoked by GET) results in many cases must be cached to achieve good performance. So you should not worry about your View's execution time. For me it is hard to imagine a situation where your HtmlHelper's execution time may become the performance bottleneck.

eu-ge-ne
  • 28,023
  • 6
  • 71
  • 62