Shims allow you to work without a browser compliance or without a browser abstraction library. Modern browsers have enough native and host APIs that you do not need any third party libraries for these features, you just need shims as your legacy browser compliance strategy.
Host objects defined in the WHATWG and W3C specifications are standard APIs. They are well known, readable and maintainable. They are highly optimised and efficient.
Consider getElementsByClassName, you can either use it and have a shim for non-compliant browsers. This gives you maximum performance for compliant browsers, good performance for non-compliant browsers.
It also gives you an easy upgrade path, as soon as all your supported browsers support getElementsByClassName, you can remove the shim.
It also gives great readability and maintainability. Any web developer knows the method, no down-time for learning library X.
If you were to instead define a wrapper function you would never be able to remove that wrapper function without rewriting your application code, even if in 10 years 100% of browsers support it. You also have a run-time (marginal) performance penalty for compliant browsers.
You also end up with a non-standard API that is not well known by the community.
They are a necessity for allowing you to use standard APIs. They involve augmenting host objects which is a difficult and frustrating task to get right.
However this host object extension is only done once and is done by a credible author. The browser normalization layer is put together with a great amount of pain and end-users can then use it without suffering that pain.
It's only not safe if you do it poorly. It's mostly safe if you know what your doing. mind you writing safe host object extension code is a nightmare.
And mind you, extending host objects should not be done unless you own the host objects. If a user wants to use a shim like the DOM-shim he needs to agree that the DOM-shim now owns those host objects and that the DOM shim fixes them by being a browser normalization layer.
Of course when shims extend host objects they will only shim compliant implementations if the current environment is not compliant.
Note that a shim is build to be safe and has minimal outside dependencies. Also note that you can build your own set of shims based on only the features you want to be emulated.
To make application level code safe and future-proof use feature detection for the host environment you expect to exist. One of three cases occurs
- the host environment exists and your code runs
- the host environment didn't exist, but the shim fixed and your code runs
- the host environment didn't exist and the shim did not fix, your code does not run.
In case 1. and 2. your code should run safely. In case 3. your code will not run, and it will not throw errors when it tries to use host environments that do not exist.
Note such a feature detection system for host objects is best done with a third party library like feature
Further reading:
Disclaimer: DOM-shim is a work in progress shim that's not ready, but illustrates an attempt at solving some of the host object manipulation problems.