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 =)

Well, MVC on the web is severly limited anyway.

In real MVC apps, the view can listen to changes in the model, and has to, because there are often multiple views and controllers interacting with the model at once.

On the web, once you’ve rendered the view, it sits there dumbly in the user’s browser. (XMLHttpRequest does not significantly change this.) That makes the distinction between the model and the controller blurry and somewhat artificial.

Makeshifts last the longest.

I don't think your split of "taking care of data, getting stuff done, and showing data" actually reflects the intent of MVC. It does reflect how most people use Catalyst though. I would expect an MVC app to have a controller that does nothing but map input to methods in the model. It would know nothing about the application itself, but plenty about the web, i.e. the point of the controller is to separate things that are web-specific about user input from the model. That is all it should do. If you want to run your model from a Tk GUI, you just make a new controller and view that understand Tk.

We do have a bit of a problem at this point, since no other useful name has evolved for the style of development you are talking about. Calling it MVC isn't accurate, but calling it "a templated web app with an O/R mapper" is not succinct enough.