In the past couple of years, the web has evolved in big steps. During the implementation of ECMAScript 5, the ECMAScript 6 standard started its development (now known as ECMAScript 2015 or ES2015). ES2015 introduced many changes in JavaScript, such as adding built-in language support for modules, block scope variable definition, and a lot of syntactical sugar, such as classes and destructuring.

Meanwhile, web components were invented. Web components allow us to define custom HTML elements and attach behavior to them. Since it is hard to extend the existing set of HTML elements with new ones (such as dialogs, charts, and grids), mostly because of the time required for consolidation and standardization of their APIs, a better solution is to allow developers to extend the existing elements in the way they want. Web components...

Nowadays, browser vendors are releasing new features in short iterations, and users receive updates quite often. This helps developers take advantage of bleeding-edge web technologies. ES2015 is already standardized. The implementation of the latest version of the language has already started in the major browsers. Learning the new syntax and taking advantage of it will not only increase our productivity as developers but will also prepare us for the near future when all browsers will have full support for it. This makes it essential to start using the latest syntax now.

The requirements of some projects may enforce us to support older browsers, which do not support any ES2015 features. In this case, we can directly write ECMAScript 5, which has a different syntax, but has semantics equivalent to ES2015. On the other hand, a better approach will be...

Although the previous section listed a lot of arguments for the required re-implementation of the framework responding to the latest trends, it's important to remember that we're not starting completely from scratch. We're taking what we've learned from AngularJS with us. In the period since 2009, the web is not the only thing that evolved. We also started building more and more complex applications. Today, single-page applications are not something exotic, but more like a strict requirement for all web applications solving business problems, which are aiming for high performance and a good user experience.

AngularJS helped us to efficiently build large-scale, single-page applications. However, by applying it in various use cases, we've also discovered some of its pitfalls. Learning from the community's experience...

In this chapter, we considered the main reasons behind the lack of backward compatibility between AngularJS and Angular. We saw that the design decisions implemented in Angular were fueled by two things: the evolution of the web and the evolution of the frontend development, with the lessons learned from the development of AngularJS applications.

In the first section, you learned why we need to use the latest version of the JavaScript language, why to take advantage of web components and web workers, and why it's not worth integrating all these powerful tools in AngularJS.

We observed the current direction of frontend development and the lessons learned in the last few years. We described why the controller and scope were removed from Angular, and why the architecture of AngularJS was changed in order to allow server-side rendering for SEO-friendly, high-performance...