Angular is the new uncool?

This week, more details about the future of Angular 2.0 have been announced at the ng-europe conference (see for the video). After the first announcements made in march 2014, more details have been disclosed. Angular 2.0 will not be backwards compatible with the current 1.x version.

It backfired. People are truly upset about the breaking changes (see this reddit thread, for example).

The interesting thing is: why is everyone suddenly so upset? From the start of Angular 2.0, it has always been clearly stated that the new version won’t be compatible with the current version in order to make drastic improvements. Also, the current 1.x version will be supported for quite a while (1,5 – 2 years after the release of 2.0, probably late 2015).

No problem or…?

I think the Angular team underestimated the impact of their message: by making such drastic changes they are giving the impression that the current 1.x version kind of sucks. To make things worse, in the presentation, they used the R.I.P. metaphor for the concepts of Angular 1.x that are going to be removed. Quick unfounded conclusion: Angular 1.x is dead.

People are upset because this message makes them feel that the cool technology they loved yesterday has suddenly become uncool and legacy. The new cool is still at least a year away and in the mean time we have to work with uncool technology, and envy other frameworks that have managed to stay cool.

Web Development on the Microsoft stack in 2014 – making sensible choices

In the early days of ASP.NET web development things were easy: Web Forms was the only option for building dynamic web applications. People were happy, people mocked, but life was simple and everybody carried on.
Fast forward to 2014 and you see that ASP.NET has expanded into a huge family of web technologies (web pages, web forms, mvc, web api, signalr). It can be very difficult to see the forest through the trees. And then there is the ASP.NET website itself:

ASP.NET is a free web framework for building web sites,
apps and services with HTML, CSS and JavaScript.

What? Doesn’t make it any clearer, does it? I always thought that ASP.NET was server-side technology (everything except HTML, CSS and JavaScript), so this leaves me kind of confused too.

With so many choices available, picking the right one for your project is a very daunting task. In this post I’ll try to identify what, in my opinion, are the most important pieces in the current ASP.NET stack (leaving out non-Microsoft alternatives for another post) and when to use what and why (or why not).

ASP.NET Web Pages

Let’s get this one out of the way first: don’t use it, just use PHP like everybody else does when you need a simple website with some dynamic content. Also hosting will be cheaper.

ASP.NET Web Forms

Use it in existing projects that are build with it. Don’t start any new Web Forms project (please). Over the years it has served well, but in the end, the ‘familiar drag-and-drop, event-driven model’ just isn’t very compatible with how the web works and more importantly, there simply are better alternatives.


MVC should be your default option for rendering pages server-side. It’s mature, not too complicated, encourages a decent architecture and has just enough extensibility points to make it work for a broad range of scenarios. In my experience this is also (still) the most productive option, especially for CRUD-style applications. With a little sprinkle of jQuery on the client it’s also very suited for applications that require a limited amount of interactivity on the client.

ASP.NET Web API with a JavaScript Framework of choice

So here it’s where it’s happening in 2014. According to blogs, articles etc. we should all be writing Single Page Applications (SPA’s) because the user experience is so much better when you don’t have those pages refreshing on you every time. This is true and yes, I’m enthusiastic too but please, don’t blindly jump on the SPA bandwagon. Two things to keep in mind:

  • A Single Page Application with Web API backend has substantially more moving parts than a ‘classic’ server side application (MVC or Web Forms). Simply said: it’s harder to develop, takes more time and is more expensive, in my experience roughly 1.5-2 times;
  • The JavaScript frameworks landscape is still Wild West. I’ve seen .NET shops go all in with the library or framework du jour (from Knockout to Durandal and now Angular ) only to find out that these are not a perfect fit for everything. Choose very careful and don’t go all in;


The next version of the ASP.NET stack promises a leaner and faster platform that merges Web Pages, MVC and Web API into one Open Source framework. Changes are huge, especially in the runtime environment, but the differences between Web Pages, MVC and Web API as stated above still apply. Web Forms is left out, so that makes one less option to worry about :-).

Appoints-Client – An Angular JavaScript client for the Appoints-Api REST API

A little while ago I blogged about Appoints-Api. This is an example appointment scheduling REST API built on Node.js. To complement this API, there now is an example HTML/JavaScript client, based on AngularJS and the angular-hal library.


The source code of Appoints-Client is at GitHub and a live demo can be found here. Feel free to create alternative implementations or native apps. Just let me know and I’ll add it to the list of clients.

For Microsoft people: did you notice that both the REST API and client are hosted on Azure? That’s right, all non-Microsoft technology but still working perfectly fine on Azure!

Appoints-Api – A simple example appointment scheduler REST API

Appoints is one of my pet projects. It’s an appointment scheduler application and I’m using it to explore new technologies and to refine existing development methods.
To stay buzzword-compliant, Appoints needs a REST API. I’ve been in some projects lately where we have had mixed results with REST API’s and client apps, so I decided to do it properly this time. Some requirements:

  • Keep it simple;
  • Design API-first;
  • Accessible for both JavaScript and native (mobile) clients;
  • 3rd party authentication: no need for user registration and management;
  • Testable;
  • Keep it simple.

The result is at GitHub: I have to say that I’m pretty pleased with how it turned out :-). It’s build with NodeJS, Express and MongoDB via Mongoose. In my opinion, this is currently the most productive technology stack for this kind of applications. I also managed to sprinkle some Hypermedia functionality on top of the API by conforming to the HAL specification.

You can find a live version of the API at For more information about the usage of the API, head over to the GitHub site. I‘d love to add an API documentation site, but I am still looking for solutions.

Next, I’ll probably create an example JavaScript client so we have a full example. At the same time, it would be very nice if anyone would be able to build a native client. Shouldn’t be too hard.

10 signs that you might be in an abusive relationship with your software frameworks and components

Software frameworks and components exist to make the lives of software developers easier and more pleasant. They remove the need to do dull repetitive tasks and allow you deliver business value faster resulting in you being a happier person.

However, we seem to be able to develop some sort of abusive relationship with our frameworks or components. After the honeymoon, small irritations start to occur, but also at the same time, our dependencies on those frameworks or components grow and grow. When realizing the state of our relationship, it’s often too late for an easy way out and the situation ends with a bang (like people quitting their jobs or projects being canceled).

The following list contains signs that you might be starting to have an abusive relationship with your frameworks or components. With no action taken, things will end up in tears. The signs are real quotes from the field.

  1. “We’d love to build this feature and we could easily build it ourselves, but we standardized on <component suite> and they do not support this scenario (yet)”
    Standardization can be a good thing among development teams, but you can also push it too far. If it’s easy to build by hand, go and build the feature. Don’t let a component suite dictate what your app is capable of.
  2. “The next project should go a lot faster because we learned all the intricacies of <framework x>”
    Do you see the word ‘intricacies’? That alone should put up a big red warning sign. There better be something very special about framework x that compensates for those intricacies.
  3. “Things are quite rough now, but <component vendor> promised that everything is fixed in the next release”
    This might sound cynical, but not all will be fixed in the next release, for sure. You have to be realistic about what to expect from a component vendor. If you still see steady improvement then there isn’t too much to worry, but when promise after promise is broken, I’d look elsewhere very quickly.
  4. “Yeah, we should really upgrade our app to <new and much improved version of a library> but we can’t because our company framework depends on a real old version of it and we can’t upgrade the framework because that would break almost all our other apps”
    Don’t use or develop a company framework. Often, companies develop application frameworks to remove the need to build certain features again and again, but over time you’ll notice that existing applications build on top of the company framework become a real maintenance burden. Everything has to stay compatible or multiple versions of the company framework have to be maintained (even to the point where every app is tied to its own version of the company framework). I think it’s a safer choice to harvest the good parts of existing applications and re-implement those in new applications, combined with small set of current developer guidelines so everyone stays on the same track.
  5. “They are working on a Visual Studio plugin”
    This indicates what you might have thought of yourself already: this component is just way too hard to use. Get rid of it.
  6. “New developers are productive after about one month because they have to learn our company framework first”
    See also #2. What justifies an initial one month learning period? What if one of our team members suddenly gets ill and the deadline is approaching fast? We can’t just hire a temporary developer and continue.
  7. “No, this nasty bug still isn’t fixed because it’s somewhere deeply inside our framework and the original developers left, sorry”
    Frameworks are usually meant to facilitate a broad range of applications and can be fairly generic, abstract and complex. It all made probably perfectly sense in the heads of the original developers but without their guidance we’re lost. If you have an application framework, the least thing everybody needs to know is the underlying vision of it.
  8. “Yes, we know it’s slow as @#$% but we can’t make it faster unless we completely bypass <component y>.
    Did component y threat you not to use a better suited alternative? I don’t think software components do that. Bypass it immediately. There is no excuse for a slow application.
  9. “It’s so flexible, you can configure everything in XML”
    What this really means is “it’s so flexible, you have to configure every darn little thing in XML and you won’t have any free time left, ever”. If possible choose sensible defaults and cut down on the configuration as much as possible.
  10. “I hear that <vendor x> is cancelling <technology y>. Did you see that coming? And didn’t we base our entire product on that?”
    It looks like your significant other has left you the cold. You have been in a relationship with a liar and a cheater without even realizing it (those cases of #1, #2, #3, #5 and #8 were actually a sign). Take your loss.