To boldly go…the trials and tribulations of a first Angular 2 / Typescript project

Our dev and project management teams are nothing if not bold. If they hear of a new development framework, or the next generation of an existing one, they will grab it by the whatsits and see how it performs. Sometimes this experience is successful and goes on to be a technology we adopt as part of our standard approach, but other times working at the cutting edge can present more problems that it potentially solves.

Earlier this year we embarked on an upgrade of one of our key Laravel 4 applications to Laravel 5.3, just a week after one of our Devs had attended its launch at Laracon Amsterdam. This was quite a significant jump in terms of reorganising code structure but was relatively risk free.

Sometimes however, we take on a bigger challenge – stepping well and truly into the world of the unknown. For example, we have just had an interesting experience (yes, a euphemism) with a first Angular 2 project.

AngularJS is an open-source front end web application framework based on JavaScript. It’s been around for a while and we have a reasonable amount of experience using it in real world projects.

Angular 2 is the latest incarnation of the framework but rather than being a simple upgrade it’s a complete re-write, including a recommended switch from JavaScript to Microsoft’s TypeScript language. While it’s been around in concept at least, for a couple of years, Angular 2 was only released in final form in September.

This is the tale of two experienced Agile teams and how they found working with Angular 2 and Typescript for the first time, and what they would pass on to ‘their younger selves, a month ago’ when they embarked upon the project.

Our dev team is extremely capable and experienced, with multifarious skills. They spend a lot of time thinking about, researching and planning for a project before using a new technology. Our project management team helps them to balance the excitement of getting to grips with the Next Big Thing, with other realities which apply.

They (the developers) say that the appeal of mastering Angular 2 is to:

  • Write great code which is much easier to maintain due to it’s fundamental modular approach (a big advantage over conventional JavaScript and Angular 1)
  • Produce deliverables which are incredibly user responsive
  • They also, only half-jokingly, said ‘fun, shiny, enjoyable’, i.e. the allure of novelty which need not be misplaced if the learning experience produces what you hope for.

We set out to use the technology to implement a set of key features in a product that while not being used by clients yet, is on the critical development path for several client facing projects. The challenge was to be attempted as part of the 2 week long sprint immediately following the official Angular 2 release date.

So did the learning experience produce what they hoped for? That depends on one’s perspective.

We succeeded in rapidly assimilating working knowledge about Angular 2, however we were unable to complete all of the required features within the time constraints or the scale estimate. Consequently, we failed to successfully deliver the sprint objectives.

In a few words, the dev team say that this is what happened: ‘we started, we paired, we evaluated, we coded, we got some of the way there, the sprint ran out, we halted the attempt’. And THANK GOD there wasn’t a client waiting for a deliverable. That sentiment was strongly expressed by the project management team.

There were real technical issues involved. The dev team found, for example, that the ECMA script is not yet supported in any browser. One of them quipped “I don’t know about bleeding edge – more like bleedin’ useless”. Definitely early days for this approach.

The team also found working with Redux (a state container to help applications behave consistently) was especially tricky.

One of the identified difficulties is a community one. By that, they mean that for existing open-source frameworks that are, say, at least a year or so old, there is already a rich resource ‘out there’ of fellow developers who have tackled the challenges, found the answers and written it up for teams like ours to benefit from. What our guys found is that the dev community resources were very thin on the ground for Angular 2 – though obviously growing every day.

The learnings have been:

  1. Ideally, be a student, a contractor or working for a Russian billionaire with bottomless pockets, when you embark upon learning to use Angular 2.
  2. If you are using it in a commercial setting, treble [quadruple?] your budget. Or another way of putting that…
  3. Trial it on an internal (or low risk low pressure) project.
  4. Even then…think of an internal project, and then think again and go for something very achievable and non-strategic.
  5. If you work within strict sprints, which we do, then be prepared for your timescales to be WAY out.
  6. Know that it is as much about Redux as Angular 2 and Typescript.

There was a real air of disappointment in the room when we discussed this with both teams, because if (1) had applied, the dev team know they would have cracked it. In our case, (2) and (3) applied. But they realise that they got (4) wrong. This means that when they come to use Angular 2 again, learnings 1-6 will be firmly in their minds.

On the back of this experience we have invested in further training with an industry leader to increase our understanding of the technology further. The dev team remains optimistic about using Angular 2, Typescript and Redux and this further investment has only served to cement a belief that this is the right way forward for us. They know what they would face next time and how to plan better for it. We hope what we’ve learned will help you to do the same.

Share this post

Share on facebook
Share on twitter
Share on linkedin
Share on pinterest
Share on print
Share on email