Read the full article at: 5 Best Practice Mentalities to Get Over
Every developers strives to write clean, maintainable, and functional code, whether they hack on the server side or dabble on the client side. Over the last few decades of the web, we’ve learned from some of our early mistakes and formed a site of always changing best practices. These best practices usually keep us out of trouble but some of them are taken way too literally, to the point where developers become too rigid and borderline crippled by them. Truth be told, with these best practices are mostly good to follow, they’re broken not out complacency but by necessity. Here are five best practices that aren’t quite as realistic as we’d like to think.
“Don’t Add Globals to window“
JavaScript developers go to great lengths to encapsulate their code, like creating classes, closures, and modules. I agree with the mentality that you should avoid globals, but sometimes you simply have to. I recommend creating one global object named after the project name (Dojo Toolkit uses dojo and Groupon’s Groupon object) and tagging properties on that. Creating an army of globals can get you into trouble but adding a few globals to window is just fine, if not unavoidable. As long as you know the environment your code will run in, you won’t run into naming collision problems.
“Adding to Native Prototypes is Bad”
The early JavaScript frameworks like Prototype and MooTools first gained popularity because they empowered native object prototypes. No longer did you write globally available functions to modify instances of String, Number, Array, Object, Function, etc — you could pin methods on the prototype for each so that every existing and future instance had those methods; a total boost to productivity and code efficiency. Then after a few new naming collusions due to standard and proprietary web and browser API implementations, developers turned on the practice, to the point where the thought of adding a method to a native prototype meant you should turn in your developer credential badge.
Much with adding a global to the window, adding methods to a native object’s prototype is fine done correctly. Name your new method properly (i.e. don’t give your method a common name) and you’ll be just fine. I’m not telling you to do this a lot, I’m simply saying that adding a method to a prototype isn’t going to bring your career to a screeching halt.
“Never Use UA Sniffing”
User agent sniffing has gotten a rotten name because it was originally used to sniff features, and we know how badly that turned out. Believe it or not though, UA sniffing is still used by most large websites to detect mobile and then forward users to the mobile version of a site. And you know what? It’s reliable and in the best interests of our users. I’ve been asked “What if the user spoofs the user agent?” My reply is “Then they get whichever site view that comes with it, so who cares? They’ve done this on purpose and if they get a dysfunctional site it’s their problem.” As long as you provide a link to the desktop version of the site, you’ll be just fine.
“It’s OK to Load [JavaScript Library] From CDN Because the User will Likely Have Loaded it Already”
This one really burns me, especially after my trip to Brazil to promote Firefox OS. Yes, loading utilities from CDN is fast and, provided enough people use the CDN, there’s a decent chance the user has the code cached, but it isn’t that simple. Assuming a site has jQuery cached, for example, is risky because there are numerous versions and subversions and subsubversions being used at any given time. If the user doesn’t have an unlimited data plan (which isn’t offered in most countries), they could be paying quite a bit for each site that uses a JavaScript library or site which loads large files, CDN or not. When I went to Brazil, I would have to pay 20 cents for just jQuery if I went to a site using it. Long story short: assuming users don’t pay a penalty for a CDN-hosted resource is a bad, bad mentality.
“Pixel Perfection is a Must”
Quality designers and developers tend to be perfectionists, that’s why they do well. We do, however, get caught up in pixel perfection when we translate from design to working page — likely because pixel perfection is achievable. The problem in focusing on pixel perfection is that the obsession leads to a lot of time that isn’t enhancing the user experience, it’s enhancing our ego. Of course other designers and developers will come to the site and notice the odd width or height issue, but 90+% of users would prefer we make performing a given task easier, not ensuring each column measures precisely. Of course I’m not advocating you create “landmine” sites with pixels off everywhere, but sometimes you need to file a bug to fix later and keep making your site more usable, accessible, and fun!
It’s important that we don’t lose sight of practicality when we try to stick to best practices. We can look sternly at a certain practices but what’s most important is that we create functional, usable web sites. Never accept a rule without questioning its total validity and never be afraid to step outside rigid trains of thought!