TL;DR
if you have your <!DOCTYPE html> and the mentioned polyfills in place an Elm program should run without problems in IE9+, iff you don’t have any other ancient JS lingering around the same page that messes with global variables.
The Long Version
The following are potential issues I’ve dealt with in the past with ancient JS engines. This is a quick run-down I compiled while looking through the generated code of one of my small Elm projects.
Low hanging fruit that is easily polyfillable, remember to include these before including your elmish JS:
-
console.logdoesn’t exist in IE if the devtools are not open so maybe include a console polyfill or write one yourself - IE<9 doesn’t support
Array.prototype.indexOf()-> MDN polyfill -
String.prototype.trimis not supported in IE<9 so use another MDN polyfill to support that -
JSON.stringify/JSON.parseare IE8+ -> www.json.org has you covered
Potential show-stoppers for IE<9:
- IE<9 doesn’t have the proper W3C event model so
event.stopPropagation,event.stopImmediatePropagation,event.preventDefaultmight be problematic, I’m not sure whether this is polyfillable without patching the kernel JS dealing with events that comes withelm-lang/virtual-dom - IE<9 doesn’t support
EventTarget.addEventListener/EventTarget.removeEventListener
Not sure but might be problematic:
- I’m not sure about keywords as labels, in my code there is a
get:label in_elm_lang$core$Dict$get, that could be an issue in older browsers -getisn’t a keyword but in ES5 is used to define a getter so I wouldn’t put it beyond IE to make a fuss about that - I loosely remember
document.createDocumentFragmentonly being IE8+ but MDN says IE supports it all the way
Non-issues:
- the JS has a
setTimeoutpowered fallback forrequestAnimationFrameso a polyfill doesn’t seem necessary after all -
"use strict";is IE8+ but falls back gracefully so that shouldn’t be a problem
Trivia:
The generated JS isn’t that idiomatic especially with the usage of the curlies on the next line and the variable declarations that make the impression that JS has block scope where it actually has function scope. There are also a lot of unguarded for (... in ...) traversals that might throw off older IE, even more so if other JS lives on the same site that potentially modifies shared globals.
General Advice:
Don’t trust IE :-), no, seriously, don’t trust it. Microsoft did a good job in keeping most of the behavior of their old JScript engine versions in their compatibility mode, kudos to the team that had that miserable job on their plate. The problems arise with the combinatorial explosion of the various document modes and their interaction with the legacy engines that are being carried around since days of yore. Multiply that by the fact that an IE version potentially behaves different on every major windows version, times the supported architectures. To sum up: the engine recreation is pretty good but the host objects and especially the document models will haunt you forever. My advice for managment still stands: if even Microsoft isn’t supporting IE<11, why should you? Usually numbers work better with management, so my anecdotal tally is 1.5 * (time spent on all evergreen browsers combined) <= time spent on keeping IE supported, so go figure.