There are other features you *could* actually polyfill, such as Array.of, Number.isNaN or Object.assign, because those don’t introduce syntax changes to the language – except that you shouldn’t.

Polyfills are naughty as they patch native APIs, while ponyfills are pure and don't affect the environment.

How are ponyfills better than polyfills? A polyfill is code that adds missing functionality by monkey patching an API. Unfortunately, it usually globally patches built-ins, which affects all code running in the environment. This is especially problematic when a polyfill is not fully spec compliant (which in some cases is impossible), as it could cause very hard to debug bugs and inconsistencies. Or when the spec for a new feature changes and your code depends on behavior that a module somewhere else in the dependency tree polyfills differently. In general, you should not modify API's you don't own.

Want to use this now? Existing projects A more robust and maintainable way to incorporate this patch into your workflow using patch-package:

But I'll definitely take underscore mixins over extending String.prototype or other clunky implementations any day.

Instead of re-opening Ruby classes like that (I get involuntary twitches), for our little exercise we are going to invent another name

prepend_message

allowing common connections to be made wirelessly