Evaluate targeted webpack builds as means to improve performance in modern browsers

Targeted builds is one of the Webpack working group's exit criteria:

Implement targeted builds for modern and legacy browsers (defined as those which do and do not support <script type="module"> respectively) with only the code transformations and polyfills needed by each target.

The first step towards this goal is to determine whether or not targeted builds are worth pursuing. It is possible that the performance/network/JavaScript interpretation costs of our current Webpack build are minimal and/or not worth the effort/compilation time/complexity of a targeted build solution.

To determine whether to go forward with targeted builds, we should:

1. Create an "ideal" Webpack build that:
   • Contains no polyfills (add useBuiltIns: usage within babel-preset-env config instead of manual polyfills – #28837 (closed))
   • Targets ES6 with target: { esmodules: true } in the preset-env config.
2. Compare the Webpack output of #1 with our current Webpack output. Things we should evaluate include:
   • Overall bundle size
   • JavaScript interpretation costs (time/CPU/memory)
   • Webpack compilation time/memory usage

Deliverables:

• Ignore rails-integration details for serving concurrent modern/legacy builds for the moment.
• Create means to build webpack targeting "modern" browsers and make it the default during development and test environments. Allow this to be overridden with a LEGACY=1 environment variable or something similar.
• Consider all ways in which "modern" build targets performance could be improved including usage of es6 versions of our common vendor modules.
• Manually compile the webpack assets for production targeting legacy browsers and modern browsers, then compare the results as outlined above.