Fixing the consistency of shim

[matt-gadd]

This is larger discussion on how we can get shim to a level of consistency that is reasonable. At the moment the things in shim wildly vary so I will try and explain whats there.

To start with we have a number of shims what I think we can now tag as "legacy" that are only required in IE11, these I think are:

Map
Promise
Set
Symbol
WeakMap
fetch

and

array
string
object
math

I have split these into 2 groups. The first group we can easily polyfill onto the global, but the second are currently actual shims that would normally be on the associated primitive's prototype. These shims are quite annoying as they obviously have different api's to the native versions which means remembering to use the shim exclusively if targeting a legacy environment. In an ideal scenario I think at this point these should all be transparent polyfills we can apply at build time automatically in legacy modes?

For the rest of this repo (which isn't a lot taking into account all the legacy for IE11 above), the majority of things in here are Web Platform polyfills, ie:

WebAnimations
Intersection Observer
Resize Observer
Pointer Events

These are fundamentally different to the other things in shim, they a) are mostly wrappers around polyfills from the community b) are applied to the window, as we have no control of the implementation.

Other shims which are not Web Platform polyfills:

global
Observable
Abortable Controller

Given all the information above, i'd like for us to discuss how we should go about structuring these what I think are separate things better in the repo, some open questions:

• should the IE11 compat stuff really be done automatically when building in legacy modes? I don't think it's acceptable for an end user to have to write different code for legacy versions when we can polyfill the appropriate things?
• should we deprecate or move Observable? I don't think this is progressing anywhere stage wise and is still at stage 1 meaning we should have probably never implemented? Furthermore Dojo as a framework does not use Observables at all. If we keep maybe it should go to core.
• the Web Platform stuff mostly contravene the principles of a shim/ponyfill in that they add themselves to the global. In scenario's where they don't, we are actually adding them to the global to be consistent. So do they belong in shim?
• should shim exist at all? should we move all the IE11 cruft to a legacy/ie11 folder, and all the Web Platform features to a platform folder?

[agubler]

I agree that shim is a confused suite of modules that operate in different ways and with different principles.

• Agreed, I think it would be preferable for IE11 polyfills to be automatically included when running a legacy build. Enabling developers to not think about legacy requirements when authoring an application certainly seems like the best developer experience. Also being able to use the native APIs instead of restricting users to shim's ponyfills opens users up to a wealth of educational resources such as MDN.
• Would this also include fetch, which I believe is only required for IE11?
• Dojo not using Observable and being at stage 1 makes it a great candidate for deprecation/removal, I'd remove it.
• How would we plan to deal with users that currently leverage the shims that are being proposed to be moved to polyfills dealt with by the build tooling?
• Given that we have a plan, be it deprecation and then removal in a subsequent release or an automatic migration (sounds tough) it makes sense to me completely deprecate the concept of dojo/framework/shim and introduce the something like the proposed dojo/framework/platform that more accurately describes the remaining modules.

[JamesLMilner]

@agubler pretty much hit everything I was thinking. I think we should auto bundle everything for IE and then for newer platform features have them under a platform namespace. Re Observable I think we should deprecate that unless there is any strong reason not too.

[maier49]

Self assigning this as I'm working on converting the legacy shims to work as polyfills while still being usable directly. This won't address the entirety of the issue though.

[agubler]

The majority of this initiative has been completed, for the remainder targeted issues will be raised.