A Static Haskell/Reflex Frontend App

Posted on November 9, 2021 by Jack Kelly
Tags: haskell, nix, coding

Over the past couple of days, I built my first static frontend application using reflex. It’s called CASAAAAA (try it out), and it’s an interactive fuzzy searcher for aviation terms. The fuzzy search and the terms were already defined in casa-abbreviations-and-acronyms, so most of the work centred around the reflex-side of things. Because I like a challenge, I used Nix Flakes to pin reflex-platform. Overall, I’m satisfied with how it all worked out — I built CASAAAAA for a friend and he’s very happy with it. After the jump, I’ll detail some thoughts about the experience developing even a small program in this stack.

What worked well?

What didn’t?

Would I use this on a larger project?

I want to say “yes”, but probably not. GHCjs is an amazing achievement, and the effort put into its surrounding tooling is genuinely impressive, but knowing how to drive it involves so much folklore. So to use this sort of stack, it seems that I’d either have to resign myself to solo projects, or be in a position to bet the house on it. Anything in-between feels like too much bus factor risk.

I expect this to improve with time. Nix has a lot of momentum behind it — even from non-FP companies — and that will make it use less of a project’s “weirdness budget”.

The other thing I find hard to accept: it’s really hard to be kind to the user’s device when using GHCjs. The JS file it generates basically contains a full Haskell runtime, so there’s a large minimum bundle size that’s slow for less-powerful devices to process. Maybe I’m an old fart and 2MB of JS is nothing by modern standards, but BACK IN MY DAY the entire shareware version of Doom was about that size.

So it seems to me that the sweet spot for GHCjs/Reflex is when most (if not all) of the following things are true:

Previous Post
All Posts | RSS | Atom
Copyright © 2021 Jack Kelly
Site generated by Hakyll (source)