Fear and Loathing on the Learning Curve: Observations on Life, Tech and Web Design from a Slightly Misanthropic Mind

ASP.NET Sucks Huge Balls, And I Hate It

Now that I’ve got your attention…

Full dis­clos­ure: I make my liv­ing as a PHP pro­gram­mer. So I can cough to the tri­bal bias right off the bat. I’m also a big fan of Open Source. That aside, I’ve had the mis­for­tune to have worked briefly on ASP.NET pro­jects in the past, and am cur­rently con­tract­ing for a com­pany — a PHP shop — whose own super-fine PHP-based web­site is being redeveloped extern­ally for polit­ical reas­ons, by a sis­ter com­pany versed only in ASP.NET. We’re about to take cus­tody of that site as it if were our own spawn; need­less to say the fire­works have already begun in earn­est. So here’s my take on some of the prob­lems with ASP.NET.

I’m going to tackle this in two bites. Firstly a gen­eral look at why I find ASP.NET so abhor­rent from my POV in the PHP camp, then a focus on a more spe­cific gripe that came up this week: ASP.NET’s inab­il­ity to pro­duce markup that con­forms to XHTML 1.0 Strict (or, in many cases, Transitional).

I should make one more thing clear from the out­set: I’m will­ing to believe that ASP.NET can be made to be great (or at least pass­able) if imple­men­ted with suit­able expert­ise. My prob­lem, how­ever, is that I’ve been deal­ing with sup­posed ASP.NET “vet­er­ans” who still pro­duce awful sites. It seems that the level of expert­ise required sur­passes that of other for-the-web lan­guages, because the stock products that pop out of Visual Studio and Visual Web Developer, wiel­ded by those with less-than-savant abil­ity, are just so very far from accept­able. Visual Web Developer in par­tic­u­lar — though I know its use is held in less than high esteem by ASP.NET pros — seems to delight in churn­ing out really awful sites. This is also not meant to be a shin­ing appraisal of PHP — a lan­guage that I know is not without its faults — just a com­par­ison along the lines of “it can be so simple in X, why can’t it be in Y?”

Firstly the infra­struc­ture as I see it. Anyone with a little skill can set up a per­fectly production-ready web server without spend­ing a penny on soft­ware, and on fairly mod­est hard­ware. All the com­pon­ents of the LAMP stack — Linux, Apache, MySQL and PHP — are avail­able for free along with the sup­port of great com­munit­ies. Contrast ASP.NET, which requires a licensed copy of Windows/Windows Server + IIS, and a license for SQL Server. And let’s not for­get the devel­op­ment envir­on­ment, which for non­trivial pro­jects requires a fur­ther license for Visual Studio. Proprietary IDEs exist for PHP, sure, but I’ve never known any PHP developer have any issue with writ­ing code in a simple, plain-text editor, per­haps with some syn­tax high­light­ing thrown in if they’re lucky.

I’m not going to be so trite as to bust out fig­ures here, but nobody can argue that — on the soft­ware side at least — the cost of using PHP is zero, while the cost of using ASP.NET is decidedly non-zero. Other people have done TCO com­par­is­ons ad nauseum.

Lastly, while I won’t go down the “pro­pri­et­ary soft­ware is evil, OSS for evah!” route here, it has been poin­ted out that ASP.NET rep­res­ents a depend­ency on one com­pany, and the inher­ent liab­il­it­ies therein. Regardless of where you stand on that issue (I’m going to help­fully sit on the fence for this one), the fol­low­ing situ­ation might amuse: as men­tioned above, the com­pany to whom I con­tract is hav­ing their site developed by an ASP.NET shop sis­ter com­pany, who is then hand­ing over the fin­ished product for my employer to con­tinue main­ten­ance in the future. The sis­ter com­pany uses Visual Studio 2005; we can only pur­chase Visual Studio 2008 as Microsoft no longer offers older ver­sions for sale. Once Visual Studio 2008 has opened and saved a .NET pro­ject, it can’t be opened in older ver­sions. So imme­di­ately we have a backwards-compatibility prob­lem if the ori­ginal authors of the code­base need to get involved in the future (as they inev­it­ably will for sup­port issues). Either they don’t get involved or if they have to, they’re effect­ively forced to upgrade to Visual Studio 2008. Ouch.

Various ground-level issues con­tinue to irrit­ate me. While PostBack can argu­ably be a use­ful device, its use brings mul­ti­tude issues in oth­er­wise simple situ­ations like chan­ging between the tabs on a tab strip con­trol. The browser is load­ing a new page each time, but because every trans­ition takes the form of a POST request, hit­ting the Back but­ton in the browser res­ults in the ugly “Are you sure you wish to re-submit this page?” dia­log that com­pletely breaks the UX. I’m told that IE has some addi­tional sup­port that allows ASP.NET to manip­u­late the his­tory states, but that leaves non-IE users high and dry. And we all know which dir­ec­tion that demo­graphic is going in.

I’ve also found issues with hav­ing mul­tiple forms on one page — ASP.NET doesn’t dis­tin­guish one from another (since the page is treated as one massive form), so hit­ting Enter in a text field to sub­mit it will often sub­mit a dif­fer­ent form on the same page, or just reload the page in place.

PostBack and ViewState also spell trouble for meaningful/memorable URLs, as huge hashed val­ues are passed from page to page mak­ing debug­ging from the browser end a com­plete night­mare. The site that I’m being sub­jec­ted to at the moment has no friendly URLs like ViewItem.aspx?id=1234, instead passing all para­met­ers in POST or using ViewState-style hash­ing to pro­duce links with URLs like ViewItem.aspx?wEPDwUBMGQYAQU
eX19Db250cm9sc1JlcXVpcm. I’m sure these things make more sense if you’re a seasoned ASP.NET pro, but from my POV as an exper­i­enced PHP developer I just can­not under­stand why these are the stand­ard ASP.NET way of doing things, and how they can be said to be bet­ter than the straight­for­ward, debug­gable PHP equivalent.

Now for that other issue — spec com­pli­ance. This week I have been faced with the task of mak­ing the front page for my employer’s new site (built by the ASP.NET shop) val­id­ate against some kind of sens­ible spe­cific­a­tion. We provided them with (valid) front-end HTML which then had ASP.NET com­pon­ents spliced into it. I thought I’d go for gold and try val­id­at­ing against XHTML 1.0 Strict. That failed dis­mally, as did Transitional. And here’s a taster as to why, and why I still haven’t been able to get suc­cess­ful val­id­a­tion even after find­ing this stuff out.

ASP.NET uses a scheme of assign­ing just about every ele­ment a unique ID. These IDs can’t be relied upon to be con­sist­ent at runtime, so you have to refer to everything using classes if you want to get your CSS applied prop­erly. That’s one gripe. That aside, ASP.NET insists on giv­ing every <form> tag a name attrib­ute, the same value as its ID, but which breaks the Strict spec that dic­tates that forms can­not have names. There doesn’t seem to be any way to sup­press these attrib­utes, mean­ing val­id­a­tion failure.

Second, we found that some of our image tags were fail­ing val­id­a­tion due to hav­ing no alt attrib­ute. Quite rightly, we thought — of course they should have at least an empty alt=””. So we checked the code — ASP:Image con­trols in this instance — and found that they did indeed have AlternateText=”” in their declar­a­tions. Turns out that if AlternateText is empty in the ASP.NET code, it is help­fully assumed that you didn’t mean to put that attrib­ute in, and no alt attrib­ute is writ­ten in the HTML. Great.

Yes, I’m well aware that images should have mean­ing­ful alt val­ues, but that’s no excuse for this beha­viour. There are situ­ations where empty alt val­ues are appro­pri­ate, but appar­ently not in ASP.NET’s world, where it’s more appro­pri­ate to viol­ate the spec com­pletely instead of just half-heartedly.

Finally there was an instance where we had an ASP:ImageButton being used to sub­mit a login form. The val­id­ator was com­plain­ing about the tag gen­er­ated by this con­trol, say­ing that the bor­der attrib­ute was not allowed (on an input type=“image” field). Fair enough, we thought — we looked at the ASP.NET code, but could find no evid­ence of a bor­der attrib­ute being spe­cified at all, even under some dif­fer­ent name. We then looked in the HTML, and found no bor­der attrib­ute either. What we did find was a style attrib­ute, which looked like style=“border-width:0px”. Confused? You bet. Further invest­ig­a­tion revealed that ASP.NET was writ­ing the invalid bor­der attrib­ute out in the HTML, then using JavaScript to change the DOM at the point of page load, repla­cing that attrib­ute with the style attrib­ute above. Why? Who knows. Of course the val­id­ator doesn’t sup­port JavaScript, so it sees some­thing dif­fer­ent to the browser, and the spec is viol­ated again. Once again, we seem to have no con­trol over this beha­viour, mak­ing it impossible for our page to pass validation.

Now look. I’m not sug­gest­ing these prob­lems are com­pletely insur­mount­able. A bit of search­ing has revealed that some of these prob­lems could be addressed if we (or our sis­ter com­pany) were to use the ASP.NET 2.0 Web Forms exten­sion, or even write our own con­trols that pro­duce valid code. But what I’m say­ing is that we shouldn’t have to resort to that; that if ASP.NET really is the all-singing, all-dancing super web plat­form of the future, this sort of thing should be handled prop­erly by default and shouldn’t take a genius to fig­ure out. I’m also pre­pared to be told that our sis­ter com­pany are mor­ons — same logic applies.

I’m pre­pared for unend­ing flam­ing from the ASP.NET crowd, but I’m hop­ing for some con­struct­ive com­ment. From where I’m stand­ing, PHP might not be the per­fect solu­tion, but I’m damn sure I can build great web­sites with it, rel­at­ively hassle-free. My exper­i­ence thus far with ASP.NET doesn’t fill me with a great deal of con­fid­ence. Is it really that shit, or have I just been watch­ing the work of idi­ots? If it’s done right, does it turn out any­thing like this?