Thanks. One of our design points in fact is that you can use the School from a tablet. We're still a bit concerned about Safari performance on the iPad, but we're on the case!

I suspect that you are not running into safari's performance limits so much. I think it's more likely that your client-side code is doing something that interferes with the browser's event loop, and is thereby preventing the browser from processing ordinary operations like doubletap-to-zoom, scrolling, pinch-to-zoom, etc. If you have a lot of JavaScript operations to perform, sometimes you need to defer some of them until the next time the event loop comes around — so that the browser can "breathe", as it were.

GWT, for example, has a DeferredCommand and IncrementalCommand facility for this situation. I believe they are just wrapping the setTimeout(func, 0) trick. (See link below.) If Fay does not have such a facility, then you may need to do some upstream work to teach it how.

http://b.javascript.info/tutorial/events-and-timing-depth#as...

But I guarantee that even an iPad 2 should have enough oomph to tackle your modest needs. It does just just fine on more intensive things like Google docs, spreadsheets, reader, and plus. And Facebook.

If, for example, I have not yet asked the monads tutorial to compile and run a snippet, then the browser's JS thread should be entirely quiescent and the event loop should be responsive to my zoom, pan, and rotation requests. That it isn't implicates your code (and/or the code Fay emits) — not the browser. I hope the creators of Fay considered this while architecting it. If they didn't, it's unlikely that they would have arrived at the correct solution by accident, because ordinarily compilers never need to worry about being "a good citizen" to a browser's event loop.

Best of luck. I envy that you get to work on this!