First off, thanks for the comments! I have had similar opinions about frameworks, in particular custom frameworks that a programmer will design to make their job easier. I used to write PHP code with crazy, object-oriented designs, that, in the grand scheme of things, probably wasted more of my time than saved. I wonder what your opinion is on Ruby on Rails? I'm not familiar with it at all, but I can't deny the hordes of programmers that swear by its ease. What is your opinion?

Well, to be honest, I haven't used Ruby on Rails, so I don't have an informed opinion. I've dabbled in PHP and I've done ASP & ASP.net professionally (so my opinion is probably biased even if it was informed). Perhaps, our RE.net friend Galen Ward, could comment on RoR in particular, since estately is developed in it?

One issue w/ ASP.net is that older versions of the framework, tried to hide the true nature of web app development (which complicated front end development once you tried to do something interesting) and it didn't have a built in ActiveRecord-like support (which made back end development tedious). I suspect, though I don't know, older Java frameworks had similar shortcomings (at least in terms of the back-end). I think ASP.net is somewhat unique w/ it's Webforms model. I don't know how Hibernate compares w/ Rails ActiveRecord, but I suspect Ruby is better w/ web front end stuff than Java is, since it was designed w/ Web 2.0 ideas in mind and Java predates it.

My beef w/ script libraries and AJAX web applications is that the richer experience you try to present, the slower your app becomes. To present a richer experience, you need to download more code to the client before you do something. With traditional app development, you can add more code, throw more hardware at the problem, and not suffer a real performance problem. With web apps, you can't improve the clients bandwidth easily, you can't change the speed of light (network latency sucks), or otherwise change the HTTP spec so web browsers makes fewer round trips.

I'm luke-warm on Rails, merely because no "large" web site I know of uses it. Every big site, either uses ASP.net or some Java variant.. That doesn't mean it's not capable, since Twitter & 37 signals are pretty popular sites running on Rails, but Google or Microsoft sized scale they are not. Once upon a time ASP.net & Java were unproven too, so that criticism is pretty weak.

My other problem with Rails, is that I have no compelling reason to learn it. Microsoft is addressing ASP.net's shortcomings, so learning C# 3.0 w/ LINQ and ASP.net MVC seem to accomplish everything the Ror community is trying to accomplish with less learning involved on my part. I could always go halfway, and learn IronRuby I suppose. Not that I don't like learning, but I have a hard enough time staying up to date and mastering one large web framework, and if I spent the time required to master & stay current on two or more large web frameworks, I'd probably miss my wife & son an awful lot. :)

Still, I think the Ruby on Rails community must be doing something right, otherwise Microsoft wouldn't be copying their good ideas for use in LINQ & ASP.net MVC and Hibernate wouldn't be so popular among the Java literate.

A-men, brother: My criticism of ASP.NET runs wide and deep, and WebForms have killed quality MS-based web development. However, ASP.NET MVC rocks my world. LINQ? Not a chance in h-e-double-hockeysticks. Check out the code that that monster generates so that you can save a few manhours from design. Oy, vey.

-Matt

At my current job, we're using classic ASP.net without the webforms & viewstate. So it's more like a compiled ASP with a better object model than typical ASP.net. I dunno how much we'd gain by switching to ASP.net MVC, since we already avoid the suckier parts of ASP.net.

At my last job, I became converted to the less is more philosophy of ASP.net app development. :)

LINQ is interesting, but I'm not sure if I have a reason to use it. I've written too many interesting SQL Stored Procs that do things that LINQ can't do (dynamic SQL, multiple result sets, CLR integration, 2008 Geometry/Geography). Still, it's an interesting idea I'll be watching.

I'm sorry but I have to disagree with you. The name of the game in the professional developer's life is speed; more software, more met deadlines makes you valuable.

This is part of the age-old choice between quality and quantity. Sure, I could (and want to) write code-art. Yet, the people who pay me want code that conforms to spec yesterday. There is no shame in staying away from the client side if the application can bear it. Another point is the difficulty involved in clean separation of HTML and JavaScript from the server code. Those guys that write the amazing apps full of tricks also tend to write difficult to understand and maintanable code.

We had a guy who was always in the "my crank is bigger than yours" mode of thought and loved tricks. After 2 years (time is precious and we had other priorities), we finally re-wrote all his "magic" and now have something maintainable.

I did enjoy the essay. Please, do not construe my comments as an attack. I just get carried away sometimes. Cheers!

I don't disagree, but I think some companies value code quantity more, and others value code quality more. I think where your company fits in that continuum depends a lot on how that company makes it's money and who it's competitors are. Most companies go for quantity over quality, but not all.

For example, at Microsoft (or Google, Apple, or any other leading edge large cap tech company), the cost of additional engineering time sometimes pales in comparison to the cost to your companies reputation or brand. For example, if MS wrote Excel in VB instead of C, they might save millions / year in engineering labor, but the business advantage MS gets by "doing things the hard way" is billions / year. Obviously where line is drawn varies greatly from group to group, but big companies tend toward the quality side.

Put another way, do you think Steve Ballmer would like a do over on Windows Vista or Steve Jobs would take a mulligan on MobileMe, even if you told them it would cost another $50 million in engineering labor?

As the saying goes, you can have development speed, feature scope or product quality. Pick any 2.