Check out a free preview of the full Angular 13 Fundamentals course:
The "A Brief History of Angular" Lesson is part of the full, Angular 13 Fundamentals course featured in this preview video. Here's what you'd learn in this lesson:

Lukas discusses component-driven architecture's ability to manage complexity between components using observable streams and NgRx. A brief history of Angular in regards to the progression from large codebases to a more manageable application size is also covered in this segment.

Get Unlimited Access Now

Transcript from the "A Brief History of Angular" Lesson

>> We are going to talk about [SOUND] my favorite subject in the world, component driven architecture. And one of the things that I want to call out here is that when it comes to application development, there's a quote that I have in the testing slides about complexity. And one of the things that they're talking about is that complexity comprises of really three main things, managing of state, flow control, and code volume.

[00:00:43] With managing of state being kind of the primary driver for complexity and then control flow and code volume being kind of like byproducts of our inability to be effective. And what I like about component driven architecture is that it kind of a mezzo or kind of mid level range, it allows us to manage complexity between components by managing state flow control and code volume.

[00:01:20] In a micro level, I believe that observable streams handle complexity very, very nicely in these really tight, small, encapsulated, observable streams. And at a kind of a macro level that this is where like NGRX comes in and handles very, very, very, very nicely manage the state flow control and code volume.

[00:01:45] But you'll see here as I talk about this that within a microcosm, this is representative of an approach that is effective at a micro level, mezzo level, macro level, and even I guess universal level, if you will. But it's when we talk about component of an architecture, just know that it's kind of it foreshadows or it is a pattern that has a lot of implications outside of just component communication.

[00:02:20] So brief history of angular, if you've ever watched any of my workshops you've seen this is not new, but if you are new and you've never heard this, well you're in for a treat. So if you think back to the, I would say the second advent of JavaScript.

[00:02:42] So the very first kind of I think advent of JavaScript where people started to take it seriously was with jQuery. Then after that, then people realize there's like, well, there's some limitations and people tried to build jQuery applications, which was very hard. It just didn't work very well.

[00:03:03] And then I believe kind of the second coming of JavaScript is within what I would say kind of the emergence of the first generation of modern web application frameworks, and one of them was AngularJS. And what really set this apart is that you were able to do some pretty impressive things very, very, very quickly and very easily.

[00:03:32] That I think I haven't been to the AngularJS site in a long time, but in just a couple lines of code I was able to define a property and then bind to it in my HTML, change that property, and the HTML would automatically update, that was like a really big thing a couple years ago.

[00:03:53] Being able to have two way data binding that just worked was a really, really kind of a shiny cool party trick. And so you had a tiny app that really consisted of a very tiny view and a tiny controller. Then in my case, I decided I wanted to make money with this possibly even move to Hollywood and make movies about this.

[00:04:19] And so my application started to grow with my aspirations and eventually I got the green light to do AngularJS for real, for money, and so I'm just in my mansion in Malibu, and I've achieved everything that I want. And I'm laying there in my bed with my snakeskin rug, and I realized that like I'm dying inside that in all seriousness that these applications had grown to where what seemed to be like this really cool novel thing is we had essentially painted ourselves into a corner.

[00:05:08] So yeah, we kind of had this huge mansion in Malibu style application but it was just on tenable. So back to me laying in my bed and my snakeskin comforter. And I was in a problem, we were in a problem that this was a real issue, at least within the AngularJS community is what do we do about the fact that we're writing applications or we have one view, one controller, and they're literally I've seen them like controllers that are 5,000 plus lines of code.

[00:05:44] How do you work with that in a team to where it's like, okay, you need to work in the first 1,000 lines, and I'm gonna work in the last 1,000 lines and don't touch anything else. So it was almost like if you've ever done any real time document editing on my Google Docs.

[00:06:00] That's kind of what it felt like, but with code that had to compile and work. So let's just take a moment. Let's appreciate this because that's the place that we found ourselves in. And there emerged two kind of reasonable approaches to this. The first one was to create named routes.

[00:06:22] And so you had these named router outlets, if you will, in your application, like maybe like sidebar, content footer. And what that would do is then load in a controller and a template. So you still had that pair, but it was going into a route. And another, I think more that gained more momentum over time was to just create directives that would encapsulate certain functionality that you would then attach to pieces of the page.

[00:06:56] So you would have like a sidebar directive, a content directive, which was in a way it just kind of foreshadowed where we ended up with angular with instead of directors, we used components. So any angular application, and if I'm being honest, I believe that this is pretty much like any react application and probably any view application, potato, there might be some differences, but I know at least when I write react, this is the same exact approach that I take.

[00:07:30] In fact, a lot of the ways that we think about components is because of the work or the innovations that react did in that space. So I pour out champagne on the ground him for the react team for really bringing components front and center into the public consciousness.

[00:07:49] And this helped us solve a couple of things, one, the problem was structure as well as the problem with communication. So remember, complexity is mentioned of state, flow control, and code volume, and by solving the structure issue, that it helped alleviate some of the code volume problems. But also by giving us a clean way to structure our code but then establishing ways for us to communicate, this helps solve a communication problem which falls firmly under the flow control category.