5 ms·

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

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.

uranian 9y ago
> 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.
- colordrops 9y ago
  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.
- zensavona 9y ago
  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?
  - bmer 9y ago
    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...
    - coldtea 9y ago
      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.
- adamnemecek 9y ago
  I'm waiting for cycle.js to become the framework du jour.
- napsterbr 9y ago
  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.
  - uranian 9y ago
    Thanks, this is interesting.
- pjmlp 9y ago
  The life on native client side development is more peaceful.
trevor-e 9y ago
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.
- tadfisher 9y ago
  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 https://github.com/Frege/frege
rimliu 9y ago
I would not be surprised to see article on GUI architecture in 2028 which does not mention FRP either. FRP is in no way a silver bullet.
gavinpc 9y ago
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 http://www.vpri.org/pdf/tr2013002_KSonward.pdf
- kmicklas 9y ago
  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. :)
chriswarbo 9y ago
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 http://conal.net/papers
kaio 9y ago
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)

uranian 9y ago

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

colordrops 9y ago
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.
zensavona 9y ago
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?
- bmer 9y ago
  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...
  - coldtea 9y ago
    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.
adamnemecek 9y ago
I'm waiting for cycle.js to become the framework du jour.
napsterbr 9y ago
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.
- uranian 9y ago
  Thanks, this is interesting.
pjmlp 9y ago
The life on native client side development is more peaceful.

trevor-e 9y ago

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.

tadfisher 9y ago
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 https://github.com/Frege/frege

rimliu 9y ago

I would not be surprised to see article on GUI architecture in 2028 which does not mention FRP either. FRP is in no way a silver bullet.

gavinpc 9y ago

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 http://www.vpri.org/pdf/tr2013002_KSonward.pdf

kmicklas 9y ago
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. :)

chriswarbo 9y ago

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 http://conal.net/papers

kaio 9y ago

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)