Along the same line as the TypeScript talk, Mads Thorgersen and Dustin Campbell did a great talk about the future of C#, opening with some statistics that show how loved and widely used the language really is. Even though I am very much in love with F#, I am also quite happy doing my work in C#, as I have been for 14 years, so it is nice to see innovation in the language continue, and especially that they keep on drawing inspiration from F#.

More...

The next pattern I want to take a look at, that is fundamental to how many JavaScript applications are structured, is the Controller pattern.

There are different definitions for what a Controller is on the client, depending on what framework people are used to working with. As you may know I often recommend not using a framework, but I go with the definition that a controller encapsulates the UI logic for a part of a web page. A common practice is to have controllers take the html element that it works on as the first constructor argument, followed by dependencies (services and other controllers) and possibly an options object. This will resemble what you are likely doing if you are writing eg. an MVC application in ASP.NET MVC or WebAPI. In much the same way, this allows you to pass in dependencies, and keep the controller free of hardcoded dependencies.

I have been working with TypeScript for quite a while now, and I really enjoy how the strong typing enables better tooling, as well as more understandable code, where the patterns of old look more like themselves, than they do in plain JavaScript. With the adoptation that TypeScript has seen in the last couple of years, I think it is safe to say that it is a good bet going forward, so if you are not already on board I highly recommend it. I will bet your time is better spent with languages and patterns, than they are learning the framework flavour of the day – although they do in themselves provide inspiration for patterns.

More...

I have been happy working with TypeScript for quite a while now, and I am happy to say that things are moving ahead with the language quite well. It is not that long ago that TypeScript version 2.0 was realeased, and with steady releases we are now at version 2.3.

One of the big things that came to TypeScript in version 2.0 was discriminated union types and the option to do strict null checks, which combine quite nicely. Discriminated unions are simply done using the pipe operator, and the compiler will do strict null checks if you use the --strictNullChecks switch. More...

One of the nice features of functional programming languages like F# is the lack of null. Not having to check for null every where makes code a lot less errorprone. As the saying goes "What can C# do that F# cannot?" NullReferenceException". Tony Hoare who introduced null references in ALGOL even calls it his billion-dollar mistake. The thing is that although this is quite a known problem, it is not trivial to introduce non nullable types into an existing language, as Anders Hejlsberg talked about when I interviewed him at GOTO back in 2012.

With version 2.0 of TypeScript we do get non-nullable types, which has been implemented as a compiler switch --strictNullChecks. More...

Pleanty of people have said that concurrency and functional programming are becomming essential to developing modern systems. Some have even gone so far as to say that if you don't adapt you will become a maintenance programmer in a few years. With the increasing need for concurrency to provide speed and handeling of huge amounts of data, I beleive it to be true. I do however beleive there will still be pleanty of smaller applications, so I am not predicting doomesday for anyone quite yet.

More...

I was asked to do a talk about Single Page Applications and Angular 2 in a couple of weeks. At first I was a little sceptical, because Angular 2 is far from a finished product yet. After agreeing that the main points could be around SPA architecture, TypeScript and how you can build these kinds of applications without using a framework I said yes. So lately I have been working on the talk and the first part has been quite easy to do. Yesterday I got started on demoes, and dived into Angular 2 for real.

Fantastic times! I just got back from a week off around easter, summer is almost here and I was awarded Microsoft MVP for ASP.NET/IIS for the first time. So all I that is missing is getting some blogging done.

At the moment I am really enjoying TypeScript, and I am feeling really good abouts future with the recent collaboration between the TypeScript and AnguarJS teams. I still argue that in most cases where you want your solution to live long, you should avoid the SPA frameworks. However I concede that they are popular, so it is a good step for TypeScript, which I think will help the adoption. I also think it will be good for Angular 2.0, to avoid introducing their own new language, and instead get the benefits of the good work done on TypeScript itself as well as tooling.

More...

As the design notes for C# 7 reveals, Microsoft are thinking about introducing pattern matching into C# in version 7. I was really happy when I first heard this, because pattern matching is one of the things I often miss from F#, where I wrote about the joy of pattern matching way back in the beginning of 2008. It doesn't get much more nice and succinct than this.

match value with
| "a" -> printfn "The value was an a"
| "b" -> printfn "The value was a b"
| _ -> printfn "Unknown value"

More...

Lately I have been speaking quite a bit about building Single Page Applications. Most recently I have been arguing that we skipped the discussion of weather or not we need a framework at all to build a Single Page Applications? Everyone quickly got into the battle of the frameworks, and argued about the good and bad parts of Angular, Ember, Durandal and a bunch of other contenders to the throne. These days I would argue that Angular won, which is supported by google batteling the frameworks, looking at training courses offered and joblistings. As a .NET developer this is furtner obvious now that AngularJS is part of the ASP.NET package, and samples are showing up that use it for Apache Cordova applications, which are also being embraced by Microsoft.

However, the more I have been working with these frameworks, the more I have started to question their actual value. At least to a point where I think it is something we need to think more about, when choosing which way to go. Sure frameworks give you a nice package that tackles application structure, routing, templating, two-way binding and dataaccess - but at what price? Using a framework, always means letting someone else decide a lot of things on your behalf, and it means taking a dependency on a large codebase. So in this blogpost, I will try and make the case for growing your own architecture.

You might think "so what, we do that all the time, we shoulden't be reinventing the wheel and what does it matter to depend on a framework". If they provide enough value I would surely agree, but it should always be measured against the risks of vendor lockin, issues with breaking changes, performance implications and restrictions on growing your application going forward. With a fast evolving web, these issues are very real. A framework might still be a good choice, but we need to at least think about the pros and cons.

Two-way binding is a huge sinner when it comes to performance and modelling restrictions, if the model chosen is not right for what you are building. Breaking changes are hurting developers daily, and with both Angular and Durandal looking to be complete rewrites for their next versions - so if you use them, you will be stuck with the current version, or you will be doing a rewrite of your own fairly soon.