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.

[aldo-roman]

@mgol @ajackson-cpi Perhaps we can use the feature detection in the mean time and remove it after ES2015 modules get to stable browsers.

They are already on Safari/iOS stable. Chrome, FF, Edge have modules under experimental flags. http://caniuse.com/#feat=es6-module

Where is the right way to add this?

[philipahlberg]

I was hoping to do something along the lines of what the Polymer team has suggested for their CLI builds, namely using UA-parsing to differentiate between es5 and es2015 browsers, and deliver index.html accordingly.

[ajackson-cpi]

@philipahlberg Serverside UA sniffing isn't compatible with CDN destinations & CDN Reverse Proxies. Client-side is possible, but loses to Feature Detection (see my comment above) on reliability and code-only-once (because UA is a moving target).

[kirillgroshkov]

I also need it!

[rvalimaki]

Shouldn't the priority be much higher than "nice to have"? It's late 2017 already. Looking forward to get native Promises, native arrow functions, and with ES2017, native async/await (though currently Zone.js is still broken with native async/await).

[kirillgroshkov]

Not to be non-constructive or to blame anyone, but indeed, things like this put angular further and further delayed in a race of angular-react-vue. Lacking of out-of-the-box SSR and HMR is a show-stopper for me to use angular in future projects. In other places it "just works".

[aldo-roman]

#15127 may be related or be stopper, given (if I understood correctly) that even with ES6 support, development would be blocket given ngc does not output ES6 on JIT.

I did some manual tests using ES6 + Babili and the bundle size was not very different from ES5 + Uglify on a production build. I think this is because the setup took all Angular files using ES5 and not ES6, but I don't know how to modify the webpack script to use the ES6 that Angular already publishes on npm.

On my app, only 10% of users (IE11) do not support ES6, so we have a big gap to address.

[jimmykane]

Any update on this ?

[sylvaindumont]

There is a pr in review for this: #7610

[filipesilva]

Fixed by https://github.com/angular/angular-cli/pull/7610

[angular-automatic-lock-bot[bot]]

This issue has been automatically locked due to inactivity. Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}