{"id":19522199,"url":"https://github.com/captaincodeman/poly-poly","last_synced_at":"2026-03-02T03:34:03.540Z","repository":{"id":66357899,"uuid":"82412445","full_name":"CaptainCodeman/poly-poly","owner":"CaptainCodeman","description":"Polymer element to load feature polyfills from polyfill.io service","archived":false,"fork":false,"pushed_at":"2017-03-05T19:32:41.000Z","size":2818,"stargazers_count":1,"open_issues_count":0,"forks_count":0,"subscribers_count":1,"default_branch":"master","last_synced_at":"2025-11-20T03:25:56.887Z","etag":null,"topics":["polyfill","polyfill-service","polyfills","polymer","polymer-recipes"],"latest_commit_sha":null,"homepage":"","language":"HTML","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/CaptainCodeman.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2017-02-18T19:58:06.000Z","updated_at":"2017-03-07T20:13:14.000Z","dependencies_parsed_at":"2023-02-22T04:00:36.780Z","dependency_job_id":null,"html_url":"https://github.com/CaptainCodeman/poly-poly","commit_stats":null,"previous_names":[],"tags_count":4,"template":false,"template_full_name":null,"purl":"pkg:github/CaptainCodeman/poly-poly","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/CaptainCodeman%2Fpoly-poly","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/CaptainCodeman%2Fpoly-poly/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/CaptainCodeman%2Fpoly-poly/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/CaptainCodeman%2Fpoly-poly/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/CaptainCodeman","download_url":"https://codeload.github.com/CaptainCodeman/poly-poly/tar.gz/refs/heads/master","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/CaptainCodeman%2Fpoly-poly/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":29991828,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-03-02T01:47:34.672Z","status":"online","status_checked_at":"2026-03-02T02:00:07.342Z","response_time":60,"last_error":null,"robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":true,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["polyfill","polyfill-service","polyfills","polymer","polymer-recipes"],"created_at":"2024-11-11T00:37:44.077Z","updated_at":"2026-03-02T03:34:03.506Z","avatar_url":"https://github.com/CaptainCodeman.png","language":"HTML","readme":"# poly-poly\n\nElement to load feature polyfills from [polyfill.io service](https://polyfill.io/v2/docs/).\n\nHelps to follow [fundamental polyfill best practices](https://w3ctag.github.io/polyfills/)\nand avoid bundling polyfills with your elements while still supporting the PRPL pattern.\n\n## Background\n\nLet's talk about polyfills ... they are never going to go away. The whole reason we can use\nWebComponents at all is because polyfills enable them in browsers that don't yet support them.\nIf we had to wait for all browsers to support a feature before we could use it, some features\nwould never be usable because use helps drive implementation by other browser vendors and the\npolyfills help with that.\n\nWe obviously need to load the WebComponents polyfill itself when using Polymer but what about\nother polyfills for features that may be required by individual elements?\n\n## The Problem\n\nThe problem is, who's job is it to load polyfills and how?\n\nOne option is for each element to load whatever polyfill it needs directly. It's easy to add\na static `\u003cscript src=\"some-polyfill.js\"\u003e` to the element and boom, job done. But there are\nsome drawbacks to doing this:\n\n1. Polyfill scripts need to be added to each element repository (and not all are available\nvia package managers). Does the element author have to maintain those scripts as they are\nupdated and improved? Will they?\n\n2. Polyfill scripts are loaded by all browsers, whether they need them or not. Some polyfills\nare small and insignificant but others can be pretty large and they all add-up and ultimately\nconsume bandwidth and add script parsing overhead which can be significant on slower devices.\n\n3. Different elements could need the same polyfills or different combinations of polyfills\nwhich would further add to waste, especially as the same scripts could then be referenced from\nseveral different paths.\n\n3. It's unclear when polyfills can be removed. For a published element it becomes a hard choice\nto support some versions of browsers or not. All these polyfills in different elements could \nbuild up over time.\n\n4. We may be forcing one particular polyfill on consumers of our element when they would\nprefer to use a different implementation.\n\nSome of these could be mitigated - the element could include some feature detection to only\nload the polyfill if it was required but this then leads to other problems - making sure that\nthe now possibly unreferenced script is included in any app bundle and so on. If we end up using\nseveral different polyfills in different elements, each will add some latency to the loading\nwhich could be undesirable. We're also still left with the polyfill versioning and support issues.\n\nBundling polyfills with our element goes against [fundamental polyfill best practices](https://w3ctag.github.io/polyfills/)\n\nThere's also some similarities to [The Problem With Using HTML Imports for Dependency Management](https://www.tjvantoll.com/2014/08/12/the-problem-with-using-html-imports-for-dependency-management/)\n\n## Use a Polyfill Service\n\nThe ideal solution to polyfill loading is to use a [polyfill service](https://polyfill.io/v2/docs/).\nThis can allow us to update the users browser to support just the features we require all in a\nsingle web request and as browsers are updated, the use of the polyfills can evaporate to zero\nall without a single code change or redeploy of our applications.\n\nIf our element used any new feature we would need to document it and it become the app authors \nresponsibility to load any required polyfill for it based on the browsers they want to support.\n\nPerfect!\n\nExcept ...\n\n## Async Polyfill Loading\n\nOur polyfills may be requested way up in the header of the page, but the elements that use them\nare right down in the DOM. If we make everything load synchronously then we're OK but it would be\nnicer if we could keep everything as async as possible and only load them if and when they are\nrequired.\n\nIf the elements and polyfills are loaded async, there is no guarantee that the polyfills will have\npatched the browser features before our elements try to use them. So how do we make them wait if\nthey have to?\n\nIn some ways, this is more of a challenge with Polymer and WebComponents because they are so \"native\".\nWith many other frameworks there is a much clearer point where the app is loaded and initialized so,\nif you are loading polyfills, you can just delay that startup. But if you have native support for \nWebComponents and you want to initialize the rest of your app while the polyfills are loaded, you\nneed some way to make them wait.\n\nSo I tried to come up with a solution ...\n\nAny element that requires polyfills should inludes a dependency on the [poly-poly.html](./poly-poly.html)\nelement. This generates a request to the [polyfill.io service](https://polyfill.io/v2/docs/) to load\nwhatever polyfills have been listed in the `window.PolyPoly.features` array. This array should be set\nbased on feature detection in the apps `index.html` page.\n\nThis will delay triggering any polyfill loading until an element that requires it is itself\nloaded which should make the system lazy-loading / PRPL pattern friendly. i.e. if only certain pages\nof an app need polyfilled features then the polyfills do not need to be loaded unless and until those\npages are.\n\nThe `poly-poly` element provides a promise that the calling element can use to delay any operations \nuntil the polyfilled features are available. Actually, it's not a real `Promise` - I didn't want to\nload the promise-polyfill that would load regardless of the browsers existing support (which is the\nwhole point of this element) so it's Promise-_like_ ... just enough to provide a `.then()` callback.\n\nAn example of the \"promise\" being used to delay functionality of an element until the required feature\nis available is shown in [lazy-img](https://github.com/CaptainCodeman/lazy-img) which requires the\nnewer [IntersectionObserver](https://developers.google.com/web/updates/2016/04/intersectionobserver)\nwhich at the time of writing is only supported natively in Google Chrome.\n\nWith Chrome, no additional scripts are loaded. Using a browser without native support will make a\nrequest to load the ~20Kb polyfill required to function.\n\n## Final Thoughts\n\nThe idea scenario would be for as much of this to be automated and built in to tooling as\npossible. Maybe elements could be tagged with the features that they use (or they be automatically\ndetected by an analyzer) and the script to load them generated automatically.\n\nI'd love to hear feedback on the approach and any ideas to improve it.\n","funding_links":[],"categories":[],"sub_categories":[],"project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fcaptaincodeman%2Fpoly-poly","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fcaptaincodeman%2Fpoly-poly","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fcaptaincodeman%2Fpoly-poly/lists"}