these days? much, much better. but even still, occasionally you run into an issue, and if the limitation or bug is inside someone else's blackbox, you reverse-hack a workaround.
here's what i ran into, above.
i'm drawing some of my own graphic labels on the map. i need the labels to sit on polygon masks that i'm also creating. the yellow masks up there always draw fine, but the labels vary.
so, come to find out that on some browsers (chrome, opera) the labels draw fine, on other browsers (msie, firefox, safari, edge) the label itself draws too low. luckily the TextSymbol object has a .yoffset property, so i can apply an offset to juke the label to make it look better, but i need to know at runtime which browser is being used so that i can tell it how far to juke, if at all.
so i start googling around, and ran into some samples of varying age, and varying usefulness. not good enough to cover all my bases. some written for entirely different purposes, or otherwise mucked up with regex, or accounting for possibilities so exhaustively, to make the end result internationally bulletproof, but for me 90% unnecessary and tough to wean back.
i even found this little gem on twitter:
rock solid advice no doubt, but feature detection doesn't really apply in my case since i'm not trying to call certain features or install extensions, etc. i just need to know the browser, so that i can go do my thing with the labels. i also tried an example i found on stackoverflow that uses ducktyping, which i suppose is a flavor of feature detection (trying to determine what something is, by testing what it can and cannot do: i.e., if it walks and quacks like a duck), and ran into more exceptions than things that actually worked. at any rate...
so i finally went brute force and found that the dom's own navigator class has a .userAgent property that contains a lot of gobbledyguk, but enough there to do some string parsing.
browsers like opera, firefox, and safari, no problem. the .userAgent returned by those browser has enough uniqueness to it.
the example above is what chrome browsers return, and while this string contains *both* the words "chrome" and "safari", the safari browser's has "safari" but not "chrome", so if i check for "safari" first, then overwrite that with "chrome" later if the browser is chrome, then i'm good. (i guess i could've used a switch condition with some fall-through), but at any rate, here's what i ended up with:
so i'm making my kludge a little kludgier and i'm deciding to avoid the problem for now by assuming that if i don't proactively find the other browsers, i can reactively assume "msie". i'm sure that won't hold up in the long run, but until i find a better way, i'll see how far i can get with it. oh, and don't miss the forced use of try...catch, because if you try to call .includes on an IE browser, the whole thing craps out.
i'm all ears if anyone out there has a better way to do browser detection. i'm betting that just about anyone reading this does. (hopefully)