Behind the Framework

Separation of Concerns is a programming principle that encourages the grouping of functionality in ways that reduce overlap and redundancy. To understand these groupings in browser based architectures, we can take cues from the native browser engine API itself. While we may not always use these APIs, we should take advantage of them as much as we can, and consider their designs as inspiration against our own. As we all know, these groupings map natively to HTML, CSS and Javascript. As engineers we often fail to leverage native groupings and unknowingly create redundancies across the scope of our solutions and the languages themself.

Not to be confused with SoC in context to Model View Controller (MVC). This POV addresses the broader UI engineering bowndries we recognize in HTML, CSS and their relationship with Javascript. Too often we see solutions built in javascript mimicking something that could otherwise have been built natively in HTML or CSS. Or we see something built with a javascript library that could have been built using modern native javascript. Today we’re seeing powerful and emerging capabilities in native HTML CSS and Javascript that challenge patterns and solutions often solved using javascript or javascript libraries. As these languages mature there is a growing need to establish SoC principals around them.

The Three Body Problem

Web based UI Architecture begins with 3 primary concerns, HTML, CSS and Javascript. What complicates separation between these languages is their ability to overlap each other in capabilities. This complexity is compounded when we consider one language can solve a given problem more efficiently then another.

Engineers will often solve a UI problem without considering SoC. For example: Animating DOM elements with javascript instead of using CSS. This often leads to inefficiencies in performance, and avoidable complexities in their solutions. For this reason we need to know which language is purposely designed to solve the right problem.

So how do we determine which one is more efficient?

Having a structured SoC can help us make informed architectural decisions when solutioning for the web. One way to achieve this is to prioritize our concerns by language.

Prioritizing concerns for low-complexity performant solutions:

1. Critical rendering path (CRP) - HTML & CSS are first-class citizens in the CRP
2. Leverage Native HTML - Always use what the browser gives you for free.(HTML & CSS)
3. Logic - Separate Presentation logic (CSS) from Procedural logic (Javascript)

SoC UI Architecture in order of priority:

Begin with HTML and falback to CSS, then Javascript. With each consideration we can seperate solutioning accross these three languages and leverage strengths and capabilities of each.

State MGMT Concerns

Accounting for state management is something that often leads to over architected solutions. As engineers, it's important for us to consider a ranking of our state management requirements when architecting solutions. Similar to data storage, requirements for state management can be ranked on a scale of high or low volatility (State Volatility). In other words, application state is easily erased or can persist forever, or persist somewhere in between. For example: The state of an accordion [expanded] can be lost on page refresh (high volatility) where a Session ID can persist after a page refresh (low volatility). In most high volatility scenarios, engineers are encouraged to architect solutions to lower state volatility. While lowering state volatility sounds good, it also means increasing application complexity. Adding complexity to lower state volatility is a tradeoff we need to consider. In the above example, we can add javascript to persist accordion state on page refresh. While this reduces state volatility on the accordion it might not be necessary and likely adds little value to the overall user experience and application logic. As we separate these concerns we want to minimize complexities leading to over-architecture, and persist state (lower state volatility) only where necessary.

The following list prioritizes state management techniques ranked from high volatility, low complexity (4) to low volatility, high complexity (1) approaches.

1. Server side State - (Session ID, DB etc.)
2. Application State - JS Client side (cookies, local storage, service workers)
3. UI Design state - CSS (variables, has() not() etc.)
4. UI State - HTML(form selection, anchor tags etc.)

Additional Concerns