Next steps

Posted on August 6, 2015

I intended to have a one month break from mpv6 / flare, which turned into 2, then 4. (I got a lot done, including new releases of rc and pacc, and a major overhaul of quux.) But now it’s time to get back to flare.

And what exactly will that entail? I spent a considerable amount of time examining various JavaScript frameworks, since it seems pretty much inevitable that there will end up being a reasonable amount on the client side. At present, flare is unusable over a 3G connection, as the browser. caches everything, so you delete a message but it doesn’t disappear from the message list….

And it’s only just occurred to me, this second, that there are HTTP-level solutions to this problem.

I decided that, given my Haskell proclivities, GHCJS is a good thing. It’s still rather immature, although I didn’t hit any critical problems. Basically it did what it said on the tin: ran pretty much any GHC code in your browser. An extraordinary piece of work.

Of course, writing “raw” haskell to interact with browser events and the DOM rapidly becomes dull. The obvious thing to slap on it next is a functional reactive programming framework. I looked at banana. I also promised its author that when I came back to the project I’d look at… <fill in this blank when I remember the name of the damned thing>

To be honest, I’m not sure I grokked the FRP paradigm. Although it certainly helped to organise the code, I don’t remember it seeming like a major breakthrough. Before I go further down this route it would be worth doing some more research into the basic approach might be worthwhile. I suspect that the idea I finally hit upon, of event processing firing further events, may be the clue.

I can’t help wondering if I’m not missing something much higher level. Basically I’ve got a state, that lives on the server, that I want to update efficiently. Is there no framework that can take care of all the details? Ember.js, for example, takes some of the boilerplate out of the AJAX calls. But the web platform can in principle do some really tricky things, such as noticing when the server has gone away, using local storage to record state changes, and then syncing everything up again when the server reappears. I’ve not come across anything that would take the donkey work out of that.

Anyway. I think the next few steps should, in fact, be to improve the existing HTML-only flare. There’s an awful lot of low-hanging fruit that needs doing anyway. And any refactoring can only help if / when we eventually move to a framework that involves the client side. (I’m also wondering if a sufficiently beefed-up server-based flare might get away with a few bits of ad hoc JS, rather than a full framework.)