What is the real cost of getting this "wrong"? For example: Backbone.js is following the MVP pattern, more specifically the passive view variant. The catch is that Backbone.js calls Presenters Views and Views Templates.
Should we be encouraging "correctness" here or is it ok that every new MV* framework reinterprets these patterns?
I think there is a contention in what MV* preaches and the reality of UI development now that it is disconnected from the server. Traditional MVC has followed a struts like architecture where the C is a procedural workflow that starts at A and end at Z. This encouraged a dumb V where say the header of a site was an HTML template and that the C would then populate with the M. This benefited the service oriented nature of HTTP request, they are a procedural workflow pattern where the request is initiated and work is done and a response is returned. This worked great for the old way of doing thing, compromises had to be made given that the view was generated and then delivered.
Fast forward to today and the UI can now be decoupled from the back-end technology so it is natural to evaluate whether or not the old patterns apply to new practices. In the old model, event based development and widgets had little advantage, event's where overly complex for a service oriented architecture, where a unit of processing is done and then a response is returned. It made little sense to bring in the indirection of event based programming. Further black boxing UI elements into widgets had little advantage because they could not directly respond to events that happen on the client side, in the old way, if a button was clicked, the server had to be notified and it would require complex routing to get that request back to a discreet widget that would have to be recreated or cached and looked up with every request. MVC with procedural C's where the best pattern available to deal with this reality.
Now jumping back to the present, we are not under the same constraints, code can be delivered to the client, the client can respond to events and the client can request processing and data from the back end. Based on this reality, procedural C's don't make a lot of sense, rather events and widgets become a more discreet solution. Designed well, a UI can actually rid itself of almost all procedural glue code external to widgets, via event routing and syndication. In this new reality there is little need to have a controller that says you do this and then you do this. Rather you can build widgets that say when this happens I will do this and when that happens I will tell everyone about this.
Given the dogmatic view of MVC being a best practice people sometimes try to draw parallels and call what they are doing MVC. A better description of MVC or widgets is separations of concerns which is still valid. You should not have JavaScript in HTML and you should not generate HTML from strings in JavaScript. Rather just like in MVC a widget should have an HTML template that represents the view. Some people call widgets micro-MVC which I suppose is correct, but to my MVC implies a controller orchestration a workflow in which I think we are trying to force definitions to not look like the guy that does not know what he is doing. That being said, I think trying to square peg round hole Event/Widget UI development into a MVC definitions is causing a lot of confusion. I think MVC is a relic of web 1.0 page/post programming. What people are really trying to say when they say MVC on the client, is separation of concerns which is still a very relevant and good practice.
I'm confused. MVC wasn't created for web 1.0 page/post programming. It was created for Desktop applications which are very similar to todays front-end heavy applications.
I think the pattern you're referring to is more like a Model2 (JSP/Rails) style pattern.
MVC, to my knowledge, was created for Desktop Application but the original scoped was limited to one widget.
For example: There is one widget (let's call it a Table) that displays data. The breakdown is as follow:
Model => Data
View => Table
Controller => Something that updates view based on changes in model (undefined originally)
Even if it wasn't limited to one widget, it was limited to a one simple View of the app (the other popular example is to use the DocumentWidget and DocumentModel "real-life" sample).
The original MVC was definitely not well-thought for rich desktop application PLUS automated testing with limited dependency to the Presentation layer (or view).
I believe Java SWING library utilizes MVC model at the widget levels.
Yes I understand that MVC predates the web, but it's surge in popularity was definitely from it's adoption as a best practice for web development and the web for the most part took the traditional view of MVC. That being said it did see some popularity in many imperative languages for desktop application but nowhere near it's popularity after the web. But I would say it and Event/Widget style UI's where neck and neck until the web's explosion.
The thing is now we try to explain evented systems in terms of MVC and I believe that we are trying to force the definition when what we are really trying to say is separation of concerns. Here is a good thread from that period that goes over how the two became jumbled together: http://c2.com/cgi/wiki?WhatsaControllerAnyway it's long the tldr; is smalltalk took the traditional view that controllers are independent of UI, they don't even know what the UI will look like. Where widget based systems such as swing where utilizing the same definition, but yet widgets where tightly coupled to the view they control by being the intelligent manipulators of a discreet view, but proper separation is observed in that all view elements exist in a HTML (or other UI) files, and the controller is a code-behind file, together they represent a discreet element.
Traditionally, this has not been considered MVC until the web UI started moving back to the client and now due to MVC achieving almost religious omnipotence people are wary of something not being MVC even if they have to make the definition match the practice.
on an interesting side note, I often wonder had MVC been as popular before the web, as it was after the web, would an event model have been chosen for the browser?
but yet widgets where tightly coupled to the view they control by being the intelligent manipulators of a discreet view, but proper separation is observed in that all view elements exist in a HTML (or other UI) files
Sorry to reply to my comment but it is too late to edit it, on the above quote, I realized that I jumped around and it reads like I am implying that swing uses HTML, that was not my intent, I jumped to HTML in my mind because I was thinking about a pure view technology which HTML is probably the best example, I mixed thoughts there but it was not my intent it would have been more proper to say like HTML not HTML as it reads like swing utilizes HTML as it's view technology which was not the concept I was trying to convey.
I think you forget that MVC is a pattern and not a specific method or an implementation. MVC could care less whether something is procedural, evented, client or serverside.
The article I posted goes over this and I remember it very well, MVC used to have a very specific definition.
(From the article: One of the central ideas of the Smalltalk-80 system was the ModelViewController (MVC) UserInterfaceParadigm?. Within that paradigm, the term "controller" had a well-defined, limited meaning.)
MVC today does not have a specific method or implementation and that was my point MVC has come to be known as a fuzzy definition for separations of concerns, as such I believe just saying separation of concerns is a better definition of what is desired. Because at some point people look at what was modeled in Smalltalk or Struts 1.0 which adhere to that concrete definition and become confused with the more nebulous definition that MVC has morphed into.
It's a violation of the implicit convention of the site, not because it's old, but because the year is not in the title. Without that, it's easy to not notice, losing valuable context.
The problem in the software industry isn't a lack of best practices, it's a lack of practitioners fully aware of the best practices. News isn't so much a function of when something happened as when someone heard about it first.
To make myself clear, I personally don't care that much about older articles. Anyway, I think it's good hn practice for older articles to put the year in title ... since many users might expect "news" or are old enough to have been pointed to those articles several times.
Should we be encouraging "correctness" here or is it ok that every new MV* framework reinterprets these patterns?