![\"Angular](\"https:\/\/contentlab.com\/wp-content\/uploads\/2021\/11\/ivy3.jpg\")
<\/p>\nAngular 8 is finally here! Although the Angular had originally planned to release Angular 8 in March or April, it didn\u2019t happen until late May.<\/p>\n
With the new release now available, it\u2019s important to understand what has changed so you\u2019ll know how to approach Angular 8. Since Angular 7 is going to be supported until April of 2020, you may decide that it\u2019s not worth upgrading if Angular 7 already meets all of your needs.<\/p>\n
With that in mind, let\u2019s walk through what is new in Angular 8.<\/p>\n
For more than a year, the Angular team has been talking about the new Ivy renderer they\u2019ve been working on. Although the team has spoken and written about Ivy on many occasions, we still haven\u2019t seen an official release. Well, that\u2019s about to change. Sort of…<\/p>\n
The Angular team has announced that they\u2019re going to be including Ivy in Angular 8 as an opt-in preview. Many Angular developers were hoping for a final release of Ivy, but that\u2019s not what we\u2019re getting in this release. A preview is a lot better than no view. Trying out the preview will let you see how well your current Angular applications work – or don\u2019t work – with Ivy.<\/p>\n
If you\u2019re not familiar with Ivy, is it something you should care about? If the user experience of your apps is important to you, then Ivy is definitely something you should care about. Although the framework has made huge improvements in file size and runtime speed since the days of Angular 2, Angular apps often tend to be on the heavy side when it comes to file size and memory use.<\/p>\n
<\/p>\n
Ivy aims to change this. Compared with the current Angular View Engine, Ivy provides the following benefits:<\/p>\n
On top of all this, Angular Ivy aims to be broadly compatible with existing Angular applications, so ideally, you\u2019ll be able to get all of Ivy\u2019s benefits without having to change your apps at all. There will be some bugs and hiccups, though. That\u2019s why it\u2019ll be helpful to try building your current Angular apps using Angular 8 and Ivy.<\/p>\n
If you run into any unexpected errors, you\u2019ll be able to let the Angular team know so they can either fix the issue or advise you on what you\u2019ll need to change to be Ivy-ready. There are a couple of areas where Ivy is lacking\u2014in particular, internationalization and Angular Universal support aren\u2019t yet fully compatible. So if your Angular app supports multiple languages and\/or uses server-side rendering, don\u2019t expect it to be ready to work with Ivy just yet.<\/p>\n
One other trouble spot some users have encountered has been Angular Material. Apps using Angular Material don\u2019t seem to play well with Ivy, as of the latest Angular 8 beta. Keep this in mind when experimenting with Angular 8 (although eventually Angular Material will undoubtedly be updated to work well with Ivy).<\/p>\n
Outside of Ivy, there are a few other changes to look forward to in Angular 8.<\/p>\n
One of the most important changes is what the Angular team describes as \u2018Differential Loading of Modern JavaScript.\u2019<\/strong> To put it simply, this means that new apps generated by Angular CLI will now contain separate bundles for legacy JavaScript (ES5) and modern JavaScript (ES2015+). This is great news because it means that modern browsers with ES2015 support will be able to download smaller, more efficient app bundles that load and render faster than before.<\/p>\n The Angular team is also adding a backward compatibility mode to the Angular router which will make it easier to upgrade legacy Angular apps to modern Angular. In an ideal world, we would have all been able to upgrade our Angular 1.x apps to Angular 2+ right away.<\/p>\n In the real world though, this doesn\u2019t always happen. To this day, there are a large number of massive legacy Angular apps happily chugging away, serving businesses and making users happy. They haven\u2019t been upgraded for a simple reason: they\u2019re working well, and there wouldn\u2019t be much ROI in doing a complete rewrite.<\/p>\n The end is in sight for Angular 1.x. It isn\u2019t going to see any new development and will only be receiving security patches until the end of its long-term support period on June 30, 2021. For teams working on large Angular 1.x apps, the time to begin the transition is now (and the changes to the Angular router will help make the transition smoother). The router updates will make it possible to lazy load parts of Angular 1.x apps inside a modern Angular app using $route APIs.<\/p>\n A small, but welcome new feature in Angular 8 will be improved support for bundling web workers with the Angular CLI. For readers unfamiliar with web workers, they\u2019re an important innovation in front-end development that makes it possible to farm out CPU intensive work to a separate hardware thread. This is great news for front-end developers because prior to web workers, our applications were limited to using a single thread.<\/p>\n There\u2019s one catch with web workers: the code that runs in the worker can\u2019t be in the same JavaScript file as the rest of your application. It must be separate. This tends to work poorly with tools like the Angular CLI that want to automatically bundle up your JavaScript into as few files as possible. The improvements to Angular CLI\u2019s web worker bundling in Angular 8 will get rid of this awkwardness and set you on the path to fully parallelized web worker happiness.<\/p>\n The Angular CLI will be gaining another new feature: opt-in usage sharing. This will give you the opportunity to opt-in to sharing telemetry about your Angular CLI usage with the Angular team. I\u2019ve got to applaud the Angular team for approaching this the right way.<\/p>\n Some other development tools share telemetry on an opt-out basis\u2014they do it by default until you explicitly tell them not to. Some even share telemetry about how you use the tools without giving you any way to opt out of this sharing. Asking for your consent up-front is absolutely the right move by the Angular team\u2014and I suspect many of us will happily share our usage details to help improve the development tools we use every day.<\/p>\n Finally, Angular 8 is going to include updates to the latest and greatest versions of Angular\u2019s dependencies, which include tools like RxJS and TypeScript. Although this might seem like a tiny improvement, it\u2019s also a welcome one. Keeping up with TypeScript, in particular, is great because the TypeScript team always seems to pack useful new features into every release.<\/p>\n Although there\u2019s nothing stopping you from manually upgrade to the latest version of TypeScript in your projects, it\u2019s great to see that the Angular<\/a> team is keeping up with everything that TypeScript has to offer and that new apps generated via the Angular CLI will also use the newest version of TypeScript by default.<\/p>\n Hearing about features is nice, but a big part of the reason many of us upgrade to new versions of Angular is to get a free performance boost! With that in mind, let\u2019s compare Angular 7.2, and Angular 8.0.0.<\/p>\n The benchmark was run with a new app created with As with any benchmark, you\u2019ll want to run it on your own code to see if upgrading will help you, but this simple benchmark will give us a baseline performance comparison between versions.<\/p>\n A production build with Angular 7.2 resulted in a main.js weighing in at 240KB. The performance numbers were as follows:<\/p>\n The final release build of Angular 8 resulted in a JavaScript<\/a> bundle roughly the same size as Angular 7.2: 250KB. That size only applies for older browsers that don\u2019t support ES2015, however.<\/p>\n In Angular 8, the build process creates two separate bundles: one for older browsers, and one for modern evergreen browsers with full ES2015 support. For modern browsers, the total bundle size is 170KB. That\u2019s a large improvement, especially for users loading your app via slow mobile connections.<\/p>\n Here are Angular 8\u2019s benchmark results:<\/p>\n That looks good! We got a pretty nice performance boost over Angular 7.2.<\/p>\n As we\u2019ve seen, the additions to Angular 8 aren\u2019t huge outside of Ivy. Although they\u2019re absolutely nice to have, they certainly aren\u2019t critical for most applications. If you want to try the Ivy preview, the official Angular Ivy guide<\/a> will tell you everything you need to know.<\/p>\n With that in mind, should you upgrade your apps to Angular 8, or stick with Angular 7? In nearly every case, the answer is yes. You should upgrade them. Since there aren\u2019t any large breaking changes, in most cases your applications with work as-is without any changes. With the additions to enable differential loading, you\u2019ll get noticeable performance gains for free.<\/p>\n More importantly, upgrading to Angular 8 will enable you to ensure your apps are ready for Ivy. Although Ivy is only an opt-in preview in Angular 8, the time to start checking for Ivy compatibility is now. If your apps are going to need changes, it\u2019s better to find out immediately than to wait and find out that your apps just stop working in Angular 9 or 10 when Ivy becomes the default, and the legacy Angular View Engine is dropped.<\/p>\n GrapeCity has a complete set of JavaScript UI components<\/a> and powerful Excel-like JavaScript spreadsheet components<\/a>. We have deep support for Angular<\/a> (as well as React and Vue) in our products and are dedicated to extending our components for use in modern JavaScript frameworks.<\/p>\n You can read about the complete history of Angular here<\/a>.<\/p>\n This article was originally published on GrapeCity’s blog<\/a>.Angular 8 Support for Web Workers<\/h3>\n
Support for TypeScript<\/h3>\n
Angular Benchmarks<\/h3>\n
ng new<\/code> and built with ng build --prod<\/code>. The benchmark itself was done using Chrome\u2019s audit tab, using the \u2018Applied Fast 3G, 4X CPU Slowdown\u2019 setting to simulate running on a mobile device.<\/p>\nAngular 7.2<\/h4>\n
![\"Angular](\"https:\/\/contentlab.com\/wp-content\/uploads\/2021\/11\/1.png\")
<\/p>\nAngular 8.0.0<\/h4>\n
![\"Angular](\"https:\/\/contentlab.com\/wp-content\/uploads\/2021\/11\/angular-8-benchmarks.png\")
<\/p>\nAngular 8 Conclusion<\/h3>\n
\n<\/em><\/p>\n