AngularJS & WebAPI/MVC: Enemy or Synergy?

Before getting into the meat of this post, I can’t not mention the fantastic week I spent at NDC. Great workshop, followed by 3 awesome days of insight into a multitude of interesting topics. Incidentally, there will probably be more posts coming from my direction on web components, OWIN/vNext and maybe even document databases (Apologies in advance for that little beaut Russ – our long suffering DBA!), but for now I’m interested in Angular and more importantly how that could fit into the existing Microsoft stack.

If you read my previous post, firstly well done! :), secondly it will come as no surprise that I’ve harboured cautious interest about all the hype over AngularJS, but until now it’s been relatively passive and non-committal. I come from a fairly pure Microsoft background. I’ve duly learned MVC and its many foibles and I have found the prospect of committing headlong into something new and non-Microsoft (such as Angular) quite daunting, hence my choice of workshop – I want a headstart if that’s the way the world is going.

I enjoyed the workshop and came away with a great starter on Angular, but as it progressed new questions developed. Performance: Critics say its not performant, Fanatics say its fine under all but the most demanding edge cases. I’m quite sure I could have got 3 different answers from as many people as to the maximum number of bindings per page that would yield a reasonable performance. Integration between the familiar world of Microsoft .Net and Angular: If we want to use Angular do we have to throw out all our time-honoured C# MVC code? How would non-Microsoft Angular going to be regarded by the big corporations of this increasingly risk averse world? Turns out I might not be the only one to ponder these questions and there is help at hand.

The Context

One buzzword you’ll hear a lot of in this arena is SPA (Single Page Applications). The premise is that minimizing postbacks improves user experience. The logical conclusion of that train of thought is let’s put the entire application on a single page, but that would be extremely hard in a loosely-typed, poorly structured, bloated language (such as javascript), but not impossible. Javascript frameworks help to abstract away some of the boiler plate/polyfilling work which in turn condenses the codebase. They dictate a structure to the script which aids readability, understanding, supportability and extensibility. Essentially, they are the tools to more effectively manage complicated logic on the client.

So which one do you choose? Every one of them does binding. Every one of them asserts some degree of structure over the client side script. Within that remit some frameworks have a particular affinity to compatibility, some have a particular affinity to syntactic beauty, some have a particular affinity to additional features and some have a particular affinity to performance. Of course there are trade-offs in every case. The judgement on what to work with comes down to personal preference, a bit of knowledge about your choices and your particular requirement. Most will work for most applications, and each one will do a slightly superior job for the particular story it is designed for.

So why pick Angular over everything else? AngularJS is stealing the limelight because it is feature-rich, has a graceful syntax (most of the time), it’s maintained by Google and performance should be acceptable in all but the heaviest  of cases (in terms of bindings). It is the one with the fewest trade-offs IMO. That’s not to say it doesn’t have any: A word of caution mooted numerous times by various industry commentators is that version 2 of Angular will be a whole lot different to version 1. That said, those same commentators also say that going from v1 to v2 will be easier than going from no Angular to v2. That’s progress for ya…


I can go and watch a workshop about MVC.Net and totally buy in to doing everything on the server (or at least I could have done 7 or 8 years ago). Similarly, I can (and did) go to a workshop about AngularJS and learn how to do everything in AngularJS. In either case, there is little said about integrating with each other.

This feels quite polar to me. MVC at the total exclusion of the emerging client side feels old-fashioned and short-sighted, especially as Silverlight isn’t an option anymore. But I’m equally uncomfortable with designing an entire line of business application in one Angular SPA. Call me cycnical but I’ve not seen it working in a full-on commercial situation such as ours. While I’m pretty sure it works I’ve not seen it with my own eyes, so committing to Angular fully feels risky. Why can’t I arrange my eggs in a few different baskets? Must I really throw my MVC baby out with the proverbial bathwater?

Enough of that… The point is there was a reason the server side prevailed all those years ago and I think it still has a place. I also think that place constitutes more than disparate abstract web apis for Angular to call into. The server side gave us a consistent environment to work in. The client environment was unimportant. We no longer had to concern ourselves with how good the client hardware was or whether the browser would support our javascript or what version of MDAC was installed (anyone else remember that??).

Furthermore, Google say AngularJS will take 10,000 bindings in a single page. Where do I stand if it turns out that comes with smallprint? The thing with client side javascript script is that it runs on the client hardware (funnily enough). Hardware has a significant bearing on application performance and, unless you are developing exclusively for intranet scenarios, client hardware is generally not that predictable.

That said, there is no doubt that the client side has become a lot more reliable since those dark days. Even on mobile devices now, you can expect fairly tasty hardware and you can normally expect it to run javascript. We can expect further improvements and the software industry will embrace that one way or another. There will always be a hardcore of users who insist on using an ancient PC with IE7 and they will complain the internet isn’t what it used to be back in the glory days (nor will it ever be on IE7). Don’t worry about those guys. Anyway, predictable client environments do not make the server redundant IMO, instead it just means the load gets shared and logically that seems prudent and feels comfortable.

So I’ve decide what I want and that’s the best of both worlds. I want to be able to build a solution and split my code logically between the server and the client.  Perhaps the complicated stuff that is easier within a strongly-typed, compiled language can live on the server, and I can indulge my penchant for tasty, postback-free UI logic on the client (eg: Fade this div in from the right which has some bound values in, but only if the value of txtFoo is ‘bar’ and option rab is selected from list ddlOof – I don’t condone Hungarian notation by the way. It just helps to visualize pseudo-logic).


I might be stretching the metaphor of generics somewhat with that heading, but my point still stands. What about a third way? Why can’t MVC play nicely with Angular and make something beautiful?

They can. I imagine Google and Microsoft would hesitate before conceding this but getting Angular and MVC to work as a team is a really good idea. Miguel Castro describes a solution that comprises of a number of SPA “silos”, each dealing with functionality pertaining to a particular ViewModel. Damian Edwards describes a similar concept with “islands” of SPA functionality.

This feels like a pretty happy medium to me. It would offer sufficient logical separation to support large, complicated applications with a plethora of a different features. It minimizes potential performance concerns because a) not everything is on the same page; and b) not everything is being run on the client. That leads us nicely to fallback. What happens if the performance goes t!ts up like the Angular naysayers warn? Answer: You got a couple of options actually. One of those is splitting some of the work into another silo, another might be to move slow running behaviour back to the server.

In a nutshell, we’ve got it organized by MVC at a controller/viewmodel level (eg: Surveyors, Surveys, Appointments), but the actions are handled in the relevant SPA Silo by Angular (eg: Surveyors/Create, Surveys/Search, Appointments/Book).

In terms of implementation, I’ve seen it working and I’ve got Miguel’s example for anyone who’s interested. The key to unlocking the potential seems to be getting the routing right. It needs to be configured such that MVC doesn’t monopolise the routing. It just needs to produce a view model and serve up our host page. Angular will take it from there. This can be achieved quite easily using catch all routes in MVC (see the RouteConfig.cs file) and then adding specific routes into the routing table for each SPA (see the App.js files in App/Customer, App/Order and App/Product).

Once that bit is done you can concentrate on getting MVC to serve up a host page with as much or as little default functionality as you like. MVC gives you some neat sections in which to put your <script> tags.  and there will also be some web apis for Angular to call into. That leaves the view which you can treat thereafter as pure Angular.

While chewing this over on the train home on Friday night, it also occurred to me that there’s another advantage that’s particularly relevant to eTech. If you already know MVVM (the prevailing methodology for Silverlight), Angular prescribes a very similar structure. Sure, the syntax is different and the terminology can bit misleading (the Angular “controller” is more synonymous to an MVVM ViewModel than it is to a MVC Controller) but structurally there is an awful lot of common ground to draw on with MVVM. It’s not as daunting as it first seems and getting in to it may be easier than you think.

In conclusion, There is some cool stuff in Angular. Like anything, there are a few risks but there are ways of mitigating it. My opinion for what it’s worth is hybrid/SPA silo applications are the future for commercial line of business applications. Regardless of what is technically superior, there’s a lot to be said for public perception. Businesses are risk averse by nature. We all love progress, but personally I find some comfort knowing that old familiar Microsoft will be waiting in the wings (read server-side) if i manage to blow my foot off with Angular.


Miguel A Castro: AngularJS for MVC Developers

Damian Edwards: AngularJS & ASP.Net

Scott Allen: Intro to AngularJS

Cory House: Web Components – The Dawn of the Reusable Web

Continue Reading

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