Where Logic Lives

We will always need presentational logic in our end-user applications, and it should probably always be separated from application logic. But where developers encode this logic continues to change. A quick note on a few things that drive where logic lives – using CSS as an example, but maybe it can be extrapolated to other things like infrastructure configuration.

A primer. CSS is Turing complete, but it doesn't behave like most other languages (no native package support, and hard to share styles between rules).

Past the obvious constraints: i.e., that it must be sent and parsed by the client, how do you decide where it goes?

• Performance – The main option here is to preprocess the code. To be preprocessed, it's easiest to have the code shift to its own files. You rarely see preprocessed and embedded HTML. CSS logic has historically lived in static .css files that are loaded in the headers of HTML documents.

• Security – Initially, the way to extend CSS with dynamic properties was to do JS-in-CSS. Back in the Internet Explorer days, you could do something like .class { width: expression(Math.max(1,2)) }). You can't do that in modern browsers.

• Developers – Who is writing the code? How coupled is it to other presentational logic? Tailwind is a CSS library that provides low-level building blocks to compose styling. This means that developers rarely need to define new classes in CSS and can compose them directly in the markup. You even see attempts at doing CSS-in-JS.

CSS may be a boring example, but the more interesting one (for me) is where infrastructure configuration goes. Is there a Tailwind-like solution that helps consolidate infrastructure and application code?