What do you want to learn? Leverged jhuang@tampa.cgsinc.com Skip to main content Pluralsight uses cookies.Learn more about your privacy Angular: The Big Picture by Joe Eames This course will teach you a high level view of Angular, to assist you in either understanding Angular better for your own development, or learning when to use Angular vs. other front end frameworks. Start CourseBookmarkAdd to Channel Table of contents Description Transcript Exercise files Discussion Learning Check Recommended Course Overview Course Overview Hi there. I'm Joe Eames, and welcome to my course, Angular: The Big Picture. I'm a Google Developer Expert in Angular and have been working with AngularJS since 2010 and Angular since it was in Alpha. Angular is an amazing, modern, highly performant framework and learning it is one of the best things you can do for your career. In this course, we are going to take a high-level view of Angular so that you can be well educated on its strengths and weaknesses. Some of the things we will cover are the benefits of Angular, its architecture, various tools to use with Angular, and some tips, tricks, and gotchas. We'll also look at the present and future of Angular. By the time we're through, you'll have all the knowledge you need to either make an educated choice on using Angular in a project or put the details of Angular into perspective as you learn to write applications with it. Before starting the course, you should be familiar with JavaScript and the web in general. I hope you'll join me on this journey to learn Angular with the Angular: The Big Picture course, at Pluralsight. Introduction Introduction Welcome to Pluralsight's course, Angular: The Big Picture. I'm excited to present this course to you. I have used Angular for over 5 years now and have built some amazing things with it and always found it to be a great solution for whatever application I needed to build. Let's talk for a minute about the purpose and goals of this course. The primary goal of this course is for you to understand Angular, what it is, what are its strengths, and what are its weaknesses? By the end of this course, you should have a good concept about Angular as a whole from a high level and understand a fair amount about the various part that make up Angular, its features and benefits, and also some of the things that can lead you astray if you don't know what you're doing. Now let's look at what this course is not. This course is not a guide on choosing a framework. If you're trying to choose between a set of different frameworks, the purpose of this course is not to compare and contrast existing frameworks and help you pick the right one for your project. But this course can go a long way to helping you do that by understanding Angular itself and some of its strengths. There are so many nuances to choosing a framework that understanding each framework is only one part of that decision. Understanding yourself, your application, your team, and your political environment can be just as, if not more, important when determining what's framework to choose. So this guide is not about choosing a framework, and as I stated, it's not about comparing frameworks. Although we will talk a little bit about some other current frameworks, we are not going to spend a lot of time comparing how Angular stacks up against other current modern frameworks. Finally, this guide is not an introduction to coding with Angular. If you're looking to learn to code to Angular, this course is a great place to start because it will give you a high-level view, but by the time we're done, you'll know very little about coding in Angular application. Now let's take a quick look at the course agenda. We'll start off this this introduction. Then we're going to look at the benefits and features of Angular. After that, we'll talk a little bit about Angular's architecture. Then we'll look at some of the tooling that is available to use with Angular. After that, we're going to look at tips, tricks, and gotchas. These are hard-won lessons learned by myself and others through coding a lot of applications during Angular's alpha, beta, and release phases. And then finally, we'll look at Angular, its present and its future. Now let's look at just the agenda for this part of the course. We're going to start off with a little section about what is Angular itself, then we'll look at a basic Angular application and build sort of a Hello World application in Angular, and finally, we'll look at the various versions of Angular and how they relate to each other. In order to keep users informed and up to date, I've created a GitHub repo for this course. The web moves fast, and things change all the time, so even though today a course might be up to date, tomorrow it could be a different story. Publishing updates to Pluralsight videos could take a long time, so I will use this repo to let you know if anything gets out of date with the course and how to work around it until I can get the course updated. It's a good idea to go and check this now. Angular, What, and Why In this section we're going to be focusing on two questions, what is Angular, and why does it exist? First, let's about what is Angular? The most straightforward and simple definition would be a tool to help you build interactive websites. Now most people would call it a framework, and that's true; it is a framework, but that gets a bit into semantics as to what is or is not a framework, which can also be fairly subjective. Understanding simply that it's a tool to help you build websites gets down to the actual core of what it is without being ambiguous. Angular is one of many alternatives. There are quite a few other tools or frameworks that can help you solve the same problem you would solve with Angular, and it's just one of the ways to solve that problem. Right now and probably for a long time to come, Angular's most popular competition is jQuery. Far more websites use primarily jQuery to solve their problems than any other tool currently. So for another viewpoint, you could also look at Angular as a better jQuery. Now Angular itself is actually two separate and distinct frameworks, an older framework and new framework. Both frameworks carry the moniker Angular, and because if this, it's useful to discuss vocabulary a little bit. The original version of Angular is now officially called AngularJS. This includes all versions of Angular that start with 1, whether that's 1.0 or 1.7. All versions of Angular 1 are the older framework, which is officially titled AngularJS. The current version of Angular and the one that this course is about is simply called Angular. This includes versions 2 and beyond, so any discussion about version 2 or version 5 or even version 8 really belongs under the moniker of just Angular. Unfortunately, this can cause some confusion when discussing the two frameworks side by side, but for this course, we will only be referring to the current framework, which we will call Angular. This also means, as you have discussions about Angular 2 or Angular 5, we're really referring to the same framework; it's just subsequent releases of that framework, and that is an important point to understand. Let's look a little bit at the history of Angular. Angular was invented by a guy named Misko Hevery. At the time, Misko worked for Google, and he thought he could come up with a really good way to help designers prototype faster using HTML. He embarked upon a project for a few weeks and eventually came up with what is now referred to as the first version of Angular, or AngularJS. This quickly became an official project at Google and is now supported there by a fairly large team of engineers. The original version of Angular, which we now call AngularJS, quickly became very popular. By the year 2015, it was probably the most popular framework for building websites, but even before that, the Angular team realized that they needed to replace it with a more modern framework. Therefore, they decided to publish at the time what was going to be called Angular 2. Eventually, the 2 moniker got dropped, and we now just call it Angular, but at this point, it was called Angular 2. The team at that point announced the death of Angular 1 and began talking about Angular 2, which would be called Angular 2 and solves a few problems Angular 2 doesn't solve. First off, it would be very standards based. Although Angular 1 is fairly standards based, it was also built against standards that were quite a few years old at this time. Angular 2 is far more standards based than Angular 1 is, especially considering current standards. Angular 2 is also more modern, using more modern paradigms, state management, change detection, and similar features. And finally, Angular 2 is significantly more performant than Angular 1 was. In general, Angular 1 was fine, but it wasn't uncommon at all to run into performance problems with Angular 1. So therefore, Angular is built to address all of these issues. Hello Angular In this section, I'm going to build a Hello World app in Angular. Now if you've done any Angular development or played with its CLI before, you can safely skip this section, since it's just a basic, high-level overview of an Angular app built with its command line interface. Don't worry about following along; just watch what I'm doing. If you want to learn more, John Papa has a great course entirely about the Angular CLI. I'll flip over to a terminal, and we're going to start by using the CLI to create a whole application for us. We do this with the ng new command using the Angular CLI, which I've already installed. Again, if you want to know more about it, check out John Papa's course. And now I'll give this application a name. I'm going to call this application BigPic. Once that command is finished, the Angular CLI has created for me not only a basic application scaffolding, but also installed all of the npm packages that I need in order to run this application. Now I want to open up this code in an editor, so we'll go into that BigPic directory, and I'll open up the code in the Visual Studio code editor. Of course, Angular works with any editor that you care to use. So here's our application opened up in an editor. The CLI does a ton of stuff when it creates an application. It creates tests, not only regular unit tests, but also end-to-end tests. Those exist here in the e2e directory. It's installed all of the node packages into the node_modules directory, it's created all my basic configuration files for me, and it's created a source directory, inside of which it has all of the basic code that I need for a starter Angular application. The core of that is going to be inside of this app directory, and that has the basic pieces of an application, including a single app component. With the CLI, I can also add additional pieces to my application. Let's say, for example, I also wanted an about page. I can use the Angular CLI to generate, using the g flag, a component using the c flag, and I can name it About. The CLI's created that component for me, and if I go over to the code, I can see I have a new about directory. And inside of here, I've not only got my component, but I've also got a template and css files for it. And finally, I've also got a place to put unit tests for that component. And one more important thing I can do is I can run the application using this CLI. I could do that with ng serve which will build the application and launch a web server that will also serve up the application. We can see that here on web browser, here's the basic app that this CLI has created for me. And that's all there is to creating a starter application with Angular. Versions of Angular In this section of the course, we're going to talk a little bit about the versions of Angular. Now when I say versions of Angular, I don't mean Angular 1 versus Angular 2 and beyond. I'm speaking just about the current Angular framework, which, version-wise, is going to be 2 and later. When Angular was first built, it started off as being Angular 2.0. The Angular team had decided to use semantic versioning, or SemVer. If you're not familiar with this, it's a good idea to check it out. independently working on a new router. This was initially set at version 2.0 as well, but then the Angular team made some breaking changes and revised the router to 3.0. At that point, they were now ready to create another version of Angular, which would be Angular 3.0. This new version of Angular would also include changes to the router as well, so it needed a new version as well. That would've put the router at 4.0 and Angular itself at 3.0. So instead of having the router always be one number ahead in its version number, the Angular team instead decided to make the next version of Angular 4.0, and they skipped 3. Of course, the router, as well, was incremented to 4.0 at this time. It's a weird thing, especially after the other naming issues that surround the framework, but this is what happened. So if you hear discussion about Angular 2 and 4 but not about 3, you'll know why. The Angular team has announced that they will have a release cadence. Their planned cadence is to release a new major version every 6 months. So if version 6 is to be released in March, for example, then 7 would be released in the fall. They have also announced plans for long-term support. Under this plan, certain versions of Angular will be marked as long-term support. Those versions will be supported through the next major version, so about one year of support. The team has yet to be extremely clear about which versions will be marked as long-term support, but the assumption is that every other version will be under the LTS plan, and probably that means every even version such as 2, 4, 6, etc. The goal with this plan is for the Angular team to provide enterprise- level stability of the Angular product. Summary In this section of the course, we learned a bit about how this course will go and some high-level things about Angular. A couple of the key takeaways are the original Angular framework is now officially called AngularJS. The new framework that this course is about is just called Angular. Angular was built to be more modern and faster than AngularJS. Angular's versioning history starts with 2, it skips 3, and then continues on from there, 6, 7, even 10. These are all versions of Angular. Finally, we learned that the CLI is very powerful and hides a lot of complexity to make developing applications in Angular much easier than it would be otherwise. Benefits & Features of Angular Introduction Angular is a great framework for building web applications. So in this section of the course, we're going to look at some the benefits and features of Angular. We'll start by looking at the agenda of what we're going to look at in this section of the course. First, we'll look at the universal benefits of Angular. These are benefits that are for the most part completely objective. These are benefits regardless of what kind of application you're building, what kind of company you work at, and your personal beliefs about development. After that, we'll look at some of the subjective and situational benefits. These are things that some people might consider to be benefits, others might not, or things that are beneficial in certain situations. And finally, we'll look at some of the features of Angular. In that section of the course, we'll look at some of the various things that you can do with Angular and its capabilities. Universal Benefits In this section, we'll be looking at the universal benefits of Angular. These are benefits that apply no matter what kind of application you're building and no matter what kind of development team or company that you work at. The first, biggest, and most obvious benefit of using Angular is going to be a reduction of cost. Using a framework to build a web application over building everything yourself is simply going to reduce the amount of cost that it takes to build the application. That's going to be realized in developer time, and bug fixing, instability, all those items and more. Compared to some other methods of building websites versus writing all the code by hand or using older frameworks, you could see as much as a 10-times reduction in the cost of building an application. Angular is also very standards compliant, especially compared to doing something yourself or some of the older frameworks that we used to use. Standards compliance will mean that your website's going to run in more browsers and be able to reach more users. This includes things like using ES6 or better. ES6 is one of the more recent versions of JavaScript, which means that you're going to be using features that will make your developers more productive, and therefore, reduce the amount of time that it takes to build your application. Angular uses modules. Modules are, again, another modern feature of JavaScript and make code easier to support. Both of these are recent standards that are becoming more and more popular. Angular also makes use of modern standards for internationalization and accessibility. This will make your applications easier to nationalize for multiple languages and also make it available to those with disabilities. Angular is extremely performant. Against current generation of frameworks, it's as fast or faster than any of them. Against previous generation of frameworks, it's significantly faster, including writing all the code yourself. Performance is one of the areas where Angular shines. Angular's also open source, which means that you don't have to pay for a license, and you'll have a perpetual license to use it that can never be revoked. And Angular's one of the more popular frameworks that is available today. This means it'll be easier to find developers who know how to work with Angular and are able to work on your project. It also means it'll be easier to find developers who want to work on your project. And finally, documentation. Angular's documentation is extremely good. It is definitely going to be one of, if not the best documented frameworks that's out there. Their official documentation has seen a significant amount of work, and so it's really good, and it's very easy to navigate. It has a ton of excellent tutorials that'll teach you a lot of different things about Angular. So for documentation, Angular just can't be beat. Subjective & Situational Benefits Now let's look at some of the more subjective or situational benefits that Angular has. The first of these is that Angular is a framework. This means that it comes with most of the pieces that you will need to build a website built right into it. You don't have to look around and find various pieces to do core work that just about every web application will need. For example, Angular comes with a router; an HTTP library; a forms-handling library; RxJS, which is a way to handle asynchronous data; and other features like this. This is a benefit because you have to make less decisions. Angular already comes with these things built in. You won't have to go around and find those pieces, find the ones that work for you, worry about whether they're well supported, and then make them work in your application. In some cases, though, this is not a benefit. For example, if you or your developers are the kind of people who really want to choose each piece specifically and take advantage of some of the differences and the options that are out there, then you don't want framework. You want to put together your own framework, utilizing a various selection of libraries. And additionally, a framework has opinions. If those opinions disagree with your own opinions, then you might find it difficult to work with something like Angular. One place where Angular is not opinionated is in its state management. You are free to use something like Redux in your state management or to write your own state management or simply to use no specific state management methodology. The next subjective benefit is uniformity. A typical Angular application was going to look a lot more like another Angular application than with some other frameworks or writing your own code. Even against AngularJS, Angular applications will look more similar to each other than various AngularJS applications would look compared to each other. This means it could be easier to get developers up and running quickly on your application. This is a situational benefit in that some applications can still vary quite enough from the norm that you may not benefit from that or some developers may have only worked on Angular applications that are quite a bit different from the norm so that when they come to work on your application, it's not nearly as familiar. Angular is backed by Google. Most people would consider this to be a benefit, but certainly not all. Some people prefer frameworks that are supported by small teams that have no corporate sponsorship. They worry about corporations having agendas or simply not being as agile and able to make changes as quickly. Again, this depends on your own opinion, but this is something that you may or may not consider to be a benefit. Finally, Angular is written using TypeScript. TypeScript is a superset of JavaScript that also adds types to it. These are optional, and you don't have to use types with TypeScript, but you really do need to use TypeScript in order to use Angular. Although it's not technically required, it would be extremely difficult to use Angular without TypeScript. Some people will consider TypeScript to be a benefit. It'll seem a lot more similar to server-side languages so it can be easier for server-side developers to begin using Angular. And also, there's a general consensus that types reduce bugs, although this is certainly not a universal consensus. So again, this is an attribute that you may or not consider to be a benefit. Basic Features Now let's take a look at some of the basic features of Angular. First, with Angular, you could fairly easily build progressive web apps. Progressive web apps are an emerging standard which allows a web application to be installed like a mobile application, to have an icon on a phone and to open up on a phone, even to be available offline. Angular provides significant support for progressive web applications. If you're not familiar with progressive web apps, you should definitely check them out. Angular supports lazy loading. This allows you to reduce the size of the data that initially needs to be downloaded to the browser in order for the application to begin working. This can improve the perceived performance of your application. As discussed before, Angular has a fully featured forms library. It's very easy with Angular to write complex data input forms and to handle complex validation and other aspects of forms. Angular is built on top of the RxJS library. The RxJS library is a very modern library used to handle asynchronous data. From a development standpoint, this can ease the amount of work it takes to make asynchronous features work in an application. Angular has a fully featured router. The previous version of Angular, AngularJS, had a very basic router, and therefore, alternative routers were very popular. It has feature parity with the routers for pretty much all modern frameworks. Finally, Angular has a very robust, fully featured animation library. This allows you to use animations when you transition from one page to another, when you sort lists of data, when you add items to a list of data, or remove items from a list of data, and similar functions. This is by no means a comprehensive list of the features of Angular, but it is a list of some of the more important features that you will commonly need in a lot of applications. Advanced Features In this section, we're going to look at some of the more advanced features of Angular. Again, this is by no means a complete list. Angular supports server-side rendering. The Angular team took a community-created project and brought it onboard for official support for doing server-side rendering. Server-side rendering can be very important for SEO and also for improving perceived performance of your application. Server-side rendering is the process of rendering your first page view on the server so the server creates the HTML and CSS and sends it down to the browser instead of asking your friend framework to do that. This makes the initial page view much faster and more parsable by search engines. Angular is very mobile friendly. There are several different frameworks that you can use Angular to build mobile applications, which is very important in this day and age. The Angular team has built an Angular language service. This is a service that you can use in order to get better IntelliSense and debugging in templates. This is not common for most modern frameworks, and by utilizing a supported editor, you can actually get intelligent information about the templates that you write, therefore avoiding simple things like typos. Finally, Angular has a library called the ngUpgrade library. This library allows you to take an existing AngularJS application and slowly migrate it to Angular, running both frameworks side by side in the same web application, and as you have available resources, you can rewrite pieces of your AngularJS application into Angular, practically a file at a time, while never interrupting the service of your application and almost never having to support two copies of the same code. This is a very great feature, and for information, you can check out my course on Migrating Applications from AngularJS to Angular. Summary In this section of the course, we talked about the features and benefits of Angular. A few highlights of this section you should keep in mind are with Angular, your front-end development will be cheaper than without a framework. Angular is extremely performant. By this, I mean that it's blazing fast. Angular is a full framework. Some people will like that; some won't. Angular uses TypeScript. This again is something that some people will like and some won't. Angular has all the basic bells and whistles you would expect from a modern framework. It has great support for server-side rendering and mobile applications, and there is a well-established upgrade tool for migrating from AngularJS to Angular. So if you have an application written in AngularJS that you need to migrate to a more modern framework, Angular is almost for sure the right choice. Angular Architecture Introduction In this section we'll be looking at various architectural features of Angular. This will range from some of the deeper items like Zone.js to some of the more common development items like components and directives. Let's take a brief look at our agenda. We'll start by looking at one-way dataflow, which is one of the key performance improvements in Angular over AngularJS. After that, we'll look at dependency injection, which existed in both AngularJS and now in Angular. After that, we'll take a look at components, then directives, and them templates, and then we'll be taking a look at Zone.js and change detection, and finally, we'll finish up with a look at how Angular supports multiple rendering targets. One Way Data Flow In this section, we're going to take a look at one-way dataflow, which is one of the key improvements in modern JavaScript frameworks. One-way dataflow is an architectural construct that has come to the JavaScript work in force recently. All modern frameworks use this sort of dataflow. Although we call it a dataflow, it's really about change detection. With this system, some kind of change happens to the state of a component, for example, the parent component, shown here. This causes all child components to also execute a change detection cycle. Each one checks its state. The components are then rerendered with the new state. Notice that this flow always goes down, never up. Also, once the change detection cycle begins, state is not allowed to change any further until the change detection cycle is finished. Angular actually has checks to make sure that this is true in your code. This was one of the big performance problems with the previous version of Angular. Advances like this have made Angular much more stable and performant than older frameworks. Dependency Injection In this section, we'll take a look at one of Angular's foundational architectural constructs, dependency injection. Dependency injection is one of the cornerstones of both AngularJS and Angular. It will be familiar to server-side developers who use strongly-typed languages such as C# or Java. These languages have long utilized dependency injection and Angular uses a similar architecture. In this code example, we have a component named AddNewTag. This component needs an article service to do its job, so in Angular, we inject the article service simply by adding a parameter to the constructor and then marking it with the correct type. The type is shown here after the colon. This is actually TypeScript, but it's doing two things. It's indicating the type of this variable for type checking and IntelliSense, and it's also indicating what dependency to inject. This is the basics of dependency injection in Angular. For more information, check out Pluralsight's Angular Fundamentals course. Components Now let's take a brief look at how components work in Angular. Custom components are another staple of modern JavaScript frameworks. AngularJS had them, and Angular is the same. Here we have again our AddNewTagComponent. Before this component is some metadata about the component. There are several pieces of data that can appear here, but one of the important ones is the selector. Our selector is set to add-new-tag. When we want to have an occurrence of this AddNewTagComponent, then we create an HTML element that matches the selector like this element here. Angular parses our HTML, finds this tag, and ultimately creates an AddNewTagComponent that will render its display here in the page, inside this div after the h1 tag. Notice how the name of the component lets you read the HTML like a document about how the application works. By looking at this fragment, you know that there will an AddNewTagComponent rendered right here, and you know what this page does. It's simple, clear, and easy. This is the power of custom components. Directives Now let's take a look at one of the other core pieces of Angular, directives. Directives are a way to add new capabilities to an element of your display. For example, we may want to make an element draggable or make it appear on hover or give it some other new functionality that isn't built into that element already. Directives are how this happens. Directives, with very few exceptions, are implemented as HTML attributes. Here we have two divs. The first one has an attribute named hover-trigger. The second one has an attribute named appear-on-hover. These are examples of directives. The first one is a trigger that shows the second div. The appear-on-hover directive controls the visibility of the div that it's attached to. These directives give these divs new functionality that they didn't have beforehand. Of course, this is a very simple example, and much more complex behavior is possible. Directives like this are a core feature of Angular. Templates Templates in Angular specify how components display. We'll take a quick look at the architectural implications of using templates, focusing on one specific attribute of them, which is their placement in relation to components. In Angular, the template for a component is always separate from the component itself. In this sample component, the templateUrl specifies the path to a separate file, which is the template. The code for the component and its metadata is in here, but the template is in a separate place. This is a deliberate choice by the Angular team. You can also use what's called an in-line template. In this example here, we can see that the templateUrl property is gone, replaced by a template property. This property contains the string, which is the template for the component. In this case, the template is adjacent to the component and not in a separate file, but it's not inside or within the component. This is different from frameworks like React, which mix the template right inside the component. Some people consider this to be better, some worse. There is hardly a consensus on this point, but it is important to note that with Angular, the templates are separate from the components. Zone.js & Change Detection Change detection is an important topic. One thing you want from any good framework is for it to rerender the display when its state changes. State change doesn't just happen spontaneously. State changes when something happens in an application. This will always be the result of some kind of an event, such as a user interaction like entering data in a textbox, or clicking a button, or an HTTP request returns its result, or a timer fires, or another similar event. When your state changes, you want your framework's change detection to kick in and rerender anything that has changed. Let's look at an example of how change detection works. Let's say you have a state change. Again, this may be because the user changes the value or because some data comes from the server or any of a various number of reasons. So perhaps the first name of a displayed user gets changed. With the state change, we may have a cascading change. For example, the user's full name might have changed because their first name changed. We want that state to update as well, before we rerender the display. Once all initial state changes and cascading changes have happened, then we want to rerender. In our case, that might just be the display of the user's full name. This is an example of a typical change detection scenario. Let's see what happens when our change detection isn't as efficient. First, we have the same triggering event, the user's first name changes, but then our system simply detects that there's been a change, and instead of waiting for any cascading changes, it rerenders the display. Then a pending cascading change happens, and the UI must be rerendered. If our system isn't smart enough to know about the cascading change and rerender the UI, then we really have a problem. But even if it does, then the system is much less efficient than it could be. This type of change detection inefficiency in frameworks that either relied on manual change detection such as Backbone or frameworks like AngularJS, which didn't utilize one-way change detection. Zone.js is the key to Angular's change detection. Zone creates a wrapper around all asynchronous operations in the browser such as user interactions, HTTP, timers, and any other events that can cause changes in state. Zone knows when any of these operations completes. Angular, in turn, subscribes to notifications from Zone for whenever one of these operations completes. This lets Angular know that it can run its change detection algorithms and rerender anything that has changed. Because Zone doesn't notify Angular until all code that deals with the state change has completed, this assures that Angular minimizes any rendering churn and makes it efficient. Of course, Angular implements many other modern methods to minimize rerendering time and makes other optimizations to keep your application performant, but change detection is a big piece of this. Rendering Targets In this section, we will discuss one the great advances of Angular, and that is rendering targets. With web frameworks, we always assume that all we will use them for is to create a typical website and, as usual, we will be rendering on the browser. We send code, templates, and data to the browser, then the framework takes all that, puts it together, and renders it. But with the rise of mobile and other needs, it quickly became advantageous to create the same experience on a phone. We also could take advantage of rendering on the server for both speed and SEO, and there's even reasons to create things such as native desktop application and other rendering targets. Most modern frameworks today allow you to not only use your code in a browser, but in other places as well. Angular is no different. Angular's built to allow itself to be rendered to any number of devices by changing the rendering engine. Angular comes with two packages that are used by default to enable rendering to the browser and the DOM. These are the browser-platform and browser-platform-dynamic libraries. They allow both just-in-time compilation and precompilation for browsers. But Angular supports many different rendering targets currently and may support even more in the future. The most popular rendering targets currently are of course the browser, server-side rendering with Angular Universal, mobile devices, desktop apps, and there will undoubtedly be other rendering targets created as well. If your application needs to run on more devices than just a browser, then you are well covered. Summary In this section, we discussed various aspects of Angular's internal architecture. Some things you should remember are due to one-way data binding, Angular is much faster than AngularJS was, Angular still uses dependency injection, just like AngularJS did, Angular uses Zone.js to manage its change detection, and finally, Angular supports multiple rendering targets so it's usable for more than just building websites. Tooling Introduction One of the great benefits of Angular is the number of tools that are available to add even more features to your applications and ease your development. In this part of the course, we will look at the following topics: The Angular CLI, which we saw a little bit of earlier on, server-side rendering with Angular Universal, frameworks for making mobile and native applications with Angular code, testing tools, the ahead-of-time compiler, and finally, we'll look at how Angular works with editors. The Angular CLI Current frameworks like Angular came about in an era when more and more complex apps are being built in JavaScript. This brought with it a necessary explosion in tools and libraries and even build processes. One of the more unfortunate side effects of this was something referred to as JavaScript fatigue. This is a big term that means a lot of things to a lot of people, but the main gist of it is the increase in the amount of time it takes just to get a modern JavaScript framework put together so that you can start writing actual code. The Angular CLI is Angular's answer to this issue. There is a literal plethora of moving pieces when it comes to building and running a modern JavaScript application. As an example, here's a basic yet incomplete list of the things you'll need to consider for an application built in JavaScript. You may have to handle JavaScript modules, the browser does not do this for you, you may want to bundle or minify your code, you may need to transpile from TypeScript or ES6 down to ES5 so that your code runs in most browsers, you may need to shim your browser for various reasons, and finally, you might use a wrapper like Zone.js for change detection. Of course, there are easily many more items you would need to worry about, not just the ones shown here, in a production application. Trying to put all of these pieces together by hand can involve dealing with five or more different libraries or tools such as webpack, Grunt, gulp, the TypeScript compiler, Babel, Node, etc. It's certainly possible, and doing any one of these items on a simple project is very easy, but take a production-grade application and do all of these items at the same time, and all of a sudden, they can start interfering with each other. Take it from me, JavaScript fatigue is real. Taking a week to just set up a basic project is not out of the question. That's where the CLI comes in. It handles all of this for you and more. Where it used to take hours or days to get an Angular project up and running while Angular was in beta, now it takes about one minute. We saw an example of that early on in this course. We looked at a few of the CLI's capabilities, but it can handle a lot more things. It can create new Angular applications and set them up correctly; it can make new components, services, pipes, and other pieces of your application, it can act as the web server in development; it can lint your code; test your code, both unit and end-to-end tests; and it can build your code for production. As you can see, the CLI has quite a few features, and they each have many options. For a much deeper look, check out John Papa's course on the CLI. Server-side Rendering Server-side rendering with Angular happens through a tool called Angular Universal. The concept is simple, but the implementation is quite complex. We'll take a quick look at the benefits and overall flow of server-side rendering with Angular. Server-side rendering has a couple of key benefits. First is performance. This happens for two reasons. Server-side rendering reduces the initial download size. A server-side rendered page isn't necessarily smaller than a client-side rendered one, but since you just need the HTML, CSS, and basic JavaScript for the one page's functionality that your user's going to see, you can actually save a lot of download space by avoiding downloading all of the code for your framework and all of the code and templates for further views in your application. Even a small savings in time to have an initial page displayed and working can mean a big difference in user satisfaction. Server-side rendering also reduces the render time. Instead of having a client-side framework parse templates, build DOM nodes, and then letting the browser render them, the browser just parses the HTML you give it and displays it. Again, this reduces the delay until your user sees your site working. The second main benefit of server-side rendering is search engine optimization. Since Google now parses JavaScript in websites, this can be of limited benefit, but it can still make a big difference, especially if you are relying on other search engines or on tools like Facebook or Twitter to correctly show thumbnails of your home page. Angular Universal has a couple options for its mode of operation. First is full pre-rendering, which involves running a development time process that will take your site and create HTML for each of the views. Then you take that HTML, load it onto a CDN, and when people hit your site, they get fast, quick initial responses. Then afterwards, Universal will make the switch on the client side to a regular Angular app. The other option is dynamic pre-render. In this case, whenever a request is received by your web server, the requested page is built by Angular Universal, and the rendered HTML and CSS is sent down to the browser, and then the switch happens. Currently, only Node and ASP.NET Core are supported in this mode. With either method, once the browser has the pre-rendered HTML, Universal kicks in, downloads your full Angular app including the Angular framework. Then in a hidden div, it boots the app, renders the current page, replays any events that the user has done so far to the page to maintain the current state, and then swaps the display inside of this hidden div to the main page whereupon the browser is now just executing a regular old Angular application. In either mode, you can get a working website up and running for your user without first having to download not only your Angular code, but the Angular framework itself. Now again, this may seem simple, but it's really quite complex, and setting it up does require a bit of work, but it can really pay off in the right situations. Mobile & Native Frameworks In today's day and age, most websites receive more views on a phone than on a desktop, but being able to step it up and offer a mobile application can really set you apart from your competition. But mobile apps are expensive, especially since you may need to build them two or three times for each of the different phone OSs. Or you may want to build a desktop application. We're not really going to talk much about the pros and cons of each of these tools, just more about their existence. For mobile applications, although there are really quite a few options, some of them are more low level than others, there are basically two tools commonly used with Angular to build native mobile apps. Those are Ionic and NativeScript. Ionic has been around for much longer and has a lot more popularity, but NativeScript, built by Telerik, has been gaining popularity fast, and may become the more popular option over time. For native desktop applications, recently Electron has taken the scene by storm. It allows you to create cross-platform desktop applications in Angular or any other JavaScript framework. It's a great tool and is even used to build Visual Studio Code, one of the more popular coding editors around and a great tool, if you've never used it. With these and other tools, you can create native mobile and desktop applications with Angular and save yourself months and even years of development time. Testing Tools Testing is an important topic for any framework. The benefits of testing are well supported by both consensus and study, so any framework you use should readily support testing. Angular definitely falls in this category. AngularJS was built with testing in mind, and Angular is no different. There are several testing tools that are either available separately or provided with Angular. Back when AngularJS was first on the scene, the Angular team built two testing tools, Karma and Protractor. Both became very popular, not just for Angular but for JavaScript in general. Karma is a unit testing tool. It is installed locally and will run your unit tests against multiple browsers, depending on how you configure it. It's very fast and very convenient and is quite popular. Protractor is a web automation testing tool used for running end-to-end tests. This is beneficial because rather than just testing a single piece of your code, you can test that the entire application is working. Now Karma and Protractor have been around for a while, but they do have some competitors. The Intern and Cypress.io are very good alternatives, and there are other tools as well. Each of them has their own advantages and disadvantages over each other. In addition to these external tools, Angular itself comes with some utilities that really help out when testing. First, there's the TestBed. This is helpful for when you want to test components with their templates. In old AngularJS you had to manually compile a component with its template. With Angular, the TestBed helps you construct components in a live environment and gives you handles to wrappers around the component and the document object model of its template. Next is the async and fakeAsync utilities. These utilities take advantage of Zone.js to allow you to run async code as if it were synchronous. For testing asynchronous code, this is incredibly helpful. And finally is the MockBackend, which can help you when testing components or services which make HTTP calls. The MockBackend utility allows you to mock out an HTTP server to respond to HTTP calls during a test and test that they happen the way you want it. And just as a note, since everything in Angular is just an ES6 class, you can always just test the code using plain old JavaScript testing techniques with no need for additional help or utilities. With all of these testing tools, Angular's testing story is straightforward and fully featured. AOT Compiler Angular's ahead-of-time compiler is one of the key innovations in the Angular framework. It radically improves the performance of Angular applications. In AngularJS and in some early versions of Angular, they used a just-in-time process for turning your templates into the JavaScript functions which actually manipulate the DOM in your application. So when the browser requests the application, the server would send down the code that you've written, your templates, and the framework itself including the piece of the framework shown here called the compiler that compiles those templates into DOM manipulation functions. This process of turning your code and templates into DOM functions takes time plus sending down the part of the framework that does this takes time as well. But Angular now uses an ahead-of-time compiler, which compiles the templates on the server so when the browser requests the application, we don't need to send down the compiler part of the framework, and no time is lost on the client compiling those templates into DOM functions. This is a huge savings of both time and download size. Editors Editors are the most commonly used tool when developing an Angular application. Giving the editor more power to help you create your websites faster and easier is one of the benefits of using Angular. There are two main ways that editors can give you additional features using Angular. The first is TypeScript. Now again, you can use TypeScript with basically any front-end framework, so this is by no means unique to Angular. But since TypeScript is basically required for Angular, it's worth listing here because with Angular, you will definitely receive these benefits, where with other frameworks, it's up to you whether or not you use TypeScript or not. TypeScript gives two main benefits. First, since you can get the type of an object, you can know its interface. This gives you better IntelliSense. For classes and objects, the editor can prompt you with the correct properties and methods, and for primitive types, it can prompt you with all the usual properties and methods of those as well. The other main benefit of TypeScript is catching typing-related bugs. Although not in complete consensus, studies have shown that this can prevent a meaningful number of bugs. Then there's the Angular Language Service. This is an additional tool built by the Angular team that provides similar functionality to that of a typing tool like TypeScript, but it does it in your templates, where there isn't a language per se, just your bindings. This way, you can get autocomplete and IntelliSense in your templates as well as in your code. The Angular Language Service has been adapted to be used in Visual Studio Code, WebStorm, and Sublime Text. Expect other popular editors to receive adaptors as well. Summary In this section, we learned a lot about some of the tooling available to Angular and how it enables better tooling. Mainly, we learned that the CLI is awesome, that the ahead-of-time compiler really lets you tune your code to its minimum size, and that with TypeScript and other tools, Angular enables editors to really reach their maximum potential. Tips, Tricks, & Gotchas Introduction In this section, we'll be looking at various tips, tricks, and gotchas in Angular. These are items that are not obvious, either from typical tutorials or from your usual documentation reading. Therefore, these are bits of knowledge that come from having used Angular for a while. We'll start by first looking at the gotchas. These are things that can more easily mess you up in Angular. Afterwards, we will look at tips and tricks, things that will either help you get around those gotchas that we mention, or things that will just make your life way easier. Gotchas In this section, we will look at some of the gotchas of Angular. Gotchas are concepts that are either overly confusing, more difficult to learn than other concepts, or are extremely complex yet can be easily used by developers who don't fully understand the consequences of them. The first gotchas that we will look at are TypeScript and decorators. The reason that decorators are listed as a gotcha is because they are a very different type of syntax from just about anything else in JavaScript, and each decorator has its own different list of parameters. The basic syntax looks like this. You have the at sign and then the name of a decorator. Then inside parentheses you have parameters. They look a bit like a function, but decorators are quite different from functions so they're easy to get confused by if you are either not familiar with them at all or if you think about them too much. The other part of this gotcha is TypeScript overall. TypeScript has its own learning curve, but you really can't do Angular without it. Well, technically, you can, but you really wouldn't want to. So to do Angular, you have to learn TypeScript. And while you don't need to learn all of TypeScript or become an expert in it, you do need to learn some of it. The most important thing to learn about TypeScript is how it gives types to identifiers. In this example, we're dealing with a parameter. Here, the parameter articleSvc has been marked with the type of ArticleService, which is a class. This is the basics of TypeScript, but the foreign syntax can easily throw you off it you're not used to seeing it. The next type of gotcha is pipes, specifically, custom pipes that you create yourself. If you're not familiar with pipes, they're the feature in Angular which lets your format data. They can be difficult because on the surface, creating a custom pipe is easy, but if you dig just a little bit, they can be crazy complex, and you can easily do something bad for your performance with them if you don't understand what you're doing. Pipes comes in two flavors, pure and impure. Pure pipes are the default kind and are simple and easy to use. Impure pipes are the more advanced kind and are extremely difficult to use properly. The reason is performance. Pure pipes are evaluated, or run, only when their input changes. This makes them very performant. Impure pipes, on the other hand, are run on every change detection cycle. This makes them very non-performant. No matter what kind of change happens in the system, all impure pipes are reevaluated. This can quickly grind an application to a halt if you don't know what you're doing, and you write your pipe inappropriately. So in summary, pure pipes are simple but impure pipes are very complex. Next on our list, we have the module API. This is listed in the gotcha section because it's kind of a big central piece, but learning the API and syntax can be troublesome. Even after dealing with it a lot, you can easily forget to register a component or service and cause a bug. The module API contains sections for imports, exports, bootstrap, providers, declarations, and several more pieces. Getting each of these right can be troublesome. Here's an example module. This one's very simple, but even just the basics can be difficult. You have to remember things like where do you put guards or custom validators. And if you forget to register something, then everything goes wrong. It's a simple thing and a simple fix, but it can be annoying and cause frequent issues. Of special concern is dealing with multiple modules in your Angular application. There's two reasons you'd create multiple modules. The first is to create a different module for each feature area of your application. This is the recommended pattern. You will also create multiple modules when implementing lazy loading. When using multiple modules, there's a few difficulties than can arise. First, there's dealing with routing and then when importing and exporting items from each of the modules. Generally, this is straightforward in most cases, but if you get something a little bit wrong in your configuration or if your particular case is a little bit out of the ordinary, then it can quickly become confusing as to how to correctly set up these various pieces. Next is a problem which was much worse when Angular first launched, but it's still pretty pervasive, and that is the cryptic error messages. With Angular, just as with all development, it's common and frequent to get an error, and sometimes the error messages just don't point you at all in the right direction. The error messages can be frequent, frustrating, and can really slow down your development as you hunt for a solution to why your code is erroring out. The Angular team is constantly working on this issue and improving it, but it remains a problem. The next gotcha to discuss is the build. Angular is significantly more complex than AngularJS was. Deploying an app involves putting together many moving pieces, and it's more important than ever to tune your Angular build to be optimized. Getting the build wrong can negatively affect the performance of your application. Thankfully, the CLI can handle much of the work for you, but it doesn't take all the complexity out of your build, and it's more important than ever to understand how your code is built and learn how to tune that process. Related to the build is the delivery size of your application. When Angular was first new, even a simple Hello World application could be over 1 MB. The Angular team is constantly working on this aspect of Angular, and nowadays, the CLI has greatly optimized the delivery size of your application. But this is still something that you will need to keep a close eye on. There are several techniques you can employ to mitigate this issue, but it can still be a real gotcha with Angular apps. The final gotcha we will discuss is RxJS. RxJS is a new technology that Angular heavily relies on. It handles asynchronous operations and replaces promises but is much more fully featured. At the same time, it's also much more complex than promises were. This technology is one of those ones that most people feel lost with when they first start working with it, and even after they get to where they can do simple things, they often still feel like they don't really get RxJS. There are several ways that RxJS can cause problems. First is just getting around the paradigm shift of no longer using promises but using observables. They're different, and it takes time to wrap your head around that. Then you can easily deliver a very large amount of code that you don't need when you include RxJS in your project. You can to be careful that you only package up what you need. When you write methods that use RxJS, you will need to worry about whether the method should subscribe to the observable automatically or not. If you haven't yet dealt with RxJS, you may not understand this item or the rest of these, but trust me, these are problems that you will encounter as you deal with RxJS. You can also easily forget to subscribe to an observable and end up wondering why your code isn't doing anything. Conversely, you can accidently subscribe multiple times and, . depending on the observable, you may end up making multiple unnecessary HTTP requests. There are also some deep complexities with RxJS such as hot versus cold observables or shared observables. All of these can make RxJS difficult to comprehend and therefore tough to deal with. Now with all the gotchas that we've mentioned, you might be thinking that maybe Angular isn't so great after all, but don't worry, even though there are a few rough spots, overall Angular is still an amazing framework, and in the next section, we'll look at ways to mitigate most of these gotchas. Tips & Tricks Now that we've seen some of the gotchas from Angular 6, we'll switch tracks and look at ways to overcome many of these problems, plus a lot of either generally good advice or specific tips and strategies to ease your development. Our first tip is to use the CLI. The CLI mitigates many of the issues that we showed in the gotcha section, especially around the build, but it also makes so many tasks just much simpler than they would otherwise be. So learning the CLI avoids many problems, and it's an absolute must-have. Only those very experienced with the CLI should ever consider not using it on a project. The next tip is to follow the style guide that's on the official angular.io site. This will do several things. It will keep your projects consistent across developers, teams, organizations, and it will also make it easier to onboard new developers. Plus it itself is chock-full of lots of great practices that are well thought out. Next, your sorting and filtering should be done in your component. If you're familiar with AngularJS, there was a filter component that handled this, but that practice had many problems centered around performance. Sorting and filtering in your components keeps the UI logic in the right place and keeps your performance up. Next, learn and use TypeScript. It's got a small learning curve, but once you get over it, knowing TypeScript well will pay off many dividends. And never consider doing Angular without TypeScript. That will almost never be a good idea. Next, learn and use NgRx. Having good state management for projects will help with both maintenance and performance. NgRx is quickly becoming the de facto solution for state management with Angular, and most developers are reporting a high amount of satisfaction and reduction in maintenance time. Our next tip is to learn webpack. The CLI uses webpack under the hood, and although you can get a fair ways without knowing anything about webpack, if you know webpack, there are many things you can and will want to do that will help you with your development. Our next tip is to use lazy loading. Lazy loading will drastically increase the perceived performance of your projects by delivering the important first pieces of your application sooner. The next tip is to use VS Code or another modern editor. Having an editor that understands TypeScript and is being actively developed to work with Angular can make a big difference in the efficiency of your development staff. Next, don't touch the DOM directly. There are ways to get at the DOM and manipulate it directly, but with Angular you rarely have to do that. And the more you resist the urge to do it and instead make changes through the provided Angular APIs, the more stable and performant your application will be. Next is to understand what you're sending down to the browser. This tip is very important in that if you understand what you're sending down, you can optimize what you're doing in your build and how you're doing it so that you can maximize the performance by minimizing the download package. So don't just blindly use the CLI and never wonder about what is sent down. You should be looking at your download package, keeping an eye on the size, and most of all, you should know what is in your download package. Our final tip is for performance. Although Angular is already a very performant framework, there are still more gains to be had. Using immutable or observable data with Angular will improve the performance of your application. Because this takes a bit more work to do, this is something that you should do only where warranted. Don't just blindly do this everywhere in your application. Use it where appropriate. And that will wrap up our list of tips and tricks. Summary In this part of the course, we looked over quite a long list of tips, tricks, and gotchas. We took a very honest look at the kind of things that frequently trip up both beginning and more advanced Angular developers. We also saw a set of tips and tricks to overcome many of these gotchas. Some key things to remember is that the build is a key feature, and it's not something you could ignore. You need to know the tools involved and exactly what they're doing to your code. And TypeScript, NgRx, and webpack are technologies you should learn to get the most out of your Angular development. Angular: Present & Future Introduction In this final section of the course, we are going to look at both the current situation with Angular and also what its future looks like. We'll start off by looking at the present of Angular, including a little bit of history. Then if you're in the process of deciding which framework to use for an application, the next section will be very important to you as we look at the conditions upon which you should consider using Angular over other frameworks. And finally, we'll take a speculative look at Angular's future. Present The present picture of Angular is a very positive one, although the history of Angular had a few bumps. It was announced long before it was ever launched, while at the same time announcing the death of AngularJS's various features. This was a huge mind job for most developers and managers. What were they to do? Continue using an obviously soon-to-be obsolete technology? As Angular continued to be promised by not released, people began looking for other solutions, and React gained a lot of popularity. But now that Angular has been released, it has proved to be a strong framework and a good option for most web applications. As mentioned before, Angular has a compelling set of benefits. It's fast, modern, and popular, so it's a great choice for any development team. It's particularly effective when dealing with an existing AngularJS application that you want to rewrite since Angular has an upgrade path that is unparalleled. If you are looking at purely technical considerations, Angular's by far the most natural choice for upgrading an existing AngularJS application to a more modern framework. The team has done tons of work on their upgrade options to make it not only possible, but as smooth and low risk as can be to upgrade an application to Angular from AngularJS. Angular vs. Other Frameworks If you're in the process of considering multiple frameworks for a new web application, then choosing the right framework can be something that keeps you up at night. So in this section, I'd like to give you a foolproof way to measure Angular versus other frameworks and to be able to objectively determine when it's the best choice for your development needs. Unfortunately, that's impossible. Frameworks are far too complex for anyone to have an objective measurement of which framework is best in a given situation, especially when compared to another framework. It's just far too difficult, especially considering that oftentimes your choice of framework might involve the subjective preferences of your current development team. And even if that was possible, then you will have to consider how things will change. You'd need a crystal ball to look into the future to see what the effects of your decisions today will have on future development. So really, trying to determine which framework is truly best for your needs is an exercise in futility, and anyone who tells you different is selling you snake oil. Instead, I'd like to give you a set of conditions, under which you would should consider using Angular. That doesn't mean that you shouldn't consider other frameworks as well for your needs. In fact, I'm not going to do any real comparison of frameworks, except in mentioning a few completely objective observations. But I will do my best to refrain from making any judgments. As you do go to decide, you should use your best judgment, considering all factors that can be important in a decision like this, such as the technical aspects of a framework, your political environment, by which I don't mean your national politics but instead the political factors of your company, your management, etc. Is your company more or less tolerant to certain types of technology or technology with certain licenses or technology produced by certain kinds of companies or open source versus closed source, etc? Personnel considerations. How easy is it find people with the right skill set? Do they want to work in certain technologies? What about your current staff's preference and skill sets or your own? And finally, what is the future likely to be? Even though I'm going to be talking about a certain future for Angular, your perspective may differ, and I certainly don't have a crystal ball. So here are the conditions that you should consider when deciding whether or not to use Angular on a given project. First of all, are you a more enterprise-type company? Angular tends to appeal to more enterprise-type companies because of its use of TypeScript and because it's a more fully featured framework. This is certainly a big reason why AngularJS became so popular, and it will definitely be a reason why Angular continues to be a very popular framework. Do you use a typed backed such as C# or Java? If so, using Angular will make you comfortable because you can use types on the front end since you'll be using TypeScript. Do you currently have applications written in AngularJS? If so, the upgrade path from AngularJS to Angular is a lot simpler than from Angular to any other technology. Do you like keeping your templates separate from your code? Not all frameworks do this, but Angular is one of the ones who does this. Do you prefer having a large, solid company backing the code that you're using? If so, because Angular is built by Google, it certainly fits that bill. Do you prefer a framework versus a set of libraries? It's a fairly subjective thing to say what is or is not a framework versus a library, but for most people, Angular feels far more like a framework than many other front-end options do. Do you need an established track record? AngularJS has been around for a long time, has been very dominant. Angular itself has been released for quite a while now and is doing very well. From this standpoint, choosing Angular would be a fairly low-risk choice. Do you prefer options that have a lot of popularity and momentum? Angular is extremely popular, definitely one of the most popular front-end frameworks today, and it has a lot of momentum behind it and should only continue to get more popular. These are the types of conditions under which you should consider using Angular. Obviously, this is not a complete list, but this is a good starting point. If any of these things apply, then Angular is definitely a framework that you should be looking at. Future If the present of Angular looks good, the future of it looks even better. We'll look at several areas of Angular that are likely to see a lot of focus in the coming months and years. In the short- to medium-term future of Angular, we're probably going to see a lot of very interesting work done, which will make Angular an even better choice for application development. First, it's worth mentioning the Labs project. Angular Labs is the Angular team's formalized umbrella for trying out experiments with Angular. So to see what is possibly coming on the horizon, Labs is the place to look. One of the most exciting projects to come from Labs is Angular Elements. Elements is Angular's delivery on a promise that has long eluded the front-end web development world. When you build a large application, you may end up with a bunch of visual controls written in the current framework. For a new project, you might want to use a different framework, but since the UI controls are written in the old framework, you lose the ability to leverage all the work and effort that you put into those controls on your new project. But Elements changes all that. You can write a UI control in Angular and compile it down to a web component, which will work in any framework so long as it's on the web. So that means that you can write a customized list control, use it in your Angular project, and another team can use it in their React project, and another one can use it in their Ember project. And it works great in all those places. So if you're not familiar with Elements, it's definitely something you'll want to check out. Getting back to the future of Angular, we're likely to see a lot more development going into a feature called Schematics, which is part of the CLI project. Schematics allows you to customize what the CLI produces, and there will likely be a lot more effort put into this. Next is Angular Universal. The future will certainly see more focus put into that project to make server-side rendering even easier than it currently is. We're also likely to see a lot of work on migrations. As more and more companies begin migrating their AngularJS projects to Angular, the team will continue to find ways to help those companies accomplish their goals. Naturally, the future of Angular will certainly see a lot of work done on the build system. We'll see more possible build targets, more options with builds to customize and tune what is delivered. With those options will come further optimizations to continue to improve the performance of Angular in production. And finally, in relation to the build is a project called ABC, which is Angular plus a couple of Google projects named Bazel and Closure. Together, the three of them can do all kinds of optimizations to your code that isn't possible without them. Although this isn't likely to turn into something where everybody is asked to write their Angular code and hook up Bazel and Closure themselves to it, it is likely that we'll see some optimization improvements come out of this project in the future. Finally, Angular is certain to see a continued increase in growth and popularity in the coming years. Front-end development is only getting more and more popular, and more and more apps are being built every day. And as AngularJS applications are rewritten, this number will only increase, so look for a continued growth in Angular overall. And that wraps up our look at the near-term future of Angular. Summary Thank you for watching this course. I hope you got a lot out of it. There are a few key takeaways I want you to remember. Angular is a great framework. It's modern, it's performant, and it's competitive with any other choice that you have. I hope that you enjoy working with it as much as I have. If you enjoyed this course, follow me on Twitter and say hi. I like to connect with the people who watch my courses. But most of all, thanks for spending your time with me. Course author Joe Eames Joe has been a web developer for the last 13 of his 16+ years as a professional developer. He has specialized in front end and middle tier development . Although his greatest love is writing... Course info LevelBeginner Rating (159) My rating Duration1h 7m Released13 Dec 2017 Share course