The Road to Angular 2.0 part 6: Migration

Intro


I gave a presentation at the GOTO conference in Amsterdam titled: The Road to Angular 2.0. In this presentation, I walked the Road to Angular 2.0 to figure out why Angular 2.0 was so different from 1.x.

This series of blogposts is a follow up to that presentation.

Migration


Last week we discussed the new bindings system in Angular 2.0, and we saw that by using trees Angular 2.0 applications use less memory and are faster than before.

In this final instalment of this series, we are going to look at how we can migrate our Angular 1.x applications to Angular 2.0.



The road to 2.0


How do you migrate an Angular 1.x app to Angular 2.0?
migration-questionmark

The answer you might hope for is running some magical wizard in some fancy IDE that will take care of the process for you. Does such a magical solution exists? The answer, unfortunately, is no. There is no easy way to migrate your applications without doing some work yourself.

Here is a video from the ng-conf showing how you can migrate code from Angular 1.3 to Angular 2.0. It is worth a view and shows the manual work required to upgrade an Angular application.

A tale of two roads


The Angular team states that there are two roads to migrate an Angular 1.x app to 2.0: Big Bang and Incremental.
migration-options


Big Bang


Big Bang is a migration path in which you halt all development on an application, and migrate an entire application to Angular 2.0 in one Big Bang.

The biggest benefit of a Big Bang migration is that it is the fastest way to get to Angular 2.0. This means you can use al the cool new features such as components, TypeScript and the new Template syntax as soon as possible.

Big Bang has a couple of drawbacks: first it might be difficult to convince your manager or product owner to freeze the product you are working on. Performing a Big Bang migration whilst the application is changing underneath your feet is not something I would recommend. So it is imperative that the application is frozen so the target does not move. Trying to sell this to your manager / product owner is going to be difficult.

The second drawback is that the size of your application determines how easy it is to pull a Big Bang off. The larger your application the more time it will take to perform the Big Bang. The more time it takes to perform a Big Bang the more difficult it is to get the application freeze approved.

The third drawback is that when you rely on third party libraries such as: ui-bootstrap or restangular, you will have to wait until they've upgraded to 2.0 as well. This means that you cannot perform a Big Bang until each and every one of your dependencies has upgraded to 2.0. Of course you could work around this problem by dropping a dependency and writing it yourself, but this can be a lot of work, especially if your application has "big" dependencies that do most of the work in your application.

Incremental


Incremental is a migration path in which you update parts of your application with Angular 2.0 code, and keep parts of your code Angular 1.x code. This is possible because you can run Angular 2.0 applications and 1.x applications side by side.

You can do this in two flavors: either you have an Angular 2.0 app which includes Angular 1.x app, or vice versa you have an Angular 1.x app which includes an Angular 2.0 app. This gives us the freedom to mix and match Angular 1.x and 2.0 as we please.

For example: we can migrate everything from controllers to services to Angular 2.0, and keep some select directives Angular 1.3 such as ui-bootstrap. Another example is that we stick to Angular 1.x for our controllers and services, but write al of our new directives with Angular 2.0 components.

The benefit of Incremental is that we have a lot of flexibility in how we migrate our applications to Angular 2.0. Just like the Big Bang migration path Incremental also has some drawbacks.

The first drawback is that you will bundle Angular 1.x with 2.0, this means that the browser will have to download two complete frameworks, and parse two complete frameworks, this will impact the performance of your application negatively.

The second drawback is that having two frameworks, Angular 1.x and 20, with two very different philosophies,  will make  your code will look like a Chimera, a strange hybrid that is stuck between two worlds, not a pretty picture. The only way to fix this is to eventually migrate to Angular 2.0 completely.

Big Bang vs Incremental


The question you might ask so which is better Big Bang or Incremental? The answer is that it depends on the nature of your application and your projects circumstances. Here is a decision matrix:
angular-path-matrix

Basically the matrix states that the smaller your application is the more Big Bang makes sense. This is because the time it takes to perform a Big Bang is directly related to the size of the  application.

Another facet in the decision is how many dependencies the application has. As stated before you can only upgrade to 2.0 completely when all your dependencies have upgraded. However some apps are more dependant on external dependencies than others, if you for example depend heavily on some big external Google Maps directive, it might make sense to wait until that directive has updated, and do an Incremental upgrade instead.

The last facet of the matrix is the time you can "get" to migrate to Angular 2.0. This is really a circumstance which is more political than technical, it depends on management. If you get oceans of time to migrate, Big Bang makes more sense, if there is a focus on new features Incremental makes more sense.

Preparing for 2.0


There are steps you can take to prepare for an migration to Angular 2.0. The closer you can get your 1.x application to the 2.0 philosophy the easier it is to migrate to Angular 2.0.

Stop using $scope


In Angular 2.0 components will no longer have a '$scope', instead the instance of the component's controller will become the scope. To prepare for this change I recommend that you use the "controllerAs" syntax. This way you won't have $scope's that need to be removed when you migrate to 2.0.

Upgrade to 1.4


Upgrading to 1.4.x: the latest stable version of Angular is a good step to take. Upgrading to 1.4 will make it easier to migrate to Angular 1.5, which brings me to my next point.

Upgrade to 1.5 when it is released


The goal of Angular 1.5 is to make migrating from Angular 1.x to 2.0 easier. What the exact nature of these features are is still in flux. One feature that I'm personally rooting for is the "component helper" function. This will make it easier to write directives that mimic Angular 2.0 components. By mimicking Angular 2.0 components Angular 1.5 will be closer to the philosophy of Angular 2.0, being closer to the Angular 2.0 philosophy makes migrating easier.

Start using ES6 today!


Using a transpiler such as Babel you can start writing ES6 today. A transpiler transforms ES6 code to ES5 code, so you application will run in todays browsers.

The biggest benefit of ES6 is that it allows you to write "classes", Angular 2.0 will heavily rely on classes, Components are classes for example. By using classes to define services and directive's controllers you have already done some of the migration work.

The new Component router


Angular 2.0 will have a new built in router called the Component Router this router will, as its name suggests, routes on components, it will instantiate a component based on the current URL.

The nice thing about the Component Router is that the router will be back ported to Angular 1.5. This means you can start using the new router in 1.5 and when you upgrade to Angular 2.0, migrating your routes is already done.

If you use ui-router today instead of ngRoute, you might want to read up on the differences between ui-router and the Component Router.

Note that the Component Router was called the ngNewRouter until a couple of months ago.

A new Hope


At the AngularU conference key Angular core team members gave a keynote in which they announced that Google has some internal tools to make migrating easier. They are in the process of evaluating which tools are useful to release to the Angular community. There isn't much information on these tools so there isn't much more to tell you, but there is some hope that migrating will easier, and more importantly partly automated.

Starting new projects


I've often received the following question: "I'm starting a new project, should I wait for Angular 2.0, or should I start in Angular 1.4?" The answer is to just start using Angular 1.4, and migrate to 2.0 later.

The reason for this is because Angular 1.x is not abandoned , in fact it is quite the opposite. The Angular team has been split into two teams: one team for 2.0 and one team for 1.x. The 1.x team even has a new project lead: Pete Bacon Darwin, so 1.x if far from abandoned. With Angular 1.5's focus on migration from 1.x to 2.0, starting on 1.x and migrating to 2.0 will mean some work, but it will not be the end of the world, and if you follow my advice on preparing for 2.0 you will make migrating easier.

Another reason not to wait for angular 2.0 is because it still doesn't have a release date, in fact there isn't even a beta available yet. Hopefully we will learn more at the AngularConnect conference in London in October, hopefully they will announce something more concrete than: "it is done when it is done".

Conclusion


Now you know the somewhat painful truth that migrating from Angular 1.x to 2.0 is not going to happen by a click of the button. We have seen that the Angular team has put together two migration paths: Big Bang and Incremental. A Big Bang migration get your project to Angular 2.0 as quickly as possible. The Incremental migration allows us ton combine 1.x and 2.0 in the same application, so we can migrate step by step.

We also know that we can prepare for Angular 2.0 by using a transpiler such as Babel to start using ES6 classes in our Angular applications today.  We should also upgrade our applications to the latests Angular 1.x version that is available, because that version is closest to Angular 2.0.

The final takeaway of this blogpost is that Angular 1.x is not going anywhere anytime soon, it is still actively being maintained, and the community is still alive and kicking. So starting a project in Angular 1.x and migrating to 2.0 later is a valid strategy.

I hope you enjoyed this series of blog posts and found them informative. Hopefully Angular 2.0 gets released soon, I think it will be a great leap forwards for us the Angular community.