A note on the name
A friend of mine recently quoted this little gem in his Twitter stream:
Is it object-oriented?
Proper separation of the behavioural layer
class attribute) in your source code. The alternative would be to write JS directly into the HTML, via event attributes such as
onClick=”” or via the
href attribute. This is not a good practice and I heartily recommend against it.
Graceful degradation is a well known software engineering concept which involves writing your code to take advantage of awesome feature X, unless awesome feature X is unavailable, in which case degrade to use slightly-less-awesome feature Y (assuming that too is available).
In short; build everything in the most up to date browser, making use of all it’s wonderful modern features, and then go back and make sure the site is still usable when any of those features are not.
The problem with approaching the issue from this direction, however, is that you are saying to your users: “You (or your browser) are incapable of handling the full experience we want to present, so here’s a cut-down version.” This pretty much flies in the face of user-centric design, and good user experience. With that in mind, we’d be better using…
Progressive enhancement involves approaching the problem from the other direction. You should design for the user-agent with the least capabilities and add functionality for more capable browsers afterwards.
In web terms this means developing and designing with nothing but the base features of HTML in mind, and then enhancing those features (or the features of the browser interpreting that HTML) by attaching CSS and JS to the HTML via element identifiers like IDs and classes.
The final outcome of these two approaches might be very similar, but the subtle difference is that you are giving more attention to the less capable user-agent when you progressively enhance.
The most common use-case for progressive enhancement is the support of a non-JS experience.
DRY (Don’t Repeat Yourself)
Every piece of knowledge must have a single, unambiguous, authoritative representation within a system. This means abstracting code into shared functions and objects whenever you find you are repeating yourself, and attempting to maintain a single source of truth in every aspect of your system.
Refactor early, refactor often
Once you’re refactoring often, you’ll be able to…
Make it work, make it right, make it fast
The first iteration of your code should only look to reach the level of functionality defined in the functional specification. Once this has been achieved, refactor to improve the way it works—so the code is “right” in your opinion. This may very well mean a complete overhaul of architecture, but you will be able to concentrate much more specifically on that since you already have it working. The final stage in this development cycle is to optimise your code for performance and efficiency; premature optimisation is a fundamental mistake in development.
When it comes to general development, there are a veritable plethora of resources out there, but my recommended starting point is the book The Pragmatic Programmer, by Andrew Hunt and David Thomas. This book outlines quite a few paradigms that should get you thinking about the way you develop.
Important things to understand
Once again the Mozilla Developer Centre provides an excellent DOM reference section, although it is slightly skewed in favour of the Gecko browser engine. You can also find plenty of information on the DOM at the W3C site.
Interaction with the browser
A good example of this is to make sure you do not break the “back” button. Often this can be achieved by simply using the
window.location.replace() method to control which pages appear in the browser history.