Stupid question from an interested outsider: how's a "subscription" different from a good ol' callback?
A Farewell to FRP
31–40 of 246 posts
Re: A Farewell to FRP
#32There's also a lot of similarity with Rx.JS and observable based (aka "Reactor") patterns:
Rx.Observable.fromTime().subscribe(tick)
Rx.Observable.fromSocket(mySocket).subscribe(handleEvent)
Regardless of the exact library or pattern, the broader concept of treating data sources as asynchronous event streams you can subscribe and react to definitely simplifies data flow and makes systems very robust.
An additional benefit of this pattern is the natural way it makes it easy to filter, chain, map, etc onto these subscriptions. Once again from the Rx world, http://rxmarbles.com/ does a great job visualizing these patterns.
Re: A Farewell to FRP
#33Elm is very cool and pleasant to use compared to JavaScript, but I have some reservations. The limited typeclass system (for numbers and such) seems... questionable. The interaction of what looks like pure declarative syntax and what is actually impure imperative semantics is confusing to me. I understand that the author wants to avoid monads and other perhaps somewhat confusing staples of functional IO, but I'm not sure the cost/benefit of doing it this way works out.
I will say that Elm is the best JavaScript-targeting platform I have tried! I have hopes for GHCJS, but it's not near Elm's level of readiness yet.
Re: A Farewell to FRP
#34One thing I'm wondering with elm is how does it deal with state across different components? I.e. where would you put the settings of the current user and how would you access that within one component? (By component I mean the (init,update,view,subscription))
Re: A Farewell to FRP
#35I am happy to see Elm evolving and it looks like a good framework, but there is a tendency in FRP articles to ignore prior work, as acknowledged at the end of the article:
> Note: Interested readers may find Lucid Synchrone interesting. Unfortunately for me, I had no idea my thesis had so much in common with synchronous programming languages at the time, but the connections are quite striking. I might argue that Elm was never about FRP.
My thesis was related to synchronous programming languages and articles about FRP tend to have too little to say about them, for my taste. Yes, there is a word or two in the related work, but also it looks like some wheels are being reinvented.
The subscriptions model reminds me of Esterel, which is imperative and uses await/emit pairs. In the domain of GUIs, which is related to Elm, there is ReactiveML (see "ReactiveML, Ten Years Later" (https://www.di.ens.fr/~pouzet/bib/ppdp15.pdf)). Look also at Lustre or Signal, with Signal allowing directives to define multiple execution units: this is used to generate concurrent programs exchanging values with message passing.
The domain is different, though. Synchronous languages do not target web interfaces. They are about embedded systems and as such, they are mostly static. On the other hand, they are compilable into a simple event loop with static memory usage and constant execution time. Maybe some of the existing research could be useful to something like Elm, even if it does not target the same problems.
Re: A Farewell to FRP
#36As someone who is just getting started with frontend development, I decided to go with Elm instead of learning JS and React. I found the whole experience very pleasant, even as a beginner. Not only is the elm code I write reliable, but I've found that adding more features does not bloat my code. Refactoring a codebase as it grows in elm is pleasant, and following the Elm Architecture guides me on the correct structur…
Nice to read.
Last time I tried Elm, (1 or 1 1/2 years ago) tutorials and docs were kinda outdated. Got errors in this REPL thing they got for beginners on the webpage and nothing from the examples worked :\
Re: A Farewell to FRP
#37As someone who is just getting started with frontend development, I decided to go with Elm instead of learning JS and React. I found the whole experience very pleasant, even as a beginner. Not only is the elm code I write reliable, but I've found that adding more features does not bloat my code. Refactoring a codebase as it grows in elm is pleasant, and following the Elm Architecture guides me on the correct structur…
Bold move, but a good one, I think. I've been considering starting my students (just friends I mentor) on Elm for a while, but it's only this year I've heard of local companies hiring for Elm here in Salt Lake City.
Re: A Farewell to FRP
#38I like Elm but its development really seems to rely on a single person. I saw this post on elm-discuss which is a pretty good summary of my thoughts https://groups.google.com/forum/#!topic/elm-discuss/AmxE3qAm...
Yep every 'native' library needed arduous review process via github issues. I waited for over a month for elm overlords to approve my 'native use' library , they simply closed the issue. Dropped elm for react and co. Now I have serverside rendering, code splitting, working debugger ect which was impossible with elm. This was last year though so not sure if it is still the process. YMV.
It has changed, in that the language is moving away from Native code, and instead is trying to provide the web-platform as part of the language/core libs.
And for everything else, there's Ports. You can't use them in libraries, but for your own projects they're a much better JS FFI.
Re: A Farewell to FRP
#39Looks very good. I got stuck learning elm at about the point I wanted to integrate a call to a javascript function. Can't for the life of me remember if that involved signals or not. Will definitely try the tutorial(s) again when I get some more time because I really was enjoying everything else about the language and developing in it.
Re: A Farewell to FRP
#40Does Elm have any nice interfaces for common JS frameworks? (like reagent / om in clojurescript, or angular2 for dart / typescript)
Ports were the way to do this in Elm. I don't know how it works in the new version.
They do, and have been made much clearer: http://guide.elm-lang.org/interop/javascript.html