Web software design principles: The Principle of Least Power
Last week, I wrote about the need for foundational software design principles to guide design discussions, peer reviews and refactoring targets if you’ve any hope of a successful web application recovery programme.
But what principles might you abide by in front end software development?
I don’t want to be prescriptive here, because the whole point is to make appropriate decisions based on your own circumstances, but I will put forward a few ‘candidates for consideration’.
Today: The Principle of Least Power
Tim Berners-Lee (or Sir Uncle Timbo as Bruce Lawson calls him) came up with this one way back in 1998, when many of us were busy abusing his creation with table-based layouts.
The description there is, in the style of Sir Uncle Timbo, a bit waffly. Fortunately there’s also a W3C Technical Architecture Group (TAG) ‘finding’ from 2006 which explores the idea a bit more and promotes it to a Rule:
The “Rule of Least Power” suggests choosing the least powerful language suitable for a given purpose
also stated as a best practice:
Use the least powerful language suitable for expressing information, constraints or programs on the World Wide Web.
This means: if you can do something with HTML by itself, use that rather than recreating functionality in a more powerful Turing-complete language like JavaScript.
Use native form elements rather than attempting to recreate them with complex CSS.
Try animating something using CSS first before reaching for JavaScript.
Use native back button behaviour rather than attempting to create a routing and navigation system in your application.
The problem with using a more powerful language to achieve the same purpose is:
you typically cannot determine what a program in a Turing-complete language will do without actually running it.
This means we need a lot more testing activities if we don’t abide by the Rule of Least Power. We can easily add a lot more complexity to our application than is necessary, just to validate something that could have been provided more reliably by a less powerful language.
Polyfills provide an interesting example. They are a deliberate breaking of the Rule of Least Power, but only for those browsers that don’t yet support the capability natively. The Rule of Least Power suggests we should be seeking an alternative approach for that feature that doesn’t involve polyfills at all, perhaps using feature detection and progressive enhancement.
Adopting the Principle of Least Power has lots of implications for web application design. As an exercise, examine your current product and see where it abides by or breaks the Rule of Least Power. Then reply and tell me about it.
All the best,
– Jim