If you’re debating upgrading an Angular 1.5.x application to Angular 2.x, here are things to consider.
Barry Kern | January 6, 2017
I recently worked on upgrading an Angular 1.5.x application to Angular 2.x for a client who was invested in product development using Angular but wasn’t sure which version to use. The central question was, “Do we favor stability and the wealth of community experience and go the 1.5.x route, or do we move into the newer but more unknown world of version 2?”
Nearly all teams discussing the future of their 1.x application are going to eventually question if they should upgrade. But there isn’t a one-size-fits-all answer. Here are some important things to consider when you’re making the decision.
There are a lot of configurations and dependencies you need in order to start an Angular 2 project, and I love that they make this easy. Similar to Facebook’s create-react-app tool, the Angular team has introduced Angular CLI. The CLI is still in beta, but I was able to fully use it, and I enjoyed having webpack there with hot-reloading enabled out of the gate.
The things I struggled with for some of the other boilerplate projects replicated the struggles I saw in the community. Particular challenges were finding projects that were up-to-date with the latest Angular 2 release, and figuring out which flavor made sense for my needs. With so many variations in tooling and technologies—like ngrx, HMR, Webpack DLLs, AoT Compilation, and sync/lazy loading—it can be tricky to wrap your head around which is best.
I watched some training videos on egghead.io and Pluralsight for about half a day before I started to code in Angular 2. I found that knowing Angular 1 concepts already helped me with Angular 2. See the quick reference for a side-by-side comparison of concepts.
I thought Angular 2’s template syntax was much clearer than version 1 in showing the differences between input/output and one-way vs. two-way binding. Once I learned the syntax, I was able to comprehend it quickly.
Wow, this was a curveball. Initially, I seriously questioned why they would add the complexity of RxJS to the Angular 2 framework, and wondered what good it does to return an Observable instead of a Promise. To be honest, you aren’t forced to make use of this library (for the most basic or simplistic applications it may not add much value). However, once I started really diving deep into Rx, I was amazed that I had accepted my current toolset for so long without learning it.
The power of Rx is hard to put into a few words. It not only enables some things not currently possible with Promises, but it also makes many familiar tasks easier through the use of its bread and butter: the operators. My best advice is to spend some time really learning Rx and slowly introduce it into your app. It takes time for this new way of thinking to set in, but the power it gives you may add value in data-heavy applications.
As a language, I’m a bit disappointed in TypeScript. My disappointment comes from knowing more advanced type systems and wishing more power was available to the developer. However, having the ability to use types in your project is still a nice boost. It’s much easier to know what data you’re working with, and I found it very helpful to see what methods and functions I could call them. Additionally, many third party libraries have community-developed-type bindings available, which give you the same benefits.
Once I figured out how to do some unit testing, I liked how much cleaner Angular 2 testing was in contrast to Angular 1. I still ran into ceremony when testing components, but overall the experience is improved in version 2, and you can more easily concentrate on writing tests.
Pipes are a bit of special case, because they’re just classes and don’t need lots of Angular inner workings to be unit tested. But I appreciated how clean and easy to read it is.
Given Angular 2’s rapid change of pace, having real-time help is invaluable. I found great help in the official Gitter, which is frequented by many active contributors. I also found no matter how complex of an Rx question I thought I had, help was always available on Stack Overflow.
It’s a given for blogs and websites to be somewhat outdated based on how fast things have been changing and how long Angular 2 was in beta/RC stages, but you can still dig through them to see if you can port some of their syntax/ideas to the current version. Also, the video content on paid sites like egghead.io and Pluralsight is generally great at calling out when their examples apply to an earlier version of the framework, showing the necessary differences, and keeping their associated Github repositories up-to-date.
Along the same lines as tutorials, an important resource for developers is Stack Overflow. If you’re running into a problem, chances are someone else has dealt with something similar and it’s been asked on this site. Again, the accepted answer may or may not work for the current version of the Angular 2. I found it hit-or-miss trying out given solutions in my local environment.
I needed to put in some serious time watching tutorials and reading to get up-to-speed on Rx. Having a functional programming background and some prior very basic knowledge of Rx was helpful, but even some experience with chaining operations in lodash will help out.
I also learned that it’s important to evaluate if Rx makes sense in context; don’t attempt to “Rx all the things.” Most importantly, it just takes time. Try to start with something that works, and clean it up later.
Some libraries existed in versions that were compatible with Angular 2, but some didn’t. Given my time frame, I had to abandon projects that weren’t compatible with Angular 2.
In its current state, I think community knowledge of Angular 2 is not as plentiful as it was when Angular 1 started being adopted heavily. I always referenced John Papa‘s work with Angular 1 (including his ubiquitous style guide), and I was happy to see his style guide for version 2 has become part of the official documentation. Even so, I struggled with some pieces of the architecture. For example, it was still a challenge to determine the best approach to managing state in my application. I found a few different ways to accomplish my goal, and I was happy with what I produced, but it was still challenging to find existing implementations to review.
For state management, I also found some of the suggestions to be topics for study themselves, like ngrx/store and ng2-redux (Redux-inspired frameworks for Angular state management). I do believe that given more time for Angular 2 to be out in the wild, perhaps I could have found more community knowledge on this topic. I definitely think the Redux pattern is a strong contender—and in my opinion a lot of JS applications are moving that way—but I’m curious specifically if the Angular 2 community will swarm to this paradigm like the React community has.
You need to think about how ready your current team is to adopt a range of new technologies. There are a lot of new things in Angular 2: TypeScript, RxJS, ES6, potentially new build tools/processes, as well as state management or other advanced features. Are your team members comfortable with experimentation, using technology in the early adopter phase, and struggling to solve issues with no easy answers?
It’s not the easiest task and is sure to create some confusion on your journey. Could you avoid Rx completely? If you’re determined not to use Rx, you can still get around it if you’re prepared to encounter some bumps along the way—however, you’d be missing out on a lot of power. I think this tool will not only have a profound impact on Angular 2, but on many other frameworks as well.
Since Angular 2 is still early in its journey, a lot of best practices and ideas are still being developed and iterated-upon. As the community moves forward, we might learn some valuable things, and you may (or may not) want to update your initial implementation to take these into account.
For full disclosure, TypeScript is not required for Angular 2, however a vast majority of documentation I found was TypeScript-based. Angular lists Dart and ES5 as viable alternative options, but you will really be on your own with these approaches.
Considering TypeScript, I think it’s important you start a project with clear direction on the use of the language. How are you going to use types in your project? How strict will you be in your typings? I ran into many tutorials using TypeScript but exposing Any which doesn’t really do anything for you in terms of type safety.
One downside of optional typing: the developer can choose to opt-out anywhere. Do you want to allow that? There’s nothing wrong with using Any, but I think it’s important you agree as a team on what your policy and expectations will be.
This is certainly an individual question for you or your enterprise to decide based on a variety of factors. It’s early in Angular 2’s journey and the verdict is still out. There’s definitely some community adoption already, but I don’t know how much enterprise adoption is currently happening. Jumping on something in this early adoption phase has both pros and cons.
If you’re seriously considering the jump in the short-term, it would be valuable to get a couple developers started as soon as possible. Start on a smaller scale, perhaps with some new project you always wanted to build, or even port a section of an existing app (but be sure to include more than one page, some routing, some server interaction, some unit testing, and some shared state). This will help you better clarify a vision for how you can move forward and figure out where there are gaps for your organization.
It’s still early to determine if Angular 2 adoption will equal that of Angular 1 and what the success of the new version will be overall. The question of whether to wait or to upgrade now is complex, and I hope this post has pointed out some things to think about. I enjoyed learning Angular 2, and even though it’s not my personal preference, I think it’s a very viable modern web framework. I’m curious how web developers and enterprises will adopt it.
Our engineers have a whole lot to say about custom software. They’re in the trenches every day, building, breaking, re-building, and sharing their hard-won wisdom along the way. Find their latest and greatest discoveries on Slalom’s new software engineering blog.
Barry Kern is a solution architect with Slalom's Cross-Market delivery center in Chicago. He uses his significant experience in front-end and back-end development to help clients with custom software architecture and engineering. Reach out to him on Twitter: @_bkern.