The Web


I have always held a passion for web development, it’s where my career started.  The whole web platform has exploded and I really believe that the gap between desktop and web applications is really narrow or nearly non-existent now.  This is a quick look at a few of the technologies I keep hearing lots about and have used to varying degrees.

Where do I start?

If you haven’t kept an eye on web technologies, looking now will likely blow your mind.  There are so many frameworks and picking the right one is a huge challenge in itself, and that’s before you’ve even opened an angle bracket.

JavaScript is just a scripting language

JavaScript is a dynamic scripting language and a lot of people use that as an argument against moving to web applications.  I think there is some element of truth to the thoughts behind this.  In the older days, JavaScript was tough, written poorly and suffered at the hands of the DOM.  I think we have come along way from this, ES6 supports classes and there are various ways to support encapsulation and inheritance, so it can be written in an OO fashion.

The other argument against is the fact its weakly typed and I have been caught out by this in some of my own applications.  I wonder if it’s just because I have spent so many years in a static language I have become complacent or do not fully appreciate weak typing.  That said, we have Type Script which is built on top of JavaScript and it does a great job of solving many of the issues you can get with weakly typed JavaScript.

I think the arguments against using JavaScript are closing down.  It’s still not perfect, but it is constantly improving and I don’t think we are that far away now.

Desktop Apps

In the Windows world, the defacto standard for desktop application development is Windows Presentation Foundation (WPF for short).  There were many reasons why the web just couldn’t deliver.  It runs in a sandbox, so no (well limited) access to the machine.  The performance was pretty poor for fast streaming data or huge grids, as popular when building financial applications.  These limitations have now gone and I think reasoning for picking WPF over a Web framework is dwindling.

The guys at OpenFin have written an impressive, really fast grid, built for the web.  What’s more they have published the source and accept contributions here.

Electron is an extremely popular framework for building desktop applications with JavaScript, HTML and CSS.  It’s a proven technology written by GitHub for their popular Atom editor.  Other big players use it too, such as Microsoft, for their Visual Studio Code editor.  Electron applications can easily run on Mac, Linux and Windows, with careful development.  It provides APIs to create windows (which can be highly customised, for example by making them frameless).  Electron is built on NodeJs which provides access to the file system, making web requests, accessing processes running on the machine and much more.  Because it’s a web platform, there are so many other frameworks you can bring along for the ride.

Web Apps

There are hundreds of application frameworks, KnockoutJs, BackboneJs and HandleBarsJs to name a few.  The two biggest single page application players (in my opinion) are ReactJs (written by Facebook) and Angular (written by Google).

Both React and Angular are fast.  React had the edge over AngularJS, although Angular have come back with Angular 2 & 4 and have made significant improvements.  One of their demos actually shows Angular 2 beating React, although I suspect in real terms the performance is negligible.

React achieves it’s blistering speeds by allowing us to manipulate a virtual DOM, which it then diffs against the real DOM and applies the difference.  DOM manipulations are well known to be expensive (performance wise).  I believe React also collects several changes and applies them once, so not every change will cause a re-render.  Changes are applied to the portions of the view affected and not the entire view.  Angular 2 & 4 has change detection which only updates the parts of the DOM that need it.

Both Angular and React have a routing module, that allows you to control navigation within your application.  Navigation is seamless since the application is running in the browser, it doesn’t need to perform a new get request for each new view.  Getting data is included in both frameworks through their HTTP clients to make requests to web services in a trivial manor.

Both frameworks also support bindings from components to the view and back again (although with React you’ll likely be binding to JSX, an extension to JS which looks like HTML, which React then generates real elements for).  In React you can pass data to components via props or through context if all components require it (Redux for example).  Angular has a similar concept called @input and supports dependency injection.  Both frameworks have the concept on uni-directional data/event binding.

React is a light weight framework, that is quick and easy to get up and running.  The learning curve is fairly shallow and it’s really lightweight.  If you need anything else, you’ll have to reach for another framework or roll your own.

Angular in comparison comes with much more, such as dependency injection and Type Script out of the box.  There is the concept of Angular modules, which bunch together related components, these can then be loaded up-front or on-demand.  There are directives, which are similar to behaviours in WPF, although in some ways better.  You can use pipes, which are similar to converters in WPF to change the shape of your bound data.  For enterprise applications, I would be more inclined to first reach for Angular as the tool of choice.  There are significant similarities to WPF, so the transition is not overly difficult for a competent developer to pickup.

Command Line Interfaces (CLI)

I have used both these frameworks in the early days and setting them up to build correctly can be time consuming (and sometimes painful) task.  Luckily both providers have introduced command line interfaces to quickly get up and running.  Package management for web is done exclusively through Node Package Manager (NPM) so you will need this.  Joining now is great, since we have moved away from multiple package managers, such as Bower.  I strongly recommend you try one of these frameworks out, to appreciate how quickly you can get started.


To get up and running:

npm install -g create-react-app

create-react-app hello-world

You now have a fully building and working project.  To run it, type:

npm start

Read more on the react git hub blog.


npm install -g @angular/cli

ng new hello-world

You now have a fully building and working project.  To run it, type:

ng serve

Read more at the Angular CLI Git Hub page.


There is a huge choice of editors out there, the popular ones are Atom (from Git Hub) and Microsoft Visual Studio Code for web development.  I use Visual Studio Code, although use the insiders version, to get the latest features as soon as they become available.  Both editors have a large contribution user base through extensions, so there are many additional options which can be bolted on.  There are extensions for everything, from helping to close angle brackets to colour pickers.

If you would like to write a service, using a technology such as Web API Core, then Microsoft Visual Studio has everything, although it’s heavy weight and only runs on Windows.  If you’re like me and have a Mac for development at home, then I love the JetBrains Rider (especially great if you’re a ReSharper fan).  It feels refreshingly lightweight and runs everywhere and have ReSharper shortcuts built in.  Microsoft offers “Visual Studio for Mac“, which feels pretty bloated, although looks good for Xamarin development.

Write once, deploy everywhere (almost)

If you’re building a single page application that can run in a sandbox, then it can quite easily run every where, in a browser, on a mobile device or on the desktop.

If you need access to the machine or to run outside of a sandbox for some reason, then you’ll need to build a desktop application, which can easily run on Mac, Windows or Linux, although not in the browser or mobile device.

Web Services/REST/Streams/GraphQL

If you’re building a significant application, you’ll likely require some data from a service.

Again, there are hundreds of frameworks.  Some popular choices include NodeJs+Express, Web API Core, Socket.IO, GraphQL and Signal R.  Services such as WCF appear to be dwindling, possibly because it’s an overly complex and bloated framework.

The NodeJs route is well established and well known for being lightweight and fast.  You opt-in to every part of the webserver you need.  You’ll likely write your entire service in JavaScript or Type Script, which might be an attractive option if you’ve already hired some web developers.

Micrsoft’s Web API is a huge, cumbersome framework with well known dependencies on bloated assemblies such as System.Web.  Luckily Microsoft have pretty much re-developed Web API to Web API Core and it follows a similar approach to NodeJs.  Everything is optional, down to supporting default file types or serving static files.  Because of this, it can run really fast (faster than NodeJs, if you believe Microsoft) and run on Mac, Linux and Windows.  No more huge Microsoft License fees for server operating systems, if you choose.  The framework is really easy to get started with and an attractive option for .NET developers.  If you have used ASP.NET MVC Framework, Web API Core is pretty much the same thing, returning data rather than HTML.

Both NodeJs (with Express) and Web API Core allow you to build ReSTful request-response services, although as mentioned in my RX – Everything is a stream! post, a lot of data is constantly changing and the request-response paradigm perhaps is not the best choice.  To accommodate streaming and bi-directional communication, there are a couple of choices that stand out, Socket.IO or Signal R.

Socket.IO is purely a JavaScript library and is really straight forward to get up and running.  It integrates seamlessly into NodeJS and front end frameworks.

Signal R is a Microsoft technology that integrates well with .NET backends, such as Web API Core.  There is a client side JavaScript library that is intuitive to use and only requires a few lines of code to get the basics working.  The framework has failover options to provide robust communication channels, for example it will use Web Sockets for its communication, although will failover to Long Polling should that not be available.


There is a lot to take in, although the community is making it very easy to get the basics up and running really quickly.  The introduction of a CLI for the front end, means all the boiler plate code is created for you.  The choice of back end technology is open, you don’t have to restrict your self to a particular technology stack all the way through and can pick what is best for your project.  The ability to run every where is appealing and the fact that updates can be seen immediately, reducing the need for old school installers.  I think the gap between traditional WPF desktop applications has closed significantly now and I think we have another exciting toolset at our disposal.





RX – Everything is a stream!


I’m a huge fan of Reactive Extensions (RX) and have been using it in a professional context for many years.  One of the interesting topics of debate between co-workers is when to use Tasks and when to use RX.  This post is about my opinion, which might be well off, but at least I have shared it and hopefully receive some compelling counter arguments. Continue reading

Installing Netatmo on a Worcester 38CDi Greenstar Boiler


We are at the forefront of home automation through the internet of things.  It’s a great time to be a programmer, since we have some unique challenges to overcome.  I looked around at a few smart thermostats, I was really impressed with Nest, it feels like a quality product.  Sadly they do not support Apple HomeKit and since the majority of my devices are made by Apple, it’s not an option for me.  Sure I can go down the Homebridge route, although why bother when there are some good products out there.

This post will show you how to install a smart thermostat, step-by-step with the use of images.

Continue reading

RX – What thread am I on?


Threading in RX is usually performed by a set of classes called Schedulers, that implement the IScheduler interface.  I have interviewed a fair few people who don’t fully understand what thread they are on at various points in the pipeline, especially when we throw in a few ObserveOn and SubscribeOn calls.

Continue reading

RX Replay’s Slow Consumer “Problem”

What is Replay?

We have been using RX for some time now although we still get caught out on the intricate details.  Replay is an extremely useful caching mechanism that allows streams to replay previous entries for new subscriptions, based on count, time or a mixture of both.

Under the covers it’s a multicast with a replay subject:

Observable.Multicast<TSource, TSource>(source, new ReplaySubject(bufferSize))

The Problem

Continue reading