Is there an official list of supported browsers for Elm? If not, what is the oldest browser you’ve tested Elm against? Lastly, is there a way to make Elm work on at least IE9 and IE10?
More context
When I decided to explore using Elm for my current project, it was not certain up to which browser version I should support. Based on a discussion here, I assumed that I should be safe up to IE9. Anyway, it was very unlikely that I would have to support IE8 and before.
Now I’ve wired in all the moving parts of the application. In the meantime, the business people specified the requirements to support IE9 as I had feared. So I tested running the app on those browsers.
The app worked fine on IE11 on Windows 7.
It did not on IE10 or IE9 compatibility mode on the same browser. I haven’t tested the app on the actual IE9 and IE10, as they are hard to come by nowadays, but I’m skeptical that my app would miraculously work on actual IE9 and IE10.
I feel terribly embarassed for not properly testing Elm before I even began working with it, but here I am. I’m looking for any kind of experience, data, or advice on Elm support for IE9 and IE10, and how to get it working if possible!
As far as I know there is no official list - I might be wrong, though. Elm should compile to plain ES3 + some extras so even IE8 should be possible: the most recent thing I can think of that you might need is requestAnimationFrame. Did you use <!DOCTYPE html>? This is necessary because IE is very crazy about document modes
What isn’t working exactly? What errors do you get?
Supporting old browser is a tricky business. The only IE version supported by Microsoft is IE11.
You need to do a serious cost-benefit analysis of supporting older browsers. You will get into a lot of trouble the further you go into the past.
We definitely used to run production Elm 0.16 against IE9. I forget if the 0.17 release preceded our dropping support for IE9, but I’m not aware of any compiler changes that would affect older browsers.
I’d recommend testing on Microsoft’s free virtual machines rather than compatibility mode - that may explain the difference.
I was recently looking into it in terms of support for Web Components ( we have about 10% of our clients who still uses IE8 & IE 7, and we can’t control their browsers ).
Some discussions seem to indicate that
Elm compiles to EcmaScript 5, so it should be supported by IE 8 and up at least.
Missing features can be plugged with polyfills.
I haven’t actually tried it, so take it for what it worth. ( So far we only run ELM on our internal apps, that just need to support latest browsers)
Thank you everyone for chiming in - I really appreciate it!
The part that was causing error had port in it so I think that’s part of the issue. I will dig into the issue tomorrow with that MS IE VM as suggested by @rtfeldman, and share my findings here.
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.log doesn’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.trim is not supported in IE<9 so use another MDN polyfill to support that
IE<9 doesn’t have the proper W3C event model so event.stopPropagation, event.stopImmediatePropagation, event.preventDefault might be problematic, I’m not sure whether this is polyfillable without patching the kernel JS dealing with events that comes with elm-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 - get isn’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.createDocumentFragment only being IE8+ but MDN says IE supports it all the way
Non-issues:
the JS has a setTimeout powered fallback for requestAnimationFrame so 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.
I’m working through bunch of event-related issues: event.preventDefault, event constructor (new Event()), and then there’s another issue with elm-lang/virtual-dom package throwing invalid argument with input type="email".
First of all, I convinced others that we should only support IE11 and above - it was a great day for the humanity.
Still, I ran into another issue so I’m documenting it here.
Html.Attributes.type_ function blows up in the most unexpected ways, a.k.a. Heisenbug style.
It’s already reported and discussed in:
Whereas Evan listed only a few examples, I’ve had my app crash on something like button [ type_ "button" ] [], which is already in HTML 4.01 spec. I also have scores of view functions with the same function but the app crashed in just two of them and I don’t understand what’s causing them to crash.
Simple solution is to use Html.Attributes.attribute "type" "button" instead.
