Since starting with MonoRail some months ago, I’ve joined the bandwagon touting its benefits over Web Forms. Part of my advocacy was to convince the developers who help me out with my online baseball game, CSFBL (which will be rewritten using MonoRail).

In a discussion on our BaseCamp site, one of those developers, Rick, said this. (Emphasis added by me.)

I finally got to spend some time with MonoRail on Friday at work… [T]he guy that sits next to me does dev work on a fairly complex ASP site… He’s just got tasked to add a whole new section of his site and he doesn’t want to do it in ASP and we both got tasked to start learning each others projects so that we can back each other up when one of us is out so we decided to give MonoRail a look. He had spent all week just trying to get up to speed on ASP.Net and . . .

→ Read More: WebForms and alternatives: You can’t convince everyone

It seems everyone is writing about the differences between MonoRail and WebForms these days. Not to be left out, I’ll throw a few of my own comments into the mix.

I think that one’s attraction (or hatred) of MonoRail or ASP.Net’s WebForms is based on their programming background. (At least, it is in my case, and that’s at least one person, so that statement can’t be totally wrong.)

• People who come from the old days of web programming (before ASP.Net), who are used to coding HTML and JavaScript by hand, or who are used and comfortable with injecting presentation code into web pages will feel comfortable with MonoRail.
• People who come from the old days of Visual Basic programming or whose experience with web programming is WebForms and ASP.Net will feel comfortable with ASP.Net.

For all its flaws, WebForms has a lot of power, but the power comes at a price. Web forms does a lot for you, which is its benefit and its bane. If you want total control of your application, you’ll be frustrated with WebForms. MonoRail leaves a lot of things in your hands (particularly on the presentation side), and tries to help you do things rather than do things for you. That’s a big difference.

One of the reasons for the popularity of ASP.Net and WebForms (aside from Microsoft, of course) are the many web controls that come built-in or that you can buy to extend your application’s capabilities without having to write your own complex code. The same issues described above, however, still apply. Whenever you rely on a web control to do a complex task for you, you’re sacrificing some control.

That’s not to say there are no "web-control-like" solutions for MonoRail. There are many community-developed scripts and code blocks that can be used to extend the functionality of a web site built on MonoRail, providing features similar to web controls with less mysterious baggage. Consider the following.

. . . → Read More: Yet another comparison of MonoRail vs WebForms

There’s a little flurry of activity going around comparing Castle MonoRail to the Web Client Software Factory (WCSF). Here’s a synopsis.

• David Hayden, who admittedly is very familiar with WCSF and not very familiar with MonoRail, touts the future of WCSF and the concerns about the lack of resources working on MonoRail in order for it to compete long-term.
• Scott Bellware talks about evaluating MonoRail for an enterprise application, and he mentions his horrible experience setting up and comprehending WCSF.
• Hammett, one of the key Castle Project people who admittedly is not familiar with WCSF, talks about the need for WCSF to compete with MonoRail, not the other way around.

Where do I stand? Before answering, I need to explain my history with web development, ASP.Net, and MonoRail.

I started doing web development in the late 1990′s coding by hand and using ColdFusion on the server-side. I migrated to ASP and, ultimately, to ASP.Net, as most people did.

Since the beginning, I’ve had a love/hate relationship with ASP.Net. I love the .Net Framework, C#, and Visual Studio .Net. I hate ViewState, complex web controls that do unpredictable things, and the difficulty injecting JavaScript into ASP.Net web pages (id="ctl00___ctl00___ctl00_ctl00_bhcr_t___TitleBarSearchText", anyone?).

When I stumbled across MonoRail some time in 2006, I liked what I read, but didn’t have the time to explore it further. Towards the middle of 2006 I was working on my own Model-View-Presenter web architecture that was simple but effective, and even started transitioning my only claim to fame, CSFBL, to it. Then, I decided to give MonoRail a try.

I never turned back.

. . . → Read More: MonoRail vs Web Client Software Factory (WCSF)