November 22, 2016
I’ve recently started work on a new project for one of our clients – one which requires us to build a new internal web-based application. As part of our planning, my team had to decide which framework (if any) would be right for us.
Rather than go into the details on why we didn’t choose x or y, I thought it might be interesting to set out our reasons for choosing the framework we did decide upon: Angular 2.
As a developer on the team, I began the process of figuring out what we’d need to have in place to ensure we can build something that’s fit for purpose (and lives up to Equal Experts’ technical values).
The first thing I did was to consider the length of time before this project will go live. In this case, it’s 18 months. With a timeline like this, I was able to consider some of the more bleeding edge (and consequently less battle-tested) options that were emerging; that’s how I came to consider Angular 2.
The first thing that I really liked about the framework was that it has adopted TypeScript as its weapon of choice for writing the application. This allows you to use up-to-date JavaScript standards (ES6/7), and has the added benefit of static typing – meaning you can catch more bugs when compiling the code. It also integrates really well with our IDE (Visual Studio Code), keeping IntelliSense updated. This is a luxury JavaScript developers aren’t too used to having, and it helps us a lot.
The next thing I looked into was the testability of the application code. Good news here, too – testing was made a first class citizen in the new framework, with a full dependency injection framework. It has all the tools you need to produce unit tested and integration tested code, using the testing tools Karma and Protractor.
With everything looking pretty good at this point, I thought “OK – now what if I don’t know how x works in the framework – what do I do then?” Well, the Angular team has you covered here. They are committed to keeping all their documentation up-to-date and release it at the same time as they release code. So as well as being able to dig through the code itself (which has unit tests to demonstrate functionality), you also have very good documentation to reference.
Looking at performance, Angular 2 is significantly better than Angular 1. When compared to React, some areas are better, some worse and some about the same (though how exactly they compared the two, I am not sure). But this is just the standard implementation – the Angular team has only just scratched the surface on performance and it will get better and better over time.
Comparing Angular 2 to its predecessor, the two frameworks are a million miles apart. This is no accident; the Angular team started afresh with Angular 2 and have made sure that all the features mentioned above are part of the core feature set. It all makes it a much more complete framework than before.
Based on all these considerations, Angular 2 seems a winner for me, and as a team we’ve decided to use it. At this early stage we still haven’t dug into all the benefits yet, either – such as the i18n support being built into the project, and IE9+ being supported. This means we can support more browsers than some other frameworks. Accessibility is also well covered within the framework and its documentation.
It’s clear the Angular team has taken a firm aim on the corporate world and wants to make sure it gives devs all the tools we needed to produce apps. I’m looking forward to increasing my familiarity with it over the months to come.
All business models have their pros and cons. But, when you consider the type of problems we help our clients to solve at Equal Experts, it’s worth thinking about the level of experience and the best consultancy approach to solve them.
If you’d like to find out more about working with us – get in touch. We’d love to hear from you.