Angular: A Deeper Dive

This is an extension of my first article on Angular, A High-Level Analysis. In this article, I will dive deeper into Angular — now Angular 4, soon to be Angular 5 — analyze its functioning, explain why it is in a completely different league from Angular 1.x, discuss opportunities for those job hunting, and finally discuss how to best hire for this brave new world of JavaScript frameworks.

Table of Contents

1. Before we begin
2. A1 to A2 to A4?: It’s How Steak is Done
3. In The Zone
4. TypeScript
5. RxJS
6. NgRX
7. Should I Use it?
8. For Your UX Team
9. Getting a job
10. Hiring
11. Final Thoughts

Before We Begin

Here, at the start of all things, an important point needs to be made: Angular does not exist. Truly, Angular isn’t even a thing. It is three things, all of which you are forced to use to truly say you are implementing “Angular.”

The first of these things is, of course, Angular. The only part of Angular that is Angular is, essentially, the plumbing and renderer. It’s the structure of the data flows and how that data is displayed. It’s the thing that all of these frameworks were originally envisioned to do back in the 2000’s.

As I discussed before, there are a great many differences between AngularJS and what is now Angular, but we’ll get to that in a bit. For now, the most important difference is that Angular is less monolithic than AngularJS and leverages technologies from other groups.

Most notably among these technologies, and the second piece of Angular’s corpus, is Microsoft’s TypeScript. TypeScript, or TS, is a superset of JavaScript. It ultimately compiles down to nothing more than JS and the benefits of TS are found almost exclusively at compile time. You can still suffer errors during run time, but hey, you are at least capturing and preventing one type of problem. That’s value, and is especially felt on large projects with multiple teams.

The third part of our Angular triumvirate is RxJS. RxJS stands for Reactive Extensions for JavaScript and is more or less a part of the rising tide of functional programming in JavaScript and the move away from object-oriented architecture style. Reactive programming is the philosophy that change should propagate through an application when something happens. This is a pretty deep rabbit hole, so we we’ll get to this in a bit. For now, just know that RxJS envisions software as a machine that produces a theoretically endless stream of output from a theoretically endless stream of input.

There is a pseudo-fourth technology as well and that is NgRX. This is fundamentally Redux of React fame, but with hooks built in for Angular. If you don’t know Redux, it is the idea that the state of an application should be stored in a single spot, and only in that spot. All parts of an application look to this unified state to determine how they should function.

Redux is important in this article because it represents the greatest conflict inherent to Angular’s architecture, a situation I will elaborate on later. And while NgRX is not necessary to create a completely functional and optimized Angular application, the general disposition of most developers picking up Angular is leaning strongly toward implementing NgRX. Perhaps because of this, Angular’s developers are beginning to implement NgRX in their talks and demos, and references to it are appearing in online documentation. Truly, if the tea leaves are correct, it won’t be long before NgRX becomes just as integrated into Angular as TypeScript and RxJS.

So what are we to make of this hodge-podge? I think that Angular’s manifold nature is both a positive and a negative. It’s great because it shows that the Angular team is humble. They are looking to other teams and other companies for insight about how to best build their product. I believe, or at least want to believe, that this also evinces a sense of humility growing in the broader Google corpus and that. Is. GREAT.

Google has been very arrogant for many years. Chrome, for example, would happily delete features, thus breaking web applications. Contrast this with the philosophy of Internet Explorer’s team, where they actually kept bugs in the browser because web apps had been built around these bugs. Their mandate was first and foremost make a developer’s job easier. Regardless of all of the problems that arose because of this, you can at least appreciate it. With Chrome, Google was dictating how the web would run, and developers simply had to keep up.

Following in Chrome’s footsteps, AngularJS’s original motivation was to dictate the direction of web technology development from the other end: the developer tools. Hell, Google even advocated for Angular by pointing out how hard it was to maintain compatibility with Chrome! That makes it sound like some kinda’ weird protection racket. “Gee. That’s a mighty nice web app you gots’ there. Would be a shame if somethin’... happened… to it.”

Google’s aim with this absurdity was the aim of any tech titan: domination. Don’t be evil, my ass. And at least as far as browser’s are concerned, they’ve come damn close to achieving their goal. Chrome is now the most popular browser in the world, and the vast majority of Android cell phones run the stock, Google-developed browser. The window to the world of the Internet is owned by Google for a majority of the planet. but Google never managed the same success with developers. We were just too cantankerous a lot. Although Angular certainly became the default framework, its monstrous success actually bred ever more frameworks and libraries. One of these frameworks, React, would ultimately surpass Angular in mindshare, thus triggering this uncharacteristic display of humility.

And as I said above, this is wonderful. By accepting outside teams as a primary part of their project, and even playing nice with React at times, Google is better enacting the dream of open-source. Don’t dictate; participate.

All that said, one of the key benefits of AngularJS was its monolithic nature. As someone who has worked on some large, bloated projects, there is nothing I loathe more than bringing yet another package or technology onto the stack. That means overhead. That means bugs. That means code that must be maintained. That means more repositories. That means incompatibilities. That means problems caused by who-the-fuck-knows. And that also means time.

Previously, I said that your developers can get up to speed in Angular in about a month, and that is true. I had a prototype app up and running in less than a week. I was customizing pipes and routers by week two. By week three, I was creating custom services to handle connections. And by week four I felt confident I could create a complete, simple app.

But the manifold nature of Angular makes becoming a ninja very hard. You need to become a ninja not just with one technology, but four! Your team will either want to have specialists in TypeScript, RxJS, and NgRX, or your entire team will need to spend time learning the complexities of all. That will be a tough sell to any stakeholders eager to push out new features. I stress, though, that this is something that you should do.

Angular has the potential to produce a tightly-structured, fast, and easy to extend application, but only if developers are given a great deal of time at the outset to understand the ins and outs of every aspect of its architecture. If you allow decisions to be made during your team’s time of greatest ignorance, your application will have technical debt that is never paid. Exacerbating the issue are preexisting prejudices among developers who are coming from a traditional MVC or MVVM web app world. They need time to perform a mind shift toward a viewless, component-based model.

This problem is especially pertinent as of this writing, May 27th, 2017, since Angular’s documentation is so dirty. There are a huge number of deprecated features in Angular that are, nonetheless, still present in a great many pieces of online writing. You can only be safe in assuming the validity of what you are reading if it was written, at the earliest, in June of 2016. Any earlier and minor changes to syntax, which they were seemingly doing for fun, will cause your applications to fail. For example, a now core part of Angular, @NgModule, wasn’t released until September of last year!

Since I wrote my High Level Analysis of Angular article, I have also learned that even if you are willing to pay, you will have problems being properly educated. I have heard from people close to, or directly representing, major publishing houses like O’Reilly who have said that they will not be producing books on Angular because of the wild state of development. That from the start of writing, to drafts, editing, and finally publication, a book can take over a year to produce. And from March 2017 forward, the Angular team plans on doing a major (read: breaking changes) release every six months. I’m sure they think this is cool, because they’re a bunch of geeks utterly disconnected from the world of actually getting things done, but it is a crippling problem.

From the perspective of the developer, It’s awesome. It is excellent job security since with the constant changes, whatever project is using Angular will need multiple experts on hand at all times. And the project will be forced to use the newest versions of Angular since all writing online, and workshops done by Google, will undoubtedly use the newest version.

Perhaps I shouldn’t be surprised by this. These tools are being developed BY developers, who are themselves backed by companies that are selling development. Obsolescence being baked into the cake is a positive thing.

And to be fair, rapid development isn’t necessarily bad for projects, either. Using the newest tools, with newest capabilities, is an aspect of economic competition. This is especially true if your project is customer-facing. But even if it is internally-facing, better, faster, more capable tools will enable the machine that is your company to better compete against other companies in your market segment.

But when the development is happening, it’s a problem. And much to Angular’s detriment, at least at this moment in time, it’s a true, wide-awake nightmare when trying to get a new project off the ground. Everything written from the early days of Angular (2015 and much of 2016) is null and void. And with every release, new developers looking to pick up the framework will have to filter out the old from the current. Throw constant updates to RxJS and TypeScript into the mix, and you are left with a project management and architecture mess the likes of which are not found in many places in the software world.

Once the project is up and running, these problems are much more manageable. But until that time, using these open source tools feels like you’re using open source tools. That is to say, you are on your own.

So, as I said above, and I will reiterate here, you need to give your team time to wrap their heads around this system. Your Proof of Concept (POC) needs to be nothing more than a POC. That code will not be reused in production! After the POC is complete, start again with a blank slate and all of your newfound knowledge. If you have an existing application that you want to transition to Angular, be prepared for at least three months of learning, ideally six, and then another six-to-eight months for actual development, with the understanding that some sprints may actually be backtracking caused by new knowledge.

This is painful, and if you decide that this pain is not tenable, whether for financial or stakeholder reasons, I recommend plan B, whatever that is. It could be a two-to-three person skunkworks, where existing features are very slowly built up with the new framework. It could be integrating Angular into an existing application in a piecemeal fashion. It could be forgetting Angular entirely and going with React/Vue/Ember.

This bears focusing on because Angular will produce a beautiful application when done in the Angular way. If not done in the Angular way, it will be an even bigger nightmare than your current tangle of code.

Angular to Angular 2 to Angular 4… Angular??

As I’m sure you noticed if you read my first article, I’m no longer referring to Angular as Angular 2. I’m just calling it Angular, and that’s because Angular 2 is no longer Angular 2, it’s now Angular 4, and will, in a very short time, be Angular 5.

Don’t panic! Angular 5, and thus Angular, isn’t that bad. It’s not nearly as big a change as Angular 1/JS to Angular. The reason for the version jump is actually pretty straightforward: the team wanted to start using semantic versioning.

Semantic version numbers are versions that tell you something about the code. So for example, version 2.3.5: the 2 means this is a major, incompatible (aka BREAKING) update over version 1.0.0. The 3 means this has significant features over version 2.2.0. And the 5 means this version has small fixes and changes over version 2.3.4.

This is very helpful, so it’s understandable why Angular wanted to use this. The problem was that the ROUTER component of Angular was already past version 3, so they had to jump straight to 4 for the entire mess to avoid confusion.

So long story short, Angular 4/5 is basically just Angular 2 with some minor breaking changes. From this point forward, we will get a new major version every six months. So Angular 5 will come out in October, Angular 6 in April 2018, and on until the sun dies. That’s why the Angular team would like us all to stop focusing on the number and just call the whole mess ANGULAR. So, I am. Angular!

So now that we’ve got Angular 5 out of the way, what about good, old AngularJS? I discussed the UI philosophy of AngularJS vs. Angular in the previous article, but here I want to go deeper into the way that data is propagated through the application and how changes are detected.

First, what are the motivating factors that caused Angular to split so completely from AngularJS? First and foremost, even though the Angular team will never admit this publicly, Facebook’s React was the primary motivator for the split. React’s philosophy of a UI-as-product rose so rapidly and suddenly that it was obvious, even many years ago, that AngularJS’s philosophy of the framework-as-HTML-extension was dead. It may still be the dominant framework as regards deployments, but it is a zombie.

But envy and fear were certainly not the only driving factors. If the Angular team had truly believed in AngularJS’s philosophy, they would have stuck to their guns, but they didn’t. Let’s analyze why to better understand how Angular is so much better than AngularJS.

An interesting side note: I spent a large portion of my first article and some amount of this article bashing AngularJS’s pattern known as MVVM. Since AngularJS treated the view as a thing, it had to check its model and its view for changes, to wit the digest cycle. This is slow, but it is utterly complete. By the end of the digest cycle, you can rest assured that your view and your data are aligned. This can be important if your view is open to outside manipulation, which is true on the web. If something outside your application changes the view - perhaps the user, a malicious piece of code, or even a library you are using - that change will not be represented in the application state in Angular. As such, that change will not be caught and replaced with correct data. In AngularJS, since the DOM is checked, any outside changes will be detected and corrected.

Most people consider this an edge case, but I don’t. Since the view is what the user is interacting with, a malicious piece of code could replace links and the application is none-the-wiser. Obviously, many layers of your application should be enhanced with security features to prevent situations like this, but ultimately, you do not have control over your client. Indeed, THE CLIENT SHOULD ALWAYS BE SEEN AS COMPROMISED.

This is a valid point in defense of the MVVM model, and why it is not a dead model theoretically. But as many people smarter than myself argued, for most web applications, this process is overkill. Whether that is true or not is up to debate, but the mob has spoken, and this is not seen as important for the majority of web developers. I suspect this is because they always see the client as compromised, so their security considerations remain the same, and they rely on the browser to enable client-side security.

Regardless, React won, MVVM lost. That said, back to covering what makes Angular better.

Simplicity: Angular gets rid of some concepts, most notably the view. I covered this at a high level in my earlier article, but I want to stress how significant this is. AngularJS, essentially, started with the view and worked its way back. That’s why there was this obsession with components being the future of web development, because they would have been part of the view, and coded by developers who specialized in the view, and placed by web developers who were basically hand coding views.

That means that HTML developers were the target audience for AngularJS, and far from making it simpler, it ultimately was more complex. Applications are not easy things to make, and something that seems easy can actually be hard. While it is a good idea to start from the result and work back when it comes to understanding something at a high level, deciding how to come to that solution requires architectural understanding and flexibility, to wit starting at the base and working forward. If the entire framework is built around trying to allow those who can’t code, to code, arriving at end results gets ever more roundabout and contrived.

So by embracing that reality, Angular ultimately is less complex. Yes, you need to know more JavaScript and less Angular to make the most of Angular, but that’s good. It also means it is harder for Angular developers to be pure full-stack, unconcerned with presentation. Getting the most out of Angular requires a deep synthesis of Angular, JavaScript, and HTML/CSS.

Speed: This is the big one. Angular is faster than AngularJS in every way, and none if it requires hacks. None of it requires custom JavaScript to step outside of, or around, Angular’s limitations. While there are more optimizations than can be quickly discussed in this article, the major speed boost comes from the advent of one-way data binding and the avoidance of the digest cycle to determine changes.

In case you don’t remember, the digest cycle in AngularJS was when Angular would check everything for changes, then update itself, but that update could also cause changes which would need updating. This back and forth until no more changes were detected was called the digest cycle or dirty checking. Just saying it out loud makes the kludgy slowness of the solution apparent. Back and forth, back and forth, back and forth, on and on and on. Large web pages could take SECONDS to fully change.

This process had other nasty side-effects outside of inefficiency as well. For example, when changes can cause other changes, it makes LIFECYCLE HOOKS problematic. A lifecycle hook is an event that you can monitor. For example, your program creates or destroys something. The creation is like the “birth” of that thing, and your code can monitor for an event like onBirth. Similarly, you could monitor for something like onDeath to make changes when a component is destroyed.

AngularJS had a huge hole in this process: there was no onDigestEnd event. You could never know when the digest cycle had ended, and it had to be that way, since doing something with onDigestEnd could trigger a change, which would then need to cause the digest cycle to continue. This process could be infinite. This meant that you were basically developing blind vis-a-vis the DOM. You never knew when it was stable - you never knew when changes were finished. Often, you would have to do a WAG (Wild-Ass Guess) timeout to ensure that everything was done before your application continued. This meant that any large AngularJS application necessarily had inefficiencies and pauses in its functionality to account for an unknown digest state.

Angular does away with the digest cycle entirely and replaces it with a much more easily-understood one-way data flow of changes that only need to be checked once. And since everything flows in one direction, lifecycle hooks like onChange or onChangesFinished are available, making the flow of events in the application easily understood. A happens, then B happens, always in that order. You did not have that guarantee in AngularJS.

This frees your application architecture a bit, since in AngularJS, you had to be judicious in your application of scopes to ensure you didn’t have too many of them in the DOM at any time. If the digest cycle was forced to run multiple times, or if you suffered DOM thrashing, the application could seize up as it calculated the UI. With Angular, even if you design it poorly and it checks the entire UI for changes, for every event it only has to check the UI once. For even colossal DOMs, check times are under 200ms.

Furthermore, a well-designed Angular app doesn’t need to check the entire DOM! As I will discuss later, Angular implements a toolset called Zone.JS, developed by the Angular team but usable in any application, that controls how events are tracked. If an event, like a mouse click, never “leaves” a particular zone, Angular knows that it doesn’t need to check for changes outside of that zone. Practically, this means that as long as changes are propagated through your application via Inputs and Outputs, Angular can rapidly tunnel down to where the change is without checking everything else. This nets HUGE benefits. Your application can run ten times as fast.

So if this is so fast, you may ask, why did we ever use MVC or MVVM models for application development? Why have the view? Early, it is because applications were simple. But later on, in the era of the first graphical user interfaces, it is because it was fast. Computers today can check and re-render a UI rapidly, but computers in the 1980’s couldn’t do that. They needed a set View that was populated with data. They needed to know beforehand where changes needed to go, because having the computer determine that was too costly. Without going into too much detail, in the past, it made sense. And even today, for many applications, it still makes sense. But for the hyper-flexible world of the web, it makes less sense.

Composability: One of the hallmarks of functional programming, and thus React and the whole Redux hullabaloo, is composition over inheritance. Those are keywords, kids. Make sure you have them in your notes. If you have seen even a single video or article about functional programming, you know that composability is damn-near the second coming of Christ according to these people. And by these people, I of course mean the Lizard People Illuminati.

Keeping this as short as I can, composability over inheritance involves the concept of pieces of code as “things.” You have a thing that can do something, but you want it to do something else! So what do you do? You can either EXTEND your thing… giggle… and thus give it a new ability, or you can create a separate thing that sockets into your current thing… giggle. If you extend its abilities, that is called inheritance. It’s called that because the new thing that you created INHERITS all of the abilities of the first thing. If you create a new thing that can then be put together with other things, that is called composability. It’s called that because you are COMPOSING a larger piece of code from smaller pieces.

Countless Twitter posts have been expended talking about the benefits of both, so as I continue to try to keep this short, I think that the primary advantage of composability is that you only use what you need. Don’t need a particular ability? Don’t include it in your recipe. With inheritance, you run the risk of inheriting things you don’t need.

And since Angular is all about only using what you need, you can see how composability aligns well with its philosophy. This provides great benefits for change detection. If you had a large hunk of code that needed to be checked for changes, Angular would have to check that whole hunk. But if you have components composed of smaller components, if the parent component doesn’t change, it’s guaranteed that it’s children haven’t changed. The change detection can stop.

Composability offers easy-to-read code, as well. If you want a button in your interface, you just put <my-button> there and set its attributes. For example, <my-button text=”submit” function=”submitForm”>. If you need to change the button, you go and work on the button and only the button. Since each component is an island unto itself, you don’t have to worry or reason about massive edifices of parts talking to each other.

Dependency Injection: It could be reasonably argued that Angular’s party piece was its dependency injector. A great many Angular applications were created solely to take advantage of this. And while implementations can get a little hairy, the concept is very straightforward.

First off, what’s a dependency? A dependency is when a piece of code depends on something to function. That usually means something is asking something else for data and CANNOT CONTINUE until it has received that data. As such, it makes a lot of sense to isolate the data request into one component and then connect all of the components that need the data to this single location. That way, if you need to make a change to the data request, you only make it in one spot.

The injection of dependency injection is when a piece of your application does not have direct access to its dependency. Instead, you explicitly give the dependency to it. This provides a number of benefits, most notably testability and memory management.

In AngularJS, a Dependency Injector is what’s known as a SINGLETON. Basically, a singleton is a component that only ever exists in one spot. If you try to create a second one, it overwrites the first. On the surface, this makes a lot of sense for a dependency, but it doesn’t make PERFECT sense, and it forces you to write repetitive code or concoct wild networks of dependencies when you have dependencies that are similar but still materially different.

For example, you could theoretically create a single component called DataFetcher. It fetches data. You can then have a parameter that controls WHAT data it fetches. You can tell DataFetcher to set up an injection for customer information data, or weather data, or Kim Kardashian’s tweets. You can then have those injectors in various spots in your application. In AngularJS, though, that theory gets thrown out the door, since you would have to write separate components to get customer data, weather data, and Kim Kardashian’s tweets.

Angular fixes the main issue by allowing DI to be created on a component basis, meaning you can have a service created at the root of the application and used by everyone, or you can instantiate as many as you want for each component. Thus, the Platonic Ideal of DataFetcher is possible. Obviously, you don’t want to go crazy with this, but ultimately it allows for very non-repetitive code. You can write one service that can handle multiple things, and instantiate it in whatever state you need for each component. This is easy to use, fast, and flexible.

Better Components: Web Components are dead. It’s that simple. There are a great many people who refuse to accept this, and I won’t go into them here, but the long and the short of it is that React has killed them, and the JavaScript-first perspective of application creation is here to stay, and for good reason. We are no longer web developers. We are JavaScript developers who write for the web.

But that’s neither here nor there… well, actually, it’s at the very least here, if not there. Regardless! While Web Components in implementation are dead, components in interface do not have to go anywhere. Indeed, the component model for interfacing with an application’s code is easy to reason about, and straightforward for a developer to grok. I love the component interface and Angular clears up a great many problems AngularJS had and extends them.

One of the biggest reasons to love them is how easily they COMPOSE, and this applies to both Angular and React. React takes an OOP class perspective on module creation and extension, whereas Angular takes a component perspective, even though they still refer to what they are exporting as a class, and React still refers to its classes as components. I know, this is getting weird.

As I talked about up in the composability section, In Object Oriented development, it is common to create an object, then to extend that object on the fly to fit certain cases. These are sometimes referred to as Mix-Ins. React implemented these early on before ultimately telling people to not do it, thus completing their wholesale rejection of OOP principles. But the remnants of this decision remain in their language choices as how they taught React early on. (https://facebook.github.io/react/blog/2016/07/13/mixins-considered-harmful.html)

Angular’s components, though, are just that: components. They are parts, immutable save for what they allow as inputs. If you want a component to handle another situation, you need to change that component in its entirety. This requires more thought, like are you sure there is no other way to achieve this aside from altering the component. This can take time, and it can require a shift in thought, but ultimately it makes things much easier. In the OOP extension model, it is hard to determine where a failure happens because that component is being extended all over the place. In the component model, everything that could be going wrong is right there in front of you because it HAS to be.

This makes components very easy to implement and very powerful. There are considerations that I will get to later, but for now, just know that this mode of architecture is taking the world by storm and will likely become the standard form of design in the coming years.

In The Zone

One of the most important aspects of Angular at a low level is how it manages change detection. Basically, how does it know what has changed, and how does it then know what to update based on those changes? This section is more important for developers and I will be using some technical language here. If you are a manager or consultant deciding whether you want to implement Angular, this section is still a worthwhile read, but if you find the language unintelligible, you aren’t missing any decision-critical information.

Before I go into greater detail, I want to address the online documentation on Zone and JavaScript in general. So much JS writing is done by geeks trying to coin terms. They’re doing this to sound smart. They invent terms to describe their concepts instead of talking about them in simple terms that any JS developer could understand. Charitably, we can assume they do this because they are coming from a non-JS coding perspective, where concepts are undeniably different. But I’m not in a charitable mood.

I think they understand JS concepts just fine and choose to talk in non-JS terminology because they think it sounds more hardcore. Redux was bad, but it’s got nothing on Zone. ZoneJS is one of the worst examples, if not the worst example, of this I have ever seen. Whenever you read anything about Zone online, they ALWAYS describe it has “thread-local storage for JavaScript.”

Well what in the bloody-blue-fuck does that mean? JavaScript has one thread. You can’t have per thread storage. But that’s how they choose to describe it, thus forcing JS developers to go and look up that term. That’s annoying. You should write to your audience, and the vast majority of JS developers are JS DEVELOPERS. This perspective is why we continue to try to shoehorn object-oriented paradigms into a language that is functional at its heart.

But that’s neither here nor there. Let’s get back to Zone. But before we talk about Zone, let’s say what Zone IS.

Zone is nothing more than a function that gets instantiated with its scope, in which variables are stored. When a series of events end, the scope is closed, the function is dereferenced, and it is garbage collected. Each Zone is literally a function sitting on the stack. If you fork a zone, you simply put another function higher up on the stack.

What ZoneJS does is ensure that the broader application knows when these functions open or close, and keeps any variables that are needed between these separate functions “alive.” Thus, as a “thread’ enters and exits functions (zones), it carries its variables along with it. This is related to the reactive concepts I mentioned above. The application KNOWS what has changed. This is an overly broad description of Zone, and frankly, I suspect that it is wrong, but I don't think that's my fault. Zone is very strange and the documentation does it no favors.

Now that you know that, fundamentally, that’s all it’s doing, let’s explore why it’s doing that and what benefits it gives us.

For Angular, and the rising world of reactive programming, you want your application to, in essence, always be “alive.” The engine that is your program is always running, ready to respond to changes.

But if your application is built out of immutable components, what happens when an event comes in, for example a mouse click, then bounces around for awhile. Services lag, the browser lags. Theoretically, you could have this event banging around in your application for tens of milliseconds. You want other things to happen at this time but maintain variables as needed by the original event. Zone becomes your temporary storage of state as functions do their stuff. This allows other async events - clicks and such - to come into the application and also start banging around with their own contexts and variables.

So basically, Zone is yet another form of faked multi-threaded JavaScript. We’ve been here before, but Zone is a notably complete package and is now part of one of the largest frameworks in the industry. If you want fake async, you want to look at Zone. And if you want Angular, you need Zone. Because without Zone, none of the bindings will work, because bindings are all based on a change.

So to bring this back to Angular, how can we best implement Zone into our Angular application? Basically, we don’t! Angular manages change detection, and thus all data, through Zone. If you don’t want to touch Zone, you don’t need to. It’s all behind the scenes magic.

That said, your goal, either as an Angular developer or an Angular project manager, is you create the best possible Angular application possible. And with that in mind, Zone is a tool that you can touch, change, and implement in novel ways. I doubt that it will ever become best practice to directly use Zone, but as web applications get more powerful, and frameworks are pushed beyond their original visions, the underlying philosophical building blocks that comprise their corpuses... corpii?... will become increasingly important; know them.

TypeScript: When You Type Script

TypeScript is growing in popularity because it is basically C# for JavaScript. It is typed. It is object-oriented. It is safe...r. And if you are working with a large, fluid team, it is a valuable addition to your stack.

I say that deliberately. As I’ve said again and again, be VERY careful before you add something to your stack, especially in the JavaScript world. It is shockingly easy to simply import modules and packages, and before you know it, your application suddenly relies on possibly THOUSANDS of pieces of outside code. It’s this willy-nilly dependency jungle that allows things like the left-pad debacle.

By and large, I am of the mind that your work should always be as vanilla as possible. And when it isn’t, you should understand exactly what is happening and how the code is being added. As JavaScript has become increasingly interconnected, this has become difficult. You may bring in a single NPM package, but within that package is dozens of other nested dependencies.

Why do I say these dependencies are bad? Because there is little accountability in the world of Open Source. No one OWNS it. No one is RESPONSIBLE for it. And if you are a company who is using a package, finds a bug, and discovers that no one working on the package has time or cares, you are suddenly saddled with the task of fixing the bug, which could take days or even weeks. Understanding and responsibility are critical.

Importantly, not everyone in the Angular community is using TypeScript. There were significant motivations to do this earlier in Angular’s life, with transpiled code being multiple times larger than the code that was actually written. If you wrote 20Kb of code, your user could receive 200Kb! This pushed many performance-minded teams to avoid TypeScript and write their own code.

Today, the concern is less significant. Advances in the TypeScript transpiler has cut code size by double-digit percentages. But it must be said, if you and your team want to use Angular but demand the highest performance, you may want to investigate vanilla JavaScript over TypeScript. I do not recommend this, though. Documentation for Angular is lean. Documentation for Angular without TS is nearly non-existent. Proceed with caution.

It is important to remember that TypeScript is a completely transpiled language. It is ultimately just JavaScript. While philsophically it is C#, it isn’t C#. It isn’t Java. Your extant Microsoft and Oracle developers will not be able to just pick up Angular and TypeScript and start writing. The value in TypeScript does NOT come from being able to better leverage existing developers. It’s value comes from giving your JavaScript developers safer tools. Do not look at TypeScript as a magic bullet. Under it all, it’s just JavaScript.

That raises my final point, which is that since TypeScript is really just JavaScript, it is part of Angular, but it is not an architectural part. As such, it’s not entirely inaccurate to say that it isn’t actually part of Angular. It’s merely the language you speak when working with Angular. TypeScript doesn’t determine how data will flow, where it will go, or what it will do. The browser does not read TypeScript directly. The web is JavaScript, nothing else. Indeed, as JavaScript advances in the coming years, I find it highly likely that TS will become genuinely optional for Angular development.

RxJS

The second thing that comprises Angular is RxJS. As mentioned, that stands for Reactive Extensions for JavaScript. Again, I have problems with the words. This is not an extension of JavaScript. It is JavaScript. You could write this yourself. In fact, people HAVE been writing this for themselves for years.

The fundamental principal of reactive programming is that the entire application is “alive,” and thus any changes automatically propagate throughout it. A good way of thinking about it is variable assignment.

x = 5;

console.log(x);

That console.log part will print 5 to the screen. But if you do this,

x = 3;

console.log(x);

Now you’ll get 3 because you changed the value of x. The program reacted on the most basic level.

Extend the example, though, and try this,

z = x + 2;

console.log(z);

You will get 5, since the last value of x was 3. If you then set x = 8, and call z, you will still get 5, since z was calculated when x was 3. The program did NOT respond.

Obviously, there’s no easy way to integrate this concept into a language itself, so it must be implemented in the architecture. The developer must integrate in “hooks” between parts of the application, such that when an event happens, it reliably travels through all areas that need to be aware of that event. As you can see, there is a good reason why reactive programming and functional programming have become such good friends. Functional programming strives for the least amount of state in an application, and the less state you have, the easier it is to make sure that the state reacts to itself effectively.

Broadly, Reactive Programming is just the most recent coding fad to solve old problems. Its principles are becoming core to some very popular JavaScript frameworks, Angular included, and I believe that Angular’s future will rely on them, and RxJS, heavily. Furthermore, the strongly structured philosophy of functional and reactive programming is a good antidote to the highly unstructured ways of JavaScript developers who have been in the industry for a long time. Working within the bounds of RxJS could be could therapy.

The biggest change that RxJS brings along from ordinary JavaScript is the concept of a STREAM. Unlike other forms of state observation, a stream never ends. For example, the basic way of observing change in JavaScript is known as a PROMISE. This is a request by one part of the application to receive something from another part. When that thing is received, the promise is finished. No one is listening anymore.

A stream instead becomes the thing that is listened to, and it produces a stream of things. Fundamentally, this is very similar to the pub-sub, or publisher-subscriber model, and the observer-observable model. Parts of the application subscribe to events and then receive them from the publisher. Like so many things in the world of “new” JavaScript, this stuff is old. Very old. All of these concepts were discussed in the seminal Design Patterns book. This is why I say that the most important things to understand are all basic computing concepts. Learn JavaScript. Don’t learn tools. With that knowledge, you can best understand how little everything has actually changed.

NgRX: React vs. Components

NgRX is Redux. Redux is the incredibly popular React framework that keeps your application’s state in one spot only. Every part of your application looks to this one spot for data, instructions, and commands.

In the introduction, I hinted at what I see as an inherent conflict in Angular vis-a-vis NgRX. What I mean by that is how Angular is component-based in its philosophy, and a component is a stand-alone THING. If you create a dashboard with three cards, and each card is a component, then each card can be instantiated, and it knows how to function, separate from everything else. It can get its own data, determine its own appearance, and manage its own functionality.

This is wonderful from a theoretical standpoint, but in a real-world environment, it has some huge problems. First and foremost is a problem that Redux and NgRX were created to solve: data repetition. If you have one component that gets customer data, and another that also gets customer data, it’s terrible architecture to have each component request the same data. If you are running an enterprise back-end, that means your load on a service is DOUBLE what it otherwise would be. And woe be you if you have three, or four, or FIVE components which are requesting repetitive data. Worse still, if one component updates the data from which they are all drawing, you must independently come up with some way to update all of the other components. To describe that as Mission: Impossible is likely an understatement. I’m digging for a Tom Cruise joke here, but just can’t manage it.

The component people will say, somewhat rightly, that if you have multiple components all requesting the same data, your information architecture is poor. You should only have a single component requesting that data. But in the messy world of an enterprise application, that simply isn’t feasible. You may have a component that needs to be customized based on authentication or customer information. You may have stakeholders who want pieces of data EVERYWHERE for some reason. All of these use cases violate the component ideal, which assumes that each component is independent and knows nothing of its siblings. Ooh! Ooh! I just thought of a Tom Cruise joke! Show me the changes!

So in comes Redux and NgRX. They are known as Single Source of Truth models, or SSOT. In this model, components are able to instantiate themselves, and they know what to do with input, but they cannot get that input for themselves. They rely on their parent to INPUT data and commands. By themselves, they are empty shells.

This brings the conception of the application back to a more monolithic model and away from a profoundly granular model. This move is one of the big reasons for the death of components, since that ideal simply has no way to effectively deal with data repetition without significant complexity.

It is also why, as I mentioned earlier, Angular is fundamentally conflicted. Angular’s ideas, structure, vocabulary, and implementation were all based on components just as components were being put into the grave. While the Angular team has done an impressive job pivoting to an architecture based on RxJS and Redux, the remnants of their old ideas persist in presentations, documentation, education, and the componentized way Angular apps are built.

Should I Use Angular?

Whether you should use a framework or not is a difficult question, and it is affected by what is known as JAVASCRIPT FATIGUE. Long story short, the JavaScript world is filled with a lot of noise, so it is often hard to determine what the best course of action is to solve any particular problem. Making matters worse is that whenever you go online in search of wisdom, you will find the majority of articles and resources developed by people who are pitching themselves as JavaScript DEVELOPERS. They aren’t mere web developers, oh no. These people are code ninjas, so they spend a lot of time talking about the absolute newest stuff, when for many projects, the newest stuff is ridiculous overkill. It’s hard to figure anything out when there are so many birds fluffing their feathers.

That said, I think that Angular is a great option for many different websites, even simple ones. Basically, for any website, the lower the load that you can place on your server, the better. It reduces the amount of bandwidth and electricity for which you have to pay. Angular helps with that by taking what would be a complete web page and reducing it to some JavaScript and some data. The page is then built by the client’s computer, and not by your server.

Angular also allows for excellent fall-back rendering on the server in case the client’s computer does not support JS or has JS turned off. It can also be thoughtful of you if you render the page on your server if the client is using a cell phone, since JavaScript parsing and processing can eat up battery life. As such, even relatively small websites that primarily serve up content can benefit from implementing Angular.

That said, if you are already using your own JavaScript on the client and are using PHP or Django for your server-side work, I see little reason to make the jump to Angular. It’s very much a case of six of one, half-dozen of another. If you are starting fresh, take a good, long look at Angular. It’s a great fresh start tool.

But now for the really difficult question, should you use Angular over the nine million (Literally. I counted.) other JavaScript frameworks out there. This is harder to nail down.

Before I go further, I am generally of the mind that the framework you choose should be backed by someone big. For me, that means Angular and React are your only choices, since they dominate the framework scene and have the backing of giant companies. But this view is heavily informed by my time on huge teams at huge companies where making sure that resources for everyone are robust and the horde of caffeine-fueled maniacs can successfully stumble their way into a working application.

If you are not working on that scale - perhaps it’s just a few devs working closely together - then choosing one of the smaller frameworks is a viable option. You can all learn the framework and begin rapidly iterating features or producing content. For this, you should check out both Vue and Ember, which are quite popular in agencies for the speed of development that they allow.

For now, let’s assume that you are working at scale. The long and the short of it is that React is modular whereas Angular is not. You implement ALL of Angular or none of it, otherwise trying to wedge it into your own architecture is a fight. In the end, your application will work, but it would also have worked if you hadn’t used Angular, and you would have likely saved time.

React allows you to implement only pieces, so if you have a large, existing application with no technological reason to change architectures, go with React. It will, I guarantee, be faster and easier.

Importantly for enterprise customers, Angular is a COMPLETE package. You cannot use Angular piecemeal. That means that it cannot be used in the same way as AngularJS. If you work at a Fortune 500 company, chances are, somewhere in your company, is the classic stack of Oracle/IBM on the back-end, Microsoft .NET in the middle, and AngularJS on the front. That was possible because Angular could be be bootstrapped on the DOM. In this scenario, the .NET framework would burp up fully built HTML with Angular built into, the client would get it and then use the Angular code to finish building the HTML. This took load off of the connection, where the .NET framework would only have to deliver a single row of a table, with an Angular hook saying “repeat this row with this data.” The table would then be built on the client, saving precious bits from the server.

This is done. Angular now owns everything. If you want to integrate Angular into the same socket that AngularJS filled in this stack, it won’t work anymore. For that scenario, you will need either Ember, React, or Vue.

As I said above, React is the only one being backed by a major company, as such I see it as your only real option. It’s a much easier sell to executives and stakeholders. That said, Vue is very interesting and warrants at least a look. It can be used in the exact same way as AngularJS, uses an architecture very similar to React, and has an interface very similar to Angular. Furthermore, it is incredibly lightweight, among the fastest tools out there, and can be incrementally built up as you need new capabilities.

For Your UX Team

This is more of a side note, but a big advantage to a component-based perspective is that it forces your developers to create each piece of an application as though it were an application unto itself. A card is no longer a card, it’s a tiny program that must deal with errors, inputs, outputs, and its own state. That forced granularity of thought is fantastic.

It is especially fantastic for your designers, since UX design has a tendency to be very waterfall in their thinking, and thus very waterfall in their conception of the application itself. This can mean that they will develop a piece of the UI without consideration for the piece in and of itself, but only in relation to what it needs to achieve in the broader application design. This means that edge cases are ignored, and future capabilities that will undoubtedly be requested and designed get tacked onto a conceptual framework that was rickety to begin with.

With both your developers and your designers looking at every piece of the application as tiny things unto themselves, every piece is given the thought and work that it requires. Yes, that can slow down the design process, which stakeholders hate, but the slowing down of that process is important when so many companies dev/design teams basically turn into feature factories, where they simply rapidly iterate features based on poorly written business requirements. Buttons and forms get tacked on. Data is tossed around like spaghetti on a wall. If this can be mitigated with a technological excuse, the slower the better.

Other Environments

Obviously, the primary environment for an Angular application is going to be the browser. Whether that is Firefox, Chrome, or Edge, the browser is king. But that doesn’t mean you will never find yourself running your application in different environments, and it is important to have at least an awareness of these possible futures.

Most likely, the first alternative environment in which you will find yourself is server-side rendering. This was one of React’s party pieces early on that was quickly loved because it allowed a full-JavaScript stack, but still allowed serving of complete HTML/CSS packages from the server just as PHP, Ruby, or .NET would have done. Today, every major JavaScript framework supports this except for the old hands AngularJS and JQuery.

In most cases, this server-side rendering was done with the “headless” browser, PhantomJS, and as I can attest to from dozens of problems, PhantomJS is just as troublesome of a cross-browser issue as any of the other browsers. Indeed, PhantomJS is perhaps the MOST difficult since it is hard to debug, and automated tests usually rely on Phantom to perform rendering. As such, something can look find in every browser, but your tests will still fail. This is absolutely the most important secondary environment with which to become acquainted.

The other two major environments are both concerned with native applications. Most trendy is the Ionic framework, based on the open source Apache Cordova project. This allows a project to reuse a great deal of their code between platforms, whether it is iOS, Android, or the web. Each implementation will require about 20% to 30% of the code to be different, but 20% to 30% is better than 100%. Furthermore, the rise of native applications being developed in JavaScript has made disciplined JavaScript architecture all the more important. If you decompose your code correctly, you can reuse large amounts of it. If you decompose it poorly, you will find yourself rewriting much more than you otherwise would need to.

Getting a Job

Getting a job with Angular is very easy. Learn Angular and RxJS. You really can’t learn them separately. Then learn TypeScript outside of Angular, since it will only get more integrated, so learn it as best you can. Granted, you will want to use as little TypeScript as possible ultimately, but you should know it inside and out anyhow. Then learn NgRX, since SSOT application architecture is the new hotness. Create a demo app using all of these things. Boom. You have a job.

Yeah, yeah. It’s very easy to say all that. All things considered, you have about six months of deep work ahead of you to get fluent in all of these technologies. Then you will have to stay absolutely up-to-date on all of the underlying technologies, because with the ever-changing JavaScript landscape, your value will come from being able to navigate the chaos. No one said being a ninja is easy.

To be an Angular ninja, beyond simply saying “learn everything,” the most important things to understand are streams, RxJS, and change detection. These three things are, in essence, the more algorithmic parts of Angular - the comp-sci aspects. As such, these are the parts where PERFORMANCE is either achieved or ruined.

And that is the most important aspect of this. Because you are handing over so much control, performance is critical. You have to know where bottlenecks are, and how to best get around them. You don’t necessarily need deep understanding of JavaScript algorithms, even though it couldn’t hurt, but you will need to understand how the framework is routing data, checking for changes, and managing rendering. The limits of your performance are out of your control, but how close you get to that limit is.

And as I mentioned in my section about ZoneJS, there are elements of the Angular architecture that you don’t NEED to touch, but you CAN. At the moment, there is little capability or performance to be had from this behavior, but as Angular pushes into the future, I feel confident that this will change. Eventually, Angular will expose many of its “wires,” and allow you as a developer to extract scenario-specific enhancements.

Before all that, though, you must grasp the philosophy of Angular. Understand its component-based interface and conception. Learn about its history compared to AngularJS, how and why it stole ideas from React, and the conflicts inherent to the component architecture in a world where Web Components is basically dead. Watch every speech on YouTube given by the Angular team. Read every article they wrote. Understand why Angular is Angular.

Then, you will be a ninja.

Beyond that, depending on where you want to focus your work, you should learn the different environments in which an Angular app may run. As I mentioned above, the two most significant ones are the Electron desktop environment, and the Ionic framework for mobile applications. I see these as very much icing on the cake. Angular is a browser-based framework for web applications first, everything else second. As such, beyond good JavaScript and Angular, learn PhantomJS and how to wrangle it.

Hiring

My advice for hiring for Angular stands: focus on JavaScript skills. If you want your developers to be ninjas, then you have 3-6 months of training and education ahead of you, but if you find that to be a deal-breaker, I recommend reconsidering your priorities. I would rather hire a great C developer who has never used JavaScript, and spend six months teaching her JS, than hire a merely decent JavaScript developer.

I say this because Angular is just JavaScript, ultimately. It is pre-written application code. That means, to best understand it, a coder should be able to write that application herself. Only by being a programmer first can a person truly grok the framework, and I say grok in its original definition, from the novel Stranger in a Strange Land.

Grok means "to understand," of course, but Dr. Mahmoud, who might be termed the leading Terran expert on Martians, explains that it also means, "to drink" and "a hundred other English words, words which we think of as antithetical concepts. 'Grok' means all of these. It means 'fear,' it means 'love,' it means 'hate'—proper hate, for by the Martian 'map' you cannot hate anything unless you grok it, understand it so thoroughly that you merge with it and it merges with you—then you can hate it. By hating yourself. By this implies that you love it, too, and cherish it and would not have it otherwise. Then you can hate—and (I think) Martian hate is an emotion so black that the nearest human equivalent could only be called mild distaste.

To grok Angular is to merge with it. It is to merge with the people who developed it and to deeply understand their thought, so you can see what they were trying to do and not simply what they did. Its capabilities and limitations become extensions of the person’s programmatic thought. This can take a loooong time, and that length of time can be significantly shortened by hiring someone who was a pure developer already. They can reduce a two-year groking process down to six-to-eight months.

Fair dinkum, I’m not the first person in computer science to latch onto the term grok. Hell, comp-sci is even mentioned on the Wikipedia page for the word.

If you are just getting an Angular application off the ground, hiring a highly-experienced Angular architect could prove valuable in that many of the high-level questions about design and structure can be answered early on. From the perspective of an architect, you are saving 3-6 months, and perhaps some questions later on. Unlike my earlier article, where getting an Angular dev saves you only a month, this time savings is not so easily dismissed. Half a year is real time and real money for a project, especially considering that an experienced architect may see mistakes early on that can cost sprints of work in the future.

It’s a tough balance. The experienced architect will probably cost a great deal. They may charge in excess of $125/hr. As such, growing your own talent who will stick around after the work is done may be worth the wait. If I were managing a project, I would lean toward growing my own Angular experts, but I always lean toward developing internal talent. If you are on a large, fixed budget project, getting a new platform off the ground may be goal #1. So instead of circumlocuting this any more, suffice it to say that an expensive architect or homegrown talent are both valid choices.

Angular also provides some pitfalls in hiring in that its interface and coding are very similar to Microsoft and Java coding. This leads many people to think that they can develop in the same way as they would in those environments. And as I said above, even though Angular LOOKS like those languages, it is not. It is, at its root, just plain, old JavaScript. Be careful of Java and Microsoft developers who think they can easily develop Angular. They cannot.

Similarly, developers rooted in the functioning of old JavaScript frameworks like AngularJS, Knockout, Dojo, and their ilk will not write Angular correctly. Do not search for developers in Angular based on experience in the old frameworks. Experience in React or Vue can be more easily transported, so I think you are safe filtering resumes based on those keywords, but even then, be cautious.

Finally, one of the things that AngularJS did was normalize putting huge amounts of application logic on the client. This was an advancement on the previous way of doing things and empowered JavaScript developers to become more than they were. Additionally, it also put far more importance on the person whose primary skillset was coding within the browser, as opposed to across the stack. The era of huge teams of full-stack devs cobbling together programs is ending. You cannot have Angular developers who produce garbage HTML and CSS like you frequently see in the Microsoft and Java development. Your developers now need to understand the ins and outs of the browser, since that is where everything they write is going to run.

As such, make sure your Angular developers are very strong with HTML, CSS, and cross-browser testing and optimization. If they don’t know what CanIUse is, that’s a problem. If they can’t tell you which browsers are the most popular, that’s a problem. If they can’t tell you the unique considerations of mobile browsers, that’s a problem.

The other environments I mentioned earlier are special cases. NativeScript, Ionic, and Electron all have very specific considerations that must be learned separate from Angular. If you plan on implementing Angular for these use cases, your team will have to learn Angular first, environment second. And in this situation, I actually do recommend looking for people who have extant experience. JavaScript is still first. JavaScript will never not be first. But with so many tools needing understanding, a head start at this point becomes very valuable.

With that in mind, seek out Angular 2 experience first, but if the candidate has experience with Electron and React or Vue, that is also good. Similarly, if the candidate has experience with Ionic and AngularJS, but not Angular 2, that can still prove valuable.

Similarly, just as the concepts of one framework can give a candidate a better starting point in another, these different tools all follow similar principles to get JavaScript working in native environments. As such, React Native, NativeScript, and Ionic do have SOME concepts that translate. All things being equal, if a candidate has experience in React Native while another doesn’t, that could be the grain of sand that pushes one candidate over the edge.

Final Thoughts

As you can imagine from my voluminous writing on the subject, I like Angular. It is such a massive improvement over the first generation of Angular libraries and frameworks that almost every criticism that I once had of them has been swept aside. It is fast, efficient, and can handle large datasets much more effectively than AngularJS or old Ember. I like its implementation, its interface, its tooling, and its growing set of packages. Its rapid development is, in my mind, more good than bad. And it is certainly stable, since Google will never let it die.

That said, there are quite a few big problems with Angular. First and foremost in my mind is documentation. Or lack thereof. There appears to be a push by the Angular team to get their documentation up to snuff, but it is still, as of this writing, poor.

Second, Angular’s biggest advantage is, as I’ve said, also a disadvantage. It is one big thing. It’s no longer monolithic in the architectural sense, but it is still monolithic in the implementational sense. You use all or nothing. That means that many applications may never use all of Angular’s abilities and are thus bringing over weight they don’t need. Or worse, what Angular has is incapable of doing what the business is requesting.

Partially because Angular has done a good job of breaking up its code base to allow for modular loading, I don’t see this as a killer. Mostly, though, I think it’s actually a good thing because it means that when scope expands and new features are requested, the team will be less likely to need to analyze and implement something new on the tech stack. Everything they need is already available. Furthermore, Angular is moving at such a rapid clip, features that are unavailable today may become available in the next release, as has happened with both NgRX, RxJS, and Angular 4. I find this exciting and think that Angular is the better for it.

That said, both React and Vue have attracted my attention. As opposed to Angular, they both have much better documentation, making learning them, and using them idiomatically, much easier. This is especially true of Vue, which has excellent documentation at all levels. You can genuinely learn Vue from its docs, as opposed to Angular, which succeeds in doing little other than confuse anyone reading the docs. Both of them are incredibly fast, and React has recently implemented its massive Fiber update, making it even faster. And as I mentioned above, they are more easily implemented in a modular fashion, especially React, which has a robust ecosystem of well-supported additions and tools to create the framework of your choosing.

Furthermore, what I see as the greatest advantage to Angular can be found in equal measure in both React and Vue. To wit, the component-based ideology of everything as being its own, tiny application. As I said, this is more a function of perspective than architecture, and can thus be implemented anywhere.

But, granting all of that, the fact that the development of Angular and its various pieces are happening in a much more unified fashion than any other framework or library gives it a sense of stability and unified vision that the other tools cannot match. It takes a little while to learn, but I feel strongly that if you don’t know what else to implement, you should lean toward Angular since it takes more architectural considerations out of your hands than the other frameworks. Yes, yes, EmberJS does this too, you geek, but as I said earlier, I see two choices for large scale apps: Angular and React. They are unique, powerful, and both will ultimately achieve what you need them to achieve. I just prefer Angular for most use cases.

Angular: It’s the bee’s knees.

In Summary

• Angular is less monolithic than before and is composed of many parts, most notably RxJS, TypeScript, ZoneJS, and NgRX. All of these parts should be understood separately.
• Angular is moving very quickly, which can be stressful but is ultimately good. New features and optimizations are happening with every release.
• Angular is backed by Google, but is still open source. That means poor documentation, hard-to-solve problems, and hidden costs. Things get easier once you are up and running.
• Angular's component-based philosophy is out of sync with modern development but maps very well to UX designs.
• Angular is still just JavaScript.