Lojban command-line and services
#1Web application frontend
The implementation of the web frontend is an open question. There are several options.
Traditional
This means generating HTML on the server and serving as a response to every request. There is good support for this approach meaning for example that we can use libraries like web-routes naturally and easily. It also has the benefits that it can easily be made to work without JS and that it promotes simple interfaces.
As for downsides it doesn't necessitate the creation of a web API, it's not interesting to implement and requires pages to be re-loaded for every request (potentially wasteful and slow, although pages tend to be light-weight). AJAX can be added on the top, but that either makes JS required anyway, of means writing two implementations, and means manipulating the DOM in error-prone manners.
JS MVC
This means making a web API on the server side and talking to the API with a JS library on the client side, to keep models in sync with the server database. This could be an all-YUI solution of use libraries like jQuery and Backbone or Angular.
With this approach a web API is necessitated, which is a good thing. The MVC library will take care of the error-prone DOM manipulations in a safe manner. It may be easier to implement more complex UI interactions with this approach.
An obvious downside is that the frontend won't work at all with JS disabled. It also probably means writing a lot of JS code directly, which is not very safe, and there will be a dichotomy between the client and the server which means violating the DRY principle and creates boundaries where for example data has to be serialized to and from JSON and care has to be taken to use the data consistently on both ends, with little or no type safety to help on the client side.
Fay
With Fay we can have a JS-heavy client-side and share types and type safety with the server.
There are downsides, however. The seamless serialization of data to and from the server might not make for a clean and sensible web API outside of Fay. The limitations of Fay's subset of Haskell has ramifications for how we write the shared code, which affects the server-side implementaion (for example how we write our data types). Also, Fay just being a compiler means we need to write bindings to existing libraries if we need to use them, which we're likely to because Fay itself doesn't do much. This means for example that there is no clear answer for doing reactivity with Fay.
Elm
Elm offers a polished answer for client-side FRP in a type safe manner with a familiar syntax. We can't really share types with the server like with Fay, so we'll have to make a JSON API. That means there will be a clean and sensible web API, but that we're back to the dichotomy problem and DRY violations. On the other hand since Elm is type checked with Haskell-like types, errors in that boundary might be caught more easily. I'm not convinced directly sharing types will ever work well, without imposing restrictions on how you model your data.
It's not clear how to do type safe routing and i18n with Elm. For routing the suggested solution appears to be to generate the elm with text interpolation at runtime, but I really don't like the idea of that.
GHCJS
With GHCJS we could share types and code without restrictions, and we could use for example netwire to implement client-side FRP. We could share the JSON code on both ends and get the clean and sensible web API without the dichotomy problem.
The downsides are that GHCJS isn't really ready yet, it's difficult to install and the JS we would end up with would probably be on the large side since we would be compiling many of the server side libraries for the client side. It also means having to code the DOM FRP for netwire.
