ViewModel rationale

Nikil Kothari had a great couple posts this week, notably this one.

He makes a good case for ViewModel, especially the idea that it's the next step up from codebehind. But there's more to be said. First off, UI is expensive, and not just mildly--it's basically as expensive as a software feature can be without being prohibitive (e.g., voice recognition). In my experience, whether on WinForms, HTML, Ajaxy and CSSed HTML, WPF, WebForms, or Silverlight--even my little tastes of Ruby on Rails--UI just takes developers longer to get a feature done-done. Often 4 or 5 times longer. There are some inherent and perhaps intractable reasons for this: UI is often what product owners feel most acutely, so there's lots of micromanaging, fiddling, and rework; the human eye is trained by evolution to absorb visual information quickly, with an especial emphasis on inconsistencies, so the tolerance for error is different; and everything in a UI tends to be intricately and sensitively connected to its neighbors, in time and in space, resulting in the wonderfully correct and illustrative metaphor of "the ripple effect".

There are also some regrettable reasons why UI is so hard: most notably that even the best tools, theories, and mindshare are still in their infancy. Many concepts that are getting some traction these days ("MVVM", "UX design") had effectively zero presence in commercial software even 15 years ago.

Since UI is expensive, a major trend among MV* patterns (MVC, MVP, MVVM, and other flavors of SupervisingController) is to make the UI dev burden as light as possible, and to provide more and framework/scaffolding that makes much of the plumbing just happen. The eventing and data binding in WPF and SL are important steps forward; so are codegen and reflection, which assist metaprogramming.

It's significant that ViewModel mindshare didn't really take off until the codebehind pattern matured a bit and there was framework support (primarily .NET) to knit the view's document-orientedness to its logic and state, as coded in... um, well, code.

I think the rise of CSS also played a crucial role, convincing millions of developers of the wisdom of separating visual markup from the containment tree--preferably in a reusable way that makes application-wide look-and-feel not only achievable but flexible and maintainable. CSS wasn't a step toward MVVM, but it cleared away some of the underbrush.

JavaScript is another factor that might have scared some devs straight, spending too much time repairing "clever" code integrated into a page.

So, some more drivers toward MVVM:
* stateless view --> one set of concerns (represention of state) out of the expensive UI
* passive view --> another set of concerns (choosing the next state, and transitioning to it) out of the expensive UI
* styles --> a third set of expensive concerns mitigated, at least partially. And MVVM handles most major tasks well, EXCEPT for styles, so it needed that task taken off the board
* scar tissue from browser scripting
* declarative code vs imperative/programmatic code, coexisting harmoniously via codebehind
* "conventions", base classes, and other forms of code leveraging/reuse that allow recurring problems to have recurring solutions, with minimal additional developer effort