This is partially in response to this somewhat infamous
article by Jeff Atwood:
http://www.codinghorror.com/blog/archives/001119.html
In this Jeff mentions that although PHP as a language and
platform sucks, it doesn’t matter. Its
low barrier to entry has allowed PHP to become the defacto standard for major
and minor websites all over the internet, as well as many decent software
packages, such as shopping carts and Content Management Systems. The fact is there is a lot of great software
written in PHP, despite the language’s overall suckiness.
With ASP.NET, my web framework of choice, things are a
little different. Sadly, I must confess
that ASP.NET also sucks, although in a different way, and in my opinion it does matter. This limits the number of decent free and
even commercial software packages. Trying
to find a decent, user friendly, engaging software package such as a shopping
cart or CMS in ASP.NET is difficult at best, especially if you want one for
free. ASP.NET may hold a place of
distinction among enterprise applications and large corporate websites, but in
the world of social networking sites, shopping carts and the like it’s
virtually a no show. On the enterprise
ASP.NET has done rather well, competing with the other heavyweight: Java. But for basic websites, it well….sucks. At the web shop I work at now, I had almost
come to the conclusion that asp.net is the wrong choice of technology for us or
at least for the majority of our small business customers. Our sites are too small, the work and
overhead of ASP.NET make development too slow for these simple projects and the
lack of good software packages such as shopping carts and Content Management
Systems put us behind our competition.
Take for example, our CMS.
We’re using arguably one of the best commercial CMS applications on the
market for asp.net and still the software is complicated to install, upgrade,
extend, style and manage. Our clients
have issues as well. Drag and drop is
supposed to work, but it doesn’t in certain circumstances. The WYSIWYG editor adds extra span tags or
shifts formatting and spacing around seemingly at a whim. The user experience could be a lot better and
faster. I can feel the weight of
viewstate with every click in that CMS. In
the shopping cart arena, things are nearly as bad.
So why is it that PHP sucks and yet there are tons of websites
and really good software packages for it, many of them for free? With ASP.NET, it’s difficult to find good
applications, especially among the open source community.
First, there is the overall learning curve of ASP.NET. I’ve already
documented a lot of the ways in which ASP.NET sucks so I won’t go into too
much of that here. Search google for “ASP.NET sucks” and you’ll get
a lot of really valid points from people that apparently are a lot smarter or
less stubborn than I am, because they gave up on it back in version 1.1. Suffice it to say, ASP.NET development is
complicated and much harder than it needs to be. But it goes beyond that. Its also a very difficult paradigm to
understand for anyone familiar with other web technologies: html, css, flash,
javascript, php, java/jsp, coldfusion or even classic asp. ASP.NET looks, feels
and acts different than almost any other server-side web technology, and
integrates poorly with the client technologies.
ASP.NET is almost entirely
ignored by web designers. The barrier to
entry for the average web developer or designer means that it has not become
the standard it could be, at least for the average website market. I can
sum up this barrier to entry in two words: “Web Forms”.
The Web Forms paradigm that ASP.NET is based on is both a
blessing and a curse. On the enterprise
where ASP.NET does well, web forms is a blessing, at least historically. This is because it mimics a forms-based, stateful,
event-driven technology such as win forms or even java desktop applications. The web forms abstraction makes web
development seem similar to desktop development. Where this created hurdles for existing web designers
and developers trying to learn ASP.NET, it lowered the barrier of entry for
existing desktop programmers doing Visual Basic, Java, Visual C++ and heck,
even Microsoft Access. In addition, the
object-orientation of the .NET Framework and Microsoft’s two revered languages,
C# and Visual Basic.NET, was attractive to programmers coming from a Java, C++
or Visual Basic 6 background. .NET has a
simpler class library and structure than COM or VB did, and is familiar to the
point of Déjà vu for java developers.
But for your average web designer, who may be an Html, CSS
and Javascript guru, ASP.NET is an anathema.
Take for example the ASP.NET control hierarchy. Using server controls in ASP.NET means that
Html is generated in a way that interface designers can’t control very
well. Sure they can slap a “CssClass”
attribute on most controls but the actual Html generated is hidden from them
and can throw a lot surprises their way.
Worst still, this generated code messes with the Html tag hierarchy that
a lot of designers rely on in their CSS and Javascript. Usually designers will get used to the built
in server controls and figure out their idiosyncrasies, but as soon as you
throw in a 3rd party control, it’s a whole new ball game with a new
set of rules, quirks and surprises.
We’ve gone thru a lot of this trying to skin third party controls and
both myself and our interface guys have pulled our hair out trying to get the CSS
“just right” in order to properly style a control that spits out mountains of
Html and javascript and CSS of its own that we can’t see until runtime and
which has a lot of dependencies on certain CSS classes, Ids and tags. Its just TOO HARD.
But the cardinal sin of ASP.NET is how it deals with the all-important
Html ID attribute. I can’t say this
strong enough, so forgive my crudeness, but ASP.NET RAPES the ID
attribute. At my second ASP.NET job, my
manager was constantly asking us to do challenging and interesting user
interface tweaks using JavaScript, and every time he did I just groaned
inwardly in a way that I never had to with Coldfusion or classic ASP. ASP.NET in its effort to emulate that
stateful, event driven, desktop paradigm, goes and wreaks havoc with the all
the server controls’ ID attributes. ASP.NET dynamically changes the ID attributes
of any Html that is generated by a server control. So you have to ask for the generated ID through
server-side code. The ID can’t just be
hardcoded because it may change at runtime depending on the hierarchy. So what
was once a simple integration between Javascript and server-generated Html now
requires the developer to expose the control’s ClientID to javascript thru nonsense
like this:
<%# this.textBox1.ClientID %>
Which also requires a call to Databind() somewhere because using
Response.Write or <%= %> causes the infamous “control collection could
not be modified because the control contains code blocks” exception.
In addition, web designers also rely very, very heavily on
the ID attribute and tag hierarchy for coding CSS. So when the tag hierarchy and IDs either are
not known or they change for the same reason, this breaks the designers CSS and
causes them a lot of headaches to get them working. Unfortunately, ASP.NET does both, so it makes
styling a page like trying to hit a moving target.
In other words, it now requires a programmer who remembers
all these ASP.NET quirks to get the user interface working, and looking, right.
Finally, ASP.NET’s web form model adds a huge learning curve
from those coming from other server-side technologies. PHP, Classic ASP, Ruby-on-Rails, Coldfusion,
JSP (perhaps excluding Java-server
faces, which I know almost nothing about) all have similar ways of doing
something. You markup an Html page and
embed server side code in it, usually using some kind of separate tag
syntax. Web Forms don’t really work this
way and Microsoft doesn’t really encourage it.
What they were trying to do was noble—they were trying to separate
markup (html) from presentation logic (C#, Java, VB, etc.) Whereas the other technologies mix them
together, Microsoft was rightly trying to separate them out. And I have to admit that a well designed aspx
page and its code-behind is a beautiful thing to behold. The aspx contains only Html and
Server-Control tags, and the code-behind contains only C#.
But consider this, let’s say I have a grid on the page full of tabular data
containing customers and their current balance. I want the Customers being displayed on this
grid that have a balance greater than zero to have their balance highlighted in
red. What is involved in accomplishing
this relatively simple presentation task?
Just breeze thru the following steps…
- Wire up the GridView’s
ItemRowBound event to an event handling method.
- In the event handling
method, check that the current row’s data item isn’t null (this avoid
exceptions because the headers and footers don’t have data associated with
them.)
- Create a local variable
for the Customer data, like a Customer object, dataset, etc.
- Now cast the row’s data
item to whatever you’re binding to—the Customer object, DataRow, etc.
- Oh, wait if you’re binding
to a dataset, you have to cast the row’s data item to a DataRowView, not a
DataRow. After 6 years of ASP.NET,
I still don’t know why that’s necessary.
- Now that you have your
data, check the customer’s balance to see if its greater than zero.
- Now use FindControl on the
current row of the GridView to find the control (label, textbox, etc.) that contains the
balance, or use the row’s Cells properties if there’s not a control nested
in there. If you have a control,
you also have to cast it to a control.
Now, I’m not being completely fair, because part of the work
above is not the fault of ASP.NET, it’s the fault of a strongly typed language
with all its casting necessity. But much
of the casting would be unnecessary even in JSPs which use another strongly
typed language.
When I first was learning asp.net and tried to do the above
tasks, I was lost. My instinct was to
start a “for loop” and put in one “if” statement and be done with it, but that
was not really feasible with a DataGrid, and probably wouldn’t be recommended
by Microsoft or the ASP.NET community. I
had a long learning curve ahead of me.
Now after 6 years of ASP.NET development under my belt, it’s a piece of
cake and I do enjoy the separation of concerns.
But I suspect a lot of web programmers coming from other server-side
platforms, took a look at all this crazy web forms stuff and swore it off. Its different, its complicated and it slows
down development.
Which goes back to what spawned this post. Why is it so many public facing websites are
written in PHP, and there are so many great shopping carts, CMS’s and other
free software for it? Why are there so few for ASP.NET? Its because ASP.NET was designed for desktop
programmers and almost completely ignored existing web designers and web
developers. For all its flaws, for all its lack of object orientation, its
global functions, its quirkiness and ugly syntax, PHP is friendlier to web
designers and web developers. It’s
friendlier with CSS, Javascript and by extension, all the cool UI toolkits out
there like Dojo, Scriptaculous and Prototype.
This doesn’t make it better, and I’d certainly choose ASP.NET in a
heartbeat for a complex, line of business, web application over PHP. But if you need a small to medium size
website up quickly and cheaply, nothing beats PHP and its slew of free, open
source, scripts and applications.
I believe there is hope for ASP.NET however. Ironically, this comes not from some quick
and dirty code-generating, drag and drop toolkit that Microsoft is throwing
over the wall, but for something that was designed to fix some of the alleged
flaws in the web forms model for enterprise development. Enter the ASP.NET MVC framework.
According the ASP.NET website, the MVC framework and the
design pattern its based upon has the following benefits:
- It
enables you to achieve and maintain a clear separation of concerns
- It
facilitates test driven development (TDD)
- It
provides more control over the URLs you publish in the application and
over the HTML that is emitted by the application
The first two bullets will probably not make a blip on the
radar of most web designers. But the
last part, about full control of the Html, as well as other deviations from web
forms, could actually lower the barrier of entry to ASP.NET development. MVC styled development isn’t going to muck
with my html tags, it’s not going to change the ID attributes, there’s no
viewstate, there’s far less reliance on events and controls. Forms can post anywhere. You can throw an “if” statement or a “for
loop” in the middle of the page to generate Html without it being quite a
sacrilege.
So besides solving a lot of the “enterprisey” problems such
as better separation of concerns and TDD, it may actually make web development friendlier
to web designers and non-ASP.NET web programmers. Maybe there won’t be an immediate slew of well
designed MVC shopping carts and CMS applications, but there might be a renewed
interest in the ASP.NET platform from designers. So in a sense, ASP.NET developers can now get
the best of both worlds: Enterprise friendly architecture, and web designer
friendly simplicity. I can get my nice
C# objects and the elegance of the .NET framework class library, without
dealing with web forms complexity. There
might be hope for ASP.NET yet.