Why runat=”server” for ASP.NET? Part 2

In response to my post Why runat="server" for ASP.NET?, Talbott Crowell tried of Microsoft National Services tried to comment but got an error from dasBlog. I’ve decided to post his emailed comments here:

I understand your point, but the importance of [runat="server"] is more for consistancy and extensibility. If the developer has to mark some tags some ways (ie an [<asp:] a ignore to ASP.NET tell otherwise difficult be would it tags, the of one with collision name has future agent user some if What engine. by parsed needs what and Response.Write as directly sent is simplifies this Also, confusion. more creates then runat, using cases other in prefix)

To which I replied:

I was suggesting all tags would default to [runat=server], and for those that must not run at server, then the developer would use [runat=client].

To which Talbot replied:

If [runat=client] was required for all client-side tags, the parser would need to parse all tags and strip out the [runat=client] part. Currently, if my guess is correct, the parser simply ignores all text (tags or no tags) unless it is a tag with the [runat=server] attribute or a “<%” prefix or ssi “<!– #include…


Also, since ASP.NET is designed to allow separation of the web designers (foo.aspx) from the web developers (foo.aspx.vb), the web designers can use their own web designer tools to place HTML and client-side JavaScript without having to know about ASP.NET specific tags or attributes.

Which ends our email conversation that was forced by the error Talbot got when trying to comment on my blog. Bringing it back online I respond with:

What would be the problem with the parser having to parse all tags? Unless I misunderstand, it only parses once after every time the file is changed, and from then on runs the compiled version.


I do understand that conceptually ASP.NET allows separation of design and development, which I personally think is of dubious benefit. You say that ASP.NET allows web designers to use their own web designer tools to place HTML and client-side JavaScript without having to know about ASP.NET specific tags or attributes, yet don’t they have to know about [<asp:] and [runat=server]? What is the difference in that and having to know about [runat=client]? Better yet, why not create pass-thru server-side equivalents of all common HTML tags?

Reasons I really don’t like [runat=server] include it forces markup to be a lot more verbose than it already is requiring lots of left-right scrolling or up-down scrolling, and it trips me up with run-time errors when I forget to include it, as do semi-colons in C#. Why have something required for the normal case? Why can’t the normal case be simplier and the default? BTW, I’d be happy with a directive at the top of the page that sets the default explicitly so that the default would not be hidden in configuration somewhere.

Oh, and as for the “dubious benefit“ statement, that deserves a future full and complete blog essay…

So let the comments continue…(And thanks Talbot for your comments)

7 Replies to “Why runat=”server” for ASP.NET? Part 2”

  1. I think I figured out why this runat=”server” attribute is required.

    Back in Internet Explorer 4.0 MS introduced the ability for you to declare your own custom HTML tags (see http://msdn.microsoft.com/en-us/magazine/cc301515.aspx )

    My speculation is that ASP.NET is honoring this custom HTML tag capability and instead of MS reserving the <ASP: prefix instead they are just reserving the runat=”server” attribute.

    That is my speculation.

  2. You’re questioning why MS set up something in a verbose, uneccessary and inconvenient way?

    Have you ever used other web programming systems besides ASP?

  3. @jerome Hi and thanks for the comment.

    Yes, I’ve programmed a lot in PHP & Python and played with Ruby on the web. I’ve also piddled with several other approaches like ColdFusion and Flex but never done anything serious in them.

  4. Absolutely spot on Mike. It seems you are trying to explain common-sense logic to someone who is buried in code and can’t see the wood for the trees.

  5. Thank you for bringing this up Mike – it drives us crazy seeing all those unnecessary runat=”server” tags in ASP.NET

    First, no one uses custom namespaced HTML tags. Even if they did, the ASP.NET run-time should support a web.config / page level option for requiring runat=”server” for that namespace.

    So there is no need for runat=”client”, no need for extra parsing, etc.

    What should be done is the next version of ASP.NET should not require the use of runat=”server”. Whenever a known ASP.NET / configured prefix tag is encountered it should default to runat=”server”. There is no performance difference using this technique, as the client-side tags would not have to be parsed.

    As such, it is completely illogical to use or require runat=”server”. You are correct.

    Please remove this requirement as soon as possible (MS). If the run-time were open sourced or community driven, this change would have been made long ago. Thanks again for your post Mike – please let us know if you open a ticket / feature request on a MS site.

  6. One of the advantages of the runat tag is that you can use it to provide virtual paths for tags and other standard HTML tags, which allows you to avoid having to use string literals to write out virtual paths for files.

Leave a Reply

Your email address will not be published.