search

skatejs / web-components

[DEPRECATED] - The frictionless way to use the webcomponents/webcomponentsjs polyfills.
MIT License
17 stars 4 forks source link

native-shim has to be ES6 #46

Open robdodson opened 7 years ago

robdodson commented 7 years ago

Looking at https://github.com/skatejs/web-components/blob/master/src/index.js#L16 it seems like native-shim.js is always required, but (as I understand it) this file must remain ES6 or it won't work in Chrome. How do you deal with a situation where the user wants to transpile these polyfills to ES5 but selectively exclude native-shim.js?

treshugart commented 7 years ago

@robdodson it's not CSP compliant, but we have a Webpack plugin that moves it into a conditional eval() only if native is detected in https://github.com/skatejs/web-components/blob/master/build/fix-native-shim.js. I really don't know of a better way to make it easier for consumers wanting to get off the ground quickly and iterate on how they include the polyfills at a later point in time. Definitely open to ideas.

A big motivation here is that the barrier to entry with the polyfills is quite large in the number of polyfills, implicit depenencies (on other polyfills) and the conditional inclusion of the native shim. This requires a significant amount of domain knowledge. You and I know the reasoning behind it, but many don't, and web components don't have the best reputation in the greater communities right now. This can be attributed to spec churn, browser support and the time it's taken to get to where we are today. Complexity here would just be another thing against them.

A better way might be to conditionally include the native shim, but I think we'd have to make assumptions about the path to the native shim relative to the parent it's loaded from, which can change depending on how consumers are loading or building it.

Thoughts?

robdodson commented 7 years ago

A big motivation here is that the barrier to entry with the polyfills is quite large in the number of polyfills...

yeah I agree with all the points listed here. I was actually looking into this package because I'm trying to use web components in a different framework and want to avoid as much polyfill loading complexity as possible :)

It looks like the Polymer folks inject a snippet into the page https://github.com/Polymer/polymer-build/blob/master/src/custom-elements-es5-adapter.ts#L112. So they always include the shim, then that snippet decides if it's needed. If it's not, the shim is removed.

But this gets away from having a simple import. Not sure if Webpack can sneak something like that into the page (I'm not familiar enough with what Webpack transforms can do).

treshugart commented 7 years ago

You can do conditional imports. At that time we were using Webpack 1, but it might be simpler using 2. Worth a try anyway! Would be good to try this with the standard fills so they're only loaded if necessary. I'm optimistic.

Once the polyfills are on NPM, we can add * deps on them so they're always up to date which makes this much more viable to consumers. Any traction on that?

robdodson commented 7 years ago

Can you point me to a conditional import example? My module skillz are weaksauce :P

treshugart commented 7 years ago

https://webpack.js.org/guides/code-splitting-async/

The only issue is that it's async, which means we might need to expose an API to do something after the polyfills are finished loading so that definitions can be registered.