Choosy nerds choose GIF
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?
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.
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.
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.