Microsoft ASP.NET MVC - Why Java web developers should reconsider action frameworks?

Microsoft's ASP.NET MVC is a paradigm shift in web development from its pioneering component based development offered with WebForms to action based web framework. This was a natural evolution due to the pains in the component based web development. While the Java community started out with the action based frameworks, the shift of the community seems to be on a higher side for the component based web development led by JavaServer Faces (JSF) in the recent years. The shift of Microsoft towards action frameworks should make the Java web developer's heads again turn towards action frameworks and reconsider their choice towards the paradigm for web development. Perhaps a thinking about polyglot web development is needed, rather than abandoning action frameworks.

A stroll with component web framework

Like many other Java web developers, I also had a chance to use JSF for my web development, after using Struts classic for almost two years. Everything was so exciting as we started with it. There was en enthusiasm to go on with Rapid Application Development (RAD) with drag and drop, the event oriented programming ushered by the component framework. The wide variety of JSF extensions, and widgets that would help us develop rich web applications, added to our excitement. The pain in tinkering with JavaScript and browser quirks would be zeroed.

As we started out, there were some initial hiccups because of the change in the way we think about developing web applications. Now we are less worried about the basics of HTTP, requests, responses, request parameters and its conversion between class properties. We were excited about the wide variety of rich controls that a JSF extension such as Richfaces or ICEFaces could offer.

Now about one year down the line as we started out writing more and more code, I felt at certain places, that I was missing action framework. It was not easy to bookmark pages - the URLs where least indicative about it, they are not search engine friendly. There are a whole lot of problems indicated by people at various blogs and articles. The flow control with JSF was very flaky, unless I used Spring Webflow to conquer my workflow requirements. I could no longer easily play with small tweaks that action frameworks would have always allowed me to. I had lost the flexibility to the framework that was primarily made to hide the details about HTTP. Although there are ways to get around with the limitations, some workarounds are very ugly and the bottomline was - the simplicity had gone. There was a higher learning curve too.

While the problems faced with JSF may not be true for every component frameworks, the higher adoption rate for JSF is causing me to rethink on it, before I could invest more efforts on it.

Looking back at action web framework

While the flexibility problems with JSF were still haunting, I heard about ASP.NET MVC from Microsoft - an action framework for .NET web development. I was looking back to action frameworks now. When I last used Struts classic in 2007,  Struts 2 had already hit the popularity headlines. But I did not had a chance to try that out, because of the obvious migration problems associated with a large project. With a mixed response to this, I started looking into Struts 2.

While I am still learning Struts 2, I could realize that the framework is much more easier that its predecessor. It could hide away the HTTP details, but at the same time, it was easy for anyone to play with the intricacies of HTTP if one would like to. Its damn simple, with least learning curve, probably because action framework are the right fit to thinking on how web works. Lead architect of Microsoft - Scott Guthrie has quoted on the action framework - "It enables full control over HTML markup and URL structure, and facilitates unit testing and a test driven development workflow" explains this.

I wondered why even after three years of Struts 2 (and so many other action frameworks for Java), JSF adoption rate was going high when compared to Struts or any other action frameworks. The job boards posted more requirements for JSF jobs when compared to action frameworks like Struts. This made me look into some depth why Microsoft adopted action frameworks, who were the people who introduced component based programming to the web development with ASP. ASP was later evolved with .NET as it became ASP.NET.

A look into why component web frameworks emerged

The significant roots of component based frameworks could be traced back to Microsoft coming out with ASP way back in mid-nineties to late nineties, as web started growing out from serving static HTML pages to creating dynamic web applications using the same HTTP protocol and HTML markups. The programming style in ASP although made some exposure to HTML, HTTP, GET and POST, primarily it was intended for VB6 desktop developers who would like to move on to web development. ASP.NET 1.0 continued this pace within the .NET framework. It was easy for seasoned VB6 developers to drag and drop components from the toolbox to author a page, with the least concern that it was a programming for web. VB6ers felt at home as they had to deal with post-backs and click handlers.

The same period in the Java space was taking a different stride. The Servlet specification was the first attempt from the Java community to deal with dynamic web pages. The pain of writing HTML markup in Java code paved the way to emergence of JSP. This was relaxing to an extent, but there were no formal web frameworks. This made the emergence of Struts by around mid of 2000, that brought in the concept of MVC to the web development. It quickly became the most popular framework in the Java community. Sun finally came out with a web-framework specification in 2004 as JSF1.0. JSF was largely similar to ASP/ASP.NET model programming and aimed at a competition with it. It is component based and even driven, that allowed rapid application developments that aimed the IDEs to give away drag-and-drop UI development combined with post-backs and even handlers in backing beans.

Why Microsoft is making a transition to action framework?

Definitely Microsoft is more experienced in component based development. The developers have always missed an inherent MVC with WebForms. They have also missed the Test Driven Development (TDD) robustness in their applications. The separation of concerns provide extensibility and testability, that was missing in WebForms. Action framework provided by the ASP.NET MVC has been now recognized as a natural fit to developing web applications. The power, simplicity and flexibility of action frameworks was witnessed earlier with MonoRail by the .NET developers. The emergence of ASP.NET MVC is the result of learning from the past and the recognition of needs by the developers for a simple, yet powerful action framework to the mainstream .NET developers. Now ASP.NET developers could enjoy TDD approach to web development in addition to the simplicity and extensibility provided by the action framework.

While the ASP.NET MVC framework was released just this March 2009, the active community around it has already found need for further improvements with an effort already into the development of its 2.0 release. I do not rule out the reasons to attract non .NET web developers into the Microsoft platform as one reason for Microsoft to come out with this plan. A notable point here is the recommendation by Microsoft to move the WebForms to the new action framework. It is already predicted by some to be the norm for ASP.NET development by 2011. ASP.NET MVC will be shipped with Visual Studio 2010 underlines its importance to Microsoft.

Learning from each other

Though late, Microsoft community has identified the importance of action framework for web development. Now when the Microsoft community is moving from component based to action framework based web development, the Java community really needs to re-evaluate its use of JSF for web development. Definitely, each paradigm of web development has its own importance, and probably can and should co-exist. But the larger Java community should not forget the learning of Microsoft community with web development framework.

On the other hand, Microsoft community can benefit from the learning in Java community with action frameworks such as Struts 2. ASP.NET MVC has released under open source license (MS-PL) and working with the community to develop it further, which is a welcome step. It also allows the community to contribute to the growth and higher adoption of the framework.

Rapid Application Development
As far as rapid application development is concerned, Rails principles such as convention over configuration, intelligent defaults, and automatic code generation with templates could be employed. ASP.NET MVC already includes tooling that uses code generation to quickly create a view based on a model object. Ruby on Rails is already a good example that can be followed. Struts 2 is no doubt, a great framework for Java web development with a flexible, simple and pluggable framework with convention over configuration and intelligent defaults that can be emulated by even the Microsoft community in developing its action framework. A good deal already seems to be into the ASP.NET MVC 1.0 inspired from Struts 2.

RAD can also be supported with plugin architecture as in Struts 2 that already offers plugins for GWT, jQuery and dojo among others. More and more code generators like the Spring ROO are also a welcome step. Perhaps we will witness a plethora of such code generators with Maven3 gets ready to be into the wild, that will support such extensions including the IDE integrations.

WYSIWYG editors for component framework can definitely will have its own role to play. We can see such editors for GWT and JSF as well. Better WYSIWYG editors for action frameworks are needed for RAD.

Concluding thoughts

The web frameworks do not end with JSF and Struts or with ASP.NET WebForms or ASP.NET MVC. There are notable advantages with frameworks like GWT and Echo that take a different stride to web development. Its time we need to re-look into our web development and see if we are beating every nail with the same hammer. Today as we speak of polyglot programming and polyglot persistence, probably a thinking about polyglot web frameworks is also needed.