search

philipwalton / webpack-esnext-boilerplate

513 stars 41 forks source link

Use esmodules target? #12

Closed gingur closed 5 years ago

gingur commented 5 years ago

Might be easier to just use https://babeljs.io/docs/en/babel-preset-env#targetsesmodules when generating module bundle.

philipwalton commented 5 years ago

I've avoided using that (in favor of manually referencing the targets I care about) primarily due to this issue: https://github.com/babel/babel/issues/8809

gingur commented 5 years ago

Hrmm, I understand your argument however the purpose of this solution is to separate the ESM vs non-ESM support. If you're bundle is for ESM support + target newer browsers, you'd run into a situation where your non-ESM build would not be used for visitors who do support ESM but do not meet your target requirements, leading to that subset of users not getting served the correct JS. This approach only works IMO if the bundle for ESM supports all browsers that support ESM, not a subset of them.

philipwalton commented 5 years ago

the purpose of this solution is to separate the ESM vs non-ESM support

That's not how I see it.

The purpose of this solution is to deliver the smallest possible JavaScript payload to users who are on modern browsers, and to not make those users have to pay a cost (both download and parse cost) for the fact that some other users happen to use old browsers.

For example, I don't want my users to have to load an async to generator polyfill just because Safari 10.3 (which 0% of my users run) happens to have an obscure bug, which Babel then includes more polyfills/transforms for.

Ultimately what browsers to support is a decision every web developer has to make individually, so if you want to use the esmodules flag and support Safari 10.3, you're free to do so. As for the article and demo repo, I still think I prefer to be explicit, so users know what they're getting.

philipwalton commented 5 years ago

BTW, you might be interested in following along with this proposal: https://github.com/whatwg/html/issues/4432

Something like this would help developers have the ability to serve small payloads to modern browsers while still having fallbacks for older (but module-supporting) browsers.

jquense commented 5 years ago

@philipwalton curious what happens for users that fall in the hole, between the compilation target and have module support? It seems like those users would crash since they are getting the newer bundle while users on older browsers would get the legacy bundle and work fine? My understanding of the technique for differential loading depends on the module script not getting run in older environments right?

philipwalton commented 5 years ago

Yes, they would likely see an error -- in the same way that a user on IE8 would probably also see errors (and BTW IE8 has a much larger user base than Safari 10.3).

As I mentioned before, this is a decision that each developer is going to have to make for themselves, and they should base their decision on actual usage data from their own analytics.

Rather than being overly cautious and adding a bunch of polyfill code that probably isn't ever needed, it's better to be tracking the errors that are actually being encountered by your users and prioritizing those. If a lot of your users are running into bugs from not including polyfills for Safari 10.3, then by all means include those polyfills.