A client of mine is developing a web application. The framework decision was made up front – Spring Webflow/MVC. I like Webflow. Its state machine based continuations concept is very cool. It lets you easy deal with things like back buttons, switching into a side piece of application flow (think needing to log in before continuing on to a section of the site) and maintaining a history of the state of a flow (where going back means using the application state as it was at that point in time). In short it’s pretty powerful stuff.
Only one problem – the application front end has been prototyped and signed off on by analysts used to working with desktop software.
Put simply, it’s expected to do some pretty crazy stuff. Think multiple layers of tabs, where the user can switch between different parts of the app without saving, navigating around fields from a central list of items that need correcting. Erk! The amount of hoops that have been had to be jumped through to get the requirements working have been huge, and it only keeps getting more complex. Without Webflow, I can’t imagine how something of this complexity could have been addressed. Classic web frameworks wouldn’t help on this one without some serious
bastardization.
The thing is, while Webflow makes it achievable, it’s not the right tool for the job. The interface requirements are too complex to easily do this stuff. Using a framework that ties you to the request based programming paradigm is the wrong way to go.
Put simply, we wouldn’t have the same sort of problems if the system we are building was constructed on a component based framework like Tapestry, JSF, or Wicket. Components have state, the page is composed of them and you react to events – “the button was clicked”. No more
request. No more session. Need to pull together info from multiple tabs? No worries – do it when the “I’m finished” button has been clicked. It takes a big mind shift to step away web concepts, but it’s worth it. At the very worst, there’s a new piece of kit in your toolkit that you can select for the task at hand.
As your tools become more capable, the requirements from your clients get more demanding. Your next web app interface won’t look like the last one you did. It will look like the latest whizz-bang offering from the latest flash in the pan start-up. Your clients use the net. They can see what others are doing. They expect that you can deliver the same. This is especially the case for internally used desktop replacement apps. If you don’t have the tools, you’re in for some late nights.
If it looks like a desktop app running in a browser, forget your father’s MVC framework – it’s just won’t cut the mustard.
It seems like a happy coincidence for Ruby on Rails that Web 2.0 apps emphasise simplicity. Classic MVC is not up to the task of rich UI.