In a few days we’ll be releasing our first code using Flapjax to drive the user interface. The core of the system is a grid view that runs in the browser. The user can edit data in place, and when they move to a new row changes are sent to the server. Invalid data is flagged in the grid, and mousing over shows the reason for the error. Given we’re probably the first people in the world to release commercial code using Flapjax a few notes on our experience are worthwhile.
The summary is: Flapjax worked very well for us. Flapjax code is much smaller and faster to write than the equivalent plain Javasscript, and Flapjax insulates you from most of the cross-browser issues. If your application revolves around events, and most Javscript applications do, Flapjax will probably be a good fit. However current Javascript implementations are so slow that they can limit how much you can take advantage of Flapjax.
Now, the details. We went through two design. Our first prototype rendered the TABLE that contained the grid data as one enormous Behaviour. Every field was an “edit in place” field, using more Flapjax code. (See here if you don’t know what an edit in place field is, though note that this isn’t the code we used.) This plays very nicely with the Flapjax model, as changes to any part grid automatically get updated in the browser. It worked fine for small tables, but scaled really badly; for large tables it was so slow to load and redraw that the browser would kill the script.
The main problem with our first prototype is that browsers are really slow at rendering elements inserted using the DOM. Our second design made two major changes to overcome these problems. First we dropped edit in place fields in favour of plain old INPUT elements, and then got the server to render the HTML instead of building the grid dynamically on the client side. So essentially we used Flapjax to handle events from the grid, but not to render the grid. This design is much faster; for example a grid with a thousand cells renders in about a second.
As with any new technology, the community still has to develop best practices and design patterns to make it easier to adopt Flapjax. The best design for error handling is still an open issue. Architectures for mixing OO and FRP (Flapjax) code are not well defined, though there is prior work. However we feel the benefit we got from Flapjax, in terms of shorter code and a faster development cycle, outweighed the cost.
I agree with you on error handling, in at least terms of language transparency, synchronicity, and recovery.
The server trick is neat. I really want to try making a more static frp system that can be compiled as either a client, server, or mixed application. With the latter case, code migration would be due to context (server load, client framerate, security, etc).
For mixing OO, I see two basic problems:
The first is getting the bulk of an existing framework moved over. In JS2/AS3, which have classes, a similar trick to the paper you cited should work. For plain old JavaScript, sans syntax support, an abstracted version of what we did for array_b should work: wrap all prototype functions with lifted versions, and all prototype fields (as an ugly hack) with behaviours that get checked every time a function is called. Class initialization (and input parameters) should be handled similarly. I remember talking to Dan about the MrEd adapter, and it seemed like he took advantage of a lot of MrEd conventions – I’m a little skeptical of achieving both a fast and general adapter that doesn’t need tuning.
The second is finding a better way of making new OO classes with FRP, or even data structures in general. Frappe (?) looked at implementing FRP constructs over java netbeans. AS3 (2?) has transparent setters/getters, which suggets another easily implementable and effective adapter in a similar vein, but I feel Frappe was just scratching the surface of what can be done.
I’m curious to see the datagrid and any optimizations you guys figured out. The Flex one seems to be a pack leader, so I want to see how a FRP one stacks up!