Hey babe, take a walk on the client side

Today is the first of 2 for me learning about AngularJS at NDC.

This for me is a particular highlight. Over the last few years or so (ever since the writing was on the wall for Silverlight to be honest) I’ve oft pondered what the future holds for rich web UI applications in this brave, post-Silverlight world. AngularJS is one of many javascript frameworks that could hold (or at least contribute to) the illusive answer to that question.

What’s it all about?

AngularJS is a javascript library. It prescribes a structure to your client side. It reduces the volume of code needed versus conventional javascript/JQuery. It brings concepts such as Dependency Injection (and therefore substitution, extensibility, unit testing and all that lovely stuff that’s long been the exclusive remit of the server side) to the client.

That’s all good. In my experience, the client side has always been a rather unstructured, loosely-typed, lawless world governed almost wholly by the discretion of the author. The issue therein is that it is inconsistent and it is entirely probable that the manner in which I structure my script will differ from that of the next developer. There are no proper rules and this inevitably leads to problems extending and supporting the code down the line.

As regards the volume of code, Angular’s directives, scopes, models and elegant apis dramatically reduce the volume of code, versus the same in conventional javscript/JQuery. In particular, interacting with and binding to DOM elements is infinitely easier with Angular.

In a nutshell, all the functionality in Angular could be done in conventional javascript/JQuery. This is not about making the impossible possible. It is about making the possible manageable.

I’m sold – Angularise my life now!

Hold on there kid! There are some down sides…

…And at number 1 its performance. Angular is feature-rich and beautifully elegant. The trade-off is performance. To what extent this is a problem depends on the application. I need to do more research into this but the performance hit seems to be proportional to the number of bindings on the page. It comes from the apply/digest cycle checking for changes in the model each time something angular happens. My gut feeling is that for a small application that’s going to handle relatively few records at a time and whose instances consist of relatively few primitive properties the performance hit will be insignificant but for higher volumes of complex instances I imagine that performance detracting from the user experience.

The next thing is that there are a few aspects of the syntax that feel a bit “Friday afternoon” to me. The DI container is one such example. It’s critics state that minifying breaks it. It’s supporters state there are perfectly satisfactory workarounds in ngMinify and ngAnnotations. Personally, my opinion is torn. On the one hand, how else do you do DI in a loosely typed language? On the other hand having to use a “workaround” from day one doesn’t bode well. Juries out for now and I guess we’ll see what version 2 brings.


I love the idea. I think it is an excellent example of how to effectively harness the power on the client side. You can offer a greater guarantee of quality than ever before. You can add to it and extend it more easily than ever before. It is a huge step forward from the vast ‘soup’ of disparate functions that conventional javascript tends to yield. I would go as far as to say that it is one of – if not the – strongest contender of the many javascript libraries available. I am very curious to see what v2 offers. Remember that it is only version 1 currently though.

In its current form I’m not totally convinced its the silver bullet. I’d happily knockout a brochure site in it. It would think twice before building a trading platform in it though…

Overall, my view is one of cautious optimism. Conceptually, I like it. There are a few refinements and optimisations I would like to see in the implementation… Hurry up with version 2!

Continue Reading