Skip to content

Conversation

galenwarren
Copy link

@galenwarren galenwarren commented Mar 25, 2018

Wondering if you might be interested in a PR that transpiles the code that goes into the dist folder? I'm using your library -- and it's great! -- but this library is flagged as containing code that is not transpiled to ES5, as described here which causes problems in some bundling scenarios.

Also, I unfortunately need to support some older browsers, so I'm hoping this will help with that problem as well.

@yyx990803
Copy link
Member

yyx990803 commented Mar 25, 2018

Thanks, but latest uglifyjs handles ES2015 just fine. I don't see a need to transpile.

FYI this library requires native ES2015 so transpiling won't make it work in older browsers either.

@yyx990803 yyx990803 closed this Mar 25, 2018
@galenwarren
Copy link
Author

Thanks. If it's not too much trouble, would you mind elaborating a bit on the dependency this library has on native ES2015 support, such that transpiling and/or polyfills wouldn't help? I may need to support a bit of IE11 traffic, at least for a while, so I'm trying to understand my options.

Thanks again, nice library.

@yyx990803
Copy link
Member

Custom Elements requires native ES2015 classes so that it can extend HTMLElement. Transpiled classes won't work out of the box because it's not real subclass of HTMLElement, and it requires esoteric hacks to make it work. Browsers like IE11 also requires non-trivial polyfills to be web-component comaptible, plus the ShadyDOM polyfill does not provide the real CSS encapsulation ShadowDOM is supposed to provide.

TL;DR: don't use web components in browsers that do not support it natively, otherwise you are just getting more trouble than benefits.

@galenwarren
Copy link
Author

Thanks, makes sense. I'm going to see if I can make this work in my fork -- looks like the issue you're discussing re: HTMLElement is what is discussed here and which resulted in this babel plugin to address it, so I'll see if that works for IE11.

I understand that, even if that works, you probably don't want to clutter up your project with a bunch of extra stuff just for IE11 support. In my case, I can't quite throw IE11 overboard just yet, so maybe this will help me and any others in my situation. I'll reply back to let you know how it goes, just in case you're interested.

@galenwarren
Copy link
Author

Just to close the loop here, I was able to get this to work in IE11 using the above approach, in this fork. I'm just publishing it privately for my own use. Thanks for the help and guidance.

@allenhwkim
Copy link

allenhwkim commented May 25, 2018

@galenwarren That's cool. I also need IE11 support.
If I use this now, I have to use your fork instead of the official one.
How about making a PR with your fork which to generate two different public files for IE11+ users and non-IE11 users, so that both users are satisfied with this module.
e.g. dist/vue-wc-wrapper.js and dist/vue-wc-wrapper.ie11.js

@galenwarren
Copy link
Author

@allenhwkim I could do that -- but let's check first to see if this is something that @yyx990803 would want to merge.

@wbern
Copy link

wbern commented Apr 21, 2020

It's truly a shame that we can't bring some ie11 to this project. I understand that it's not easy for a maintainer to maintain, but its still a shame having to use forks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants