Most of the times when I start a project, the framework has been previously set and my job has been to inject some best practices where opportunity allows. On personal projects, I do get the opportunity to build from scratch, usually it is to satisfy my curiosity in a certain technology so I haven’t had the liberty (or the forethought) to include all the tools.

However, in recent projects where I have been able to include all the tools available to me and as a result have done most of my projects as such.

So what would you do with such a blank canvas? What tools and frameworks would you use? As a front end developer, this is my list (this list is an approach that considers enterprise development):

NodeJS (as a Web server)

Why use NodeJS and not Apache Tomcat? If you are not familiar with NodeJS, this is a quick description (from their home page):

Node.js is a platform built on Chrome’s JavaScript runtime for easily building fast, scalable network applications. Node.js uses an event-driven, non-blocking I/O model that makes it lightweight and efficient, perfect for data-intensive real-time applications that run across distributed devices.

Back to question of “Why NodeJS?”. The answer is why not. As a developer whose choice of language is JavaScript, this is ideal where as a developer I can modify the web server and can manage the session, cache, memory, etc… This is on top the evented server side JavaScript which is very light weight and has a good handling on lots of I/O by making the majority of I/O calls asynchronous.

Reference:

• http://nodejs.org/

NodeJS (as a package manager)

If you chose not to use NodeJS as a web server, it is still a great tool to install on your machine. Installing NodeJS will give you access to Node Packaged Modules (npm) which opens the door to a wealth of packaged modules that can easily be installed on a local machine, enabling the developer to start developing quickly. The other advantage of npm is also that it will allow developers to package up their modules easily to be shared with other developer. As you will see, most of the tools that I am using can be installed through npm.

Reference:

• https://npmjs.org/

GruntJS

GruntJS is a tack runner which will allow for automation on tasks that as developer we run (or should be running) repeatedly. Tasks like minification, compilation, unit testing, and linting are examples of tasks that can be run every time the developer makes a change. GruntJS is very easy to install and has a large community of developers creating plugins for it.

Reference:

• http://gruntjs.com/

Jasmine

I have been a huge fan of Test Driven Development or Behavior Driven Development. This style of development has several advantages:

1. Capturing the requirements in human readable form
2. Unit test is built from the beginning
3. Test output can be treated as a report
4. Failures are captured early and often

In order to develop in this approach, Jasmine has been one of the tools that I have used. There are other tools like QUnit and Cucumber (I am exploring Cucumber further and may blog about my experience in the near future). Nevertheless, this approach allows me to think of every requirement in the following manner:

Given a context

When an event happens

Then an outcome should occur

 Reference:

• http://en.wikipedia.org/wiki/Behavior-driven_development
• http://pivotal.github.com/jasmine/

Asynchronous Module Definition (AMD)

Asynchronous Module Definition allows for an approach where the developer thinks of their code as a modular functional area which can be used repeatedly in different areas if needed. Addy Osmani describes this best:

The AMD module format itself is a proposal for defining modules where both the module and dependencies can be asynchronously loaded. It has a number of distinct advantages including being both asynchronous and highly flexible by nature which removes the tight coupling one might commonly find between code and module identity. Many developers enjoy using it and one could consider it a reliable stepping stone towards the module system proposed for ES Harmony.

This approach coupled with a powerful script loader like RequireJS can help in building a highly modular systems or web applications.

Reference:

• http://addyosmani.com/writing-modular-js/
• http://requirejs.org/

MV* Framework

MV* frameworks have several advantages like defined framework and pattern but one of the best advantages, in my humble opinion, is organization. These frameworks allow us to tame the beast that is spaghetti code. For the purposes of enterprise development, there are several options out there. I have had personal experience with a few but a list of top 4 frameworks (once again in my humble opinion), would be something like this:

• BackboneJS (for large applications, one should consider backbone layout manager)
• KnockoutJS
• AngularJS
• EmberJS

With these frameworks, a selection of a templating tool is necessary. With BackboneJS and its hard dependency on underscoreJS, Underscore’s templating can be used. For more advanced templating, HandleBar and Mustache should be considered.

Reference:

• http://backbonejs.org/
• http://documentup.com/tbranyen/backbone.layoutmanager/
• http://knockoutjs.com/
• http://angularjs.org/
• http://emberjs.com/
• http://underscorejs.org/
• http://handlebarsjs.com/
• http://mustache.github.com/

Pre-processors

There are several pre-processors available for different aspects of front end development.

CSS

For this aspect, on the top of the list are two main pre-processors, LESS and Sass CSS. A lot of people select LESS because of the adoption of Twitter bootstrap. I am bigger fan of Sass CSS, because it is being maintained more often. Sass CSS also is adding more necessary features.

JavaScript

CoffeeScript being the most popular in this area has a huge following. In the development community, the use of CoffeeScript is divisive, some people really love it and some really hate it.I have used CoffeeScript and see the advantages of using it but I do not have any strong feeling for or against it. Let’s not forget TypeScript for those fans of .NET.

HTML

In this area, HAML and Jade are in the forefront. These tools although help with easy HTML writing.

Reference:

• http://lesscss.org/
• http://twitter.github.com/bootstrap/
• http://sass-lang.com/
• http://coffeescript.org/
• http://www.typescriptlang.org/
• http://haml.info/
• http://jade-lang.com/

No matter the size of the project, a well structured and well written application along with its success may result in a  demand for expansion which is why every code should be written with scalability in mind. These technologies were considered with a scalable, maintainable and well-documented enterprise level architecture in mind.

As a result of this article, I have created a github repository with all these technologies (well most of them) incorporated. Please refer to https://github.com/kianoshp/node-boilerplate for more installation.

• Smooth some of the harsh edges and create code frameworks  i.e. consistent code patterns
• Extends the current process further by adding needed and missing features

A pre-processor like Sass does both.

My introduction to Sass was in 2009 during an interview for a job. During this interview, the interviewer asked me if I knew of Sass. I did not. However after the interview, I googled it and was introduced to the world of sass-lang.com. After the 5 minutes that it took to install it on my Mac (Sorry PC users, it might take 10 minutes for you), I was up and running. I played around with all its features and before I knew it, I was hooked.

In future projects, I was introduced to other CSS specific pre-processors like LESS, Stylus, and Closure Stylesheets. There has been certain feature sets that have made me gravitate back to Sass. Here are some of those features (I have used some code example from a real project) :

The Basics

All CSS pre-processors are built on the DRY (Don’t Repeat Yourself) principle. On that basis they all have the following features:

• Variables
• Import
• Mixins
• Functions
• Selector Inheritance

Variables, Import, and Mixins are basic features that were my first foray into Sass and all by themselves have added quite a punch in this application.

CSS is a great language allowing designers and developers to improve the presentation layer. But until the introduction of pre-processors like Sass it has been a static language that uses its cascading feature to dynamically override styles and apply them to the presentation. With the introduction of Sass, DRY principles were added to CSS and therefore extending its features.

So let’s dive into some code and learn about Sass. The following is an example of a simple CSS. On one of the projects that I have been working on, I needed to create a header for sections of the site. This header will have a linear gradient background and white colored text.

/*This is a variable for the primary color of the side*/

$primary: #00096E;

/*primary grey color to be used throughout the site*/

$greyColor: #E0E0E0;

/*This is an example of a mixin that will create a linear gradient. The advantages of using this is

that we do not have to write the multiple vendor prefixed CSS repeatedly. And code maintenance is easier.*/

//this mixin will create a linear-gradient. The parameters passed here are:
//$pos: position of the gradient which defaults to top but can take bottom, left, or right
//$G1-G10: these allow for 10 color stops values, color and length/percentage
//$fallback: this is the fallback color that will be used for older browsers, if this parameter
//is not provided then the first color stop is used.
@mixin linear-gradient($pos, $G1, $G2: false,
 $G3: false, $G4: false,
 $G5: false, $G6: false,
 $G7: false, $G8: false,
 $G9: false, $G10: false,
 $fallback: false) {

 // Detect what type of value exists in $pos
 $pos-type: type-of(nth($pos, 1));

// If $pos is missing from mixin, reassign vars and add default position
 @if ($pos-type == color) or (nth($pos, 1) == "transparent") {
     $G10: $G9; $G9: $G8; $G8: $G7; $G7: $G6; $G6: $G5;
     $G5: $G4; $G4: $G3; $G3: $G2; $G2: $G1; $G1: $pos;
     $pos: top; // Default position
 }

 $pos: unquote($pos);

$full: $G1;
 @each $g in $G2, $G3, $G4, $G5, $G6, $G7, $G8, $G9, $G10 {
     @if $g != false {
         $full: $full + ',' + $g;
     }
 }

$full: unquote($full);

 //If using COMPASS uncomment the line below and remove line 82 - 89
 //$full: compact($G1, $G2, $G3, $G4, $G5, $G6, $G7, $G8, $G9, $G10);

 // Set $G1 as the default fallback color
 $fallback-color: nth($G1, 1);

// If $fallback is a color use that color as the fallback color
 @if type-of($fallback) == color {
     $fallback-color: $fallback;
 }

background: $fallback-color;
 background: webkit-gradient(linear, $full);
 background: -webkit-linear-gradient($pos, $full);
 background: -moz-linear-gradient($pos, $full);
 background: -ms-linear-gradient($pos, $full);
 background: -o-linear-gradient($full);
 background: unquote("linear-gradient(#{$full})");
}

The above mixin is courtesy of Thoughbot’s Bourbon mix which has quite an extensive collection of Sass mixins and functions.

Functions

Sass comes with several built in functions. These are functions that are commonly used and they fall in the following categories:

• RGB functions
• HSL function
• Opacity functions
• Other Color functions
• String functions
• Number functions
• List functions
• Introspection functions
• Miscellaneous functions

Aside from the built-in functions, custom functions can also be created.

.main-header {

    @include linear-gradient(top, $primary, lighten($primary, 20%));
    color: white;
    display: inline-block;
    font-size: rfs(36);
    margin-left: 20px;

}

In this example, we are taking advantage of built-in color functions by passing the primary color and a 20% percent lighten primary color to our linear gradient mixin. We also are using a custom function that we have created to calculate the pixel font size in em, for a more responsive approach. Here is the detail of that function:

// ==|===Responsive Font Size calculator====================
// Function that will calculate the responsive font size
// return the em value to be used.
// =========================================================*/
@function responsiveFontSize($fontSize: $defaultBrowserSize, $isIE: false) {
    @if $isIE {
        @return (($fontSize/$defaultBrowserSize) - 0.02) + em;
    } @else {
        @return ($fontSize/$defaultBrowserSize) + em;
    }
}
@function rfs($fontSize: $defaultBrowserSize, $isIE: false) {
    @return responsiveFontSize($fontSize, $isIE);
}

For more information on functions, refer to the Sass documentation.

Selector Inheritance

This feature is one of the best features of Sass and one of the least used. This feature allows the user to think of the CSS and its features holistically and ensure the proper relationship among all the presentation elements.

For example there are times that one class will encompass most of the styles needed however there will an addition of other classes that will include not the styles of the more general class but also some of its own. For example, in our code above we have a ‘main-header’ class. Now we want to create sub headers:

.main-header {

    @include linear-gradient(top, $primary, lighten($primary, 20%));
    color: white;
    display: inline-block;
    font-size: rfs(36);
    margin-left: 20px;

}

.sub-header {
    @extend .main-header;
    @include linear-gradient(top, $secondary, lighten($secondary, 15%));
    font-size: rfs(24);
}

In this example, we inherited all the styles from ‘main-header’ and over-wrote the linear gradient with a different color and reduced the size of our font. And the output will look something like this:

.main-header, .sub-header {
    background: #00096e;
    background: webkit-gradient(linear, #00096e,#0011d4);
    background: -webkit-linear-gradient(top, #00096e,#0011d4);
    background: -moz-linear-gradient(top, #00096e,#0011d4);
    background: -ms-linear-gradient(top, #00096e,#0011d4);
    background: -o-linear-gradient(#00096e,#0011d4);
    background: linear-gradient(#00096e,#0011d4);
    color: white;
    display: inline-block;
    font-size: 2.25em;
    margin-left: 20px;

}

.sub-header {
    background: #cfc35d;
    background: webkit-gradient(linear, #cfc35d,#e0d998);
    background: -webkit-linear-gradient(top, #cfc35d,#e0d998);
    background: -moz-linear-gradient(top, #cfc35d,#e0d998);
    background: -ms-linear-gradient(top, #cfc35d,#e0d998);
    background: -o-linear-gradient(#cfc35d,#e0d998);
    background: linear-gradient(#cfc35d,#e0d998);
    font-size: 1.5em;
}

For a more comprehensive example of selector inheritance read this article by Thomas Reynolds.

Placeholder Selectors

Placeholder selectors follow the guideline of selector inheritance with one major improvement, they are silent until needed. A placeholder selector is a series of styles that are created for when there is situation where it is needed. If it is not extended, it will not be compiled to the final css output. If it is extended then the resulted styles will be in the output but the placeholder selector will not be in the compiled css. If we follow the example above, then the code will look like this:

%header-setup{
 color: white;
 display: inline-block;
 margin-left: 20px;
}

.main-header {
 @extend %header-setup;
 @include linear-gradient(top, $primary, lighten($primary, 20%));
 font-size: rfs(36);
}

.sub-header {
 @extend %header-setup;
 @include linear-gradient(top, $secondary, lighten($secondary, 15%));
 font-size: rfs(24);
}

We placed the portion of the styles common to both classes in a placeholder selector and named it header-setup. The output of the code looks like this:

.main-header, .sub-header {
 color: white;
 display: inline-block;
 margin-left: 20px;

}

.main-header {
 background: #00096e;
 background: webkit-gradient(linear, #00096e,#0011d4);
 background: -webkit-linear-gradient(top, #00096e,#0011d4);
 background: -moz-linear-gradient(top, #00096e,#0011d4);
 background: -ms-linear-gradient(top, #00096e,#0011d4);
 background: -o-linear-gradient(#00096e,#0011d4);
 background: linear-gradient(#00096e,#0011d4);
 font-size: 2.25em;

}

.sub-header {
 background: #cfc35d;
 background: webkit-gradient(linear, #cfc35d,#e0d998);
 background: -webkit-linear-gradient(top, #cfc35d,#e0d998);
 background: -moz-linear-gradient(top, #cfc35d,#e0d998);
 background: -ms-linear-gradient(top, #cfc35d,#e0d998);
 background: -o-linear-gradient(#cfc35d,#e0d998);
 background: linear-gradient(#cfc35d,#e0d998);
 font-size: 1.5em;

}

Object Oriented CSS (OOCSS)

Sass allows for a better framework for the implementation of OOCSS. If you are unfamiliar with OOCSS, Nicole Sullivan‘s answer to writing a well structured, efficient and performant CSS; here are a few resources:

• How to write a well structured CSS
• http://oocss.org/
• https://github.com/stubbornella/oocss/wiki
• http://coding.smashingmagazine.com/2011/12/12/an-introduction-to-object-oriented-css-oocss/

Combining Sass and OOCSS principles make for a great way to write CSS. Here are some great articles in this regard:

• http://ianstormtaylor.com/oocss-plus-sass-is-the-best-way-to-css/
• http://takazudo.github.com/presentation-oocss-sass/#/
• http://memerocket.com/2009/03/28/oocss-sass-fewer-classes-on-your-elements/

Conclusion

Sass is a great that will enhance and improve upon CSS. If you have any reservations about using Sass, just experiment with it especially with the SCSS extension which allows you to use regular CSS in their along side with all the features of Sass. Cheers.

• Designer guy: I am not familiar with Sass CSS
• Me: Here is some information on it.
• Designer guy: Compile my CSS? I don’t want to compile my CSS.
• Me: Just use the ‘watch’ feature
• Designer guy: I can’t debug my CSS in the browser.
• Me: Use FireSass (For Firefox only)
• Designer guy: I don’t want to use Sass CSS
• Me: WE ARE USING SASS
• Designer guy: Sass is just a fad
• Me: We are using Sass

Multiple meetings were held that followed the same pattern as above. Looking back, I wish the discussions had gone a different way. Not in the sense that who was right or wrong but in the sense that it  could have been handled better. Introspectively, I could have done better.

Later on at the Backbone Conference in Boston, there were a couple of presenters that made statements like “CoffeeScript, you either love it or hate it”. This got me thinking, why should that be? Why are we in such polarized opinions when it comes to pre-processors in front end development? We are not the US Congress or the Senate for that matter. This got me thinking and started me on a path to find a peaceful solution to this issue.

Can you define pre-processors please?

In researching for this blog, I looked up the word pre-processors and found a lot of information. Wikipedia defines it as:

“In computer science, a preprocessor is a program that processes its input data to produce output that is used as input to another program. The output is said to be a preprocessedform of the input data, which is often used by some subsequent programs like compilers. The amount and kind of processing done depends on the nature of the preprocessor; some preprocessors are only capable of performing relatively simple textual substitutions and macro expansions, while others have the power of full-fledged programming languages.”

By this definition, any work done on the code before compilation is the job of the preprocessor. There are two types of preprocessing:

1. Lexical: This is typically macro substitution, text inclusion, conditional compilation, etc…
2. Syntactical: Syntactical preprocessing’s role is to transform syntax trees according to user defined rules.

In the realm of front end development, most of the pre-processing tools are of the syntactical type. However stepping out of the computer science field, preprocessing exists in many areas of our lives. Couldn’t any encryption or decryption of code be considered as a preprocessor to gaining the underlying information. When a court stenographer types all the information in the court, wouldn’t that be considered a form pre-processing? How about short hand notes?

What tools are available?

In front end development, there has been an increase in the number of preprocessing tools thereby causing a bit of a polarized attitude towards them, not just whether to use any preprocessing tools but also which one. The tools that are available are as such:

• HTML
  • HAML: (HTML Abstraction Markup Language) is a lightweight markup language that is used to describe the XHTML of any web document without the use of traditional inline coding. It’s designed to address many of the flaws in traditional templating engines, as well as making markup as elegant as it can be.
    
  • Jade: Jade is a high performance template engine heavily influenced by Haml and implemented with JavaScript for node. http://jade-lang.com/
  • Zen-coding: In this post we present a new speedy way of writing HTML code using CSS-like selector syntax — a handy set of tools for high-speed HTML and CSS coding. It was developed by our author Sergey Chikuyonok.
• CSS
  • Sass/Compass: Sass is an extension of CSS3, adding nested rules, variables, mixins,selector inheritance, and more. It’s translated to well-formatted, standard CSS using the command line tool or a web-framework plugin. Compass is an open-source CSS Authoring Framework.
  • LESS: extends CSS with dynamic behavior such as variables, mixins, operations and functions. LESS runs on both the client-side (Chrome, Safari, Firefox) and server-side, with Node.js and Rhino.
  • Stylus
• JavaScript
  • CoffeeScript: CoffeeScript is a little language that compiles into JavaScript. Underneath all those awkward braces and semicolons, JavaScript has always had a gorgeous object model at its heart. CoffeeScript is an attempt to expose the good parts of JavaScript in a simple way.
  • IcedCoffeeScript: IcedCoffeeScript is a superset of CoffeeScript. The iced interpreter is a drop-in replacement for the standard coffee interpreter; it will interpret almost all existing CoffeeScript programs.
  • Dart: Dart is a new web programming language with libraries, a virtual machine, and tools. Dart helps developers build structured modern web apps. Dart compiles to JavaScript to run across the entire modern web.
  • GWT: Google Web Toolkit (GWT) is a development toolkit for building and optimizing complex browser-based applications. GWT is used by many products at Google, including Google AdWords and Orkut. It’s open source, completely free, and used by thousands of developers around the world.

How to argue correctly about preprocessors

At the Boston Backbone Conference 2012, Andrew Dupont had a great presentation about “How to argue about JavaScript”. This was a result of the famous discussion about semicolons – between Douglas Crockford and the world. Andrew outlined some great strategies and tactics to use when having a discussion (which I will shamelessly steal).

A lot of the times, we enter a discussion holding steadfast to our position and we feel that if we budge even a little bit then we have lost. This is unfortunately mirrored in our political environment and may give us a slight albeit wrong justification.

“In science it often happens that scientists say, ‘You know that’s a really good argument; my position is mistaken,’ and then they actually change their minds and you never hear that old view from them again. They really do it. It doesn’t happen as often as it should, because scientists are human and change is sometimes painful. But it happens every day. I cannot recall the last time something like that happened in politics or religion.”

Carl Sagan

When entering a discussion, one should consider approaching it as a scientific discussion vs. a political debate. Here are some more tactics and guidelines.

Discussion goals and tactics

On August 20th 2012, after hearing Representative Todd Akin’s comments regarding ‘Legitimate Rape’ saddened me as an American and human being. So I decided to post my thoughts on Facebook:

What started as an attempt to be diplomatic while expressing myself, ballooned into a full fledged political discussion. What made it worst was a comment from a friend:

The photo in question is this:

This was just a landmark in Seattle and being a proper tourist, we decided to take picture with it. That’s all. However this is an example of how discussions can get out of hand. In our community, the development community, we have plenty of vitriolic discussions. Let’s not forget the Semicolon war of 2012 or the selective tragedy of 2008.

I try, everyday I try to better myself especially when it comes discussions like this. The following are some of the tactics that I use in order to improve (these are mostly excerpt from the book “Getting to Yes negotiating agreement with giving in” by Roger Fisher and William Ury).

Goals of an argument

An argument/discussion has three goals:

• It should produce a wise agreement, if possible
• It should be efficient
• It should not damage the relationship between the parties

Looking back at my interaction with “Designer guy”, I should have outlined and presented the reasons behind the use of Sass better or tried to reach a compromise for example let’s try it out for a while (a week or two) and re-visit this discussion then.

Tactics for an argument

• Separate the people from the problem
• Focus on interests, not positions
• Invent options for mutual gain
• Insist on objective criteria

In my example, I should have outlined our goals e.g. better development methods which is also a common goal and common interest.

Discussion preparation

When entering a discussion prep yourself in the following manner:

• Retain the willingness to be convinced
• Imagine where others are coming from
• Account for your own taste
• Account for your own emotions

Take a deep breath

When in a discussion follow these rules:

• Be nice
• Speak with surgical precision
• Be honest in your characterizations
• Don’t rise to the bait of others vitriol

If you see me taking a deep breath and counting to 10 (in my head), don’t take it personally.

Conclusion

I consider myself a work in progress when it comes to civil disagreements. However there will be times that one will have to walk away from a discussion. Don’t be afraid to do that, time will sort out the right from the wrong.

Further Reference

• Nicole Sullivan’s “Don’t feed the trolls”

The opportunity came up on my next project with MIT where I inherited a website in dire need of structure and organization. This is where my previous research paid off and I choose KnockoutJS to implement and this is what I learned in the process.

What does MVC mean for Front End Development?

When it comes to development, there are several design patterns and the MV* frameworks are examples of one design pattern. There is the all familiar MVC and there is also MVP and MVVM. Nevertheless, all these frameworks have similar baseline structures with minor differences. For simplicity sake, I will concentrate on MVC framework.

“The idea behind [MVC] is to make a clear division between domain objects that model our perception of the real world and presentation objects that are the UI elements we see on the screen…Domain objects should be completely self contained and work without reference to the presentation, they should also be able to support multiple presentation, possibly simultaneously.”

Martin Fowler

• Model: domain or structural objects representing the application’s state. If your application has data or logic, then you need a model. Your application can be broken down into different models for example users, photos, experiments, classrooms, etc… These models contain a state that will be displayed to the user  in the “View”.
• View: Observes the model’s state and generates output for the user. This is generally the part of the application the user sees and it is our way of displaying the model to the user through markup and templates.
• Controller: Translates the user input into operations on the model. As the user interacts in the “View”, the controller captures the interaction and updates the state of the “Model”. Subsequently the implementation of an observer pattern will update the “View” with the latest state of the “Model”.

The frameworks that support the MV* structure are numerous, here are a few options:

• BackboneJS
• KnockoutJS
• EmberJS
• SproutCore
• AngularJS
• BatmanJS
• Which ever one that has been written in the last hour…

When should one choose one of these frameworks? Some people think that if your application reaches certain level of complexity, you should be using one these frameworks. I am of the humble opinion that, aside from informational websites that can be written with WordPress, Drupal, or simple HTML (and no backend or database interaction), should adopt an MV* framework. Many sites may start as simple applications but your simple application especially if successful will become complex and at that point it may be too late and more difficult to implement these frameworks.

One of the best tools to evaluate the different types of MVC frameworks is Addy Osmani’s TODO MVC site. This site shows you how to implement a simple todo application using different frameworks.

Benefits of Using a MV* Framework

• Separation of concerns: This is the main goal of an MVC framework, to be able to separate the different working areas of the site into Model, View, and Controller.
• Easier overall maintenance
• Side by side development: This is a  benefactor of the separation of concerns which will allow developers to work side by side on different parts of the application with reduced over-stepping on each others work.
• Organization: If you have had to trudge through as much spaghetti code as I have, then this will be your favorite benefit of these frameworks.

One thing to consider is that these frameworks are not a substitute for good JavaScript development. These frameworks will enhance your code, it could enhance good code or bad code; you pick.

MVVM

MVVM was originally defined by Microsoft for use with Windows Presentation Foundation (WPF) and Silverlight, having been officially announced in 2005 by John Grossman in a blog post about Avalon (the codename for WPF). It also found some popularity in the Adobe Flex community as an alternative to simply using MVC. In the MVVM framework, the “Model” and the “View” follow the definitions as stated above. The “ViewModel”, as the name suggests, is the go between the View and the Model. The ViewModel can be considered a specialized Controller that acts as a data converter. It changes Model information into View information, passing commands from the View to the Model. For example, the Model may contain a boolean value like isAvailable, it is up to the ViewModel to interpret that and display the correct information to the user.

Benefits of KnockoutJS

• Declarative bindings: Easily associate DOM elements with model data using a concise, readable syntax
• Automatic UI refresh: When your data model’s state changes, your UI updates automatically
• Dependency tracking: Implicitly set up chains of relationships between model data, to transform and combine it
• Templating: Quickly generate sophisticated, nested UIs as a function of your model data

Next Steps

In order to better understand KnockoutJS, I have created a tutorial creating a Flickr app. Creating this app will help in better understanding of the KnockoutJS.

References

• KnockoutJS
• Understanding MVVM – A Guide For JavaScript Developers by Addy Osmani
• The Plight of Pinocchio a presentation by Brandon Keepers

Model

In this example the Model will contains the information/data for the application. In this case we have two types of data, Photo and Favorite. The Photo model will have the following structure:

  Photo = function(id, owner, title, farmId, serverId, secret, ispublic, isfriend, isfamily) {
    this.id = id;
    this.owner = owner;
    this.title = title;
    this.farmId = farmId;
    this.serverId = serverId;
    this.secret = secret;
    this.ispublic = ispublic;
    this.isfriend = isfriend;
    this.isfamily = isfamily;
  };

The Favorite Model is simply a collection of Photo models:

  Favorites = function(Photo) {
    return this.Photo = Photo;
  };

ViewModel

The ViewModel not contains the objects that will be used in the view but also the functions and interactions between the model and the view. The first step is to create observable objects. KnockoutJS has three types of observable objects:

• Simple object
• Function
• Array Object

Here are some how the observables will be used in KnockoutJS:

// Simple object
var myViewModel = {
    personName: ko.observable('Bob'),
    personAge: ko.observable(123)
};

//Function
function AppViewModel() {
    this.firstName = ko.observable('Bob');
    this.lastName = ko.observable('Smith');
    this.fullName = ko.computed(function() {
        return this.firstName() + " " + this.lastName();
    }, this);
};

//Array
var myObservableArray = ko.observableArray();    // Initially an empty array
myObservableArray.push('Some value');            // Adds the value and notifies observers

Keep in mind that some browser do not support getters and setters so all ko.observable objects are functions In order retrieve a set value, one will have to use the following code:

myViewModel.personName(); //will display Bob

To change the value of a viewModel, you will implement in the following manner:

myViewModel.personName('Roy');
myViewModel.personName(); //will display Roy

In order to create the proper structure, the first step is the create the objects of the viewModel. Some of the time, these objects will mirror the model data that has been returned from the server. However there will be times where we will need to create an object reflecting not only the information displayed to the user but also to record the interactions with the user. In our application, we have created a photos object which contains arrays of ‘image’ objects. The ‘image’ object has the following structure:

• Photo object: this is an instance of the Photo object created in model
• Photo src: this is the source for our image to be retrieved from Flickr

  photoViewModel = {
    //Photos: will be an array of image objects which will contain
    //Photo object and photo src
    photos: ko.observableArray([]),
    //Favorites
    favorites: ko.observableArray([])
  }

As you can see, the ‘photos’ and ‘favorites’ objects are initialized as empty knockout observable arrays. This is all that is needed in order to initially render the page. Once the user searches for a certain tag i.e. cat, dog, table, etc.., we will fire off a request to Flickr to retrieve the images. In the viewModel, we also create functions

photoViewModel = {
 ... //Photos and Favorites object are here //Function that will retrieve all the photos based on the search tag
 //and place them in the photos viewmodel
 getPhotos: function(formElement) {
   var searchTag, that;
   //reseting the previous search results
   photoViewModel.photos([]);
   //getting the search tag
   searchTag = $(formElement).find('#search').val();
   that = this;
   $.getJSON(flickrURL + searchTag)
   .done(function(photoData) {
     return _.each(photoData.photos.photo, function(photo) {
       var image;
       image = {
         photoObj: new Photo(photo.id,
                             photo.owner,
                             photo.title,
                             photo.farm,
                             photo.server,
                             photo.secret,
                             photo.ispublic,
                             photo.isfriend,
                             photo.isfamily),
         photoSrc: that.createSrc(photo.farm,
                                           photo.server,
                                           photo.id,
                                           photo.secret,
                                           'thumbnail')
       };
       return that.photos.push(image);
     });
   });
 }
}

We also need a function that will create the src URL for the images for us.

//Function that will create a src URL to be retrieved from Flickr</pre>
createSrc: function(farmId, serverId, id, secret, size) { return 'http://farm' + farmId + '.staticflickr.com/' + serverId + '/' + id + '_' + secret + (size === "thumbnail" ? "_s.jpg" : "_n.jpg"); } 

To add a photo to the favorites, we simply take the photo object that the user has selected and add it to the favorites array. By simply adding the object to the array combined with the fact that the favorites object is bound to the DOM element on the view, the photo will appear in the designated area.

 //Function that will add the selected photo to the favorites viewmodel
 addToFavorites: function(id) {
   var currentPhotoObj, favoriteExists;
   //getting the photo object of the selected photo
   currentPhotoObj = _.find(photoViewModel.photos(), function(photo) {
     return photo.photoObj['id'] === id;
   });
   //Checking to see if the item exists in the favorites or not
   favoriteExists = _.find(photoViewModel.favorites(), function(favorite) {
     return favorite.photoObj['id'] === currentPhotoObj.photoObj.id;
   });
   //adding the photo object to the favorites list
   if (!favoriteExists) {
     photoViewModel.favorites.push(currentPhotoObj);
   }
 },
 

The remaining code will perform the following functions:

• remove from favorites
• Show larger image

//Function that will remove the selected photo from the favorites viewmodel
 removeFromFavorites: function(id) {
   return photoViewModel.favorites.splice(_.indexOf(photoViewModel.favorites(),
                _.find(photoViewModel.favorites(), function(favorite) {
                  return favorite.photoObj['id'] === id;
                })), 1);
 },
 //Function that will show the larger image in the a modal box
 showLargerImage: function(id) {
   var currentPhotoObj, imageSrc;
   currentPhotoObj = _.find(photoViewModel.photos(), function(photo) {
     return photo.photoObj['id'] === id;
   });
   imageSrc = photoViewModel.createSrc(currentPhotoObj.photoObj.farmId,
                                       currentPhotoObj.photoObj.serverId,
                                       currentPhotoObj.photoObj.id,
                                       currentPhotoObj.photoObj.secret,
                                       'large');
   $('body').modal({
     height: 'auto',
     width: 'auto',
     loaderImgSrc: 'img/loader.gif',
     showSpinner: false
   });
   $('body').modal('openModal');
     return $('body').modal('updateContent', $('</pre>
<img alt="" />').attr('src', imageSrc)); } }; 

Note that in this process, we are using underscore.js and jquery.modal.js (a jquery plugin that I wrote myself).

View

The view being the center where we display the model at its current state to the user and also give the user the ability to modify/update the model. This is the markup for the search box:

<header>
<h1>Photo Finder</h1>
<strong>Search for photos in Flicker using tags</strong><form data-bind="submit: getPhotos">
 <input id="search" type="text" />
 </form>
</header>

As you can see, we have bound the submit button to the ‘getPhotos’ function in our view model. This binding (for the submit button binding ensure that the button is in a form) will prevent the default submit action but also will allow you to use the form as a handler for the view model and perform the specific function needed. In our case, we use it to retrieve the Flickr photos and place them in our view model. Once the photos are retrieved, we add them to the photos object in the view model. Because the view model is bound to the DOM, therefore consumed by the ‘photos-template’. At this point, any changes made to the photos object in the view model will be reflected in the UI automagically.

</pre>
<div id="main">
<h4>Search Results</h4>

<hr width="81%" />

<div id="results" data-bind="template: 'photos-template'"></div>
...<script id="photos-template" type="text/html">// <![CDATA[
<ul class="clearfix">
 {{each photos}}
	<li>
<div class="imgResult"><img src="${photoSrc}" id="${photoObj.id}" alt="${photoObj.title}-    ${photoObj.owner}" title="${photoObj.title}" /></div>
<div class="tabs"><img src="img/fav-icon-sketch.png" width="40%" alt="add to favorites" data-bind="click: function() { addToFavorites(photoObj.id) }"/>
          <img src="img/enlarge-sketch.png" width="40%" alt="show larger image" data-bind="click: function() { showLargerImage(photoObj.id) }"/></div></li>
{{/each}}</ul>
// ]]></script>

Also please notice that we have not only bound the photos object to this markup/template but we have also bound a couple of ‘click’ events that will call the appropriate function, passing the the photo id. Similar treatment for the favorites section:

</pre>
<div id="favs">
<div class="header">Favorites<img src="img/fav-icon-sketch.png" alt="add to favorites" width="15%" /></div>
<div id="favorites" data-bind="template: 'favorites-template'"></div>
</div>
<h3>...<script id="favorites-template" type="text/html">// <![CDATA[
<ul class="clearfix">
 {{each favorites}}
	<li>
<div class="imgResult"><img src="${photoSrc}" id="${photoObj.id}" alt="${photoObj.title}-${photoObj.owner}" title="${photoObj.title}" /></div>
<div class="tabs"><img src="img/remove-sketch.png" width="40%" alt="add to favorites" data-bind="click: function() { removeFromFavorites(photoObj.id) }"/></div></li>
{{/each}}</ul>
// ]]></script>

Reference

• https://github.com/kianoshp/KnockoutJS-Demo

Next Steps

Common complaint of KnockoutJS is the what seems like the mixing of javascript, data-bind attributes, and markup. However KnockoutJS allows you to create custom bindings. One option to combat the overly tied application logic to the view is to create a custom binding similar to CSS classes. Ryan Niemeyer has suggested this procedure. In part II of this tutorial, we will tackle this option.

The event had the following lineup:

Day 1

• Keynote – Jeremy Ashkenas, New York Times, Backbone project
• Ember.js – Yehuda Katz, Tilde
• How to argue about JavaScript – Andrew Dupont
• MVC Module Magic – Alex Sexton, Bazaarvoice
• AngularJS, Testability in Mind – Vojta Jina, Google
• New Dogs, Old Tricks (or DOJO already did that) – Rebecca Murphey, Bocoup

Day 2

• Lumbar Support – Brad Dunbar, Pathable
• Migrating a Large Project to Backbone – Sam Clay, NewBlur
• Real-World with Realtime – Henrik Joreteg, &yet
• Building Robust Backbone Applications: AirBnb’s Journey Into Mobile Web – Harrison Shoff, AirBnb
• Y.App: Coordinating URL Navigation, Routing, and Managing Views - Eric Ferraiuolo, YUI, Yahoo!
• The Plight of Pinocchio: JavaScript’s Quest to Become a Real Language - Brandon Keepers, GitHub

Day 1

Keynote address

Jeremy’s introduction of Backbone was a great way to start the venue. Jeremy took the time to outline the reasons behind the Backbone project, the simplicity of it, its light weight advantage and its extensibility. Here is the presentation by Jeremy:

Further Reference

https://speakerdeck.com/u/jashkenas/p/state-of-the-backbone

Ember.js

It was interesting to witness the battle between EmberJS and BackboneJS. My limited experience in either prevents me from declaring a winner nor should one be declared.

I enjoyed the talk Yehuda gave on his project, Ember.js. I have been following Yehuda ever since he branched this project from Sproutcore and started developing Ember.js.

Being a fan of MV* development, I have used KnockoutJS in the past, will be using Backbone in my next project and will definitely be experimenting with EmberJS in the future.

Further Reference

https://speakerdeck.com/u/wycats/p/backboneconf-emberjs

http://emberjs.com/about/

How to argue about JavaScript

I really enjoyed this topic and very much appreciate that Andrew decided to talk about this. Being in the development community, I have been disheartened about some of the immature and at times vitriolic discussions online which has resulted in discouraging me to express my opinion at certain times. Andrew pointed out the mistakes of our community quite vividly and took the time to give solutions. I do hope that his talk does not fall on deaf ears.

Further Reference

http://www.slideshare.net/savetheclocktower/how-to-argue-about-javascript-13167253

MVC Module Magic

Alex coining the term ‘MVWTF’ was priceless. His outline of the app structure which I have been guilty of, was very informative. Making debugging and using require were some points that I will definitely be using in the future.

Further Reference

http://alexsexton.com/talks/backboneconf2012

AngularJS

At this point it would have been quite easy to roll my eyes and wonder why do we need another MV* framework. However Vojta did a great job presenting and doing some live coding, which in my experience can go awry quite easily, that pointed it out all the aspects of framework. Being a fan of MVC frameworks, I may or may not try this framework in the future (must draw the line somewhere).

Further Reference

http://vojtajina.github.com/html5la/2012-05-30-boston/index.html#/slides/

https://github.com/vojtajina/ng-todo

http://angularjs.org/#/list

New Dogs, Old Tricks (or DOJO already did that)

I always enjoy Rebecca’s presentations. She has the right mix of information, humor and  getting off track (and getting back on track). I really liked the extension of the Backbone.View resulting in a SuperView. This is an approach that I will be implementing in the future.

Further Reference

https://github.com/rmurphey/srchr-demo

http://pinboard.in/u:rmurphey/t:new-dogs-old-tricks/

http://dl.dropbox.com/u/2916642/code/superview/base.html#section-8

Day 2

Lumbar Support

Brad’s presentation was chock full of various gotchas that were very informative. I especially liked the SupermodelJS that he had created in order to track the model relationships. I have used Backbone relational in the past and will definitely be considering this extension.

Further Reference

https://speakerdeck.com/u/braddunbar/p/lumbar-support

http://pathable.github.com/supermodel/

Migrating a Large Project to Backbone

Sam’s experience mirrors the current project that I am starting. I would have loved to sit down and talk further with Sam regarding his experience but alas time did not allow this (Sam if you are reading this, DM me on twitter if you have time to chat).

Further Reference

http://lanyrd.com/2012/backboneconf/stpyh/

http://ricostacruz.com/backbone-patterns/

Real-World with Realtime

This was certainly the most entertaining presentation of the conference (the song in the middle was quite courageous). I have not had the privilege to work on a real-time app but hopefully in the near future I will have the chance and take advantage of the wisdom given in this presentation.

Further Reference

https://speakerdeck.com/u/henrikjoreteg/p/real-world-realtime-with-backbone

http://andyet.net/blog/tag/backbone/

Building Robust Backbone Applications: AirBnb’s Journey Into Mobile Web

I wanted to applaud Harrison’s bravery for tackling an endeavor like this and coming through with a great product. To start a mobile project, with such a close deadline and selecting Backbone and Coffeescript while not having experience in any of them was as Harrison mentioned “jumping off a cliff and try to build wings on the way down”. The amazing part is that they did build those wings!!

Further Reference

https://speakerdeck.com/u/hshoff/p/airbnbs-journey-into-mobile-web

http://airbnb.com

Y.App: Coordinating URL Navigation, Routing, and Managing Views

Eric did a great job outlining the difference in performance between full path URLs and hash tag event based URLs. However I don’t think I agree with the need to steer away from hash tag event based URLs. In the single page applications that I have created, this has been an essential  part of the process. His presentation is something that I will have read further on and mull it over.

Further Reference

https://speakerdeck.com/u/ericf/p/yapp-coordinating-url-navigation-routing-and-managing-views

The Plight of Pinocchio: JavaScript’s Quest to Become a Real Language

TEST DRIVEN DEVELOPMENT, what a concept!! Implementing this approach is a great idea but at times getting your team members to follow this path has been a feat for the centuries. However it is great to hear that others are beating this drum.

Further Reference

http://opensoul.org/blog/archives/2012/05/16/the-plight-of-pinocchio/

I had great time at this event and would like to thank Bocoup and all involved in organizing this.

Presentation slideshow:

Demo files

Video

Further Reading

• Know the CSS Specificity and inheritance rules
• CSS Lint
• Commenting
• Beautification: ensuring that the CSS code that is written follows a coding standard for example curly bracket placement or indentation
• Use of pre-processors like SASS, COMPASS, LESS, and STYLUS

To review the topics that were discussed in part one of this post,the rules were:

• DRY – Don’t Repeat Yourself. This means taking advantage of the cascading rules of the stylesheet and writing the minimal amount of CSS in order to apply the styling.
• Performance – to keep the CSS file lightweight, the above rule (DRY) is very important. Consider the CSS specificity and inheritance for better performance (there is a great article on Smashing magazine regarding CSS Specificity). Also minimizing and removing comments is also important, therefore running the CSS through a minification process can help in keeping it lightweight.
• Know when to place all CSS styles in a single file and when to break up modular portions of the CSS into it own CSS file.
• Follow front end development separation of concerns tightly which means that everything that concerns presentation styles should be in the CSS (and only in the CSS).

We had also outlined a few guidelines:

• Start with a reset or normalize CSS
• Set default values
• Follow the DOM
• Class begins

Note: In regards to the “Class begins” guideline where we talked about creating classes as they are needed for styling. This concept follows the rule of single responsibility principle. Harry Roberts of csswizardry.com wrote a great article regarding the single responsibility principle applied to CSS.

Continuing with further CSS guidelines:

CSS Specificity and inheritance

I am not a big fan of using “!important” in a CSS file. I know that it exists, what it is used for, and I know that at times it is necessary. I believe that every CSS file should get a limit of 10 applications of ‘!important’ in it (even less for small sites), and any overuse of this rule by a developer is to be considered heretical and may cause the revocation of their CSS badge.

CSS specificity and inheritance is what the “cascading” definition in CSS is all about. Used correctly and it will help not only facilitate better writing of CSS but it will also help in debugging an errant CSS style.

Although this is not a simple concept to grasp, however if there is any recommendation I can make is that – LEARN AND UNDERSTAND THIS CONCEPT!! Here are some really great reference material:

• CSS Specificity: Things you should know http://kiano.sh/MnDQm2
• CSS Specificity and Inheritance http://kiano.sh/MnDVpX
• Specifics on CSS Specificity http://kiano.sh/MnE0K0
• Specificity calculators:
  • Star Wars approach http://kiano.sh/MnE64m
  • Poker game approach http://kiano.sh/MnE8cL

CSS Lint

CSS Lint  a tool written by Nicole Sullivan which validates CSS code. This is great tool to ensure that your CSS code is valid. I have used this in the past to consistently validate my CSS code. On the major benefits of this tool is that it can also be run from the command line  and incorporated into the build system (https://github.com/stubbornella/csslint/wiki/Command-line-interface)

Comments

As deadlines approach, sometimes developers cut what may be considered non-essential processes, “comments” are one of them. I know this because I am guilty of it. As we know when the deadline passes and with further development, we touch and review old code; there are times when we ask out loud “Why did I write this code this way?” (this point is 1000 times exasperated when trying to read someone else’s code).

So make commenting in all aspects of coding an essential habit.The approach I take for commenting is as follows:

• Add comments to outline a section. To indicate the beginning and the ending of a certain section.

/* ==|== primary styles =====================================================
 All CSS pertaining to the site will go here. Also keep in mind that any mixins created
 will go in '_mixins.scss' file. All functions will go in the specific functions file labeled
 '_<function_name>.scss
 Author: Kianosh Pourian

Comment Legend
 prefix = tpl = Template Styles

================================================================== */
/* CSS code will go here */

/* ==|== end primary styles ========================================== */

• Also use comments to explain some of the classes, how, and even where they should be used

/* ==|== header classes ======================================
 These classes apply to the header. They are as follows:
 1. tpl-subBrand: sub-branding section of the site. Located on the top left.
 2. tpl-userInfo-linear-gradient: class to apply gradient to the element.
 3. tpl-userInfo-Cont: container showing logged in user's information.
   a. tpl-userInfo-photoCont: container showing the user's photo.
   b. tpl-userInfo-first & tpl-userInfo-las: borders flanking the user
     information section.
 ============================================================== */
.tpl-subBrand {
   @include add-margin(all, 7px 0 0 10px);
}
.tpl-userInfo-linear-gradient {
   @include linear-gradient(top, #405979 0%, #334455 100%);
}

.tpl-userInfo-Cont {
   height: 55px;
   width: 315px;
   @include add-border(all, 1px, solid, #121212);
   @include add-border-radius(all, 5px);
   @include add-margin(all, 15px 15px 0 0);
   @include box-shadow(false, 0, 0, 6px, 1px, #121212);
   a {
     background: url("../img/sprites/coreSprite.png");
   }
.tpl-userInfo-photoCont {
     background: #333;
     height: 40px;
     width: 40px;
     @include add-border(all, 1px, solid, #2b2b2b);
     @include add-border-radius(all, 3px);
     @include add-margin(all, 7px 30px 0 0);
   }
   .tpl-userInfo-first {
     left: 0px;
     @include add-border-radius(top-left, 5px);
     @include add-border-radius(bottom-left, 5px);
     @include box-shadow(true, -4px, 0, 6px, -3px, #000);
     a {
       background-position: -0px -0px;
     }
   }
   .tpl-userInfo-last {
     right: 0px;
     @include add-border-radius(top-right, 5px);
     @include add-border-radius(bottom-right, 5px);
     @include box-shadow(true, 4px, 0, 6px, -3px, #000);
     a {
       background-position: -20px -0px;
     }
   }
}//end .tpl-userInfo-Cont
/* ==|== end header styles ================================== */

• Inline comments should be used sparingly and as needed.

Beautification (coding standards)

Following a coding standard will not only make the code more readable but also help in finding issues faster. Proper indentation and syntax highlighting should be set and followed. There are several CSS beautifier tools that can be used for this effort or better yet, as you are coding ensure that you are following the coding standards that has been agreed upon. Here are some CSS beautifiers:

• http://www.codebeautifier.com/
• http://cssbeautify.com/
• http://www.lonniebest.com/FormatCSS/

To pre-process or not to pre-process, that is the question

There are different views about whether to use pre-processors like SASS, COMPASS, LESS, STYLUS, etc… This article is not about convincing you in one way or another (more talks about pre-processors coming up in other blog posts). Frankly in order to write a well structured CSS, the use of pre-processors is not necessary. However in regards to using pre-processors, I will give the following advice:

• Know your CSS: pre-processors are only tools that only help in writing CSS proficiently; what it will not do is write proper CSS. So know CSS well, whether you are using pre-processors or not.
• Another tool in your arsenal: Pre-processor like SASS and LESS give writing CSS a new dimension of dynamic coding which did not exist. In my humble opinion, anything that can help in making writing CSS easier and more robust is aces in my book.
• One last point: Use them! I have been using SASS for the past year and I really have enjoyed it. It has made the process of writing CSS very fluid and easy.

Further reading

• Pre-processors:
  • SASS
  • LESS
  • STYLUS
  • COMPASS

CSS patterns, is there such a thing? A pattern of writing proper and well-structured CSS? There are great articles by Jonathan Snook regarding Decoupling HTML and CSS and Nicole Sullivan regarding Object Oriented CSS, however they do not outline how to write a well structured CSS.

So the question is “is there a point of reference on the common standards for writing a well structured CSS?”. As I was trying to explain to a junior developer how to set up a well structured CSS, I was trying to find references on the internet to point them to it. There were a lot of issues I found with the results I got from a Google search:

• Most of the articles were 2 or more years old. Not that CSS has changed much since (other than the ever changing CSS3) however we have learned quite a bit on how to set up a well-structured CSS that does require revisiting.
• Most of the articles were very light in examples and/or guidance.
• There were plenty of aricles on the syntax of CSS but not much on proper structuring of the file

As a result, I decided to outline the approach I take in writing the CSS for every project. I understand that there are different approaches to writing CSS and some may agree or disagree with my approach and I welcome that! I am always eager to discussing  a better approach, so feel free to write your agreement or disagreement in the comments section.

For every CSS project, I follow these general rules:

• DRY – Don’t Repeat Yourself. This means taking advantage of the cascading rules of the stylesheet and writing the minimal amount of CSS in order to apply the styling.
• Performance – to keep the CSS file lightweight, the above rule (DRY) is very important. Consider the CSS specificity and inheritance for better performance (there is a great article on Smashing magazine regarding CSS Specificity). Also minimizing and removing comments is also important, therefore running the CSS through a minification process can help in keeping it lightweight.
• Know when to place all CSS styles in a single file and when to break up modular portions of the CSS into it own CSS file.
• Follow front end development separation of concerns tightly which means that everything that concerns presentation styles should be in the CSS (and only in the CSS).

Side Note: The ‘DRY’ concept of CSS can be better implemented by using tools like SASS, LESS, and COMPASS. Consider looking into these tools and using them in your next project.

With the above rules in mind, here are some guidelines to follow:

Start with a reset or normalize CSS

Reset CSS as Eric Meyers states “The goal of a reset stylesheet is to reduce browser inconsistencies in things like default line heights, margins and font sizes of headings, and so on.”

Normalize CSS  a project started by Nicolas Gallagher and Jonathan Neal performs the following:

• Preserves useful defaults, unlike many CSS resets.
• Normalizes styles for a wide range of HTML elements.
• Corrects bugs and common browser inconsistencies.
• Improves usability with subtle improvements.
• Explains what code does using detailed comments.

The benefit of using either reset CSS or normalize CSS is that it will give the canvas (i.e. presentation layer) a consistent look in a world marred by inconsistent browser interpertation of the CSS styling. The difference between reset CSS and normalize CSS is that reset CSS will wipe the canvas clean regardless of which browser is being used while normalize CSS will preserve some defaults and updating the inconsistent ones. Regardless of which one is used, one of the above should be your starting point.

Set default values

Once the reset or normalize CSS has been set, set default values that will govern the entire site. At this point, the governing rule or global defaults like font-family, anchor tag settings, input settings, and etc… will be set. The following is an example of global defaults from Tim Wright’s site www.csskarma.com:

	html {
		text-align:center;
		overflow-y:scroll;
		-webkit-font-smoothing:antialiased;
		-webkit-text-size-adjust:none;
		   -moz-text-size-adjust:none;
		    -ms-text-size-adjust:none;
		        text-size-adjust:none; }
	body {
		text-align:left;
		color:#333;
		position:relative;
		font: 0.75em/1.5 Sans-serif; }

	h1,h2,h3,h4,h5,h6 {
		margin-bottom:24px;
		font-weight:700; }

	h1 {
		font-size:1.5em;
		line-height:1em; }

	h2 {
		font-size:1.375em;
		line-height:1.0909em; }

	h3 {
		font-size:1.25em;
		line-height:1.2em; }

	h4 {
		font-size:1.125em;
		line-height:1.333em; }

	h5,h6 {
		font-size:1em;
		line-height:1.5em; }

	p,ul,ol,dl {
		font-size:1em;
		line-height:1.5;
		margin-bottom:24px; }

	ol ol,ul ul {
		margin:0 0 0 60px; }

	blockquote {
		margin: 0 60px 0 45px;
		border-left: 5px solid #ccc;
		padding-left: 10px;
		text-indent: -0.4em; }

	pre {
		white-space:pre;
		white-space:pre-wrap;
		white-space:pre-line;
		word-wrap:break-word; }

	/* Anchors */

	a {
		color:#1e80a0;
		overflow:hidden;
		border-bottom:1px solid #ddd;
		text-decoration:none; }

	a:hover {
		border-bottom-color:#bbb; }

Follow the DOM

What I mean is while reviewing the DOM setup of the HTML, your CSS default for each module/element section should follow the DOM structure and will be set at this point. For example if your DOM is setup as so:

<html>
	<head></head>
	<body>
	<header>
		<section> </section>
	</header>
	<!-- side modules -->
	<aside>
		<!-- aside code will go here -->
	</aside>
	<!-- navigation -->
	<nav>
		<ul>
			<li><a href="#"><img src="img1.png" /></a></li>
			<li><a href="#"><img src="img2.png" /></a></li>
			<li><a href="#"><img src="img3.png" /></a></li>
			<li><a href="#"><img src="img4.png" /></a></li>
		</ul>
	</nav>
	<!-- side modules -->
	<article>
		<section>
			<!-- main header info will go here -->
		</section>
		<section id="content"> </section>
	</article>
	<footer> </footer>
	</body>
</html>

Then the CSS will follow the DOM structure and look like so:

header {
	height: 88px;
}
header section  {
	position: relative;
	color: #fff;
}
aside  {
	float: right;
	width: 330px;
	color: #fff;
}
nav  {
	margin: 0 345px 20px 0;
	min-width: 800px;
}
nav ul  {
	height: 86px;
	width: 670px;
	margin: auto;
}
nav ul li  {
	float: left;
	height: 64px;
	width: 64px;
	background: #fc0;
	margin: 10px 0 10px 10px;
}
nav ul li img  {
	width: 64px;
	height: 64px;
}
article  {
	background: white url("../img1.png") repeat-y;
	border-left: none;
	min-height: 600px;
	margin: 0 345px 0 0;
	position: relative;
	min-height: 600px;
	border: 1px solid #9a9b9b;
	-moz-box-shadow: 1px 0 10px 1px black;
	-webkit-box-shadow: 1px 0 10px 1px black;
	box-shadow: 1px 0 10px 1px black;
}

This will allow the CSS to not only mimic the DOM but also you can implement the general style in each module/element section of the page – another level of cascade for the style that is to be applied to the page. Also consider decoupling the HTML from CSS further and according to an article by Jonathan Snook take advantage of child selectors more frequently:

nav > ul {
	height: 86px;
	width: 670px;
	margin: auto;
}
nav > ul > li  {
	float: left;
	height: 64px;
	width: 64px;
	background: #fc0;
	margin: 10px 0 10px 10px;
}

Class begins

Chris Coyier has written a great article regarding when to use IDs vs. when to use classes - http://css-tricks.com/the-difference-between-id-and-class/. My personal approach is to create classes as needed for styling. There are two types of classes that can be created:

• specific class – these classes will be applied to particular area of the site and it is unique to that area. Now if you are thinking “if it is unique, then why not apply it to an ID”, you may be right, however then you will restrict yourself to that section of the application may be harder to abstract it later if needed. For example:

.arrow-up {
	width: 0;
	height: 0;
	border-left: 5px solid transparent;
	border-right: 5px solid transparent;
	border-bottom: 5px solid black;
}
.arrow-down  {
	width: 0;
	height: 0;
	border-left: 20px solid transparent;
	border-right: 20px solid transparent;
	border-top: 20px solid #f00;
}
.arrow-right  {
	width: 0;
	height: 0;
	border-top: 60px solid transparent;
	border-bottom: 60px solid transparent;
	border-left: 60px solid green;
}
.arrow-left  {
	width: 0;
	height: 0;
	border-top: 10px solid transparent;
	border-bottom: 10px solid transparent;
	border-right:10px solid blue;
}

• utility class – these are classes that will be used throughout the site in order to apply certain styles in different areas. These classes can be a style as simple as setting float left or right or it can be something like:

.flip-img {
    -moz-transform: scaleX(-1);
    -o-transform: scaleX(-1);
    -webkit-transform: scaleX(-1);
    transform: scaleX(-1);
    filter: FlipH;
    -ms-filter: "FlipH";
}
.float-lft  {
    float: left;
}

A utility class can be applied to any element in the DOM as needed, as you know multiple classes can be added so multiple functional/utility classes can be added to the same element. For example:

<img src="img/img1.png" class="flip-img float-lft" alt="flipped image example" />

Reserve class usage to areas where it cannot be applied to any of the above guidelines. Do not create classes to apply styles to all div elements, for example, and avoid creating a class like this:

.div-style {
    background-color: #fff;
    margin: 0 10px 5px 0;
    height: 100%;
}

The correct approach is:

div {
    height: 100%;
    background-color: #fff;
}
/* the margin setting can be set at the DOM level CSS or in a specific class */

Note: The above examples have been borrowed from Chris Coyiers snippets section of the CSS-tricks site (http://css-tricks.com/snippets/).

Conclusion

These rules and guidelines are essential in building a CSS file that is lightweight and highly performant. In part 2 of this post we will review further guidelines in building a well structured CSS file. Stay tuned.

Further Reading

• CSS-tricks
• Comprehensive CSS Principles
• Nicole Sullivan – Object Oriented CSS
• Jonathan Snook – SMACSS
• Jina Bolton – CSS Workflow

I have worked in environments where I walk in with shorts and sandals and worked in an environment where the same shorts and sandals got me a visit to the ‘principal’s’ office. I have worked in an environment where my boss and I shared a beer on a Friday afternoon in his office and also worked in an environment where the boss was hesitant to buy the beer at the bar because he was concerned about him or his company being liable for other’s drinking.

These environment’s differ from each other tremendously but I could not tell you which is better than the other – I know which ones I preferred but I still can’t intelligently say which method of management is superior to another. And that is not what I am qualified to talk about – business management was never my forte – but what I feel qualified to discuss is technology.

And in my experience, large corporations are always behind in technology and hesitant in the adoption of new technology. Some of the reasons behind the lagging in this realm are reasonable and some are not. I am going to attempt to breakdown some of the issues that I have encountered and hopefully try to provide solutions. Here we go:

Inexperienced managers

Big corporations are stacked with Vice Presidents, directors, middle managers and the ever-lovingly titled individual contributors (really? shouldn’t it be ‘team’ contributors, how many employees does one see working in a silo or ‘individually’?).

The Vice Presidents and the managers (henceforth referred to as the Witt brothers, Dim and Nit) have offices that are strewn with ink jet printed awards, “Good to Great” book (or similar bland management books), and one or two technology-based books that let’s be honest, look like they have never been opened or have not been creased passed the first chapter because they fell asleep after the first chapter.

To be fair, there are some managers that have been developers or programmers in the past and do have some technology experience and may be able to make sound decisions, however with the speed of technology advancement; 6 months or more away from hands-on development and that same developer-promoted-to-manager will become slowly out-dated and slowly lose their technical talent.

The flaw is that these managers, low to medium technically experienced ones, are in the forefront of making technology decisions and most of the times they will make the scared, conservative, and wrong decision. As a technology enthusiast, seeing that deer-in-the-headlights look is very discouraging or worst facing the I-know-what-is-best attitude from some managers is horrifying.

Solution: One solution is to have a technical manager counterpart for every non-technical manager. Since in big corporations this means doubling the workforce and in reality would not be feasible, then a technical architecture group should be created. Now in order for this group to be affective, it needs to be a governing body that must go beyond architectural recommendations. Not a Jedi Knight ‘May the force be with you’ type group but a Sith Lord dark side of the force ‘don’t fuck with us or I will force-choke you’ governing body. What I mean is that this group should not just recommend an approach but ensure that the standards have been maintained throughout the project and even go as far as having periodic reviews to ensure the integrity of the standards that have been set are maintained.

Mediocrity breeds mediocrity

Some of the burden of promoting new technology does fall on the ‘individual contributors’. If my job description is to maintain a corporate website, well that is just boring. The problem is that the employees that are bored with this type of work, the ones that are always looking for a challenge to better themselves will not stay in order to maintain the same website day in and day out. Which means that the ones that remain are the ones that are looking for a stable position that will lull them into a comfort zone and will be happy to maintain the same product no matter how old and rusty it will become. I apologize for making such a blanket statement, of course not all employees of large corporations fit the above description but unfortunately most do.

This mediocrity is further perpetuated when busy employees don’t have the time to upgrade their skills and/or the inexperienced managers – remember the Witt brothers? – don’t give them the opportunity.

Solution: Two words – Research & Development. This is lacking in big corporations and it is amazing the results that it can produce. It is not a coincidence that companies like Google are so successful,  allowing the employees one day to work on personal projects is liberating for employees and rewarding for the employer (yes that’s right the EMPLOYER!!) and employees. Even if the project has nothing to do with the core business the fact that there is a ‘outside of the box’ thinking (the paradigm most of those bland management books promote) is priceless. Maybe the architectural governing body can sponsor and encourage team exercises/conferences/seminars to promote this type of behavior.

Don’t take away the free coffee

In one the companies I worked, initially when I started we had free perks throughout the day, free coffee in the morning, fruit and soda throughout the day, pool table, and fooseball table area for relaxation. From my understanding, this was done to attract the employees to the company during the dot.com boom era of the mid 90s to early 00s.

After working there for six months, slowly the perks were taken away (at this point, we were beyond the boom era and we were in the decline phase). The sad part was that the company did not make the effort to notify the employees that these perks will be taken away, the approach was a much more cowardly one.

Everyday one of the perks were slowly taken away. One day it was the apples, the next it was the skittles, and on and on. I am not sure what the reasoning behind this approach was but did someone actually think that it will go unnoticed. I am not sure what is worst, that they thought it would go unnoticed or that even if it was noticed they did not care.

I agree that the spending of the dot-com era was frivolous however there were some good ideas that came out of that era. Some good ideas that companies like Google, Facebook, and countless other companies did decide to keep.

What is the cost of a free lunch or morning coffee compared to a happy and satisfied employee? It doesn’t take much to turn a frown upside down (sorry been watching too many kids shows).

I recall that after leaving one of my large corporate jobs, one where I had to dress business casual everyday; my next job was one with a more lax environment where shorts and sandals were welcome. It was amazing to me how much happier and more relaxed I was.

Solution: dont’ take away the free coffee!! A lot of companies spent most of their energy keeping the customer/client happy sometimes at the expense of their employees. I may be naive, but in my opinion there is only one group that needs to be satisfied and that group is the employees. Subsequently, a happy employee will do everything in their  power to promote the company that they love and eventually try to prove their loyalty by keeping the customer/client happy.

I understand that I may have taken a simplistic view to an over-arching problem; nevertheless sometimes the best answer is the simplest one. I don’t claim that my solutions will resolve the issues but maybe they are a step in the right direction.

Not sure if I have all the answers but here is my $0.02.

NO REFUNDS!!!