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.
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…
MVC vs SPA?
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?
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