Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GUI Architectures (2006)

martinfowler.com

Post reply on HN
Print view View original

21–29 of 29 posts

Re: GUI Architectures (2006)

#21

Post by pavlov »

narribbi wrote: post #10

When you read Trygve Reenskaug's original 1979 paper "MODELS - VIEWS - CONTROLLERS" -- it is very short, simple, and crystal-clear -- ( http://heim.ifi.uio.no/~trygver/1979/mvc-2/1979-12-MVC.pdf ), it obvious what Trygve meant: * The MODEL is something like a web server * The VIEW is something like a browser * The CONTROLLER is something like the Windows start menu Trygve literally writes: "A view (=browser) is attac…

I feel this demonstrates why the MVC nomenclature is too vague and overloaded to be very useful any more. When every person has their own interpretation of the terms, they've lost meaning.

Case in point: to you, it seems obvious that the controller is like the Windows start menu. To me, that doesn't make any sense at all.

Re: GUI Architectures (2006)

#22

Post by coldtea »

cottonflop wrote: post #15
pvg wrote: post #14

Earlier quoted context omitted.

He literally writes these things but none of it really suggests your analogy. 'Controller = start menu' seems particularly iffy.

Taskbar might be more appropriate. Or even browser tabs, given he went with the browser.

Browser tabs are the same thing as a start menu conceptually.

Hardly the best example of an MVC controller (even if they still are controllers).

Re: GUI Architectures (2006)

#23

Post by coldtea »

bmer wrote: post #11
zensavona wrote: post #5

Earlier quoted context omitted.

I think what this person is talking about is simplicity in the actual UI pattern, and thinking about them. The problems you mention are JavaScript problems, not UI problems. Have you ever tried to build a UI with Qt or JUCE?

Isn't JUCE music-app only (or, mostly)? Also, I am having a hard time figuring out whether you are mentioning Qt and JUCE in a positive light, or a negative one...

JUCE is mostly for music, but otherwise fully flexible UI-wise and with tons of helper stuff for all kinds of things.

And the parent is obviously implying QT/JUCE are much harder to create a GUI than js/html/css/etc.

Re: GUI Architectures (2006)

#24

Post by chriswarbo »

kmicklas wrote: post #2

At first I was amazed there is no mention of Functional Reactive Programming. Then again this is from 2006 when there were no fast, powerful, and practical FRP frameworks. I suspect we will see somewhat of a revolution in terms of client side development in the coming years - with a vast reduction in complexity and huge increase of programmer productivity.

The article cites papers for some of the architectures, and FRP papers have been around since the 90s. AFAIK the first mention of "functional reactive" is FRAN, written in Haskell, in 1997.

TBAG was close enough to the idea (maybe closer than most JS implementations!), in C++ in 1994.

For papers see http://conal.net/papers

Re: GUI Architectures (2006)

#25

Post by wruza »

narribbi wrote: post #10

When you read Trygve Reenskaug's original 1979 paper "MODELS - VIEWS - CONTROLLERS" -- it is very short, simple, and crystal-clear -- ( http://heim.ifi.uio.no/~trygver/1979/mvc-2/1979-12-MVC.pdf ), it obvious what Trygve meant: * The MODEL is something like a web server * The VIEW is something like a browser * The CONTROLLER is something like the Windows start menu Trygve literally writes: "A view (=browser) is attac…

In common^W my sense, controller is a thing that rules the views in a non-data plane. E.g. in master-detail scheme someone has to switch detail datasets once user selects new master row. Controller is the one responsible, cause data has no knowledge of how it is presented — master-detail vs. tree-unfold vs. edit-dialog. Controller emerges from the fact that a single data item can be presented on many different forms with different behavior rules. The last sentence is pretty straightforward on that.

Re: GUI Architectures (2006)

#26

Post by pionar »

wruza wrote: post #25
narribbi wrote: post #10

When you read Trygve Reenskaug's original 1979 paper "MODELS - VIEWS - CONTROLLERS" -- it is very short, simple, and crystal-clear -- ( http://heim.ifi.uio.no/~trygver/1979/mvc-2/1979-12-MVC.pdf ), it obvious what Trygve meant: * The MODEL is something like a web server * The VIEW is something like a browser * The CONTROLLER is something like the Windows start menu Trygve literally writes: "A view (=browser) is attac…

In common^W my sense, controller is a thing that rules the views in a non-data plane. E.g. in master-detail scheme someone has to switch detail datasets once user selects new master row. Controller is the one responsible, cause data has no knowledge of how it is presented — master-detail vs. tree-unfold vs. edit-dialog. Controller emerges from the fact that a single data item can be presented on many different forms…

So, I would think in that case - in our sense :) - that the "C" would better be served by being called a "Coordinator" instead of "Controller".

Re: GUI Architectures (2006)

#27

Post by kaio »

kmicklas wrote: post #2

At first I was amazed there is no mention of Functional Reactive Programming. Then again this is from 2006 when there were no fast, powerful, and practical FRP frameworks. I suspect we will see somewhat of a revolution in terms of client side development in the coming years - with a vast reduction in complexity and huge increase of programmer productivity.

Why should it be mentioned? FRP itself isn't an architecture. And as far as I know a lot of RxJava would easily fit into the "Observer pattern" (which is mentioned in the article)

Re: GUI Architectures (2006)

#28

Post by kmicklas »

gavinpc wrote: post #13
kmicklas wrote: post #2

At first I was amazed there is no mention of Functional Reactive Programming. Then again this is from 2006 when there were no fast, powerful, and practical FRP frameworks. I suspect we will see somewhat of a revolution in terms of client side development in the coming years - with a vast reduction in complexity and huge increase of programmer productivity.

Was just re-reading this paper [0], where they discuss how they "addressed some familiar limitations of the FRP model" in a research language called KScript. The defining constraint of the STEPS project was to make an entire personal computing system in 20,000 lines. http://www.vpri.org/pdf/tr2013002_KSonward.pdf

The limitations discussed in that paper should be fully addressed by a modern FRP framework like Reflex.

The existence of STEPS is actually one of the very few things that keeps me motivated to continue programming - maybe all that complexity isn't so essential after all. :)

Re: GUI Architectures (2006)

#29

Post by uranian »

napsterbr wrote: post #8
uranian wrote: post #3

Earlier quoted context omitted.

> with a vast reduction in complexity That is very optimistic looking at the current state of client side development with it's ever changing Javascript, Babel, Typescript, whatever script, Webpack, with HMR?, React or Vue? Angular? Flux? Redux? Isomorphic? Linters? Testing? CI? CSS/???SS or inline?, some NPM modules maybe?, and so on.. Sorry for me being a bit more pessimistic here.

Elm. No, really, elm. It goes away with all the js fatigue, your code is clean, readable and reliable, and does not produce runtime errors. You don't need npm (though it's probably a good idea for development, since you get hot-reload for free). Linter, testing and ci is a must, regardless of which kind of development we are talking about. Of course, linting with elm is a no-brainer with elm-format, and testing is mu…

Thanks, this is interesting.
Post reply on HN