Hi -
I would like to congratulate you on this new project, and I am eagerly looking forward to your progress.
I don't have much experience yet programming ClojureScript and Reagent, but I've been reading up on this stuff for the past few months, and I hope start getting more involved soon once I understand it better.
I must say that the ReadMe for re-frame was one of the best tutorials I've ever seen on this subject.
Re-frame gets so many things right!
Prefers reagent instead of the other Clojurescript/React libraries... yes!
Views CRUD as a kind of discrete, dynamic, asynchronous, push FRP... yes!
Avoids om's cursors... yes!
Defines a single db (like an SQL schema) rather than a bunch of classes (like in O-O)... yes!
Pays homage to elm-lang... yes!
Views a ratom
not as immutable data, but as a value that changes over time (eg, a signal
)... yes!
Nice long conceptual / tutorial ReadMe... yes!
"So much incidental complexity evaporates."... yes!
The re-frame ReadMe is one of the best tutorials available regarding FRP-like programming
I must say, this is the first time I every really "got" all this stuff about React, FRP etc. - and I've been reading everything I can get my hands on for months (Elm-lang, Bacon, ThreePenny, Apfelmus, Reactive Banana, the various React / Flux frameworks and libraries, the various ClojureScript wrappers over them).
This lengthy, well-thought-out, heavily referenced, clearly written ReadMe which you have provided is a major contribution to the understanding of "reactive" programming in the browser. This is a new topic, which many front-end JavaScript programmers are struggling with as people try to make the transition from MVC to something resembling FRP.
People are coming up against a lot of conceptual barriers - and the excellent tutorial which you provided will clear up a lot of confusion. It was a big help to me. In fact, it's the first time I ever really "got" what's going on with FRP-like programming. (In my case, the lightbulb lit up when I realized that re-frame's computation
is similar to a "dependency" in an older version of the functional language K I had studied years back - more details on this below. Somehow this had never occurred to me while reading any of the other tutorials and papers on FRP. But re-frame's ReadMe really helped make the connections.)
Related concepts in theoretical computer science
Ultimately I suspect that the asynchronous event-handling we're dealing with in JavaScript front-end frameworks and libraries involves what some theoretical computer scientists call "co-algebraic process types" (perhaps also called "streams" in other contexts) - which would be dual to "algebraic data types".
The "alegbraic data type" literature has percolated from academia to the world of practical programming - we do induction on algebraic data types all the time, it's called "recursion".
But the "co-algebraic process type" literature remains pretty much only in the academic world, and we don't often (explicitly, formally) do "co-induction" on "co-algebraic process types" - which seems to be what the older MVC JavaScript front-end frameworks (as well as the newer React/Flux JavaScript front-end frameworks) are (somewhat informally or naïvely) trying to deal with.
https://www.google.com/?gws_rd=ssl#q=coalgebra+streams+jan+rutten+nijmegen
A related implementation in an older version of the K language
Meanwhile, a blast from the past:
You may have heard of a language called K - a tiny, lightning-fast, functional, vector-processing (or columnar database) interpreted language in the APL family, also somewhat related to LISP. It's not very well known, but it's used by a handful of investment banks. Anyways, an earlier version of K happened to include a feature called "dependencies" (as well as "triggers"). It's interesting to note that a dependency
in K appears to be fairly similar to a computation
in re-frame (or a signal
in elm-lang, etc.).
Below is an archived PDF of an early version of the K reference manual, which describes "dependencies":
http://web.archive.org/web/20050504070651/http://www.kx.com/technical/documents/kreflite.pdf
You can search the PDF for occurrences of "dependenc" (to match either "dependencies" or "dependency") as well as "trigger".
A time-limited trial version of the K interpreter may still also be floating around online somewhere. I can also send a copy if anyone is interested. There is also a newer version of the language out now, called Q or KDB, which also has a trial version, but it no longer includes the wonderful dependency / trigger features of that earlier version of K. The newer version does however apparently implement something similar, called views. I imagine they got rid of dependencies and triggers in K because they also involved a native GUI (in Windows and Linux), which actually worked fine at the time, but which might have been a hassle to keep up-to-date with OS upgrades.
There is also a simple example of a dependency in K on this page:
http://88.97.16.226/apl/APL/Reviews/kreview.htm
A major development in front-end programming
It is encouraging to see that web front-end developers now starting to use these efficient and easy-to-reason-about "dataflow" constructs / architectures which have occasionally popped up in a few functional languages in the past.
This is one of the things that makes ClojureScript such a great language: functional / immutable data structures + the syntactic power of LISP (able to manipulate abstract syntax trees directly by defining macros). You always have the abstract syntax tree available, parsable - so you can define something like re-frame's computation
macro to act on it, and have the computation
macro implement this sort of dataflow or FRP style of programming (instead of doing something clunky in a language which merely lets you call eval
on a monolithic - ie, unparsed - string).