AngularJS 2.0: Did They Shoot Themselves in the Foot?

Right now, AngularJS seems to be one of the hottest emerging front end technologies for developers. Virtually, every recruiter has been calling me up and asking me about my AngularJS background (despite only possessing a year of it). However, there was a blog post talking about the major changes for the 2.0 version. And it’s not going to be pretty.

AngularJS 2.0 essentially will require a re-write of websites currently working with the current version. The big issue I’ve read comes from the parsing of tags where there’s a performance penalty. Since the technology was originally aimed at enterprise developers with more JSP/Java background, the adoption has been a little bit hesitant for non-enterprise developers.

Yet as one of the hot emerging technologies, many companies want to pick up on the trend. From my own experience, AngularJS’ primary technical benefit is the data binding. The way I like to look at the situation is that the Javascript objects you create on a page “acts alive;” meaning that when their properties are updated, the changes are reflected on the page. This feature is immensely powerful as your models on the page don’t have to be redundantly recreated/accessed through events and DOM manipulation, which is the way the older Jquery paradigm had operated.

The problem with AngularJS (and other single page application architectures) is that you have to design the site from the beginning with the intent of the site being centered around this paradigm. For traditional content-heavy web pages, single page application architectures may seem like overkill. If you want a few simple effects, plain old Jquery with a few of the inherent effects is fine for most sites.

Single page application architectures though work when you are attempting to create an actual application as opposed to static content type of pages. Part of the popularity is using something like AngularJS with a responsive framework such as Bootstrap to create a hybrid site for mobile and browser based applications. Doing this can allow a company whose skill base may be initially oriented towards web development to invest in backend services that are exposed for mobile development at a later stage.

So what’s the real issue with AngularJS if the benefits seem fairly clear? The primary issue as mentioned is that adapting AngularJS is like injecting yourself with AIDS as a test monkey in the hope that a cure will be found in the coming year or two. In short, you’re working with a very specialized ticking time bomb that is expensive to defuse.

As a developer, you have to ask yourself whether to invest into a framework like AngularJS knowing that in a year or two’s time, everything is going to drastically change. Or should you wait to get into AngularJS in the hope that the rewrite will clean itself up and deliver on a lot of promises.

For companies, the question is similar in investing into a technology that will be antiquated very quickly and try to hire these expensive developers right now because it’s the hot thing and later commit to rewriting your application. I think realistically most companies will end up shunning this out of the cost factor, in terms of time, money and resources.

What AngularJS needs right now is a clear roadmap for migration. At the moment, outside of the known fact that code will be rewritten for the purpose of improved performance, there’s no clear cut future for developers and companies. Companies that have already invested into AngularJS probably don’t have to worry as much because the work has been done. But those starting off from scratch need to look at the bigger picture.

Then again the real issue isn’t just with AngularJS but the technology industry as a whole. The latest fad comes out, developers and companies both jump on it. Developers want to try it out because it might solve a single problem that their current methodology does not as well as something to put on their resume. Companies fall for it because they put too much faith into their developers in making the right choices.

Instead, the reality is that we end up going through these loops where we rebuild the same damn thing over and over again. Companies get burnt because they’ve invested far too much time, resources and money into a project/technology. Developers get burnt because they are forced to deal with this Darwinian system of regurgitation and keeping up rather than taking an existing thing and trying to make the best of it. I suppose the jQueries of the world are far and few in between but until we stop trying to adopt early and really think about the problems we’re trying to solve, then it won’t be the software that eats the world. Instead, we’ll just eat ourselves out of sanity and home since we won’t make the real progress and the economics of the situation won’t improve for us.

Comments

comments