Incorporate fetch() and Promises polyfills to support Safari/IE/others

[brlodi]

Our current use of fetch() is not supported by current versions of Safari (both desktop and mobile, although WebKit nightlies appear to have support), IE, Opera Mobile, old Android browsers, UC Browser (I've never heard of it but it has nonzero market share apparently), and some other niche browsers.

At the moment we just fail to display any map data in these browsers. I'm proposing incorporating Github's own window.fetch polyfill and their recommended Promises pollyfill taylorhakes/promise-polyfill (IE doesn't support Promises either) which should largely resolve the problem with minimal work on our part. Considering the affected browsers include the primary iOS browser and the stock browsers for several platforms I don't think we can afford to not support them, and this beats rewriting everything with jQuery.

I"m happy to work on this when I have a moment to sit down and do it properly.

[vonbearshark]

Great idea. I'll assign you to this issue. I would prefer if we could keep it out of main.js. If there's not already a shim we could pull in in the HTML via CDN then we should create a new file for this. Thanks, @brlodi !

[brlodi]

I've had partial success, I'll submit a PR in a moment. In testing I've found support for some of the targets (*cough* IE < 11, some mobile browsers) is blocked without refactoring to our own script because they don't or only partially support ES6 and break or misbehave on const, but that's a different bug that I'll leave up to @vonbearshark to make an issue for if he deems it necessary.

[vonbearshark]

Yeah this prompts a larger question: do we want to ignore es6+ completely and only implement legacy-supported JS, or do we want to add a build step for production? I think we should try and shim what we can for now, and add a build process later in the semester when we are thinking about deployment, people are accustomed to the repo flow, etc.

But fetch itself works now?

[brlodi]

Should do in the browsers that aren't blocked. I submitted a PR #47

[brlodi]

And I agree. Honestly the only code change I might make directly is to avoid using const if possible (or at least being conservative with it), since there's a decent amount of partial support that basically just treats it as var with no scope or write-protection.

[vonbearshark]

Yeah if we can just shim some features and avoid others that might get us through just fine. I'm okay with saying to use var as a rule (despite how frustrating I know that will be) and adding shims for the Array functions like .map that we'll probably use, for example. Even still, I think we can readdress it later in the semester and convert what we need then when we have more working functionality.

Thanks, @brlodi !