Is it considered bad practice to run different JavaScript for IE

Question

Is it considered bad practice (and how bad) to run different JavaScript for IE? Currently im writing some JavaScript and the simplist way to work arround IE quirks seems to be to check for browser version and run different code

var browserName = navigator.appName;

if (browserName == "Microsoft Internet Explorer") {
  //Do some stuff
}
else
{
//Do other stuff
}

It's quick and works well but does lead to duplication of code and feels "hacky".

Answer 1

Yes

Inferring functionality from a user agent string is a weak and error-prone test. Though relatively common, in this day and age I would say it is certainly considered a bad practice.

For example jquery has a function for detecting which browser a user is using and it's been deprecated since version 1.3

Therefore: Don't do UserAgent sniffing to decide what the browser is or what it's capable of.

Best practice

The accepted best practice for handling the differences between browser capabilities is to use feature detection.

There are a few libraries around for this, the most well known is probably: Modernizr. Modernizr makes it easy to tailor your javascript to the abilities of a browser. It works by detecting what's available; not guessing based on a UserAgent string (except as a last resort fallback) and simply adding classes to the html tag. This makes it not-only possible to easily handle different cases in your js - but also to address certain deficiencies with css alone. e.g. (purely for illustration only):

ul.menu {
    display:none;
}
ul.menu:hover {
    display:block;
}

# A touch device can have no hover - so show it always
html.notouch ul.menu {
    display: block;
}

Answer 2

It’s ok when it’s valid JS and there are no abstractions

It's not exactly bad practice, even though it got better, browsers aren’t 100% identic.

But, before starting special cases, look carefully, if they are really special cases and not just idiosyncracies of another browser. In this case, you should search for a solution using standards all browsers share (caniuse.com is of great help for that).

When you are sure that it is indeed browserspecific, imho you should look if you can use a library that hides this detail from you. Cross Browser Compatibility is a hard thing to get right, so if someone did it for you, just profit.

As a last resort, do what you have to do ;)

Answer 3

If by "do some stuff" you mean "use IE specific facility x" and by "do some other stuff" you mean "use more common facility y", then it is better practice to just check for the presence of x or y.

I'm guessing that you are currently not using any external Javascript library. In that case, I would check to see if jQuery supports the task you are trying to accomplish. If it does, I would use it.

Answer 4

Use the IE specific comments <!--[if IE &gt; 6]>... or something like that. Works on all super crappy browsers IE? -> IE8, but not on IE9+ which is considered sort of ok as a browser.

The bottom line, once you deal with super crappy browser that needs workarounds, it's ok to do whatever is necessary, but avoiding turning well written baseline code into a hackatron.

Hopefully, IE will go away one day, and you will be able to delete the hackatron code and leave the well written baseline only.

Answer 5

I think it is better to defer this kind of decision-making to the framework designer, and use one JavaScript framework that encapsulates this kind of complexity. Nowadays we have AngularJS, JQuery, ReactJS, and so on, doing things without a framework would get you this kind of difficulties.

Answer 6

Well, assuming you're actually interested in learning JavaScript, the best practice is this: Prefer testing by absence/existence of methods and write normalizing functions. So a totally lame example but it hits three principles:

if(!document.getElementsByClassName){
    document.getByClass = function(){ //look at all elements, check for class etc...
}
else { document.getByClass = document.getElementsByClassName }

1. Don't browser sniff.
2. You might as well eliminate a little bit of the DOM cruft as you go. The DOM API's purpose is to be explicit, not to go easy on your carpal tunnel if you've failed to notice how freakishly flexible JS is. The barely-eliminates-any factor is what makes the example lame.
3. Cache to a new function. Don't do the method test every time it's called.

The advantage is that you can never 100% trust browser sniffing and you never know when some other library being linked to didn't actually add an equivalent method back in for you.

Whether you're just trying to get stuff done or want to learn more, I recommend JQuery. It does a bang-up job of eliminating DOM API cruft and maintaining a high level of cross-platform normalization but it's also something you can learn a fair bit from studying under the hood. More importantly, if you bother to continue actually learning core JS, it doesn't become useless like so many other JS frameworks and libraries and you'll continue to benefit from being able to de-soupify your JQuery junk with your mad OOP-ish skills.

Also, check out quirksmode.org to understand why Microsoft should be truly despised for all IEs prior to 9 on the JS front and a lot of nitty gritty details on exactly how much is wrong with their proprietary DOM API and suggestions for working around it.