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.