I think this is because GUI frameworks allow controllers and views much more tightly coupled and complex - UI kits are bigger, more flexible, and much more "manual" than the web, where browsers take away a big piece of the job (reducing your options, ofcourse). There's another issue in "real" UI applications - the chronology is more easily intertwined. With web apps the interaction is much more spaced out and separated (i'm not really sure how to say this).

Because we have to deal with far less technical complexity in web applications, we can take the lesson learned from MVC - that most applications can be easily broken into 3 layers that relate to taking care of data, getting stuff done, and showing data, and that furthermore breaking an app down like that will probably help the design and maintainability of the application.

Since the parameters involved have all changed applying this lesson to web applications merits reinterpretation, or at least that's how I see it...

What's your opinion on MVC in the webapp scene? How do you write your apps? What's your opinion on the meditation above?

I think it's interesting to understand how MVC evolved so much in this scene... I have not written UI programs (only maintained them - and they were badly designed), so I actually had no idea MVC in that world is so different.

Lastly - I disagree with the model being the "dumb part". I usually try to make the model slightly more than just a mapping layer - it gets some application specific features, and many times it's not even database related. This is where the quote that got me into the thread makes sense to me - the model should take the technical load off the controller, as long as it doesn't over-abstract things (wasting time).

Thanks for the interesting comment =)