In the past year or so, I have been learning AngularJS (aka Angular 1) and have found it intuitive and enjoyable. I used it on a few different projects, both for clients and for fun.
When I first began looking into Angular 2 (aka just plain Angular as opposed to AngularJS, which is now a synonym for Angular 1), it was…confusing to say the least.
I found Google’s Angular Quickstart guide to be informative and helpful after getting to know it a bit. But I also found it extremely terse, often lacking the detail I would expect.
For example, the first line of code I see for their sample Angular app is this:
I assumed at this point that there was ES6 involved, but then I noticed that they were referencing something called TypeScript as well. Curious!
Modules Demystified, Kind Of
As noted about the single line of code above, I wasn’t sure where the
import syntax was coming from (was it from ES6 or TypeScript?), and I definitely did not see a folder called
@angular/core anywhere to import things from.
I soon learned that the
import syntax is a feature of ES6 and is part of its module system. Not knowing this beforehand, though, I was scratching my head from the get-go.
importing modules in ES6 does strike a familiar chord based on my experience with the
require syntax from Node.js, I felt like a few words were missing from the Angular Quickstart guide to explain how Google expects us to run this code in today’s browsers. And remember, this is the first line of code in the first introductory example!
It turns out that even by ES6 standards, the use of modules has horrible browser support. Of course, this means we have to rely on another tool within our workflow (in this case, Google recommends a library called SystemJS) in order to get the module loading to work.
Using Decorators in ES5 and Beyond
Unsure initially if I was seeing an ES6 standard or a TypeScript standard being implemented via the
import keyword, I tried my best to move on to the second line of code and not worry too much:
OK, let’s forget for a second about the fact that we have a class which has nearly nothing inside of it. Reflecting on literally the first character in this code block, we see the mysterious
Suffice it to say that seeing an
@ much at all. “Illegal character,” my browser says. LOL!
It turns out that the
@Component syntax refers to something called a decorator, and this is a feature which (as used in this context) will apparently be coming in ES7 but which is currently available via TypeScript.
There is such a thing as a decorator in ES5, but the concept is not very commonly used from what I can tell from my basic research. With ES6 we get the
I do think that it’s worth looking into the history of decorators in ES5, as this gives a general idea of the concept we are working with. Thanks to Reg Braithewaite’s post from 2015, I was able to get some insight into the fact that decorators have been around for a long while. Really, they are just functions that modify other functions, classes, or class properties/methods and typically endow them with added functionality.
For example, consider the decorator below which I have named
warnMissingArguments, which modifies any given function by logging a message to the console if the function is called with fewer or more arguments than expected.
As you can probably tell, I learned a little bit about ES5 during this process (namely about the
arguments object as well as the
length property for functions). This was an added bonus which I expect to experience more of as I continue to scrutinize bits of Angular 2 code that I see in future examples.
The concepts of modules and decorators (not to mention the intermingling of ES6, ES7, and TypeScript) were themselves enough to derail any hopes I had of getting a solid grasp on Angular 2 without doing some serious background studying first.
One of the things I like about AngularJS (i.e. Angular 1) is that you can simply include the minified JS file containing the AngularJS library and you’re on your way. You can even bundle the file with your own code using any of the many build tools out there, and AngularJS goes along well with whatever workflow you have.
The bottom line is, AngularJS just doesn’t care too much about your development workflow, so you have the freedom to work it in however you like. However, it is clear at first glance that the Angular 2 framework has many preconceptions about the ideal workflow into which Angular can be incorporated.
Once you have a feel for how Angular 2 works from an ES5 standpoint, this page from the Quickstart guide can most likely help you to get set up with the npm modules that you will need to write and compile your own sample Angular 2 app using TypeScript.
Did you have a similar experience with getting up and running with Angular 2? Did I mess up any part of the explanation, leave anything out, or get anything wrong? Let me know in the comments!
Leave a Reply