Webpack and Babel Loader - Which target to define?

[dsilhavy]

Description

In our current build process, we are using webpack as a module bundler and Babel to transpile code to a specific JavaScript version. In this thread, I would like to discuss which Babel target we should be aiming for. Our current base configuration looks like this:

{
    loader: 'babel-loader',
    options: {
        targets: 'defaults',
        presets: ['@babel/preset-env']
    },
}

However, this will not lead to valid ES5 code when checking with npx es5-validator dash.all.min.js:

[es5-validator] Your code is not ES5 Compatible. It's not ready to ship to production, otherwise it will break you App on Android 4+ or iOS 8+.
As an example, the nullish-coalescing-operator is not transpiled with these settings.

When removing the targets option, Babel does the following:

When no targets are specified: Babel will assume you are targeting the oldest browsers possible. For example, @babel/preset-env will transform all ES2015-ES2020 code to be ES5 compatible.

While this ensures the highest compatibility it increases the bundle size. As an example:

• dash.all.min.js with targets: 'defaults': Size: 929KB, ES5 validator: fail
• dash.all.min.js with no targets option: Size: 1100KB, ES5 validator: success

Question

As described above, there is a tradeoff between bundle size and compatibility. I would like to understand if people have an opinion regarding which setting to choose.

Links

• Babel Targets: https://babeljs.io/docs/babel-preset-env#targets
• dash.js build configs: https://github.com/Dash-Industry-Forum/dash.js/tree/development/build

[littlespex]

My question would be: Why target ES5 at all?

https://philipwalton.com/articles/the-state-of-es5-on-the-web/

[nigelmegitt]

Fair points!

I wonder what the size improvement actually is for dash.js if we stop transpiling. That linked article suggests it could be a compelling reason.

[dsilhavy]

Thanks for the good discussion, guys.

Actually, one of my colleagues used the v5 debug build today with targets: 'defaults', on a Samsung SmartTV year 2021 without any additional bundling/transpiling, simply using a <script> tag in an HTML page. The device failed to handle the nullish-coalescing-operator of the builds.

[littlespex]

Targeting "chrome 51" should produce a baseline ES6 build without more modern features like nullish coalescing.

https://caniuse.com/es6

[gkatsev]

as you alluded to, the best way is to target specific browsers that should be supported rather than javascript versions. A common version is chrome 53 (because often TVs of a particular vintage are chrome 53) and chrome 70 (because it's the next version after the PTS/DTS switch).
Then, the tooling can figure out which features of newer JS are available.
Additionally, depending on things, it's possible to keep older versions of a lib around for older browsers during the transitionary period while newer versions, with a major version bump to drop older browsers, skip forward.
Also, depending on setup, you could also have separate builds that target different browser versions as well. That way, for newer browsers you get slimmer code that uses newer features, but older devices would have more code but greater JS support. Though, this would require more work from consumers, as well.

Especially given how complex players are, the tooling shouldn't compile down to ES5 just because at this point. The question is what your baseline browser support is and then that should be your target for transpilation.

[gkatsev]

(also, I do think that libraries generally should be as permissive as possible, within reason)

[dsilhavy]

Thank you all for your input. I followed @littlespex suggestion and set the target to chrome 51 for now: #4620

[testeur-990]

Hello @dsilhavy ,
For your information, we are using dash.js on many smart TVs, including Tizen 3 and webOS 3, which have older versions of Chrome (e.g., Chrome 42, 47, etc.)
Thank you.

[JESUSMHG]

Hi @dsilhavy,

In my case, I support since chromium 53 with this Babel target configuration:

{
        targets: [
          "last 3 major versions",
          "Firefox ESR",
          "Chrome >= 53",
          "not dead",
          "not ie 11",
          "not baidu 7",
          "not and_qq 11",
          "not and_uc 12",
          "not op_mini all"
        ],
 }

[eirikbjornr]

Missed this until now: We're extremely catious with polyfills on TVs in BBC as we've seen pretty much every issue under the sun. Hence we don't use build/transpiled Dash.js. Instead we pull Dash.js source files directly and build them ourself.

Our final build is transpiled to target ES5, and we aim to avoid using language features from later versions unless the benfits far outweighs the cost. For example we've been using Promises for years. We make use of TypeScript's transpilation to enable writing modern(ish) syntax.

[eirikbjornr]

In our final build we target Chrome 32, Firefox 27, Opera 19, Safari 8. As I allude to above that's not the whole story though, as we allow/denylist what polyfills can enter the build files