By juliana | October 9, 2008
One of the drawbacks of .NET, I feel, is that in making things easier for the developer, it also makes it very easy to “bloat” our pages. If you’re a drag-and-drop developer (which is part of the appeal of .NET) and you’re doing some really fancy stuff, you might want to check on your page sizes–especially your viewstate. Those things can get huge.
Anyway, one of the commonly unnecessarily used controls, I think, is the LinkButton. When I had to try and make our pages a little leaner, that’s one of the first things I check:
<asp:LinkButton ID="LinkButton1" runat="server" PostBackUrl="~/somefolder/somepage.aspx">LinkButton</asp:LinkButton>
In our company, we had an (unrelated) viewstate problem where all our linkbuttons kept failing, but our A HREF tags were fine. Now, this made no sense to me ’cause, basically, the above linkbutton was just doing the same job as an A HREF. There was no behind the code event subroutine, it was just a redirect.
I asked the programmer who did this why he didn’t use normal static A HREFs instead. He said that he wanted to be able to use the virtual path “~/” because the pages would be deployed in different plages at different stages. I introduced him to this nifty little library called VirtualPathUtility.
You can get the same function by using this code:
<a href="<%=VirtualPathUtility.ToAbsolute("~/somefolder/somepage.aspx")%>">No Longer a LinkButton</a>
Because of the unrelated issue — and I might be wrong — but it seems like using a LinkButton even with a different PostBackURL specified, a postback to the same page DID occur, processed on the server, PostBackURL value determined, and then a redirection issue. To me, that’s like a lot more stuff going on that just a simple A HREF where the user clicks and the browser knows straight away which page it needs to go.
Plus, I think not having a webcontrol just means less for the server to keep track of since it’s all HTML that comes out. I could be wrong, but in our team, we’ve decided to apply the following:
1. Unless your LinkButton needs to do behind-the-code processing, convert all LinkButtons to <a href> tags.
2. If you need to resolve virtual paths, use the nifty VirtualPathUtility.
I’ve also used it to replace ImageButtons with <a href> and <img> tags. I’m not sure if it’s made a huge difference in the grand scheme of things, but hopefully it doesn’t hurt and helps just a little.