Rediscovering front-end development - Part I

Front-end development for the web is all the rage these days. But having spend the last few years developing .NET and ASP.NET applications, developing a modern web front-end is not an easy task. This will be the first post in a series of blogposts I hope to write about my team’s rediscovery of front-end development. In this first post I will focus mostly on providing some context. Future post will dive into the challenges we faced and explain how we managed those.

A brief history

As with all projects, in order to know where you are heading, you first have to look at where you came from. In our case that takes us back about 8 or 9 years, right about the time the team (at that time, I was not yet part of the team) had to build our current front-end. At that time Microsoft had just launched mature version of their proposition for rich client applications in the browser: Silverlight 3. At that time it felt like a natural step to build a Silverlight application to replace our ASP.NET front-end.

Perhaps it’s a bit of a cliché, but back then the world was a simpler place. Most of our user base had a simple, if outdated (even then), windows machine which ran it’s default browser: Internet Explorer. Firefox was hardly used, Chrome wasn’t around yet and Netscape had recently died. So there were no concerns about our users not being able to run Silverlight applications. A year later Microsoft released Silverlight 4 which even provided support for Chrome, easing any worries we might have had.
Sadly, when Microsoft released Silverlight 5 in late 2011, they also announced they would not continue active development on Silverlight. Yet, they would be supporting it for another ten years. Now, roughly five years later, Silverlight is only officially supported on the latest version in Internet Explorer on just a few versions of Windows. Chrome and Firefox will no longer run Silverlight and even Edge, the successor to Internet Explorer 11, does not know what to do when served a Silverlight application.

Rebuilding the back-end

Already expecting that Silverlight wouldn’t make it the full ten years, we have started preparing for a migration to another technology stack a while ago (perhaps two years or so ago). Originally our back-end was exposed by a series of SOAP services serving a Silverlight specific binary format. We been gradually replacing them with REST services. This served two purposes: first, rebuilding them as REST makes them a lot easier to use from most frond-end frameworks. Second, replacing them allowed us to split them up in smaller services, each focussing on a single functional area. In a way we have been moving them a bit in the direction of microservices.

Present day

With our history out of the way, let us take a look at our current situation. We are now faced with the challenge of replacing a fully operational Silverlight application with a modern web front-end. A tasks which will have to be accomplished while maintaining and supporting the current front-end. This means time is not our side. The longer we take, the more expenses we make in maintaining the current front-end.
The current front-end integrates all functionality in a single shell, forcing us to replace the entire thing at once.
These two points directly lead to the first requirement for the new front-end: it should be modular. After all, the back-end has already been split in functional areas. This should be possible for the front-end as well.

Ideally we would select a framework which will be around for the next decade or so. Sadly, that is not the way the HTML5 world works. Most frameworks only have a few good years before everyone seems to forget about them. As new standards emerge, so do new frameworks. All you can really do is build your application in such a way that you can reuse most of your code once the time comes to move to a new framework.

While looking for a suitable Javascript framework we settled on Aurelia. Aurelia satisfies our two main criteria quite nicely. First-off it’s minimally invasive. It has been designed with portability in mind. Aurelia offers a lot of functionality straight out of the box, like:

• a Binding/Templating Engine
• Dependency Injection
• an HttpClient
• a FetchClient
• and much more!

All of these are optional however. You can select the perfect component for the job, be it the one Aurelia provided or one from another framework.
Aurelia also satisfied our other requirement: it has native support for modular applications. Aurelia allows for additional apps to be instantiated which allow you to run other webapplications within your webapplication. More on that in my next post!

This already brings me to the end of this post. Just reiterating our history takes up a lot of space. From my next post onward I will be diving into our actual development challenges and solutions. The next post will focus on designing, implementing and integrating the modular front-end applications.

Until next time!