Building Awesomer Apps with Angular Benefits of Angular

[00:00:00]
>> Lukas Ruebbelke: So let's talk about the big picture. Think of this as the cheat sheet module. I think before we get into the what, I'm gonna just take a few slides, I'm gonna talk about the why. And this is why Angular, according to Lucas. I've been doing it for over five years.

[00:00:17] And with Angular 2+ and above, here are the things that really kind of stand out. When I talk about why I love angular, why I use it, here's some of the reasons. So one is that we have well defined best practices. So if you've done angular 1.x and this is like 0.9, 1, 1.1.

[00:00:42] The beginning stages of Angular, and the Angular team will admit that they didn't really understand how to build JavaScript applications at scale. And so, some of the ideas that they had even from the official documentation was just wrong. And they'll admit it like, if we could do the way back machine, one of the things they said is put all your controllers in a folder, put all your services in a folder, and there was no concept of component driven architecture which create a lot of problems.

[00:01:13] Over the course of people starting to build things and learning from pain, and solving these problems, some best practices started to emerge. And so, this is when you saw the style guide. John Papa's style guide, Todd Model style guide. Then the Angular team kind of conversed and said, we're gonna make this an official thing.

[00:01:33] And then with Angular 2 and above, there's also a style guide for that. But it's community driven and a bunch of really smart people are saying, this is the way to build an Angular app. And because we have Angular CLI that as best practices emerge, that they just get baked into the CLI.

[00:01:52] So if you've ever done one CLI project and you come into another one, the shape is immediately recognizable. And so, on one end it's not like, what do you want it to be? Whatever, so this was I think one of the challenges with Backbone initially is like, are you an NVC or what are you?

[00:02:11] And Backbone was just like, whatever you want, we don't care. You define the structure. At the same time, some other frameworks they were super restrictive. Like, you have to do it this way or it's the highway. And so, what I like about Angular is they have well-defined best practices, but if you just say, I don't agree with this.

[00:02:30] This doesn't make sense for our situation. You can move on, you can kind of work around that to suit your needs. But the fact that there are opinions from a large group of people that are very smart, and they kind of agreed this is the way to build large scale applications.

[00:02:45] If you're coming in, be happy that this exists. When it didn't, it was just the wild west and people just did all sorts of crazy things. Secondly, is if anybody's ever tried to set up a development workflow, especially in JavaScript. And so, we have some of these things here like .NET.

[00:03:03] And in Java with like Maven and Jenkins, and you'll continue this integration. And so, there's kind of this mature ecosystem around how you set up and build a Java project or a C# project, or .NET project. Every major framework is kind of suffering from, I would thing JavaScript fatigue.

[00:03:20] It's like there's so many moving pieces, and getting them all to know the secret handshake in working together is quite a task. I mean, we could do a entire two day workshop just on development workflows. Thankfully, the Angular team has invested tons and tons of times into the Angular CLI and just streamlined a lot of those really messy pieces, and ng new, boom.

[00:03:48] You have a totally working front-end project. I can just say, for me, if I have to set that up by hand, it would take me two days. It is very tedious. They streamlined a lot of that for you. When you do a production build, ng build, done. You wanna do static analysis?

[00:04:07] NGtest or /CC, or -CC, done. And so, these streamlined pieces where we can focus on writing code and building features, and not having to worry about the moving pieces is really really important. The last thing you wanna do is get bogged down by things that actually have nothing to do with your code, it's just you're trying to get your environment up and running.

[00:04:29]
>> Lukas Ruebbelke: And there is a rich ecosystem, so starting with Angular material and the fact that we have material design, which I'm a huge fan of. That we have Angular officially supported components that inherited material design is a real value add. Not only that, it's that they're doing a component kit where you can have all of the guts of the components without the material design and styling.

[00:04:59] If you for some reason you don't wanna go in that direction, the Angular team has invested a lot of time into building even just a, the material components. And then just components without the material piece. So the fact that you can get up and running and you're not having to spin up a date picker.

[00:05:15] I think, Mark actually wrote on one time. And it really made him famous. Something I would definitely not wanna write. And more importantly, it's not something that I would wanna support. So the fact that you get that right out of the box saves me a lot of time, and I'm lazy.

[00:05:30] And with Angular 1, I think there is 50 or 80, there's just a ton of directives in Angular. It's kind of inserting itself into the DOM at every point, like there's a custom handler for a click or a mouse-over, or whatever. With Angular 2 and above is they really focused on standards, and letting JavaScript, TypeScript do the work.

[00:05:55] And so we'll see this, and I'll point this out through the workshop that the majority of what you write is just JavaScript. And so once we see components and compare them to services, and these different things. You'll see like, it's just an ES6 class or it's a TypeScript class.

[00:06:11] And I'll use those kind of interchangeably. But because they let standards do the work, we have half the framework but with twice the power. And that is, again, you can pick something up that is Angular and just pull the Angular piece out, and you can use it as a standalone.

[00:06:30] It's a very, very small footprint in your application, which I think is critical.
>> Lukas Ruebbelke: Yes, so this gets the googly eyes. They built the entire framework to be reactive, and so this is first class support for observables. We'll talk about that a bit tomorrow, but the point is when something changes, how do you know about it in your application?

[00:06:53] More importantly, is if you have two things that are looking at a single piece of data, how do you communicate state change into your application? That's a really tricky thing that a lot of people including myself have gotten wrong. Usually what happens is you end up resulting to shared beautible state, which is then just a powder keg waiting to happen, like that is the devil.

[00:07:16] But by using observables, you can communicate state change throughout your application effortlessly. And so, we'll see some of that a little bit later, probably tomorrow. But that it's just baked right in, again using observables to do the work. And you can just like, we don't need to do this, let's let observables do it.

[00:07:37] And last but not least, this also gets a big googly eyes, is you may remember it like three, four years ago. The conversation around frameworks was really really, I think caustic and negative. There was a lot of like, this framework could beat up your framework, and this framework works better than this framework.

[00:08:03] And I think most people realize that this is not the right question. It's about building things that ultimately, we can use better. For instance, Angular, we don't need to create our own version of JavaScript. Let's work with the TypeScript team. All the better, and I think the entire web community is one because of that collaboration.

[00:08:26] So Dojo, which is a framework, I think people sometimes forget exist, a very good framework. Dylan Schiemann actually lives in Phoenix, and they're doing their entire framework the next version of Dojo in TypeScript, because it's just such a great technology. And so, being able to pull TypeScript into kind of the forefront is a good thing.

[00:08:48] The Angular CLI, where did that come from? Well, from the Ember CLI. And so instead of Ember fighting Angular they got together and said, look how do we build something that can benefit everybody? Even component-driven architecture, it would be, I mean, obviously hats goes off to React for really driving component-driven architecture.

[00:09:07] And then the Angular team wisely kind of said that and said, well this is where it's going. Let's take some of those ideas and work it into our framework. And a lot of the people on the React team, the Ember team, Angular team, they talk they collaborate. I think it's just a much better place to be.

[00:09:24] And you know to that end, I don't think you'll ever hear me say something bad about another framework. And so a lot of I get this a lot of Angular versus React question a lot, and ultimately I think they're both great frameworks. And it comes down to how do you want to solve the problem?

[00:09:41] What makes the most sense for you and your team? Because they're philosophically a little different, but I think they do the same thing very well. So that is a big, huge plus one for me. This is seeing everybody moving in the same direction and not fighting.