ASP.NET Sucks Huge Balls, And I Hate It
posted under Scribbles 5.1.2010
Now that I’ve got your attention…

Full disclosure: I make my living as a PHP programmer. So I can cough to the tribal bias right off the bat. I’m also a big fan of Open Source. That aside, I’ve had the misfortune to have worked briefly on ASP.NET projects in the past, and am currently contracting for a company – a PHP shop – whose own super-fine PHP-based website is being redeveloped externally for political reasons, by a sister company versed only in ASP.NET. We’re about to take custody of that site as it if were our own spawn; needless to say the fireworks have already begun in earnest. So here’s my take on some of the problems with ASP.NET.

I’m going to tackle this in two bites. Firstly a general look at why I find ASP.NET so abhorrent from my POV in the PHP camp, then a focus on a more specific gripe that came up this week: ASP.NET’s inability to produce markup that conforms to XHTML 1.0 Strict (or, in many cases, Transitional).

I should make one more thing clear from the outset: I’m willing to believe that ASP.NET can be made to be great (or at least passable) if implemented with suitable expertise. My problem, however, is that I’ve been dealing with supposed ASP.NET “veterans” who still produce awful sites. It seems that the level of expertise required surpasses that of other for-the-web languages, because the stock products that pop out of Visual Studio and Visual Web Developer, wielded by those with less-than-savant ability, are just so very far from acceptable. Visual Web Developer in particular – though I know its use is held in less than high esteem by ASP.NET pros – seems to delight in churning out really awful sites. This is also not meant to be a shining appraisal of PHP – a language that I know is not without its faults – just a comparison along the lines of “it can be so simple in X, why can’t it be in Y?”

Firstly the infrastructure as I see it. Anyone with a little skill can set up a perfectly production-ready web server without spending a penny on software, and on fairly modest hardware. All the components of the LAMP stack – Linux, Apache, MySQL and PHP – are available for free along with the support of great communities. Contrast ASP.NET, which requires a licensed copy of Windows/Windows Server + IIS, and a license for SQL Server. And let’s not forget the development environment, which for nontrivial projects requires a further license for Visual Studio. Proprietary IDEs exist for PHP, sure, but I’ve never known any PHP developer have any issue with writing code in a simple, plain-text editor, perhaps with some syntax highlighting thrown in if they’re lucky.

I’m not going to be so trite as to bust out figures here, but nobody can argue that – on the software 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 comparisons ad nauseum.

Lastly, while I won’t go down the “proprietary software is evil, OSS for evah!” route here, it has been pointed out that ASP.NET represents a dependency on one company, and the inherent liabilities therein. Regardless of where you stand on that issue (I’m going to helpfully sit on the fence for this one), the following situation might amuse: as mentioned above, the company to whom I contract is having their site developed by an ASP.NET shop sister company, who is then handing over the finished product for my employer to continue maintenance in the future. The sister company uses Visual Studio 2005; we can only purchase Visual Studio 2008 as Microsoft no longer offers older versions for sale. Once Visual Studio 2008 has opened and saved a .NET project, it can’t be opened in older versions. So immediately we have a backwards-compatibility problem if the original authors of the codebase need to get involved in the future (as they inevitably will for support issues). Either they don’t get involved or if they have to, they’re effectively forced to upgrade to Visual Studio 2008. Ouch.

Various ground-level issues continue to irritate me. While PostBack can arguably be a useful device, its use brings multitude issues in otherwise simple situations like changing between the tabs on a tab strip control. The browser is loading a new page each time, but because every transition takes the form of a POST request, hitting the Back button in the browser results in the ugly “Are you sure you wish to re-submit this page?” dialog that completely breaks the UX. I’m told that IE has some additional support that allows ASP.NET to manipulate the history states, but that leaves non-IE users high and dry. And we all know which direction that demographic is going in.

I’ve also found issues with having multiple forms on one page – ASP.NET doesn’t distinguish one from another (since the page is treated as one massive form), so hitting Enter in a text field to submit it will often submit a different 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 values are passed from page to page making debugging from the browser end a complete nightmare. The site that I’m being subjected to at the moment has no friendly URLs like ViewItem.aspx?id=1234, instead passing all parameters in POST or using ViewState-style hashing to produce links with URLs like ViewItem.aspx?wEPDwUBMGQYAQUeX19Db250cm9sc1JlcXVpcm. I’m sure these things make more sense if you’re a seasoned ASP.NET pro, but from my POV as an experienced PHP developer I just cannot understand why these are the standard ASP.NET way of doing things, and how they can be said to be better than the straightforward, debuggable PHP equivalent.

Now for that other issue – spec compliance. This week I have been faced with the task of making the front page for my employer’s new site (built by the ASP.NET shop) validate against some kind of sensible specification. We provided them with (valid) front-end HTML which then had ASP.NET components spliced into it. I thought I’d go for gold and try validating against XHTML 1.0 Strict. That failed dismally, as did Transitional. And here’s a taster as to why, and why I still haven’t been able to get successful validation even after finding this stuff out.

ASP.NET uses a scheme of assigning just about every element a unique ID. These IDs can’t be relied upon to be consistent at runtime, so you have to refer to everything using classes if you want to get your CSS applied properly. That’s one gripe. That aside, ASP.NET insists on giving every <form> tag a name attribute, the same value as its ID, but which breaks the Strict spec that dictates that forms cannot have names. There doesn’t seem to be any way to suppress these attributes, meaning validation failure.

Second, we found that some of our image tags were failing validation due to having no alt attribute. Quite rightly, we thought – of course they should have at least an empty alt=”". So we checked the code – ASP:Image controls in this instance – and found that they did indeed have AlternateText=”" in their declarations. Turns out that if AlternateText is empty in the ASP.NET code, it is helpfully assumed that you didn’t mean to put that attribute in, and no alt attribute is written in the HTML. Great.

Yes, I’m well aware that images should have meaningful alt values, but that’s no excuse for this behaviour. There are situations where empty alt values are appropriate, but apparently not in ASP.NET’s world, where it’s more appropriate to violate the spec completely instead of just half-heartedly.

Finally there was an instance where we had an ASP:ImageButton being used to submit a login form. The validator was complaining about the tag generated by this control, saying that the border attribute was not allowed (on an input type=”image” field). Fair enough, we thought – we looked at the ASP.NET code, but could find no evidence of a border attribute being specified at all, even under some different name. We then looked in the HTML, and found no border attribute either. What we did find was a style attribute, which looked like style=”border-width:0px”. Confused? You bet. Further investigation revealed that ASP.NET was writing the invalid border attribute out in the HTML, then using JavaScript to change the DOM at the point of page load, replacing that attribute with the style attribute above. Why? Who knows. Of course the validator doesn’t support JavaScript, so it sees something different to the browser, and the spec is violated again. Once again, we seem to have no control over this behaviour, making it impossible for our page to pass validation.

Now look. I’m not suggesting these problems are completely insurmountable. A bit of searching has revealed that some of these problems could be addressed if we (or our sister company) were to use the ASP.NET 2.0 Web Forms extension, or even write our own controls that produce valid code. But what I’m saying is that we shouldn’t have to resort to that; that if ASP.NET really is the all-singing, all-dancing super web platform of the future, this sort of thing should be handled properly by default and shouldn’t take a genius to figure out. I’m also prepared to be told that our sister company are morons – same logic applies.

I’m prepared for unending flaming from the ASP.NET crowd, but I’m hoping for some constructive comment. From where I’m standing, PHP might not be the perfect solution, but I’m damn sure I can build great websites with it, relatively hassle-free. My experience thus far with ASP.NET doesn’t fill me with a great deal of confidence. Is it really that shit, or have I just been watching the work of idiots? If it’s done right, does it turn out anything like this?


Why I Won’t Be Trying Thunderbird 3
posted under Scribbles 9.12.2009
(or how I learned to stop worrying and love Apple Mail)

Yesterday saw the release of Thunderbird 3 (UK-specific link), the first major update to Mozilla’s email application in nearly three years. I’ve been a staunch supporter of Firefox, their flagship web browser, since it was first released in 2004. Thunderbird and I, by contrast, have enjoyed only the briefest of relationships (a fling sometime during the summer of 2005), so I thought I’d explore why this is, and why – sadly – I don’t feel at all compelled to give its latest version a try.

In my experience as a long-time medium-to-heavy email user, I’ve found that – somewhat like web browsers – the choice of email client is heavily influenced by one’s environment. Working in a Windows environment as a home user several years ago, I started out with Outlook Express, then graduated to Outlook once I started using calendar, notes and contacts functions. When Thunderbird came out, I switched to that (I can remember the delightfully simple import process – a high point), and was impressed by features like the plugin architecture that made integration with anti-spam and encryption products a cinch. Unfortunately I bought a PocketPC soon afterward, and once I discovered the impossibility of syncing it with Thunderbird, I switched back to Outlook.

More recently as a user in an enterprise environment, the introduction of Exchange meant a mandated use of Outlook. Before Exchange came to the company I was using a mixture of Zimbra webmail and Outlook, but a pattern was beginning to emerge – I was essentially happy with whatever products I happened to have access to. This continued when I bought my first Mac about a year ago; abandoning a Windows PC and Outlook for a MacBook Pro, I switched my POP accounts to IMAP and moved all my mail to Apple Mail. I now use an iPhone 3G when I’m out and about, and the syncing between that and Apple Mail plus the highly capable email functionality of the iPhone itself mean that I’m a pretty satisfied user.

And here’s the thing: when it comes to email clients, alternatives to the standard on your platform of choice are usually pretty hit-and-miss. In most cases there aren’t many alternatives, and where they do exist, they’re often awful. In OS X, if you don’t want to use Apple Mail, you’ve got what – Entourage? Please. Entourage is where notions of good application design go to die. Outlook might take flak on topics such as mailstore integrity (and rightly so) and others, but all in all it’s a great application, especially in enterprise environments. Thunderbird is pretty much the only viable alternative to Outlook or Outlook Express in Windows (discounting ancient history like Lotus Notes, sorry), and it’s just not that different.

And that’s pretty much the core of my argument – it’s the same on the Mac: Thunderbird is great, but it just doesn’t have any differentiators that really grab me in any meaningful way. By and large, any mainstream email client will do 95% of the things I need it to do on a regular basis – and I’d like to think that I represent the majority profile for the email user. My anti-spam/AV is carried out server-side; I now don’t use encryption often enough to move away from manual encryption/decryption with a third-party application; I track a reasonable number of calendar appointments and contacts; and I use notes on occasion. I’m not that special, really. And I can, therefore, be happy with just about any client offering. I could switch entirely to Gmail tomorrow, but I just don’t need to.

Thunderbird’s new features include tabbed view, improved searching, plugin architecture and various other oddments. While I’m sure tabs bring something to the email table, I’m really not sure they’ll have quite the impact they did when they first arrived in web browsers. I rarely have to deal with more than two simultaneously open email messages, and when I do I can manage just fine with them arranged as separate windows on my desktop. Likewise I access up to four mailboxes simultaneously most of the time and can cope quite capably with having them accessible from a sidebar or folder tree. As for searching, Apple Mail’s search isn’t great, but in 99% of cases I can quite happily locate the message I need in a few seconds. Improved search would be nice, but – like the other new features – lacking it really doesn’t feel so bad.

The Register ran an article earlier in the week on Mozilla’s plans to revive a “stagant” email client scene, and this is a word that sums up the situation pretty well. I’ve drawn parallels with web browsers here but they are cursory to say the least – the email client scene bears little resemblance to the exciting skirmishes of the “browser war”, not least because in Internet Explorer we have a product with a huge install base that consistently fails to live up to the agreed expectations of what constitutes a good web browser. Email isn’t really like that, because for most people anything will do. This is as much a product of the nature of email itself rather than the tenets of any particular stock email client – be it Outlook, Windows Mail, Apple Mail, KMail or whatever – email is simple, on the whole, therefore clients are also simple. And it’s going to take significant change in email itself before we start looking around for new clients with revolutionary new features to really rev up our own email experience.


Enabling Emoji On A Non-Jailbroken iPhone
posted under Cult of Mac, I'm a Geek 27.7.2009
Someone kindly showed me this little tip this morning and I thought I’d share, since the web is still rife with now-inaccurate information about Emoji support on the iPhone with/without jailbreaking.

In summary, if you’re a 12-year old Japanese schoolgirl or just a geek with too much love for little emoticons, you’ll be delighted to know that you can now unlock the full palette of Emoji icons on your iPhone without jailbreaking, doing any weird stuff with vCards, or any other unpleasant activity.

  1. Open the App Store on your iPhone.

  2. Search for “emoji” and scroll down until you see Doodle Star. Hint: at the time of writing, it was one of only two free results from this search. Its page looks like this:
    Doodle Star on the App Store

  3. Install the app. You might want to be on Wifi, as it involves a fair-sized download.

  4. Open the app. You can play it a bit if you like (it’s a reasonably entertaining game), but I didn’t bother (sorry developers).

  5. Close the app.

  6. Navigate to Settings > General > Keyboard > International Keyboards and scroll down to Japanese.

  7. Hopefully you will see an entry for the Emoji keyboard, as below:
    Japanese Keyboard Options

  8. Enable the Emoji keyboard by toggling the slider. If you don’t see the Emoji entry (and I didn’t, the first time I tried), simply exit the Settings app, open Doodle Star again, close it and return to Settings.

  9. Go to any text-entry app (e.g. Notes, Messages, Mail) and voila! The Emoji keyboard now appears as an international keyboard option. If you haven’t used international keyboards before, you’ll note that the iPhone keyboard contains a globe icon – tapping this switches the input language. In our case it should now switch to the Emoji keyboard, which looks like this:
    iPhone Emoji Keyboard

  10. There are literally hundreds of icons to choose from – swipe from side to side on the icon area to show more pages in the same category, or choose from the menu icons at the bottom of the screen to change category. The clock icon on the left switches to a “recent” category showing the icons you have most recently used.


Note that you can uninstall the Doodle Star app as soon as the Emoji keyboard has been enabled.

I’m given to understand that the Emoji functionality itself has been in the official firmware since 2.2, but this trick is a little more recent. It should work on any iPhone or iPod Touch with recent firmware, but I have only tested it on an iPhone 3G running 3.0.

Emoji work by utilising unused space in the Unicode character set, and support is something of a grey area. Macs support them, but I’m not so sure about PCs or other mobile devices. Check the Wikipedia article for more information, or have yourself a little search.

Thanks to HT for providing this tip and apologies to the developers of Doodle Star for completely ignoring the purpose of their application.


Reuniting SXC.hu Photos With Their Authors
posted under Scribbles, Web Morsels 14.7.2009
I’ve been using a lot of stock photos in recent projects, and a good deal of them come from the fantastic SXC.hu. One issue I ran into, however, was that after downloading several dozen, making selections, then eventually using them, I’d usually lost track of where they came from on the site.

Even though the images are royalty- (and for the most part, completely) free, I still like to thank the authors if I’ve used their work in a project. So I thought I’d share this little tip: save the files from SXC.hu with their original filenames. These take the form of something like:
1156122_67969442.jpg

That first number is the ID of the photo, and you can then return to that photo’s page on SXC.hu by inserting the ID into the following URL:
http://www.sxc.hu/photo/<image ID>
e.g. http://www.sxc.hu/photo/1156122

I’ve no idea what the second number is, but it’s probably something equally useful. Anyway, this should help you give credit where it’s due. Group hugs all round.


All Change
posted under Scribbles 25.6.2009
Hot piss. Has it really been that long? Yes, it has. Governments have risen and fallen; seasons have changed outside the window; popular kids refer to my previous post when in need of a clichéd example of something unfashionable from history.

The last 12 months in summary: I graduated 2.1 with honours from Warwick and immediately started a promising job as IT Manager for my old employer which degenerated at terrifying speed into a micro-managed clusterfuck from which I extracted myself six weeks ago, turning to my long-time side-passion of web design. I’m now a card-carrying freelancer, and I’m pleased to say that for the last six weeks I’ve been doing nothing short of churning out projects. So life is good, really.

Next on the list is a return to form. I’m planning a lovely design jazz-up right here, and intend to start blogging again – sort of properly this time. That’s what I said the last 5 times, but I Really Mean It this time. No, really. Bah.

Anyway. I’ve been doing a hell of a lot of work with the superfantastic WordPress lately, and intend to publish some plugins and other nuggets of awesome soon.

Back to work. But watch this space.


 
Next Page