After working on the backend for so long I'm having a bit of a frontend renaissance. One area of confusion is the difference between MVC and MVP. There is a lot of conflicting/confusing information out there. I noticed that many of the posts and comments get it partially right which is more confusing than getting it completely wrong. So after trudging through many posts, the ones linked below seem to explain the difference accurately and clearly.

TL;DR, here was my take, for better or worse:

• MVC
• ...had a view/controller pair for each element on the screen (textbox, button, etc).
• ...the controller handled raw user input and decided if it was relevant to its view (i.e there was a mouse click or keystroke, was it within the coordinates of my view? Yes, I'll handle it; no, I'll ignore it).
• ...the controller did not manipulate the view. It just handled user input and updated the model...period.
• ...the view observes the model and updates itself.
• MVP
• ...has one view/presenter for multiple widgets, perhaps an entire screen.
• ...the presenter handles high level input that is passed along by widgets on the screen.
• ...the presenter manipulates the view...
• supervising controllers manipulate the view only in complex scenarios but let view update itself as much as possible, either by data binding to the model or observing the model.
• passive views are manipulated only by the presenter and they have no knowledge of the model. Changes in the model are strictly observed by the presenter which in turn manipulates the model.
• Comparison
• Controllers in MVC were focused on processing low level, raw input (Which was a lot of work), updating the model was a by product. Handling of low level, raw input is no longer necessary these days as it is handled by widgets; widgets then fire higher level events (Like button click instead of mouse click). So since the job of handling of low level input is now on the widgets, the MVP presenters are focused on updating the model in response to higher level events.
• Controller/view pairs in classic MVC were responsible for one "dumb" UI element. The view and presenter in MVP are responsible for an ensemble of "smart" widgets.
• MVC controllers did not manipulate the view whereas MVP presenters do (By varying degrees with supervising controller and passive view).

To me the biggest difference between the two is the relationship between the view and controller/presenter. The rest seems less relevant, especially now-a-days; who cares if the controller is handling low level or high level events or if it is handling one UI element or many widgets. These seem to simply be a function of the available technology. In MVC the controller does not manipulate the view, the view only updates itself as a result of changes in the model. In MVP the presenter manipulates the view to varying degrees. That to me is the real conceptual difference that has relevance today. I think it also explains why MVC is not used today in the UI; it's just not practical to restrict the controller from manipulating the view (Although the presentation model & mvvm attempt to successfully do this). That restriction would make it difficult to handle and test non-trivial UI logic. It also explains why MVC (flavored a bit differently) is used in many server side web frameworks as this separation between view and controller is practical and valuable in a stateless environment.

History/differences:

http://aviadezra.blogspot.com/2008/06/mvc-model-view-controller-design.html

http://aviadezra.blogspot.com/2007/07/twisting-mvp-triad-say-hello-to-mvpc.html

http://martinfowler.com/eaaDev/uiArchs.html

http://lostechies.com/derekgreer/2007/08/25/interactive-application-architecture/

Definitions:

http://martinfowler.com/eaaCatalog/modelViewController.html (Just a stub with the structure and a pointer to POEAA where you can read more)

http://martinfowler.com/eaaDev/ModelViewPresenter.html

http://martinfowler.com/eaaDev/SupervisingPresenter.html

http://martinfowler.com/eaaDev/PassiveScreen.html

http://martinfowler.com/eaaDev/PresentationModel.html (Good to understand in comparison to the other patterns)