Angular 2: Should You Upgrade?

By Dave Ceddia

Angular 2 Mountain

With all the churn in the JavaScript world, it’s easy to feel overwhelmed. Articles have been written about it (and I suppose this is another one). The breakneck speed at which the JS ecosystem is evolving and the never-ending chorus of “don’t fall behind!” lead to a stressful situation.

In the Angular community, we’ve reached a bit of a crossroads with Angular 2. Now that it’s in beta, more and more people are giving it a try. Some of them really like what they see, and some of them really don’t…

“Angular 2 suffers from complexity because of TypeScript.”

“It’s configuration over convention!”

“The syntax is just too off-putting.”

“I can’t think of a single reason I’d choose this monstrous framework over React.”

Many of us Angular devs have gotten used to 1.x, and even started to like it. It feels comfortable. Our codebases are fairly organized thanks to the invention of style guides. No need to make any drastic changes.

And now Angular 2 is on the horizon. It has the same name with a higher version number, so it must be the next logical step! Upgrade for upgrade’s sake. It’s what we’ve always done.

But some of the examples out there look like flashbacks to the Dark Ages of mid-2000’s Java. The proliferation of AbstractServiceProviderAdapterFactorys can’t be far behind…

@Injectable()
class TodoService extends AbstractTodoService{...}

It’s like someone came in and told us there’s a new sherriff in town, rules are changin’! And we might not like ‘em!

Except our belongings fit in a suitcase, and the next town over is plenty friendly and “easier to reason about” (those React townspeople love saying that). Maybe it’s worth a visit, just to see…

Drastic Changes

One might look at Angular 2 and think “gee, this doesn’t look like Angular 1 at all.” One would probably be right.

Angular 2 shares some concepts with its predecessor – the special HTML templating syntax, directives/components to modify the DOM, and a “kitchen sink” approach to including everything you’ll need to make an app – router, HTTP service, etc.

There are more similarities, too, but Angular 2 is really more of a spiritual successor to Angular 1 than a proper “update.”

Your existing Angular 1 code will need some serious changes to work with Angular 2. It’s not like a drop-in replacement where 60% of your code might kinda-sorta work: nothing will work out of the box. This is what I mean when I say Angular 2 isn’t really an “update” to Angular 1.

This is important to keep in mind: if your Angular 1.x app is working fine, it’s worth considering whether you need to change anything at all.

“Need” to upgrade?

If you’ve got a fully functional 2016 Car, do you sell it when the 2017 Car with Updated Stereo comes out? Well, probably not. Your car works fine, and going through the entire process of buying a new car is a lot of work just for a fancier stereo.

Now look, I’m as much of a magpie as the next guy or gal. I like shiny new toys. But just because “version 2” is out doesn’t mean we need to jump ship from “version 1” like it’s on fire.

Angular 1.x is not going to suddenly go up in smoke. It’s going to be around for a while (especially if developers keep using it).

Why upgrade?

We in the software profession seem to love upgrades. New version comes out, we’ve gotta have it. Sticking with the old busted one just won’t do. We need the new hotness.

I’m gonna go ahead and challenge you to ask yourself “why.” A real, honest, philosophical “why.”

Here are some reasons I came up with when I asked myself:

  • It’s new, and I like learning new things.
  • Everyone is talking about it and saying how great it is.
  • Leaving your software using the old version of a library is Just Not Done.
  • Because the features are better
  • Because Components are the way of the future and the future is awesome.
  • Because security.
  • I don’t want to fall behind.
  • I don’t want to be stuck holding the bag (and 100k lines of code) when they deprecate the old one.
  • If I don’t know the newest thing then no one will hire me.

These are real reasons. All of them. Some of them are logical, some of them are based in excitement, and some are based in fear.

But here’s a freeing thought: “I don’t have to use the latest and greatest.”

The key is knowing why you feel the need to upgrade. Product requirements? Management says so? You just want to learn? Great!

But don’t do it “just because.” It might turn out that you don’t need to upgrade after all.

All the churn in the world doesn’t matter if you ignore it.