You may have been hearing the buzzword "Ivy" being tossed around.
But what is Ivy?
Google’s Angular Team is setting a soft May 2019 release date for the generally-available version 8.0 release of its web app framework. Angular 8.0 is expected to include the first opt-in technical preview of the new rendering engine, Ivy.
Ivy is Angular's upcoming new rendering pipeline and view engine. Ivy is next in line. Ivy Renderer is a backward-compatible Angular renderer focused on further speed improvements, size reduction, and increased flexibility.
How Ivy rendering will improve Angular 8.0?
Normally, the renderer doesn't affect day-to-day development much. For those of us in the real world, though, we've had our fair share of frustration with the AoT (ahead of time compiled) compiler when moving from development to production. Ivy is going to drastically improve our development experience by removing much of the "black box" of the rendering process.
The features of Ivy rendering
-
Generated code that is easier to read and debug at runtime
-
Faster rebuild time
-
Improved payload size (Real world applications should see some size improvements, but many more improvements are planned)
-
Improved template type checking
-
Great backward compatibility. So that existing applications wouldn't break.
Ivy is going to be smaller, faster, and simpler applies not only to bundle sizes but also to the compilation process. This is mainly due to the two key concepts:
Locality
Locality means that Ivy compiles one file at a time. It only looks at a component and its template, not its dependencies, when generating the output. It's a process of compiling each component independently with its own local information that rebuilds faster by compiling partial changes and not the entire project files. This increases the speed of your build process. In the current angular code, each component has its parent information, which leads to compilation dependencies, whereas in Ivy, each component is independent. With this process, you can ship a precompiled code as a 3rd party lib. Additionally, it doesn’t require any metadata for compilation.
Compiling one file at a time will mean smaller sets of instructions, and it will also mean we'll be able to do incremental builds.
Tree-shaking
Ivy has been designed from the start with tree-shaking in mind. "Tree-shaking" means removing unused pieces of your code, which results in smaller bundles and faster load times.
Until now, Angular compiler takes angular templates, parses and would generate optimized JavaScript code that represents the data structure of the template. At runtime, this template data structure is interpreted by an angular interpreter and generates DOM. During the process, Angular compiler has to pass through conditional code paths, which may or may not be used during runtime. Tree shaking tools only recognize reference code and bundles all the code.
Tree-shaking is done using static analysis, which doesn't actually run your code. Because of this, it must take into account all possible scenarios and include anything that might be needed in the bundle.
With Ivy, your application will be built with Ivy runtime instructions instead of the ViewEngine runtime. Any dependencies you use from Angular or other 3rd parties should keep working as they will be run through the compatibility compiler. This opt-in preview will be focusing on moving applications to the Ivy compiler and runtime instructions without requiring developers to rewrite their applications.
The Angular team aims to release it as an opt-in preview in Angular v8.0 and you will be able to switch between the Ivy and View Engine build and rendering pipelines in your project. Ivy will be available as an opt-in preview in 8.0.0 in order to provide backward compatibility the team has promised and work on any automated migration tools if needed.
