Summary
Flapjax is a programming language that extends JavaScript. It provides: event-driven reactivity, consistency, and uniformity. It can also be used as a library directly from JavaScript. Callbacks are necessarily side-effecting which makes reasoning and analysis difficult. Flapjax uses reactive semantics to eliminate callbacks. It supports event streams and behaviors as basic reactive constructs. Both UI and network I/O are modeled with these constructs (example: auto-save text box). Combinators allow complex composition of event streams (example: drag and drop). Event streams and behaviors naturally lead to composable abstractions (example: filtering). Existing web services can easily be recast as event streams (example: Flickr thumbnail viewer). Doing so results in reusable abstractions that make mashups easy (example: Twitter + Geocoder + Google Maps). Flapjax also comes with a server that provides an event-based interface to JSON object persistence. Implementation details: evaluation model, dataflow graph construction, lifting expressions to behaviors, JavaScript interoperability, inline Flapjax, event propagation, DOM event conversion, library design. Evaluation: third-party apps: Data Grid, Interactive Wiki, Network Monitor, first-party apps: TestFest, Resume, Continue. Design discussion: benefits of consistency, potential for security analysis, challenges of debugging, relational dependencies between DOM and application models. Related work: FrTime, Frappé, Yahoo! Pipes, StreamIt, Flex, JavaFX, ThingLab, Kaleidoscope, Arrowlets, jQuery, Formlets, Links, Hops, MapJAX.
Comments
I’ve been growing increasingly fond of FRP in the UI realm, and these guys show that it’s a pretty good match for JavaScript and AJAX. The idea of modeling web services as event producers and consumers is interesting as well, but I feel that it’s probably less broadly applicable. They briefly touch on modeling persistence in this way as well which really starts to feel like a stretch. It’s informative to try to push the technique as far as it will go, so that stretching is useful. FRP is clearly a useful tool to have in the box, but it probably should not be the dominant paradigm for a language. Their comment that using Flapjax as a library turned out to be less cumbersome than they imagined is good news in that regard. I found doing FRP as a library in Java (GWT actually, but close enough) was not totally cumbersome, but there was non-negligible syntactic overhead. JavaScript has first-class functions and no type system, which makes it possible to achieve more syntactic conciseness, perhaps at the expense of some under the covers magic. I’d be interested to see what one could accomplish in Scala, with tastefully selected implicit conversions and some type-system magic.