Still "immature"? about bureaucracy HOT 4 CLOSED

Do you still find statecharts useful/relevant for how you use reflex-dom?

I'm not sure I have a straight-up yes/no answer for this, but it's probably more "no" than "yes". There's certainly nothing in the reflex-frp/reflex-dom code that I've been writing that directly models a statechart, and I haven't been drawing statecharts and writing my code based on them. If I were to go draw some statecharts to represent the UI that I've built in reflex-frp, I'm sure it'd be a fairly rote exercise: the natural structure of reflex-frp code using is to construct widgets that compose/decompose in very similar fashion to what you'd come up with if you were drawing statecharts. I suspect, though, that that's inherent in the way you write reflex-frp code;
I don't think that's just the way my code's falling out because I'm coming from a statechart-inspired place.

To elaborate a little more on my previous response...

I wrote bureaucracy because I thought that it would help me bring more structure to the UI code I was writing, and that would help me keep the UI I was building more tractable to work on. I hoped that that additional structure would enable me to build more complex UIs while still allowing me to iterate quickly and produce high quality.

What I found, though, was that I ended up with UIs that were nicely structured, but still difficult to work on. The difficulty turned out to be because the nice structure was fragile. I had a nicely structured set of abstractions, but in practice, whenever I wanted to add new features, or change existing behaviour, I broke stuff. Sometimes I broke stuff because there were typos in the names of dispatched events or states; sometimes I broke stuff because the state machine state that I was passing into a view function wasn't the one I thought it was; sometimes it was because there were just too many small, simple event handlers going on in a single namespace that I was losing track of what I was doing in the code.

And, despite having put effort into making sure bureaucracyis fairly easily testable, I found I was breaking stuff in production without my tests having picked it up. It got to the point where making large changes to the codebase was unpleasant, because I was so afraid of what I might break.

A bit of reflection on how I was breaking stuff let me to conclude that bureacracy was pretty reasonable at allowing me to build composable things, structured nicely, but it wasn't giving me a lot of help making sure that I plugged everything together right. I'm thinking about web apps these days as things that are "wide and shallow", in the sense that they're lots of quite small simple pieces and the complexity is in the way that those pieces are put together. The sorts of solutions I was coming up with for how to improve my code leaned pretty heavily towards putting lots of Prismatic Schema or clojure.spec annotations in my state machines to validate that the data I was passing around was what I thought it was. At that point, you have to wonder whether it mightn't be better to switch tooling so that you can have some static analysis do that work for you.

I'm happier now (so far!) with GHCJS and reflex-frp/reflex-dom because static typing gives me reassurance that I'm putting the pieces together in a sensible way.

Since switching, I've built interfaces (for the same product where I was previously using bureaucracy) which are substantially more complex than I had built in ClojureScript, and despite some occasional fairly significant refactoring, I still have yet to break anything in production. For what it's worth, I don't seem to be paying too much cost for that, either: my pace of development has remained fairly similar, I think -- though I will absolutely concede that learning to write UIs in reflex-frp/reflex-dom has a very high barrier to entry, so I'm not going to jump on my high horse and suggest that the solution I've found for me is one that everyone else should also be reaching for.

from bureaucracy.

from bureaucracy.

Hmm, very interesting! Thanks for the summary. It's certainly useful to hear that you've moved beyond statecharts and Clojure, Do you still find statecharts useful/relevant for how you use reflex-dom? I'm more than happy to wait until August for an answer 😉

from bureaucracy.

Thank you for writing up the longer response 🍻

It's great to get this kind of perspective from someone a few steps ahead!

from bureaucracy.