Webapps and Separation of Concerns

by | May 19, 2011 | Software Development, Webapps | 0 comments

Separation of concerns is a big deal in software engineering.  Program structures should be nicely organized, such that distinct tasks are handled by distinct program elements.  In other words: no business logic wrapped up in our SQL statements; no data access in our user interfaces.  When concerns are not separated, a big ball of mud ensues, and changes to any part of a program ripple around to every other part; the cost of changes to such systems can’t be predicted, and they’re just generally no fun to work on.

OK then; what concerns should be separated, in terms of web application design?  How about these:

  1. The page structure
  2. The page look and feel
  3. The page behavior

Interestingly enough, these 3 concerns map directly to the technologies that so dominate our time:

  1. HTML
  2. CSS
  3. JavaScript

When I wrote that my new project involves some HTML5/CSS3 goodness, I wasn’t quite accurate.  It involves some HTML5/CSS3/JavaScript goodness!

When Web pages separate these concerns, each aspect is easier to read, easier to understand, easier to maintain, and easier to test.

  1. HTML should include only document markup, with hooks for CSS and JavaScript to latch onto (e.g. class attributes, id tags).  No JavaScript in the HTML; no inline styles.  This HTML should be usable as-is, even on devices with no/limited CSS/JavaScript capability.  Even gmail provides an alternative site for users who can’t / don’t want to use the full interactive goodness that is gmail.
  2. CSS should define styles and layouts; it should not include markup; no markup attributes or elements.  Styles should be defined in their own separate files, apart from HTML and JavaScript.
  3. JavaScript defines behavior; feature detection should be used for graceful degradation in the face of missing features.  JavaScript should be in its own separate file, apart from HTML and CSS.  Unobtrusive JavaScript codifies some practices implied by this separation of concerns.

To change the structure, all we have to read is HTML; we don’t have to understand all the implications of the CSS and JavaScript cluttering up the HTML we are trying to change.  Our nicely-encapsulated JavaScript files should aid in supporting the subtle (and not-so-subtle) differences between browsers; the browser quirks are handled in separate JavaScript functions, and don’t clutter our HTML or CSS.

Do your web applications separate markup, look and feel, and behavior nicely and cleanly?  Mine could do better.  Now that I’m aware of these concepts I’m thinking how best to apply them in my projects.

Many thanks to Christian Johansen, whose book Test-Driven JavaScript Development introduced me to these ideas.  The whole book is well worth reading.


Need a bit more info on how Armedia can help you?

Feel free to schedule a 30-minute no-obligations meeting.


Submit a Comment

Your email address will not be published. Required fields are marked *