There is also now a name for that kind of extension: Prollyfill.
And with that there is going to be an explanation necessary in order to understand what this all means. There are two seemingly competing ideas here but effectively they are completely different. Here is a quick and simple outline to understanding what all this is.
Here is a table to visualize the difference between Polyfills and Prollyfills:
|Standard||Implemented by Browsers|
|Polyfill||Yes||Some or Most|
The mentality of the two is different. Polyfill is something that is backwards looking and Prollyfill is forwards looking in the sense that with Polyfills you’re achieving browser compatibility for your code and with Prollyfills you’re achieving a complete extension of existing technologies through your code.
So why the group?
There are many people and companies moving in this space. They all have wonderful ideas. In some cases they have excellent Prollyfills. This group wants more of all that. And to make it easier, the group believes there could be a standard way to do it. There should be APIs and tooling that helps authors create these new extensions, implement them and then socialize or popularize their work in order to influence browser implementors and standards bodies.
I still don’t get it … why?
It’s impossibly hard to get browsers updated to all of the latest standards and not break the web. Even if they do a great job of continuous improvements, it is equally hard to get users (read: Corporate or Enterprise restricted computers) to let go of their favorite browser even if it’s impacting their experience. Given this it’s extremely slow for browser implementors to be in lock-step with each other and natively cover all the latest and greatest ideas.
Design by committee is also very hard. There are lots of smart people with smart ideas that don’t always match up. Given this it’s usually a very long time before a really good concept gets articulated into a standard that everyone agrees too. Standards authors and editors have to make very cautious decisions about what goes in and out of a standard. A bad standard can create terrible precedences and good ideas could be lost.
With both the browsers and standards being slow to progress it’s also important that when they do converge that they converge on the very best ideas. The best ideas are usually the ones that are being used. If there are two choices for a way to do something but one is clearly being used by everyone, that is conceptually a standard. So why not have a framework that allows individuals to create things in a systematic way and drive browsers, standards and authors toward a particular implementation? This goes in the other direction too. What if there is just one implementation? Who says there couldn’t be a different or better one? It would be far better for the competition to happen and provide standards bodies the opportunity to watch the good ideas bubble up.
Waiting on you
So now there is a new group devoted to creating this standard way to extend the web. And there is a clear definition of what this means. What’s missing is your participation. Here are some links to help you get started: