Angular 2: Ready for Primetime?
by Barry Kern
To upgrade or not to upgrade
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 were uncertain on which version to use. The central questions tended to be “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?”.
There isn’t currently a blanket answer to this question which fits every developer and enterprise, but I learned a lot from the experience, and wanted to share some things I think are important in coming to a decision. I think this is an important topic because the popularity and wide adoption of Angular 1 (especially at the enterprise level) will sooner or later lead nearly all teams who are discussing the future of their 1.x application to question if they should upgrade.
Things I liked about Angular 2
Angular CLI / many existing boiler plates
There are a lot of configuration/dependencies etc. you need 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, however I was able to fully utilize it and 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 that 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 such as ngrx, HMR, Webpack DLLs, AoT Compilation, and sync/lazy loading, it can be tricky to wrap your head around which is best.
Knowledge of version 1 made the transition easier
I did watch some training videos on egghead.io and Pluralsight for about half a day before I started to code in Angular 2. I found knowing Angular 1 concepts already helped me with Angular 2. See the Quick Reference for a side-by-side comparison of concepts.
Clearer syntax in templates relating to data binding
I thought Angular 2’s template syntax was much clearer than version 1 in showing the differences between input/output and 1-way vs 2-way binding. Once I learned the syntax, I was able to comprehend it quickly.
Rx (Reactive Extensions Library)
Wow, this threw me 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 just 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, it also makes many familiar tasks easier through 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.
TypeScript / library definitions
As a language, I am 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/functions I could call. Additionally, many third party libraries have community-developed type bindings available which give you the same benefits.
In the above example I am injecting the Router component from Angular 2. By using TypeScript I can instantly see more information than if I had used untyped JavaScript.
Testing
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 I feel like the experience is improved in version 2, and you can more easily concentrate on writing tests.
Pipes are a bit of special case in that they are just classes and don’t need lots of Angular inner workings to be unit tested, but I appreciated how clean and easy to read this is.
Help available in Gitter/Stack Overflow
Given the rapid pace of change Angular 2 is still undergoing, I think having real-time help is invaluable. I found lots of great help in the official Gitter, which is frequented by many great and active contributors. I also found no matter how complex of an Rx question I thought I had, help was always available on Stack Overflow.
Things that were difficult
Community writing/tutorials generally behind 2.x
It is just 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. Additionally, 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.
Stack Overflow answers hit-or-miss
Along the same lines as tutorials, I think 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.
Being productive with Rx
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 it is 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.
3rd party libraries were hit-or-miss
Some libraries existed in versions that were compatible with Angular 2, but some didn’t. Given my timeframe, I had to abandon projects that weren’t compatible with Angular 2.
Too early for patterns, best practices, & preferred toolchains to emerge
In its current state, I think community knowledge of Angular 2 is just not as plentiful as it was when Angular 1 really 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 still 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 am curious specifically if the Angular 2 community will swarm to this paradigm like the React community has.
Things to think about before adoption
Where is your development team’s skill level?
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?
How do you feel about learning Rx?
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, I think you can still get around it if you’re prepared to encounter some bumps along the way, however you would 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.
Are you OK with refactoring down the line?
Since Angular 2 is still early on its journey, I think 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.
What is your stance on TypeScript?
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.
It is one downside of optional typing that (for whatever reason) the developer can choose to opt-out anywhere. Do you want to allow that? There is nothing ‘wrong’ with using Any, but I think it’s important you agree as a team on what your policy and expectations will be.
So what should you do?
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 is definitely some community adoption already, but I really don’t know how much enterprise adoption is currently happening. I think jumping on something in this early adoption phase has both pros and cons.
In my opinion, if you are 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). I think 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 too am curious where it lands in terms of adoption/deployment for web developers and enterprises.
About the Author
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.
