Sunday, March 19, 2017

Should you use Angular 2?

A lot of people ask me two questions when I tell them I use Angular 2:
Should I learn it?
Should we adopt it?
Number 1 is more for the lone employee trying to expand his/her horizons. Number 2 is for the manager looking to start or upgrade an existing project.



Should I learn it?


The answer is always yes.  We are in a period of technologies where new frameworks and new libraries are popping out of the ground like daisies.  Angular 2 wasn't even out of release candidates, when Google was touting a Angular 3 in the next year.

What this means for the average interviewee is that in order to stand out of the pack, know as much as possible.  Be the sponge you always hoped to be.  There is absolutely no downside to knowing just a little bit about a new framework with a huge community around it.

One time my professor was asked how he got so smart.  He answered, "the way to seem smart is to be able to talk a lot about stuff people don't know."  So take the opportunity to just delve into the unknown and get your feet wet with Angular 2 or whatever language you were wondering.

At this point you might be asking yourself, 
Peter, if things are changing every one or two years is there any point to learning it? 
This is a pretty valid point.  However, there is always a lag time.  Companies cannot move their infrastructure very cleanly every year or two, which means last years technology will still be around.  Heck, that's why so many people are still on IBM mainframes and Weblogic servers.  Cobol programmers still get paid a $20k premium right out of college.  Hopefully, Angular 2 is a building block for Angular 3 and beyond.

Should we adopt it?


Everyone who writes about Angular 2 proclaims how great it is.  "It's the best thing since sliced bread. It's faster than Angular 1. It's more logical separation of code.  It has ahead of time compilation."  However, none of these answer the question of whether or not you should bite the bullet and go with Angular 2.

The question isn't as simple as Angular 2 is better than Angular 1 so we should adopt it.  Remember that making the framework is half the battle.  
You don't buy the newest gaming console for the specs; you buy it for the games (paraphrased from Extra Credits).
Let's start by comparing Angular 1 and Angular 2.  Angular 2 is for sure a better mousetrap.  Angular 1 scaled directly to how big your application was, and if you didn't carefully manage performance than your user experience would effectively be shot.  Angular 1 became an unwieldy beast that had to be patched over and over again, until Google went back to the drawing board to make Angular 2.  But if Angular 2 was the PlayStation 5 and Angular 1 was the PlayStation 4, then I would recommend that you stick with your old PlayStation 4.  The reason is there are no games, yet...

Moreover, I can tell you, as someone who has been working with Angular 2 since a release candidate, that it time consuming to be toward the innovator portion of adoption curve.  There has to be a heavy reliance on the Angular cookbook, since the likelihood that someone has run into the same problem as you is low.  This means you should be pretty conservative with your estimations when you brave new territory.

3rd party support


The main drawback is that there is not enough 3rd party support; it is too early to depend on them.  With Angular 1 you could import Angular UI packages, like angular-ui bootstrap that made it so easy to make a site from scratch.  Even if you didn't like the bootstrap look, it would take you far less time to build out the functionality for all the directives.

Of course you can just load JS files from various node modules, but if you want the server-side rendering with Angular Universal, then you have to be wary if they use browser only keywords like document or window.  Otherwise, your pre-rendered HTML won't even compile.

If you are going to use Angular 2 today, then I would say bake enough time to build these custom components.  Making dropdowns, modals, and small UI components can take a long time.

I am using ___ for my front-end, should I switch?


I am a firm believer that front-end technologies are somewhat interchangeable, but they emphasize different things.  Angular and other SPA frameworks are stressing reducing subsequent page load times, by reducing the number of assets that are being reloaded.  React tries to decrease the load time of these requests.  

Theoretically, a pure JavaScript application takes significantly less time to run than an Angular or a JQuery application.  Why, because these frameworks send compilers to translate these things back into JavaScript. However, if you are loading all the files on each page load, then it starts to taper off very fast.  The difference between Angular 1, 2, React, and JQuery is not as big as you think.  It all depends on your use case.

It shouldn't be a question of using the newest technologies, because changing a large scale application every couple of years is a ridiculous notion.  Modifying 100,000 of pages to a technology that teams have low experience is destined for failure.  Instead determine if there is even a problem with your current setup and if it is framework specific.

Last Thoughts


Angular 2 is a great framework, and it can only get better from this point forward.  I can only imagine it will go from nice to know to need to know.  However, we should all be wary about switching frameworks willy nilly.  

Thank you so much for reading.  Please leave a comment down below.

Peter











  

No comments:

Post a Comment