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:
Immediately I am thinking, “I know that regular JavaScript (or ES5) doesn’t have an import keyword, so this must be using a library with some build tools involved to make it all work.” Not to my surprise, this turned out to be an understatement.
I assumed at this point that there was ES6 involved, but then I noticed that they were referencing something called TypeScript as well. Curious!
As it turns out, using TypeScript to develop Angular applications as suggested by Google allows us to actually use some features which are not scheduled to exist in JavaScript until ES7. And just think, today’s browsers do not even fully support ES6 yet!
This is truly a futuristic JavaScript development setup for someone like myself coming from an ES5 background, but with some wrangling we can actually get our apps to run reliably in today’s browsers. However, the advanced workflow and language requirements make Angular 2 much more difficult to get up and running when compared with Angular 1.
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.
Although importing modules in ES6 does strike a familiar chord based on my experience with the module.exports and 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 @ symbol.
Suffice it to say that seeing an @ symbol in JavaScript code was a surprise for me. I tried using it directly in my browser console in a few different ways and found quickly that browsers don’t like the @ 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 class feature, and this has proved to be much more fertile ground for incorporating decorators. Still, to truly have native JavaScript support for the style of decorators used within Angular via TypeScript, we’ll have to wait until ES7.
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.
Conclusion
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.
If you are interested in exploring Angular 2 further, I recommend starting with the JavaScript Quickstart as opposed to the TypeScript Quickstart. In my experience, seeing how it all works in ES5-land was extremely helpful to do before using all of the futuristic enhancements which I still have not fully learned yet.
As a caveat, I found a few gaps (and downright errors) within the JavaScript Quickstart guide as I worked through it. I believe this is due to the rapid pace of Angular’s evolution as well as the fact that the documentation does not place the pure JavaScript examples as a high priority. So leave a comment if you get stuck! I was able to work around some of the errors, so I may be able to help.
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