I have heard from various sources that Angular 2 is a complete re-write of Angular 1, but I did not believe it until I tried it. From Angular to Angular 2, (almost) everything has changed.
Language – From js to ts
Angular started out as JavaScript front-end framework, but Angular 2 was not built for JavaScript.
Although the official documentation has a section for using Angular 2 with JavaScript, both guide and tutorial are currently empty:
The only place where you can find JavaScript support is in the QuickStart guide. This is not helpful when the end product of that guide can be easily created as a static HTML page.
Instead, Angular 2 has chosen to partner with Microsoft and embraced TypeScript (along with support for Dart) as the official language. Proof:
I don’t really have a problem with learning and using TypeScript. In fact, I enjoyed the TypeScript presentation given by Anders Hejlsberg. Having been using TypeScript for a few days, the experience was good. The syntax is very intuitive and it just works. Also, the plugin integration with Sublime Text 3 is very polished, with syntax highlighting and built-in linting.
However, that does not excuse you from release the framework without proper documentation on a language that you claim to support.
You may ask, “since TypeScript is a superset of JavaScript, why can’t just use JavaScript following the TypeScript guide?” Well, in theory you can. However, in practice, with guides, tutorials and perhaps more importantly libraries all using TypeScript, you will have a hard time understanding them or using them with plain-old JavaScript. For example, if a library defines an API function with types, or class with typed attributes, you have no choice but to stick to it.
So, be prepare to learn TypeScript if you want to use Angular 2.
Architecture/Module – From AMD to ES6
Although the general idea of modularization is still there. The implementation of of modules has changed drastically. Angular 2 2 with TypeScript has adopted the official ES6 module syntax, with keywords import ... from ...
and export
. This is different from the Asynchronous Module Definition (AMD) syntax used in Angular 1.
So what’s the big deal? It just a syntactic different right?
Well, not exactly. With ES6 module syntax, you only took care of the compilation dependency, as the variables and references can be solved by whatever loader/builder you are using. But Angular 2 requires dependency to be resolved in an additional way, through declarations and dependency injection.
To illustrate this, consider adding a service called AgendaService to a component called AgendaComponent. You have to do 3 things:
1. Import
You have to write the path to the file for every single file that depends on the service. In this case, for the file that contains the AgendaComponent.
1 2 |
// in file containing AgendaComponent import { AgendaService } from '../agenda/agenda.service'; |
2. Dependency Injection
You declare an instance of that service in AgendaComponent:
1 2 3 4 5 6 7 |
export class AgendaComponent { constructor( //... private agendaService: AgendaService) { } //... } |
3. Declaration
You have to declare the service on either component or module level. For simplicity, I think people are just going to do it in root module AppModule:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
@NgModule({ imports: [ //... //dependencies that are modularized and not part of core angular 2 ], declarations: [ //... //all the components go here ], providers: [ AgendaService ], bootstrap: [ AppComponent ] }) export class AppModule { } |
Oh wait, we forgot to import it before using it in our root module…
4. Import (Again)
1 2 |
// in our root module app.module.ts import { AgendaService } from './agenda/agenda.service.ts'; |
Now, compare those steps with Angular 1, where I can just use AMD and add another argument to the controller function:
1. Dependency Injection (AMD, Angular 1)
1 2 3 4 |
angular.module('AgendaApp.controllers') .controller('AgendaCtrl', function(AgendaService) { // my controller logic } |
Of course, you still need builder/bundler to compile the souce-code and declare it in HTML file, but that can be automated easily. The point is, developers need to go through a lot more steps to the get same thing done in Angular 2. And that would likely cause frustrations when people start moving from Angular to Angular 2.
Filters – Renamed to Pipes
Filters are longer there, instead, we have pipes. They work in exactly the same way, except the usage is different.
Basically, the filters in Angular 1 are considered impure pipes, which requires checking within the objects, such as change in object properties. These operations are expensive and degrades user experience. Hence, they are not built-in with Angular 2. Instead, you are encouraged to use the pipes that are pure pipes, which only checks for changes in primitive values and object references.
In order to bring back the functionalities of the original filters, you are supposed to move filtering and sorting logic into the component itself, instead of relying on pipes to perform the magic.
Or, you can consult the community and get back the original filters ported to Angular 2 pipes.
Other changes
No more Controllers and Promises
Controllers (together with beloved $scope
, controllerAs
), factories, they are removed from Angular 2. So now you only have 4 main building blocks to choose from:
- Components (recommended, through
@Component
decorator) - Services (through
@Injectable
decorator) - Pipes (optional,through
@Pipe
decorator) - Directives (optional,through
@Directive
decorator)
Promise
is also removed from Angular 2, replaced with new Observable
, from rxjs. It is promised to be better:
While promises may be more familiar, observables have many advantages. Don’t rush to promises until you give observables a chance.
Syntax Changes
There are lots of minor syntactic changes here and there that makes you wonder why. For example, ng-repeat
has been changed to *ngFor
., ng-if
becomes *ngIf
. And they now have a name, structural directives. Yes, there is an asterisk for a reason, omitting it gives you errors!
Decorators
Angular 2 embraces the concept of decorators. Instead of defining templates and styles within the component logic, you use decorators before the component to specify them as metadata. I don’t see how it is different from a developer’s perspective other than a syntactic sugar. But perhaps there are advantages for using decorators behind the scenes, like ensuring backwards compatibility…Okay, ignore what I just said.
Migration Guide?
In fact, there is a dedicated section on how to upgrade from Angular 1 to Angular 2. But given the complexity of legacy Angular 1 projects and the minimum similarity between the 2 versions, I doubt anyone would do that.
Conclusion
Indeed, from Angular to Angular 2, almost everything changed. Is it for the good or made it worse? It is still too early to tell. But one good way to find out is to try it on your own.
Cover photo from http://www.shibajidebnath.com/2016/06/20/angular-1-vs-angular-2/