Choosy Nerds Choose GIF

There's more than one way to do things from a front end web development perspective. Tables vs divs? Layout and mouseovers in css or javascript? GIF and JPEG and PNG, oh my! Engineering is an art of tradeoffs in many ways. I'd like to illustrate some of the reasons you might choose one thing over another when designing and building your front end code.

One of the biggest considerations is how your code will end up on the user's device. Is it an email? Is it a website? Is it a facebook or opensocial app?

Email is an unforgiving hellscape where every useragent is out to get you and nothing's as it seems. You have no javascript, CSS may get stripped out by the mail client and the clear/float status of the parent container is a mystery wrapped in an enigma wrapped in 1995. So having a CSS driven scheme where blocks and inlines flow together in modern bliss is out of the question. And using javascript to handle user agent rendering differences is out too. As a result many people choose a table based layout. The more savvy and modern shops will do this 'neo-classical' style, using tables for structure and inline styles for text, background and padding. And maybe using stacked div's for paragraphs and the like (yeah, some major webmail clients fail at rendering p's correctly). Some of the bigger, cheaper commoditized email DM shops will go 'full-1999' and use spacers, font tags and other techniques from when Deuce Bigalow: Male Gigolo was a new movie.

Facebook's limitations are similar to webmail in a way. Both are constantly changing in what you can and can't do. You may be able to use a technique this month, but not next. Then you can use it again. It's a full-time job keeping up with it all. This is easily mitigated if you're an agile shop developing an app over a long period of time. You just make dealing with the changes part of your iterations. But if you're an ad agency maybe you're doing limited time contests or microsites. This becomes a heftier consideration because Facebook as a platform could change in the middle of your campaign. In this case you may choose to keep things simple and limited so that the damage and remediation is minimal if it happens. You may also choose to go with a third party vendor who specializes in keeping up with the platform. In this case you may be doing almost entirely prod art and CSS. And firebug.

All this makes websites seem like the merry old land of OZ or Willy Wonka's factory. But it has a different problem. You have plenty of rope with which to hang yourself. Because you have a lot fewer restrictions and the power of the entire web browser you have to make a lot more decisions. Which means you have plenty of opportunities to make bad ones. You could go new buzzword fanboy, you could overuse one technique when another is better suited or you can lose sight of who your audience is and design for something else.

Buzzword fanboy-itis is the more dangerous cousin to hammer-nail ("when all you have is a hammer, everything looks like a nail") syndrome. At least with hammer-nail you know what you're doing. But when you get all excited about the new hot thing you're not only taking on something you don't know anything about, really, but it's likely fresh out of beta. Sometimes you can take a risk and go a little bleeding edge if there's a good reason for it. For instance, this is an HTML5 site. We had to use a lot of libraries (CSS3PIE, html5shiv, innershiv) and drop some browsers to do it. Had we done it just for the sake of playing with HTML5 it would have been a reckless and naive decision. But the consideration that made it a very good idea was that if we built a site for the web of 1 or 2 years from now... that's more time we can spend serving our clients instead of keeping up or doing another refresh a year from now. So that would be an example of when embracing the buzzword du jure can be a wise choice. Now, if you make a habit of it you're not providing a service to anybody. You're just reacting instead of making informed and well-considered decisions about what technologies to use.

By far one of the most prolific errors made by developers is overusing one language of "the trifecta" (html, javascript and css) to perform the functions of another that is more suited. Specifically many people do a lot of style in javascript instead of css. Ideally one would do their structured data in html, their style and layout in css and application logic/interactivity in javascript (and the backend, for sure). Why is this 'ideal'? Because your audience as a front end developer is a robot who may or may not be acting at the behest of a human. And they don't have javascript or CSS. In order for googlebot or assistive technologies like a screen reader to make sense of your site as they intermediate between robots and humans, the site has huge advantages if usable with only html. Well, unless SEO is meaningless to you and you're a heartless monster who cares nothing for people with disabilities. If your site doesn't have any nav served up in the html and it's pulled in via AJAX on load, you're shooting yourself in the foot. If your primary nav isn't navigable without js that's unwise. If your page's content doesn't display or is black text on a black background until a script runs google won't see it or will ignore it. And as far as styling is concerned, it's almost always slower to do in javascript what css was designed to do. The browser is object code after all. If you must change the way something looks when an event happens use classes on the objects to be styled and let the browsers 1's and 0's work their magic for you.

This isn't to say that using js is bad or that using AJAX is a no-no. It's to say that a site that isn't primarily a javascript application should still function in it's absence. We're big fans of unobtrusively turning static links into dynamically bound events.

And this comes down to the pitfall of losing sight of your audience. On what device are they using this thing you're creating? A computer? A smartphone? A regular phone with an awful browser? Why are they visiting? Is this an app they're going to use every day? A news site where they're going to land on an article via a deep link and never see the home page? Is this a microsite that'll be up for 2 months?

All these questions shape how you'll design your code and what languages you'll use more than others.

If you're on new browsers and smartphones you may be using html5, no rollovers and no flash. If it has to work on a razr, html4 and style/js as progressive enhancements. If you're an app behind a login, it's reasonable to require javascript... but keep an eye towards accessibility. If you're a marketing microsite you may opt to make your site as SEO friendly as possible and treat css and js as progressive enhancements as a result.

In the end what it all boils down to is if you want to create front end code that is optimal for the task at hand you have to get over yourself. There are many choices you can make about how to approach the problem. The deciding factor has to be why you're building this thing in the first place. Not what you feel like doing or have done in the past.