search

samroberton / bureaucracy

First-class state management via state machines
Eclipse Public License 1.0
65 stars 2 forks source link

Still "immature"? #1

Closed refset closed 7 years ago

refset commented 7 years ago

Hey, I just saw bureaucracy mentioned in the comments on one of Cognitects' recent blog posts and I have a few questions, when you get the time:

In the meantime will attempt to build a working demo based on the tutorial, which ideally you could link to at the end of the page :crossed_fingers:

samroberton commented 7 years ago

Hey Jeremy,

A short response, since I'm on holiday for all of July.

It's definitely immature, and if I'm completely honest, I'm not sure whether it will see much further development at this point. Some aspects of the programming model I think work quite well, but I've come to the conclusion that the problem that bureaucracy solved for me wasn't actually my biggest pain point with front end development. My attention recently has headed in the direction of statically typed languages instead (specifically GHCJS with reflex-frp and reflex-dom), on the basis that actually I can get most of what state machines give me from an advanced type system instead.

That said, I'm still using it in production, for the moment, for what that's worth.

On 4 Jul 2017 13:04, "Jeremy Taylor" notifications@github.com wrote:

Hey, I just saw bureaucracy mentioned in the comments on one of Cognitects' recent blog posts http://blog.cognitect.com/blog/2017/5/22/restate-your-ui-using-state-machines-to-simplify-user-interface-development and I have a few questions, when you get the time:

In the meantime will attempt to build a working demo based on the tutorial, which ideally you could link to at the end of the page 🤞

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/samroberton/bureaucracy/issues/1, or mute the thread https://github.com/notifications/unsubscribe-auth/ABMRcs4wIfslLF_9qWho5gwRJ2HlxTSMks5sKio6gaJpZM4ONRD- .

refset commented 7 years ago

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 :wink:

samroberton commented 7 years ago

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.

refset commented 7 years ago

Thank you for writing up the longer response :beers:

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