When I first became interested in functional programming, a more experienced engineer told me: “you know functional programming doesn’t really amount to much more than procedural programming.” As I insisted on the benefits of map, filter and reduce, he simply shook his head. “You’re thinking in the small. Go look at a large real-world application.”
It took some time for me to see what he meant. My preferred language, Clojure, is a functional language.
This is the second post in the series “Have Clojure UIs Taken the Wrong Path?”. The first post is here.
How do we choose between building an application using a hypermedia approach versus the client-side SPA? This post won’t answer that question. But it will say how not to make that choice.
A common heuristic is the spectrum that stretches between old fashioned “Multi Page Apps” (MPAs) for basic use cases, to Single Page Applications for rich client interactivity.
The Clojure community has focused on React-based solutions for complex front-end clients such as Reagent, Rum, Om, Re-frame, and Fulcro.
For all their differences, they follow a very similar architecture, making heavy use of client-side state and using RPC for client-server communication. We will call this the “React+” approach.
But is this the right choice?
I will suggest the answer may be negative. My suspicion is that as web UI libraries advance, the problems they solve are not essential.
Andy Hunt and Dave Thomas tell us: 'it’s critical that you write code that is readable and easy to reason about.' This seems uncontroversial; it is the rare point on which software engineers typically agree. Or do they?
The library locker antipattern occurs when we try to add functionality to a library function, but do so without separating concerns.
Avoid writing brittle Clojure with tactics for flexibility and robustness.
Feature branching with large monoliths causes merge hell. Microservices promise independent deployability. But sometimes you get distributed merge hell