Get 10$ Digital Ocean SSD Hosting Credit for free.

Pumped up about Angular 2.0 and NodeJS in 2016

This was 2015

This year was very eventful for me. It was my first year as a freelancer and I already graduated from that to the next level of entrepreneurship by taking the chance to join the sofware startup snapADDY as the technical co-founder. Awesome!

If you or your company has a marketing or sales team that researches leads online or struggles with CRM data quality, you will love what we do, so check it out!

At snapADDY we are heavy JavaScript users, mainly AngularJS at the front and NodeJS with Express at the back end. We are a team of 4 great developers right now, which will further grow this year. (Hint: We are hiring 😉 )

Rather than contemplating too much on what happened this year, I took some time rambling about the most interesting technological developments, that will affect us next year.

What will 2016 bring?

Adopting Gulp

Finally saying goodbye to Grunt and adopting Gulp. Grunt was very important to professionalize JavaScript development with a modern task runner tool for building, testing and process automation.

But after some time the flaws of Grunt became apparent. The Gulp way of using NodeJS streams, which enables in memory processing and easier configuration of the tasks is way more performant.
Many other projects already switched and now we do too. So goodbye Grunt, welcome Gulp!

ECMAScript 2015

The current NodeJS versions have it natively and for browsers there is BabelJS for now.

ECMAScript2015 is a big step forward to mature the JavaScript language. Really looking forward to block scoping, arrow functions, classes, modules and lots of other neat things!

Who knows? I probably won’t use the var or function keyword ever again! 😀

Angular 2.0 is coming

Official Angular Logo

Official Angular Logo

I read and tinkered a bit with the Angular 2 Beta the last couple of days. I like the concept of using components as the basic abstraction to structure applications and its usage of the web components API at base.

import {Component} from 'angular2/core';
import {Todo} from './todo';
import {TodoList} from './todo_list';
import {TodoForm} from './todo_form';

  selector: 'todo',
  template: `
    <span>{{remaining}} of {{todos.length}} remaining</span>
    [ <a href="javascript: false" (click)="archive()">archive</a> ]
    <todo-list [todos]="todos"></todo-list>
    <todo-form (newTask)="addTask($event)"></todo-form>`,
  directives: [TodoList, TodoForm]
export class TodoApp {
  todos: Todo[] = [
      {text:'learn angular', done:true},
      {text:'build an angular app', done:false}
  get remaining(): number {
    return this.todos.reduce((count, todo: Todo) => count + todo.done, 0);
  archive(): void {
    var oldTodos = this.todos;
    this.todos = [];
    oldTodos.forEach((todo: Todo) => {
      if (!todo.done) this.todos.push(todo);
  addTask(task: Todo) {

Taken from the official Angular 2 example plunker

With the new classes and annotations it now looks like a Java framework like GWT and I believe programmers coming from this world will like Angular 2 for that.
For people coming from classic HTML/CSS front end development and jQuery I believe the hurdle to get into Angular 2 will be higher, as there are more advanced object oriented programming paradigms to learn. With Angular 1 you could just start annotating your html a bit and have a simple “One Controller” application to start out and be amazed of two way data binding.

When going full Angular 2, it probably will make sense to use TypeScript, which is something I am not really sure about yet.
I am also curious about the migration from Angular 1; the first blog posts I read about this topic looked promising, that one will be able to gradually move your application over.
But I am actually not sure if we want to do this in reality or if we just start new projects with Angular 2 and keep the old ones in Angular 1 land, as it might not be really worth it economically (Angular 1 is still pretty cool I believe 🙂 )

I also looked a lot at the Polymer project by Google over the last years and I am curious about how the promised interoperability via shared web component roots will play out between Angular 2 and Polymer elements.

Pro tip: Check out the thoughtram blog about everything Angular 2 related, great stuff!

NodeJS micro service architecture

Even though I was certanily sceptical at the beginning, I never regreted choosing NodeJS as the main back end solution. Most other programming languages and frameworks try to be more functional, reactive and asynchronous. NodeJS has all of this out of the box!

An requirement for using NodeJS without headaches though is to have a firm grasp on JavaScript basics and to be familiar with its functional nature and the asynchronous event loop based approach. You can mess up way more in JavaScript than in PHP, Java or C# if you don’t know what you are doing.

But it is well worth to learn in my opionion. It is super easy to deploy and update your server, even without complicated continous delivery infrastructure: git pull, npm install, service restart -> Updated without much downtime.

NPM packages are also a very nice way to structure your application into many small projects, which I highly recommend. It makes your software easier to test and develop in a team.

Besides using NPM packages to structure your code, NodeJS is also great to put your application into multiple services, rather than running one monolithic server. This architecture principle became recently popular under the buzzworkd micro services.
This makes for a more resilient and scalable architecture, that again is easier to test and work in teams on. There is a great talk by Martin Fowler on youtube about this topic, although he disses NodejS a bit in it.
Another great case study for micro services is the refactoring of the Wunderlist backend led by Chad Fowler.

Finally writing automated tests for NodeJS with mocha and chai is very easy and they execute super fast, which actually encourages you to do more TDD.

PostgreSQL as a hybrid SQL/NoSQL database

To be honest: I did not want to go full NoSQL. Perhaps I am used to classic SQL statements and table structured databases. The possibility of using JSON as a type in Postgres intrigued me and we are using it as our database.
We actually have yet to really faciliate all the Postgres JSON features, but so far it just works fine! It is a database and it does what it should do 🙂

As it has not been necessary yet, we have not put much thought into using a cache in addition to the database, which will probably also become a topic in 2016.


After some quiet time with family over christmas, reading about the new developments and technologies made me very excited to start working in 2016 again. It will be an important year for us at snapADDY and the JavaScript ecosystem finally takes a huge maturation step with ECMAScript2015 being here to stay and Angular 2.0 knocking on the door.

go2016(); 🙂

Get 10$ Digital Ocean SSD Hosting Credit for free.

Handle asynchronous non-blocking IO in JavaScript


One of the big “WTF” hurdles for apprentice JavaScript developers, that come from languages that mostly embrace synchronous and blocking IO APIs like Java or PHP is to get into thinking asynchronously about everything IO related in JavaScript with its event loop construct.

The mind of a Java developer learning JavaScript

The mind of a Java developer learning JavaScript

It is actually one of the cool things about JavaScript and why NodeJS on the server got so much attention in the beginning, so it is something anyone at least half serious about learning JS should learn about.

What does asynchronous vs synchronous IO actually mean?

For any computer program to do something useful it is important to handle Input/Output (IO) operations.
IO is basically everything that gets in and out of the “container” your program runs in, like mouse or keyboard input, sending a request and receiving a response from a web service or reading a file from disk.
To handle this there are two different API models, one is synchronous and blocking, the other is asynchronous and non-blocking.
The illustration explains the basic difference between the two approaches.

Blocking UI vs Non-blocking IO

Blocking IO vs Non-blocking IO

The blocking IO approach on the left ‘waits’ for the response to come back until the program continues. The asynchronous program on the right however continues immediately and invokes a callback once the response came back.

From Callbacks to Generators

While handling blocking IO is pretty straight forward and intuitive, non-blocking IO can be confusing at first. The next part of this article gives concrete code samples of different ways of doing ajax calls in JavaScript synchronously and asynchronously. The examples make use of the jQuery library.

Synchronous/Blocking IO

The XMLHttpRequest API actually allows you to do ajax calls synchronously.
This is however almost never a good idea. Due to the single threaded nature of JavaScript your complete UI will be blocked while you do your call. It is even flagged as deprecated by recent Chrome versions

   url: 'doSth',
   async: false,
   complete: function(data){
  • People are often more used to blocking IO APIs
  • You block the UI thread
  • Bad user experience, as your complete UI hangs during the request

Callback Functions: The basis of non-blocking IO

This is the way the browser JS APIs such as DOM handlers are implemented at base. You register callback functions, that get called by the browser once the IO operations returns.
To use this approach directly however may lead to pretty ugly code. Novice programmers tend to build endless ‘callbacks inside callbacks inside callbacks’ chains, which are very hard to read, maintain and debug.

   url: 'doSth',
   success: function(data){
         url: 'doSthElse',
         success: function(data){
         error: function(err){
  • Asynchronouse IO gives the UI room to breathe
  • Code can get really ugly with endless callback inside callback chains

Promise objects: The ‘State of the Art’ in non-blocking IO

As a way to solve the ‘callback hell’ problem a design pattern called promises (jQuery also calls it Deferreds) got very widely adopted and integrated by popular frameworks.
When using promises you write your asynchronous function calls not by passing in a callback function, but by directly returning a so called Promise object.
As the name implicates this object ‘promises’ you a value.
The promise object is now the place where you can attach your callback functions. This makes it easier to chain asynchronous calls, while staying on the same nesting level.

var promise = $.ajax({url: 'doSth'});
   return $.ajax({url: 'doSthElse'});

Notice the callbacks get registered via the ‘then’ function on the promise object.

  • It is a relatively advanced concept for beginners to grasp for solving the simple problem of just chaining two async calls.

ECMAScript 6 Generators: The future of non-blocking IO?

ECMAScript 6 will introduce Generator functions to JavaScript. Generators are a programming construct that basically enable a way of doing iterations.
These iterator functions can be used to create synchronously looking code, that actually gets executed asynchronously in the background. A great blog post, that describes in detail how this will work in detail can be found on the website of Strongloop.

    try {
       var result = yield makeFirstAsyncCall();
       var finalResult = yield makeSecondAsyncCall(result);
    catch (e) {

The final code will look something like this. Notice the “function*” keyword, that marks a generator function and the “yield” keyword that marks the iteration steps inside the generator.
It will also be possible to do seemingly synchronous error handling with try/catch in this construct, without an extra fail or error callback as with the other async methods.
You can already play around with all the ECMAScript 6 goodness by using NodeJS 0.11.2+ with the –harmony flag.

  • Straight forward syntax, that looks just like a blocking API.
  • Still calls are really asynchronous, so the UI thread can breathe.
  • Enables programmers to easily write async code, without necessarily needing to understand it.


In retrospect really understanding asynchronicity and the event loop construct is one of the great things I took from learning JavaScript.
Besides the obvious benefit of writing better JavaScript applications, it opened my mind in thinking about other languages and frameworks too.
For example it recently helped me a lot grasping the concepts behind Akka, which is a framework written in Scala, that implements the actor model for distributed and concurrent computing.

Get 10$ Digital Ocean SSD Hosting Credit for free.

A look at AngularJS Material Design with Google Polymer in mind


After trying out Google Polymer and diving into the world of web components, I also got excited about Angular Material Design, that is currently heavily under development on GitHub.

The project’s goal is to provide a reference implementation of Material Design based on AngularJS.

AngularJS Logo

AngularJS Logo

Ionic Logo

Ionic framework Logo

Besides the core AngularJS developer crowd, it is also pushed forward by the guys behind the Ionic framework.
Ionic is an exciting looking new framework for HTML5 mobile apps based on AngularJS and Cordova.

To start off, let’s have a short introduction to AngularJS and Material Design.

The rise of AngularJS

Google Trends JS Framework War

Google Trends JS Framework War

I don’t know how statistically significant a Google Trends search is to judge the quality of a JS framework, but the graph pretty much shows, that AngularJS crystallized itself out of the mass of JS MVC style frameworks in the last two years.

It also is a common sight in requirements for open front end developer job and freelancer positions at the moment.

The main reason for the success is probably, that it is very well structured and the two way data binding makes it feel very productive.
It is also very tightly coupled into the actual html mark up and does not abstract away from it, which feels quite natural.
Besides the technical factors, the official support by Google probably doesn’t hurt either.

Material Design

Material Design is Google’s new cross device User Experience and Visual Design language, that got pompously introduced at the Google IO 2014 keynote. It plays with a paper and ink metaphor and makes heavy use of motion and transitional animations.

Design is always to certain parts a matter of taste, but the overall reception of Material Design is quite good I believe.

Angular Material Design

What Angular Material Design in this context now basically does is extending the Angular framework with custom directives, that implement the Material Design guidelines and also provide basic layouting capabilities.
It comes with Angular services for basic interactive elements and has theming support.

It can probably best be compared to the paper elements library of Google Polymer.

Inbox Style Application

To try Angular Material Design I attempted to create a Google Inbox style front end mock up.
Google Inbox is the fancy new interface for GMail currently in Beta with a lot of convenience features and handy batch operations.

Mock Up of Google Inbox style front end in Angular Material Design

Mock Up of Google Inbox style front end in Angular Material Design

Here you can see a screenshot of my attempt. It is obviously not quite there at the original yet, but it helped me to get the basic picture of the framework. I put the code on GitHub, if anyone is interested.

Mark Up

Lets take a closer look at the code:

    <md-toolbar scroll-shrink layout="row">
        <div class="md-toolbar-tools">
            <md-button ng-click="toggleMenu()">Menu</md-button>
                <span>Angular Inbox</span>
<!-- CONTENT -->
<div layout="vertical" flex>
    <!-- LEFT SIDEBAR -->
    <md-sidenav class="md-sidenav-left" component-id="left">
        <md-toolbar class="md-theme-indigo">
            <h1 class="md-toolbar-tools">Sidenav Left</h1>
        <md-content ng-controller="LeftCtrl" class="md-padding" flex layout="vertical">
           <!-- SIDEBAR CONTENT COMES HERE -->
    <!-- MAIN CONTENT -->
    <md-content id="main" layout="horizontal" layout-align="center">
        <md-list id="content">
            <div ng-repeat="chunk in ::chunks">
                <p ng-if="chunk.divider">{{chunk.title}}</p>
                <md-card ng-if="!chunk.expanded && !chunk.divider" ng-click="chunk.expanded = !chunk.expanded" ng-mouseover="hover = true" ng-mouseout="hover = false">
                    <md-item layout="horizontal">
                       <!-- CONTENT COMES HERE -->

Here you can see the very clear, declarative and semantic mark up of the page. It almost looks like a Google Polymer Web Components page, but without the Shadow DOM awesomeness like CSS scoping and of course due to the use of the directives API bound to the AngularJS framework.


For interactive UI elements like dialogs, toasts or a bottom sheet, Angular Material Design comes with ready to use Angular services. Here is an example of the ‘$mdDialog’ service:

app.controller("YourController", ['$scope', '$mdDialog', function($scope, $mdDialog) {

    $scope.openDialog = function($event) {
            targetEvent: $event,
            '<md-dialog>' +
            '  <md-content>Hello {{ userName }}!</md-content>' +
            '  <div class="md-actions">' +
            '    <md-button ng-click="closeDialog()">' +
            '      Close' +
            '    </md-button>' +
            '  </div>' +
            controller: 'DialogController',
            onComplete: afterShowAnimation,
            locals: { name: 'Bobby' }
        // When the 'enter' animation finishes...
        function afterShowAnimation(scope, element, options) {
            // post-show code here: DOM element focus, etc.

This is of course very useful.
Compared to the web components approach, where you can put your dialog into its own custom component with a real DOM template, this regular AngularJS service seems a little old school though.


    <link rel="stylesheet" href="/bower_components/angular-material/angular-material.css">
    <link rel="stylesheet" href="/bower_components/angular-material/themes/blue-theme.css">

Another cool thing is the theming capability, which can be achieved by simply adding an additional style sheet.


So here are some overall thoughts on the project, from what I could take from my first tinkering steps. These conclusions are based on the current ‘under development’ version in November 2014.


  • The high productivity of AngularJS
  • Material Design is cool (obviously depends on taste)
  • Designed from scratch for responsive mobile web apps
  • Theme support
  • Feels faster and more stable than Google Polymer at the moment (No Polyfills)
  • Makes use of Flexbox (‘float: left;’ my a** 😉 )
  • Supported by Angular and Ionic Team (Will probably be great for building HTML5 mobile apps in the future)
  • Will probably easily transition into the world of web components with AngularJS 2.0
  • Will probably be production ready with Angular 1.3 before Polymer

Update: Had a closer look at Angular 2.0 by watching this talk and it actually looks a lot different. So one might say a plus of the Angular Material Design project is, that you will get a MD based UI library with the current 1.3 Angular and without web components (and thus a more reasonable browser support for most current real life projects).


  • Not yet based on real web components like Google Polymer
  • Angular JS 2.0 will most likely not be backwards compatible (Probably some migration effort)
  • Still under heavy development (like with Google Polymer, every big update, breaks something)
  • Browser support (especially due to flexbox and Angular 1.3, IE 8 and 9 sadly still relevant 😉 )

But like Google Polymer, Angular Material Design is currently not supposed to be a production ready framework (as of November 2014).

Additional Note: Angular Material Design requires AngularJS 1.3.x, which might be a concern to some projects (thx @ Splaktar)

2015 will be exciting

It will be very interesting to see how frameworks will adapt to the web components and ECMAScript 6 era.
I can definitely see a bright future for AngularJS 2.0 with Material Design and Google Polymer.
My old buddy, the Google Web Toolkit, might even have a shot of experiencing a second awakening with web components in version 3.0.

If the web component promise of providing easy interoperability between all the different JS frameworks will hold up, 2015 and beyond could really change a lot in the still kind of weird distributed and siloed JS front end landscape.