
GUI Architectures - huytoan_pc
http://martinfowler.com/eaaDev/uiArchs.html
======
camwest
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?

~~~
kls
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.

~~~
camwest
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.

~~~
kls
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?

~~~
kls
_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.

------
DanielRibeiro
2006\. But a great article nevertheless.

~~~
angerman
This seems to be a recurring phenomenon on HN. Why is the timestamp given so
much importance?

~~~
stewbrew
The N in HN is supposed to mean "News". Imagine a news paper that reprints
issues from six years ago.

~~~
Joeri
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.

~~~
MortenK
There is unfortunately also the problem of too many "best practices", that
gets popularized, dogmatized and horribly misused.

