Angular 2 is almost here. It’s currently in the mid-release candidate phase, and the web is buzzing with excitement. However, there will be many groups of people – development teams, contractors and tech leads – that are both excited and a little unsure of what to do next – and those people are the Angular 1.x codebase kind.
Rest assured, you have options and in this article, I’m going to drop some thoughts on general upgrading to Angular 2 and what you/your team can do to prepare.
"We need to start upgrading our codebase to Angular 2 right now, everyone is!"
Hold fire, dear friend. Let’s take a step back and consider some options first. There are companies that live on the bleeding edge, and there are many that don’t – probably tenfold that don’t. There are many of us who lead the life of the bleeding edge to bring others new content, tutorials and start to introduce new concepts or frameworks such as Angular 2 to the web.
So, you might ask, when shall I start upgrading? For me, it’s not about using the “coolest” and “latest” technology (always), it’s about being smart and timing it right.
Now, my thoughts are completely speculative, and you may agree or disagree, however I think there will come a time when Angular 2 is ready for your business. That time might be tomorrow, the next day, or at the end of the year – and that time is 100% your decision, nobody else's.
The decision to upgrade to Angular 2 is a big one, and should be a team effort. You should feel comfortable working with Angular 2 before building an application for production with it, it only makes sense this way.
We all jumped into building right away with Angular 1.x, and made a lot of mess – but had a lot of fun at the same time! Angular 1.x matured and now leads a path to Angular 2 through latest features such as
.component(), one-way data flow and the lifecycle hooks, mirroring many of the concepts and design patterns we now see in Angular 2.
So why Angular 2?
For me it’s all about where you want to build for. Many companies nowadays cannot build simply for just the web. The web is fantastic, but it also slows us down in distributing codebase to run on multiple platforms. This is where Angular 2 shines.
If you’re building purely web-based apps, then your desire to shift from Angular 1.x to 2 might not be as strong as companies that build solely Angular 1.x and native applications, or even desktop applications too. If you’re wanting to share your codebase for mobile, desktop, then you know where to go.
I’m a firm believer that you and your company should upgrade at the "right time", and that right time differs from person to person, company to company. There is no “rule” here, it’s what is best for you.
If your company or you love trying out the latest and greatest, then by all means jump into Angular 2 and get a taste of what’s it like! Angular 2 is extremely exciting, and I’m super excited for a stable release in the coming weeks/months. If you’re fortunate enough to invest some development time into making a prototype, testing the Angular 2 features, and comfortable with TypeScript and RxJS – then you can dive in and get started pretty fast.
For others, the business decision to migrate to an entirely new framework comes at a cost from things like:
There are likely many more factors than those listed above, so well considered approaches are a must. Angular 2 is big, it’s powerful, but it’s not something you can migrate a team to over a weekend with some pizza and beers.
So, the time has come for your team to start seriously considering the upgrade. It doesn’t matter if it’s now, tomorrow or at some point next year. Angular 2 won’t be going anywhere, so focus on your customers, current project commitments, those new features you’re implementing and consider ways to start integrating the future of Angular.
So, how would I approach this? Current codebase assessment.
You need to focus on your current codebase, and ensure you’re upgrading to the latest version of AngularJS. I speak to many folks at conferences that are still using Angular 1.2, for business and customer reasons, and that’s okay – their transition will take a little longer, but they’ll get there. For others on 1.3 and above, your legacy IE days are over and you can make the jump whenever you’re ready.
Before you even contemplate migrating to Angular 2, I highly suggest that you hit my checklist:
.component()with a component based architecture
If you need help with these things, check out my ES2015 and Angular 1.5+ styleguide to help with your future migration.
So, why all these things? One by one:
.component()maps nicely to Angular 2’s
The time has come for your upgrade, so what next? Do I go module by module, view by view, or do we go for the "big bang" approach?
If you have the development power, then your approaches to upgrading may differ than a really small team. A smaller team may replace module by module, slowly replacing (for example), a home view with an Angular 2 version, and then redirecting further views to the legacy application. This approach is interesting, because it at least gives you time to learn Angular 2 in an isolated project rather than diving into the unknown and attempting to replace all your application with Angular 2 immediately.
There is an alternative approach to upgrading to Angular 2, using the upgrade adaptor. The adaptor allows you run Angular 1.x and Angular 2 in parallel, upgrading components one at a time. This might be a good approach, but it entirely depends on the state and design of your codebase, there is no silver bullet. Seeing as the
.component() method and many of the new features have only been available for a few months, it’s likely many codebases will be running older versions of Angular that are using template views over a component-based structure.
The "big bang" approach is also another interesting approach, and I can’t give you the answer as to whether it's right for you. The big bang approach may be a sensible option depending on the development team size, where you can you make the decision to split your team’s effort to maintaining the Angular 1.x application whilst the new Angular 2 project is in flux.
My suggestion? Get your codebase right, replace module by module. You’ll have fuller understanding of your codebase, make necessary time for refactoring (an extremely important part of the development cycle) and gradually get your team, application(s) and knowledge across to Angular 2.
A few weeks ago, I released the Angular 2 migration guide – a project I’m working on here at Telerik. I’m extremely excited about it and am lucky enough to be able to help the community out. We’ve called the project ngMigrate, where you can visit particular things in Angular 1.x that you already know, such as passing data into a Directive/Component, and it’ll teach you the Angular 1.x way, followed by the Angular 2 way. It’s a work in progress as there is a vast amount of material to cover.
If you’re also interested in contributing a migration guide, I’d love to hear about it!