ES2015 Build Target

[ajackson-cpi]

angular-cli: 1.0.0-beta.16

Today angular-cli targets ES5 and then polyfills may allow IE9 support, but 70% of browsers support native ES2015 (Netflix). Targeting ES2015 makes a smaller download & faster execution,
Building a project for both ES5 and ES2015 helps the common ES2015 case.

Typescript has an ES2015 target, and babel-minify is a valid ES2015 minifier. This could also benefit the developer iteration loop.

A fallback mechanism would need development:

1. Test for ES2015 (not loading the arriving script if until validated).
2. On fail, load to the ES5 bundle (thus making the ES5 UX slower).
   Multiple options can be considered for this, like a browser sniffing server-side solution OR abandoning non-ES2015 browsers (a possible future one day).

[httpdigest]

I am using the Babili webpack plugin successfully with Angular CLI (currently 1.0.0-beta.32.3) and an ES2015 target. In node_modules/@angular/cli/models/webpack-configs/production.js I just replaced the UglifyJS plugin instantiation below with new BabiliPlugin({}, {}) and added a const BabiliPlugin = require("babili-webpack-plugin"); at the top. Additionally, we then need to install the Babili plugin with npm install --save-dev babili-webpack-plugin.

[fdcastel]

@httpdigest I tried your suggestion but unfortunately I'm getting

ERROR in unknown: Duplicate declaration "e" (This is an error on an internal node.
Probably an internal error)

Probably due a Babel bug 😢 -- But thanks anyway for the nice trick 👍 .

@filipesilva Could we adopt a similar approach when targeting ES2015? UglifyJS appears to be far from getting there. And Babili appears to be a promising solution.

Currently angular-cli doesn't support ES2015 due this limitation. Yes. It works in development builds but what this is good for? It is disappointing to discover it simply doesn't cut when deploying to production.

Or, alternatively, to disable UglifyJS when targeting ES2015? (This is what I'm doing for now, with a hack similar to the one suggested by @httpdigest).

[filipesilva]

We could perhaps use .browserlist instead to allow a user to choose what browsers should be supported (similar to using https://github.com/babel/babel-preset-env).

I know @clydin was also thinking of using .browserlist for polyfills so this would play into that.

[aldo-roman]

@filipesilva I've been thinking on an approach but don't know how to implement it:

0. We build for both ES5 and ES2015. Say:
   main.<hash>.js -> ES2015
   main.<hash>.es5.js -> ES5, for legacy support

1. We validate whether the browser supports ES2015 and load the correct files.
   1.1. We can use Netflix ES2015 feature detection, like this one
   This would require inserting the main, vendor, polyfill and chunks at runtime.
   Perhaps we can inline the feature detection.

   1.2. We can use the ES2016 modules to deliver:
   <script type="module" src="main.<hash>.js">
<script type="application/javascript" nomodule src="main.<hash>.es5.js">
   The later approach seems cleaner, but ES2016 modules are still in progress. Currently only Safari supports it but support on Chrome and Edge are both under development.

[philipahlberg]

@aldo-roman I tried setting up two builds for my app similar to your first point.

It looks something like this:

"apps": [
    {
      "name": "es2015",
      "root": "src",
      "outDir": "es2015",
      "polyfills": "polyfills.es2015.ts",
      "tsconfig": "tsconfig.es2015.json",
       ...
    },
    {
      "name": "es5",
      "root": "src",
      "outDir": "es5",
      "polyfills": "polyfills.es5.ts",
      "tsconfig": "tsconfig.es5.json",
       ...
    }
  ]

Unfortunately, I'd been trying for a while before reading this thread... @filipesilva does the CLI currently not support es2015 compile target at all?

[aldo-roman]

@philipahlberg that is an interesting approach. That way we would produce 2 apps, and would need to specify a target propety for each app. That target can be used as the extension suffix.

The problem is we would need a way to determine whether to serve the es5 or the es2015 app. We would also end with 2 index.html files, right? Do you have any thougths about it?

[ajackson-cpi]

At simplest, index.html could have:
<link rel="prefectch" href="es2016version.js">
use the result of this script: https://gist.github.com/DaBs/89ccc2ffd1d435efdacff05248514f38#file-es6-feature-detection-js
could append the script tag necessary & window.localStorage.add('isES2016', true) // and use this to avoid future tests.

[mgol]

@ajackson-cpi Why not use the <script type="module"> approach @aldo-roman mentioned instead? Less JS-based eval hacks that may influence performance in a bad way.

[ajackson-cpi]

Modules are the future (if it ever lands), but we can use this feature today with my index.html.

Eval & big downloads happen parallel with prefetch (supported everywhere but Safari). On a cached load, neither happens.