-
Notifications
You must be signed in to change notification settings - Fork 12k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ES2015 Build Target #2907
Comments
I am using the Babili webpack plugin successfully with Angular CLI (currently 1.0.0-beta.32.3) and an ES2015 target. In |
@httpdigest I tried your suggestion but unfortunately I'm getting
Probably due a @filipesilva Could we adopt a similar approach when targeting Currently Or, alternatively, to disable |
We could perhaps use I know @clydin was also thinking of using |
@filipesilva I've been thinking on an approach but don't know how to implement it:
|
@aldo-roman I tried setting up two builds for my app similar to your first point. It looks something like this:
Unfortunately, I'd been trying for a while before reading this thread... @filipesilva does the CLI currently not support es2015 compile target at all? |
@philipahlberg that is an interesting approach. That way we would produce 2 apps, and would need to specify a 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 |
At simplest, index.html could have: |
@ajackson-cpi Why not use the |
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. |
@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. Where is the right way to add this? |
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. |
@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). |
I also need it! |
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). |
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". |
#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. |
Any update on this ? |
There is a pr in review for this: #7610 |
Fixed by #7610 |
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
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:
Multiple options can be considered for this, like a browser sniffing server-side solution OR abandoning non-ES2015 browsers (a possible future one day).
The text was updated successfully, but these errors were encountered: