Another obvious observation…

I’m in the middle of exercise the aim of which is expression of an OLAP hypercube into a web page, using HTML/CSS/Javascript (no applets, or Flash, or …). The presentation is very much like a spreadsheet, but the data and UI manipulation models are very different. Add to this the fact that end result is a definition (a “model”) of how to build hypercube and then generate a report from the cube. The model will be used many times by a back-end “publisher” to generate reports (often in very large volumes).

So in the end I have a sheet that must evaluate identically in the web browser and in a back-end process.

Spreadsheets typically have a small expression language used to calculate fields from other fields. The expression language is usually something invented - not used anywhere else - and need their own little specialized interpreter. In my case I have need for a similar interpreter. I could have one implementation on the server, and do a round-trip to the server every time a cell needed update. I could do an implementation to run in the browser, and another implementation for the back-end process, with the risk that the two implementations might differ (and additional development and testing time). Neither alternative is ideal.

What if the expression language used in the spreadsheet were Javascript?

With Javascript we get a much more expressive language, eliminate the need to implement an interpreter, and get multiple well-tested implementations (Rhino, Spidermonkey, JScript). The syntax may be a bit more of a bother than the usual spreadsheet expression language, but perhaps not enough to matter. There is the potential for security risks that needs to be addressed (and should be quite solvable).

Have to chew on this one a bit more…