5 ms·

GUI Architectures

123 points by huytoan_pc 15y ago

DanielRibeiro 15y ago
2006. But a great article nevertheless.
- angerman 15y ago
  This seems to be a recurring phenomenon on HN. Why is the timestamp given so much importance?
  - zyfo 15y ago
    Because things change fast in the industry.
    - whateverer 15y ago
      Yet mainstream languages are just catching up now to the state of the art of 30 years ago.
      - ryanbraganza 15y ago
        Good thing HN hasn't gone mainstream.
    - hello_moto 15y ago
      Too fast to get it right. We're back to square one a few years ago: high rate of crappy code.
  - stewbrew 15y ago
    The N in HN is supposed to mean "News". Imagine a news paper that reprints issues from six years ago.
    - Joeri 15y ago
      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 15y ago
        There is unfortunately also the problem of too many "best practices", that gets popularized, dogmatized and horribly misused.
    - sambeau 15y ago
      "On-Topic: Anything that good hackers would find interesting." The age of an article has no bearing on how interesting a good hacker would find it.
      - stewbrew 15y ago
        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.
    - mattgreenrocks 15y ago
      Wait until you find out that some of dijkstra's letters make it to the front page.
  - lukifer 15y ago
    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.
- gaius 15y ago
  More snake oil from Fowler, more like.
  - praptak 15y ago
    Fowler's persona aside, have you found any specific flaws in the article in question?
deleted 15y ago
[deleted]
camwest 15y ago
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 15y ago
  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.

GUI Architectures

123 points by huytoan_pc 15y ago

DanielRibeiro 15y ago

2006. But a great article nevertheless.

angerman 15y ago
This seems to be a recurring phenomenon on HN. Why is the timestamp given so much importance?
- zyfo 15y ago
  Because things change fast in the industry.
  - whateverer 15y ago
    Yet mainstream languages are just catching up now to the state of the art of 30 years ago.
    - ryanbraganza 15y ago
      Good thing HN hasn't gone mainstream.
  - hello_moto 15y ago
    Too fast to get it right. We're back to square one a few years ago: high rate of crappy code.
- stewbrew 15y ago
  The N in HN is supposed to mean "News". Imagine a news paper that reprints issues from six years ago.
  - Joeri 15y ago
    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 15y ago
      There is unfortunately also the problem of too many "best practices", that gets popularized, dogmatized and horribly misused.
  - sambeau 15y ago
    "On-Topic: Anything that good hackers would find interesting." The age of an article has no bearing on how interesting a good hacker would find it.
    - stewbrew 15y ago
      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.
  - mattgreenrocks 15y ago
    Wait until you find out that some of dijkstra's letters make it to the front page.
- lukifer 15y ago
  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.
gaius 15y ago
More snake oil from Fowler, more like.
- praptak 15y ago
  Fowler's persona aside, have you found any specific flaws in the article in question?

deleted 15y ago

[deleted]

camwest 15y ago

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 15y ago
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.