You don’t have to be an engineer to be be a racing driver, but you do have to have Mechanical Sympathy.
-Jackie Stewart, racing driver
The term “mechanical sympathy” was originally coined by Jackie Steward to capture a characteristic of race car drivers, who needed a deep and intuitive understanding of how a race car worked in order to get the best possible performance out of the vehicle.
This term was applied to software development by Martin Thompson when discussing his LMAX architecture, which utilized a low level and intuitive understanding of how his cloud system functioned in order to maximize the performance of it. Thompson maintained a blog on the topic for many years, and it is well worth going back and reading the posts there.
In this brief essay I want to propose another concept and design principle, that of Architectural Sympathy:
Architectural Sympathy is the characteristic of one piece of software adopting and conforming to the architectural design of another piece of software
This is a design principle that I have kept in mind when designing htmx and hyperscript and I wanted to write it down for reference and so others can think about, criticize and improve it.
htmx is architecturally sympathetic to The Web because it adopts the underlying REST-ful architecture of The Web: exchanging hypermedia in a REST-ful manner with a hypermedia server. As much as is practical, htmx takes design cues from the existing Web infrastructure:
htmx attempts to fold in to the existing conceptual architecture of The Web, rather than replace it.
This is in contrast with the SPA approach to building web applications. Most SPA frameworks have little architectural sympathy with the original web model. Rather, they largely replace the original, REST-ful, hypermedia-oriented architecture of the web in favor of a more thick-client like architecture, exchanging information over an RPC-like fixed-data format network architecture.
If a new piece of software maintains architectural sympathy with an original piece of software, the following advantages are obtained:
Of course, as with any design principle, there are trade-offs when using Architectural Sympathy:
A non-software example of architectural sympathy that I like to point to are medieval cathedrals: these cathedrals were often built, rebuilt and improved over centuries by many different builders and architects (such as they were). And yet they were able, over those centuries, to maintain a high level of architectural sympathy with the earlier workers.
Rather than focusing on radically new approaches to building, workers focused on maintaining a coherent whole and, within that framework, on the craftsmanship of their individual contributions. Yes, there were flourishes and changes along the way, but these typically did not sacrifice the conceptual coherence of the whole for the sake of innovation.
Adopting an architecturally sympathetic mindset in software development often means sacrificing how you would like to do things in favor of how an original piece of software did things. While this constraint can chafe at times, it can also produce well crafted software that is harmonious and that dovetails well with existing software.