Goodbye KnockoutJS, you were a good friend

One of the things we love about working in an agency is the ability to have so many new greenfield projects constantly kicking off. It’s meant that over the years we’ve always been able to try out new Microsoft technologies as they come out or at least update to the new frameworks when they’re released. It’s why most of our active projects are now running on .NET 8! We get to enjoy the fairly bleeding edge of tech on products which in turn reduces costs for our clients. Everyone runs their infrastructure in the cloud these days (we’re all about Microsoft Azure, obviously) and performance increases in the new versions of .NET can lead to efficiencies that mean reducing the instance sizes (cost) as the code gets more performant. But we digress…

One of the ‘skeletons’ in our closet is a front-end JavaScript framework called ‘KnockoutJS’. Back in the early days of MVC frameworks (like .NET MVC and Razor Pages) we were keen on introducing more modern UX to some of the pages we were building for clients. Rather than doing full page refreshes we started playing with what was then a highly regarded and Microsoft promoted framework called Knockout. This was a great stopgap in the JS world to be able to have a better framework for handling the data binding on the view rather than doing everything by hand with vanilla JavaScript (or JQuery at least).

It was always going to be a stopgap as we waited for Microsoft web technologies to evolve (and evolve they did!) and with the introduction a few years ago of .NET Blazor we started to build components and then pages in this new tech and did away with the KnockoutJS frameworks (and as much JavaScript as possible, to be honest!).

Technical debt is a real problem in app development and just because we’re often working on the shiny new things doesn’t mean we’re not also working on some of the older stuff we’ve built years ago. Besides, most of our clients are with us for years and years, evolving their products, reacting to user needs and using Bad Dino as the ‘tech arm’ of their business along the way. So over the past year or so we’ve often been faced with a decision when new features are being discussed on some of these older platforms…

Do we build these new features into the existing KnockoutJS framework or do we start moving everything over to a more modern Microsoft technology, like .NET Blazor?

Well, it’s not a one size fits all decision and for some we’ve decided the change isn’t big enough to warrant what will most likely be entirely transparent to the end user (a very common pitfall of startups, thinking the tech architecture is what is holding them back!). But for others, we’ve had a whale of a time migrating whole modules of apps over to the new .NET Blazor way of doing things.

Luckily .NET Blazor can be used in one of two ways in any modern .NET project – either running as Blazor Server or Blazor WebAssembly. The latter is our weapon of choice but for the projects where you don’t want to remove all of the MVC / Razor Pages parts of your apps, you can just implement Blazor Server into your existing web app and then drop some Blazor components in.

It’s not a silver bullet and Blazor Server does have some constraints (needing a permanent connection to the internet for one – and usually a fairly decent one at that) as everything is rendered on the server still and sent down to the browser. We see this as a stepping stone to moving to full Blazor WebAssembly, but doing it just a few steps at a time. But anyway, it’s certainly better than writing JavaScript!

If you have an existing .NET project with some old (or sometimes even new!) JavaScript frameworks kicking about (like KnockoutJS or anything ending in JS, really) and are in the need of some modernisation rather than continuing to build in these less modern frameworks then give us a shout. We’ve been using .NET Blazor since it was pre-production ready – we’d like to think of ourselves as one of the pioneers of .NET Blazor in production environments - as well as .NET MAUI, but that’s for another post!