A few years ago, I wanted to write a paper entitled ASP Considered Harmful, mostly because of the name. ;-) I felt that there was something fundementally wrong with the ASP style of coding, because bad ASP code is wretched, and ASP code goes bad so very easily.
I didn't do much with it, because every argument against ASP is an argument against that style of coding, whether the tool is ASP, PHP, JSP, or whatever. When I saw PHP getting increasingly popular, and surpassing Perl in popularity for web development, I figured it was either a personal preference against that particular style, and that I had missed something obvious about PHP, ASP and the like.
Fast forward a few years, to today, when I happened to read two totally different articles about web development. The first piece is from David Heinemeier Hansson, author of Ruby on Rails:
In Java with JSP, it's incredibly tempting to allow your view logic to deteriorate through responsibility creep (overloading them with business or mere complex logic) that leads to a rapid rot. Back in 2001, I worked on a J2EE system fraught with rot of this kind.I'm going to sidestep the whole J2EE-vs-Rails dogfight, and focus on this tidbit instead. This is the crux of my discomfort with ASP/JSP/PHP/XYP -- the fluidity with which domain models can leak or be totally avoided yet still produce "working code". (David goes on to describe the root causes why the JSP model per se encourages the precise wrong kind of behavior; the rest of his essay is really worth a read.)
OK. Something interesting to chew over. Then I read this other article by Jeff Veen on the business value to adhering to web standards (e.g. XHTML, CSS vs. HTML tag soup, tables and hard-coded styles):
Recently, we hosted a CSS file for a client on our development server while they began production on content and backend systems. As we continued to iterate the design, we were able to simply edit the file without having to integrate with their versioning and release system. By working in parallel, we dramatically reduced the time to market.(Note: this isn't an endorsement to avoid using CVS; but it is a very good reason to decouple editorial from design efforts, so they can vary independantly.)Speeding development is a competitive and financial advantage. Shorter development times not only reduce costs, but free resources sooner, thereby increasing opportunity.
There's a common thread here: when developing for the web, you can get a lot of mileage from a little whipupitude, regardless of the domain -- Perl CGI scripts, mod_perl handlers, J2EE containers, PHP sites, nested HTML tables, a couple of regexes, or whatever.
But there's a downside: simple techniques are easy to learn and can get you going fast on the web, but they take a lot of effort to maintain and extend, especially as you push beyond the first few early successes. You can push beyond the limits of any simple technique (ASP, nested tables, etc.), but at a cost; all of a sudden, web programming is a little less trivial, and a little more disciplined, and a lot more maintainable and extensible over the long term.
Funny thing is, I'm in the midst of refactoring one of these "wretched" codebases from the moral equivalent of JSP-done-wrong to something vaguely approximating JSP-as-intended. (Independantly derived, believe it or not...) In the process, I'm noticing that the short-term cost of development increases (more work to get a preliminary result), but the long-term cost of development is getting much cheaper (core features implemented once, and parameterized, not copied and pasted dozens of times).
FWIW, it feels to me like this is a kind of universal pattern in web development today. It's like a shift from one-dimensional thinking (just get it to work with $TECHNOLOGY) to two- or three-dimensional thinking (get it to work right, and make it easy to update over the next two years).
The gap between what is traditionally known as web development, and a tougher discipline known as application development.
J2EE and ASP are application development languages, specifically designed to support applications (including client-server cooperative computing), with defined frameworks for applications, deployed over the web.
Perl and PHP are powerfull enough to support application development, but are also straight forward enough to be picked up and used by a layout designer for a 'quick script' (SSI included stub for instance).
The difference is the scope of the project. As well as realizing the potential of the method to solve a problem. The mental switch from a 'quick fix' to dealing with a full-blown application, is that gap.
In this, I would point out, the potential for doing a 'quick-hack' and creating non-obvious execution dependancies is not specific to any language. Perl and C make it more obvious that you are doing it (having to move a variable to global defined space, before changing it in an odd sub-routine), but the same potential for abuse is still there.
I would even go so far as to say that, even ASP has it's place in computing (just not on my network).
