A few nights ago over coffee at the local Starbucks I enjoyed one of those moments we as web developers secretly love: a full throttle conversation about ideal, multi-tiered web applications. As we broke down tiers and discussed their relationships, we considered different scenarios: what if the user is on a mobile device? What if their connection speed sucks? What if the site they are using has a million controls?

In fact, what if the website looked and needed to behave like a regular application? Would a massive collection of ad hoc jQuery event handlers, Ajax calls / RESTful services and finely crafted HTML be enough? Maybe. But a better solution exists. Enter the framework.

Frameworks and Libraries

A framework is a specialized type of library. For programming languages, a library is a collection of behaviors (think: functionality) written in terms of the language, that can be called by using a well-defined interface. Libraries are meant to be used by multiple programs or in multiple areas of a single program, largely because they encapsulate commonly used functionality set apart from the program’s actual code. This makes writing complicated code somewhat easier, as repetitive / complex chores have already been solved and are only a friendly method call away.

A library is passive. Developers must write their code using that library’s interface to get anything out of it. Thus an entire program can be written never using a library’s treasure trove of functionality, even if available the whole time. Not so with frameworks.

The Take Charge Library

Like the libraries from whence they came (poetically anyway), frameworks are a collection of functionality written in terms of the language they support. Frameworks are portable, meaning they too can be reused in multiple projects written in their given language. However, unlike a library, frameworks are bossy. Using a framework correctly means subscribing to how the framework developers view application organization and development. Let that sink in for a moment. Within a framework, your program no longer directs traffic. The framework becomes the traffic cop, and your program the exotic sports car (or three row SUV, which ever you prefer).

Frameworks share four attributes that set them apart from libraries. Where libraries are accessed as needed, frameworks work on the Hollywood Principle, aka “Don’t call us, we’ll call you.” The framework takes care of business and calls your program when it’s show time. The fancy term for this behavior is inversion of control. Second, a framework must have a default behavior, meaning once installed and properly configured, it has to do something useful right out of the box (typically a “hello world”). Next, they must afford some way for developers to extend their functionality, either by overriding default behavior or by creating new behavior within the internal guidelines. Finally, framework internals are considered off-limits. Extend all you want, look under the hood, show it off to your friends, but don’t touch anything inside. Modify the magic and you void the warranty.

Frameworks In The Wild

During my research I looked at many languages. Each of these languages had at least one framework written for them. So, while a statement like “all languages have frameworks” would probably get me in trouble, I think it is safe to say frameworks have benefits that are tough to ignore, no matter the language. Here are a few popular languages and their corresponding web frameworks:

PHP: CodeIgniter, Zend
Ruby: Padrino, Rails, Sinatra
Java: Grails, Play
Python: Django, Zope2
JavaScript: AngularJS, Ember.js, Backbone
Node.js: Express, geddy, Meteor

In fact, frameworks are so helpful they are even used in CSS. Examples include:

Bootstrap
Foundation 3
Skeleton


Should I use a framework?

Frameworks are not for everybody. Some are better than others in any given situation. Frameworks can have tough learning curves, particularly for the novice developer. The unusual usage demands and seemingly arbitrary control flow may seem senseless until well understood. Framework use can also lead to code bloat by adding unnecessary functionality and inspiring work arounds written by developers unfamiliar with the framework’s complexity. Speaking of complexity, take a look under the covers and marvel at the magic. Pre-implementation study and research is sincerely recommended!

These are real concerns you should absolutely consider. However, frameworks also bring a feast to the table. As well-tested and typically open source application scaffolding, frameworks can help separate concerns in extremely reliable ways, decreasing code spaghetti. In fact code quality is often amplified when developers follow usage rules and color inside the lines. Although structured, frameworks are extensible when necessary – while still cutting development time by taking care of common tasks (just like any other library). Finally, over the long-term the framework becomes invisible, improving project delivery time and code reusability.

Thanks for reading, and happy frameworking!

The conventional approach to detecting screen resolution with JavaScript using RWD requires you to duplicate break points within your actual code and consequently having to maintain them in two different places. Very annoying. Using a flag embedded in each of your CSS break points is a much simpler approach because they can be programmatically accessed. Multiple flag techniques exist, but in this blog post I will discuss my personal favorite, the pseudo-element flag, invented in 2012 by Jeremy Keith and the readers of his blog adactio.

Pseudo-elements?

Pseudo-elements exist in an odd realm. Technically they are not part of the DOM, so they cannot be accessed via traditional selectors nor participate in regular DOM flow. Pseudo-elements, and their cousins, pseudo-classes, are CSS constructions that afford some interesting presentation options. We have all used pseudo-classes before, such as :hover, :focus, and :first-child. Pseudo-elements are used in a very similar way, but not quite as often.

The relationship between real elements and their pseudo-element counterparts:

Element and Pseudo-element relationship

Image Source: Nicolas Gallagher, blog entry Multiple Backgrounds and Borders with CSS 2.1 (original image revised by me to remove some copy not topical to this blog entry, and to trim it down to size).

In fact, pseudo-elements are not new – CSS1 introduced :first-line and :first-letter. CSS2 saw the arrival of :before and :after, and CSS3 has introduced the newest member of the team, ::selection. As a quick side note, CSS3 spec suggests we use double colons (::) when using pseudo-elements, to differentiate them from pseudo-classes, which use the single colon (:). However backward compatibility within browsers ensures the single colon works for both cases, and from a practical standpoint it’s probably best to still use the single colon for now.

The :before and :after pseudo-elements, having been around for many years, are in fact backward compatible all the way to IE8 (not that modern Android or iPhone users care – but it’s still good to know). The caveat however is that the HTML5 document type declaration must be used, or IE8 will poop the bed and forget everything it learned.

Building the Pseudo-Element Flag

While other techniques probably exist, the way I implement pseudo-element flags is to differentiate one at each break point. Therefore, the values contained within each set of CSS rules for each independent flag remain constant. For this reason I like to attach the flag to a relatively safe, static element, the body itself.

body:after{ }

As CSS constructs pseudo-elements enjoy CSS rules not available to conventional DOM objects. One in particular is in fact the secret in our secret sauce:

body:after{
content:"mobile";
}

To ensure the content is not actually displayed we’ll add the final piece:

body:after{
content:"mobile";
display:none;
}

Accessing the Pseudo-Element via JS

Okay so, if a pseudo-element is not part of the actual DOM, how can we access it – or more to the point, the CSS rules defined for it? The answer:

window.getComputedStyle()

This sweet method returns the CSS styles applied to an element and the corresponding pseudo-elements, after the browser has finished applying them. Nifty right?

function whatIsMySize() { return window.getComputedStyle(document.body,':after').getPropertyValue('content'); }

Now you have access to the value of the content property of your pseudo-element. Nice!

Last note: Firefox (maybe others, I haven’t tested them all) will return an extra set of quotes if your content value was a string. So, in the example above, Firefox would return:

""mobile""

Thus for conditionals I like to use:

var checkMySize = whatIsMySize();
if ( checkMySize.indexOf("mobile") != -1 ) { // off to the races }

Thanks for reading!