AngularJS is honestly one of the best things I have stumbled upon in years. After Silverlight doing its fantastic disappearing act, my interest in developing things on the web took a nosedive. I had no interest in doing it what so ever. HTML/CSS/JavaScript was a massive step back from XAML in my mind. And I still think so. I think we are trying to do things on the web using technologies that weren’t built for it, ending up with a lot of hacky solutions…
However, when I found AngularJS and realized that I could use my MVVM experience, and my “XAML patterns” on the web, it changed a whole lot! I could focus on building applications and leave a lot of the hackyness to the side. I would still have to do the hacks, working with HTML and CSS, but at least I could build the logic side of things in a structured way.
However, Angular might not be the easiest thing to just pick up and learn. For web developers, picking up dependency injection and MVVM can be a daunting task, and being a .NET developer, taking up a dynamic language like JavaScript, and loosely strung together applications built on spread out text files, might seem less the perfect.
Angular isn’t overly complicated, and there are a million resources for learning it out there. But for some reason, I haven’t found one that suited me. So…I decided to do what all simpletons do…we re-invent the wheel and do it all ourselves… The goal is to write an introduction to Angular from my point of view, which means from the point of view of a person who normally works with C# building ASP.NET MVC applications as well as XAML-based applications. I have a background in building web applications, but more from a ASP.NET side of things than from a client-side.
Before we go anywhere at all, I just want to highlight that I am in no way involved in building AngularJS. I will describe things as I think of them, bot necessarily in in the way that they are implemented. The goal is to explain how I think about it when I build things, and how that, however wrong it might be technically, helped me to get a grip of what and how I can do things in Angular. Makes sense…? I hope so…
Ok, with my customary disclaimer out of the way, I guess it is time to start looking at Angular. But before we start looking at how to use Angular, I think we need to have a look at what Angular actually is… AngularJS is, a JavaScript framework that is built to help developers build what is called “Single Page Applications” or SPAs. SPA, is just a fancy way to say that you are building functionality on a single page, using HTML and JavaScript instead of spreading it out across multiple pages and using server side computing. This way, we can offload a lot of the computational work to the client, and at the same time give them a more responsive feeling. More of an “application” than a website if you know what I mean. It has many upsides, as well as a bunch of downsides.
The main downside when building SPA style applications is that most cases they are more or less impossible to get indexed by search engines. It is possible to get around this, but it is something to keep in mind. Hopefully, in the future, the search bots will learn how to handle SPAs, but for now, they don’t as they don’t run the JavaScript on the page. But it is also important to realize that it might not actually be such a big problem. Unless you decide to build your whole site as a single SPA.
Imagine a e-commerce site… You would want all of its product pages and so on to be indexed, and thus should probably not do the product catalog as an SPA. To be honest, those pages should be built as indexable as you could possibly make them. However, there is very little gain from building that part of the site as an SPA. The check-out on the other hand, is a different story. The check-out is a multi-step, complicated process with a lot of logic. This is the kind of thing that SPAs were invented for. However, you don’t really want that part indexed, do you... So it might not actually be a big problem…just saying…
When building applications, you need a way to work with data. It is all about data, and logic around that data. And when building applications, that data needs to be put into controls such as textboxes, checkboxes, radio buttons and so on. The data is then manipulates using these controls, and the changes made to it needs to be handled in some way. In “old school” web development, that would either mean posting it to the server for handling, or handled client-side using changed events and event handlers. Using Angular, this is all handled by data bindings. This means that Angular will, with the use of magic, unicorns and pixie dust, take data that you have and put it into the different controls you have in HTML. It it will also make sure that when the user changes the values in those controls, the changes will be propagated to your models. Two-way data binding is the core of Angular, and a bit part of what makes it so extremely useful.
On top of the awesome data binding support, Angular also offers a whole heap of other features such as dynamically loading views, dependency injection, animations, messaging etc.
I won’t talk about all the features for obvious reasons, but I want to highlight one more hero feature in this post. One that, together with two-way data binding, is enough to get your SPAs going. There are other features in Angular that are great, but data binding and dynamic view loading, which is that other feature I want to highlight, is all you really need in my mind. Dependency injection and messaging and animations are all neat features, but you get extremely far with just data binding and dynamic view loading.
Being able to load views dynamically means that the user can load up different UIs without having to round-trip to the server, making it feel as if he/she is, but without the flickering. This is why it is called an SPA. You do everything in a single page. However, as mentioned before, you don’t need to build your entire application as one page. You can pick parts of your site that should work like this, and basically have several small SPAs in a bigger application.
A note is that you often actually load the dynamically loaded views from the server, but your don’t post the whole page to the server and get a completely new page back. So even if you aren’t “round tripping” to the server, you are still involving the server. But in most cases you just use it to serve up static content, and thus use VERY little resources on the server. And if you want to, you can even include the views in you JavaScript instead, ignoring the server completely when loading new views.
There are 2 main ways of dynamically loading UIs in Angular. Both work in the way that you designate an HTML element that will host the dynamically loaded UIs. The difference between the two ways is in how you tell Angular what to load. You can either data bind the Uri to the view to load, and Angular loads it into the designated HTML, or you can use what is called “routing”. When using “routing”, instead of telling Angular what view to load from code, you uses the browsers to do it. You basically tell the browser that you want to navigate to a new view, and Angular will handle that and load the new view. That way you can create bookmarks and interactive links in your application.
The fact that things like routing is built in, is partly what sets Angular aside from other frameworks like Knockout.js. Knockout has the data binding covered very well, but you have to get other frameworks to get the other features. If you want routing, you need to find a framework that handles routing for you. If you want animations, you need to get another one that handles that. And if you want dependency injection, you need to get yet another one. You get the point… I think this makes Knockout a bit more complicated to work with as a n00b. On the other hand, it makes it VERY flexible. It means that you build up your own custom environment by combining several other framework, which enables you to get an environment that suits your programming style perfectly’. But, if you don’t know exactly what you want, it will take some time to figure it out. With Angular, it is a lot more of a “take it or leave it” situation. You can obviously switch out parts if you want to, but by default, it is very opinionated in the way things should be done. So if you like it, you probably like it a lot, and if you don’t like it, you probably hate it. But if you come from a XAML/MVVM background like me, I am pretty sure you will love it!
Ok, that is a not too brief look at what AngularJS is, and what it does… The next part is about getting started. What you need, how to start and so on.
Take me to the code! Take me to the next part!