GUI Architectures (2006)
martinfowler.com
GUI Architectures (2006)
1–10 of 29 posts
Re: GUI Architectures (2006)
#2At 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.
Re: GUI Architectures (2006)
#3At 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.
> 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.
Re: GUI Architectures (2006)
#4At 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.
> 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.
Many of these are particular implementations of FRP, not FRP itself. That's like saying MVC is complex because there are 50,000 implementations. It's a non sequitur.
Re: GUI Architectures (2006)
#5At 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.
> 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.
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?
Re: GUI Architectures (2006)
#6At 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.
> 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.
I'm waiting for cycle.js to become the framework du jour.
Re: GUI Architectures (2006)
#7At 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.
My team tried using RxJava for our Android app with mixed results. While it's easier to model some UI problems with reactive streams, and certainly more fun to write, we found it's really easy to introduce subtle bugs and performance problems due to the high learning curve. Debugging is also worse.
Re: GUI Architectures (2006)
#8At 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.
> 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 much easier when you don't have side-effects. Plus you get fuzz testing "by default".
I was just as pessimistic as you wrt frontend development, I had dropped it off altogether. Elm made frontend dev enjoyable again. Can't recommend it enough.
If someone wants to talk about elm and how it is to develop with it, feel free to drop me a line. Email is on profile.
Re: GUI Architectures (2006)
#9At 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.
My team tried using RxJava for our Android app with mixed results. While it's easier to model some UI problems with reactive streams, and certainly more fun to write, we found it's really easy to introduce subtle bugs and performance problems due to the high learning curve. Debugging is also worse.
Same. The problem is that RxJava shoehorns FRP into, well, Java. A language built for it (Haskell, et al) might have just as steep a learning curve but probably a higher plateau.
Frege looks promising for Android, in particular: https://github.com/Frege/frege
Re: GUI Architectures (2006)
#10When 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 attached to its model (=server) and gets the data necessary for the presentation from the model by asking questions (=submitting queries). It may also update the model (=posting) by sending appropriate messages. A controller (=start menu) provides the user with input (=menu items) by arranging for relevant views (=windows) to present themselves in appropriate places on the screen."