It is serendipitous that I noticed a blog post about a callback combinator while adding a few drops to the Flapjax bucket.
Flapjax is nothing more than a coherent set of callback combinators. The key insight to this set of callback combinators is the “Event” abstraction — a Node in FJ’s implementation. Once callbacks are Nodes, you get two things:
- a handle that allows you to multiply operate on a single (time-varying) data source, and
- a whole host of useful abstractions for manipulating handles: mergeE, calmE, switchE, etc.
The last I saw the implementations of Resume and Continue, they were built using this idea. The more I think about it, the more the FJ-language seems like the wrong approach: the FJ-library is an awesome abstraction, in theory and practice.
Absolutely! I’m trying to get into FJ (as a user, not a researcher) and finding it very hard to dig into. Neither the tutorials nor the set of links on the RHS of the main page give any indication how to use it as a library.
I don’t think many web developers are ever going to commit to using an extra compiler. In the short term, it makes it harder to get into the product (“just let me download your library and tinker with it!”). In the long term, no one is going to trust a research prototype compiler, whereas an open source library is something that, in a pinch, they can always tweak and even fork if need be.
It’s totally fun to write a compiler, and of course you get more points in our research community for making something a language instead of a library. But from what I can tell so far, I agree with you that the library design seems more like the crown jewel of Flapjax.
I found idea of behaviors and lifting quite interesting.
That’s what brought me to your blog :)
It feels like a lot of thought was given into this, to make it clean and nice.
I think you should take a look at CCR/DSS though, if you did not have a chance yet.
I myself build and still working on very similar ajax system for our projects. While also abstracting event stream and trying to make it composable, main goal was very generic server side API and easy propogation of data/events from server to client and vise verse. Extra control should be added to it – like join, merge, critical calls and so on.
Depending form your communication to server you would want to have some ways to be specific about it. Like critical sections, time outs, repeats and so on.
Form this point of view FJ seems to be very one sided to me. There’s work with webservice but not with post of the form (or maybe im missing it)? Bundling requests together also wold help a lot in performance plus it wold allow to scale server side. But again you would need then give programmer more explicit control over communication channel with server.