If you’re like me, you’ve worked with Angular a lot or you are currently working with Angular and over time you have grown accustomed to its very concepts; controllers, directives, factories, providers and services. In Aurelia those concepts can exist, but not in the way you think. If you’re thinking of porting over an Angular 1.x application to Aurelia, below we will touch upon various concepts to make the transition as easy and seamless as possible.
So you’ve decided it’s time to join the future and port your existing Angular application to Aurelia. Your first port of call was probably the documentation and chances are you probably got confused, because Aurelia lacks the concept of a “directive” – don’t be discouraged my friend, there is light at the end of the tunnel. The concept of directives do exist in Aurelia, however they go by the names: Custom Attribute and Custom Element. In Angular 1.x, a directive can both be a custom attribute and a custom element. It is a confusing concept that fortunately has been removed in Angular 2.
Update 28/1/2016: This post was about Angular 1, it was published well before Angular 2 was even near ready for beta release. A bit has changed since then, but my thoughts on Angular in this post have not. For quite a long time developers have been using AngularJS. Coming at a time when the alternatives were the likes of Backbone.js (while powerful in its own right), which just didn’t tick all of the boxes a modern web application needs ticked, we thought we had reached developer nirvana.
As ES6 edges closer to evergreen browser support by the estimated mid–2015, many are wondering given the MASSIVE inevitable API breaking changes in Angular 2.0 if it is worth learning the current version of Angular (1.3 at the time of writing this). The fear around Angular 2.0 I think is overblown. While it will be a complete rewrite, your newfound Angular 1.x skills aren’t just going to go to waste, especially considering Angular 2.0 might not even be released until late 2015/early 2016.
One of the biggest bottlenecks in Angular 1.x is the $digest cycle. Essentially what the $digest cycle does is keeps track of two-way bindings, watchers and other parts of your Angular application that can be updated. For example if you have a text field using an ng-model, whenever you type in a value into this field, it will trigger a $digest cycle causing Angular to update all watchers and bindings in the app to see if anything has changed. This is because of the lack of object.observe() in ECMAScript 5 (although it is in ECMAScript 2016 (ES7) and planned for Angular 2.0).
In AngularJS when it comes to communicating between controllers, one would naturally assume to reference another controller you can simply inject it into another controller and call its methods: however, you cannot do that. Method 1: Shared service One such method of communicating and sharing methods betweens multiple controllers is a shared service. Here you might put in a method for closing a overlay or redirecting the browser somewhere or checking the state and value of a variable.
Chances are if you have been using AngularJS for a little while that you have come across $scope.$apply() at some point, whether it be your own code or someone else’s. What the heck is $scope.$apply() and why should you care? To understand why we have $scope.$apply we have to understand that Javascript is turned based. When you write your Javascript code, it does not run all at once, code is run in blocks. So it is possible when you change a value within Angular and a $digest cycle has already been run, your changes will not be seen.
The subject of global variables in most languages is enough to bring the most passionate code junkies out of the woodwork ready to debate and bite off your feet for even entertaining the thought. The reality is in a framework like AngularJS globals are warranted at times, but only if you implement globals the Angular way. But not globals in the way you know. Constants and values Out of the box, AngularJS supports global constants and values. Obviously constants are read only pieces of data and values are pieces of data that can change at any time, anywhere.
In the front-end framework race there are many contenders, but the one that stands out from most is AngularJS which is supported by Google. It simplifies the process of complicated and simple application flow, but when it comes to rendering many items (especially using ng-repeat) you soon notice AngularJS struggles. I will not bother posting my own benchmarks, as there is pretty conclusive proof out there you can find via a Google search. I love Angular, do not get me wrong, but it sucks for rendering lots of UI items, like for example a large catalogue of products comprised of; titles, descriptions, star ratings and a thumbnail image.
Recently the AngularJS team released a slideshow showcasing what we should expect when AngularJS 2.0 is released. It detailed that controllers, directives and AngularJS as we all currently know it will be changing, with the aforementioned features being removed. Some people are excited and others are naturally freaking out. The steep learning curve of AngularJS means that some have had to struggle and learn harder than others to get to the point they are at now and when 2.0 is released, it will be an entirely new framework.