- 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.
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.
As for WCSF, my experience with it was similar to Scott Bellware’s — I was frightened by the weight of it from the start, and it didn’t alleviate my existing WebForms issues. It simply didn’t stack up to MonoRail’s powerful simplicity.
Having said that, how does MonoRail compete with WCSF? I think MonoRail’s "weaknesses" are its strengths. It doesn’t try to do everything; instead, it does enough things just right. It’s scalable and super-fast. It has a reasonably short learning curve, which is more impressive considering the fact that it is lacking in documentation in some areas.
I’m on the MonoRail bandwagon, and plan to be for a long time.