Separation of concerns was one of the first programming principles I learnt, and is one that continues to be very important, in my mind. However, following this principle in web application development becomes especially challenging. With standalone application development, there is usually a framework put into place to encourage this principle to be fully applied. Let’s take the GUI component of an application as an example: Sun’s Java has Swing and AWT, while Microsoft’s .NET has Windows Forms.
On the other hand, with web development, the HTML page is effectively the GUI component of the application. The HTML page is what the browser on the client side parses and renders into a visible, interactive web page. And the HTML page is where the separation of concerns principle for web apps falls apart.
HTML as a research documentation tool
Back in 1980 when Tim Berners-Lee created the first HTML page, I don’t think he was thinking about web application development, so it wouldn’t be fair to blame him for HTML’s shortcomings. In fact, HTML’s use today is very far-removed from its initial purpose back when it was first conceived: to share research by connecting a number of independent static documents by hypertext.
An HTML page typically contains a mixture of data. First, it contains the actual information we are seeking from the web page (generally known as content). For example, the contents of a paragraph. Second, it contains structural information on how the content should be laid out on the screen (layout). For example, the row and column structure of a table. Third, it contains decorative information on how the data is presented to the user (presentation). For example, the use of bold and italic tags for text.
We wanted more: enter CSS & JavaScript
As the internet grew in usage and popularity, we required our HTML pages to do more. No longer was it simply used as a research tool. The people creating web pages started demanding more control over how everything was displayed to the end user. Furthermore, editing HTML for stylistic purposes was cumbersome at best, and a nightmare at worst.
Then Håkon Wium Lie and Bert Bos came along and invented CSS, making our lives a whole lot easier. Not only do we now have a strangle hold over every last pixel of the displayed HTML page (thank you, CSS-P!), we can also radically change the presentation of the web page by simply swapping the CSS definitions file.
As it turns out, having pretty pages displayed on our browser wasn’t enough. We wanted interaction. Whether it was an image swapping, custom alerts, or dropdown menus, we just had to have them. Brendan Eich then gave us JavaScript and the DOM, thus providing web developers with a way of dynamically manipulating HTML pages.
Separation of concerns made possible (in theory)
From the perspective of the separation of concerns principle, CSS and JavaScript has made up for many of the shortcomings of HTML. For example, we don’t need to use HTML tags such as <font> or <strong> as widely as before. In fact, use of such tags for dynamic pages is highly discouraged, as these are presentation specifics that should be separated from the HTML page and kept in a CSS definitions file instead. With JavaScript, we are able to define behavior for a web page, that can also be separated from the HTML and kept in an imported JavaScript file.
| Concern | Layout | Presentation | Behavior |
| Language | HTML | CSS | JavaScript |
Our ability to separate concerns in a web page is summarized in the above table. If you have actually tried to implement this principle in your web apps, you’ll know that this looks a lot neater in theory than it does in practice.
In a subsequent post, I’ll go into the various issues that have come up for me when I have tried to stay true to the separation of concerns principle.