JavaScript for .NET Developers – March 2015 edition

The last couple of years, many .NET developers are making a gradual shift from developing  Windows and/or server-side ASP.NET applications to client-side JavaScript apps, myself included. That is not really specific for .NET developers, it happens elsewhere too. What is specific, are the tools and frameworks that .NET developers tend to use to build these JavaScript apps.
I’m suspecting that the vast majority of the .NET community went through the following stages:

  • 2005-2007: ASP.NET AJAX
    This new ‘AJAX’ thing is all the rage, but we really don’t want to write JavaScript. Love those UpdatePanels!
  • 2007-2011: jQuery
    We still don’t want to write JavaScript, but ASP.NET AJAX is way too clunky and jQuery is supported by Microsoft, so hey, it must be good!
  • 2011-2012: KnockoutJS
    jQuery spaghetti becomes unmanageable but luckily, Steve Sanderson ports the MVVM concept from WPF and Silverlight and we can build proper client-side apps. At one time, KnockoutJS was even part of standard Visual Studio templates
  • 2012-2013: Durandal
    Based on KnockoutJS and RequireJS, Rob Eisenberg (of Caliburn fame) creates Durandal, which is a complete framework. Now we have a one-stop shop for all our needs. No hassle with 3rd party libs for routing etc. anymore.
  • 2014: AngularJS
    Some influential .NET people have discovered Angular. Two-way binding without those pesky observables and it’s backed by a real big company. Hurray! Even Durandal creator Rob Eisenberg joins the Angular team, so that must really be the best thing since bread came sliced.
  • 2015: Unkown
    Wait, whut?!
    In october 2014, AngularJS 2.0 was announced as a being non-compatible with the current 1.x version and a month later, Rob Eisenberg announced that he’s left the Angular team. BOOM!!! Suddenly, AngularJS wasn’t the coolest kid in town anymore and the .NET/JavaScript community is kind of left in the dark where to go now.

The Framework Vacuum


After the Angular 2.0 announcement, some of us went desperately looking for alternatives like React, Ember or even VanillaJS, some went back to their trusty Durandal or Knockout codebases and wait for Aurelia to mature and perhaps most of us just continued on the Angular 1.x stack. But there is no clear leading framework or library anymore.

And that is good.

Not having a dominant framework or library or whatever, forces us developers to think about what we really need instead of the cargo cult mentality that has been so prevalent the last  years. Take the time to do a proper analysis of the problem you need to solve.

And that is good too.

When starting a new project, just pick the framework that is the best fit for the project at that time, taking into account the particular skills and knowledge of your co-workers.
It’s impossible to predict which one will survive the next years. Just don’t go all in with a single framework. Keep your options open. Also keep considering full server-side apps. They’re terribly out of fashion but unbeatable for some scenarios.

Some people advocate the use of no framework at all, but only use small, very focused libraries (microjs) or write everything yourself. Personally, I think that only a very, very skilled team can get away with this because you’ll end up building a framework anyway.

Meanwhile today

Having some kind of framework vacuum these days gives us a nice opportunity to focus on other important aspects of modern day JavaScript development.

Javascript build tools

Invaluable. Automate everything from building and minifying JavaScript to deployment and everything in between. You could use ASP.NET bundling for this, but in my experience, dedicated build tools are much more powerful and flexible.

Grunt and Gulp are the main players. Grunt is widely used, has a huge amount of plugins but isn’t really fast and can be somewhat complex to configure, Gulp is faster and requires less configuration than Grunt and is generally preferred these days.

WebPack might be an interesting alternative. It’s not a general purpose build system, but focuses on bundling. A unique feature of WebPack is that it can bundle all parts of your application into a single bundle, including images and stylesheets.

Javascript modules

You should really put your JavaScript code in modules. It allows for better encapsulation, modularity and prevents polluting the global scope (the window object in browsers).
There are multiple ways to define modules in JavaScript: AMD with RequireJS and CommonJS with Browserify are widely used, but with ECMAScript 6, native modules are coming as well. AMD allows for dynamic module loading in the browser where CommonJS/Browserify always requires a build step. On the other hand, I personally find the AMD module syntax intrusive, RequireJS requires way too much configuration and a build step is required for your production builds anyway. I’d say use CommonJS/Browserify for the time being and reconsider when ES6 is ready.

Javascript package managers

Still using NuGet to pull in JavaScript libraries and frameworks? Please don’t. Use Bower, NPM or JSPM (can use Bower as well as NPM). All major JavaScript libraries are being released for Bower and NPM where NuGet comes as an afterthought (if at all).

ECMAScript 6 (ES6)

ECMAScript 6 is the next incarnation of the JavaScript language. Although native browser support is not there yet, there are so many interesting features that you might consider using it today. Transpilers like Babel or Traceur can turn your ES6 code into ES5 code that runs in all modern browsers. With the JavaScript build systems it’s super easy to add a transpile step so there are no real obstacles.

Visual Studio 2015

While it can be refreshing to step out of our trusty Visual Studio Environment, it’s good to know that Visual Studio 2015 will get support for Gulp, Grunt, Bower and NPM.

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.