1 June 2020

Blazor: Five reasons to use .NET for your front end development

Is web development a thorn in your side? Every tech company, from startups to large enterprises, must now operate on the web in some way. Maybe your entire product is a web application, maybe it has a simple web front end for management and configuration - either way, you probably have two streams of development, one for the back end and one for the front end. And chances are, your web interface is coded in the inevitable Javascript. So what does that mean for companies like yours who primarily use a .NET stack and C# for their development? A headache, most likely!

You now have two different tech stacks, two different sets of skills, two different ways of deploying and maintaining code, very probably two different swimlanes in your project management board, and maybe even two distinct teams or sub-teams, one to handle each end. Wouldn’t it be better to rationalise your tech stack and increase your productivity by using one single team and one single language for both your front end and back end?

Well, it’s possible! There’s no reason to use Javascript anymore, and we’ll tell you why. Here are the top 5 reasons why you should start adopting .NET for front-end development right now.

5. Your company is already C# focused

You already have invested in a .NET stack and architecture. Your team is staffed with C# developers. You have the tools you need to deploy and manage your code easily. You know this way of working is a solid, reliable foundation for your product.

But when it comes to front end development, it might seem like you have few options. You can outsource your web interface. Or you can hire front end developers who won’t be able to work on the core back end services of your product. Or you can have a few of your developers doing the front end on the side.

Depending on their experience and their background, developers might not pick up front end skills quickly, or they might even hate doing it! To a C# developer, having to work with Javascript can feel like a demotion: both because Javascript is messy, and because, while they’re wading into JS debugging, that developer is not expanding the .NET skills that they (and your company) rely on.

Wouldn’t it be much better to be able to handle the front end and the back end with the same tech stack, the same language, the same libraries - and the same developers?

4. Javascript is less than ideal for C#-first teams

There are many pitfalls with Javascript, especially for programmers coming from C# and other object-oriented languages. You can find a plethora of articles on the Internet explaining why, but here are a few reasons to start:

  • The lack of strong typing in Javascript leads to errors, which are hard to debug - JS will happily chug along with an error and pass it downstream, before the issue causes an error all the way down the line. This makes it difficult to diagnose the problem: cue endless “alert” debugging messages to understand where the original error originated from. To someone used to C# exception handling, it’s torture.
  • There are as many ways of doing things in Javascript as there are developers. Which is great… until it’s not. A non-expert can easily get lost in a thicket of possible implementations that don’t work, and code reviews might just become arguments about the merits of different JS libraries and packages.
  • Javascript is notorious for not working as you think it will. Browsers are not standardised when it comes to interpreting Javascript, leading to a lot of time wasted checking how the code behaves in different browsers.
  • It’s easy to get started with Javascript, but it’s also almost impossible to master. The Javascript ecosystem changes incredibly fast; by the time you’ve become an expert at your preferred library or framework, another one will have come along. Competing JS frameworks are popping up all the time, and existing frameworks often release new versions that break existing code. A developer might learn React, but then everything moves to Angular - so now they need to learn Node.JS and Typescript.. and then a new framework comes along! It doesn’t make for stable code, and time is lost porting code from one latest framework to another.
  • If page speed is your main concern, Javascript can be a headache. Not only can the loading of the scripts themselves take significant time, but render-blocking Javascript execution in the browser can make a web page load as slowly as if it were 1999. If the page content above the fold does not show fast, not only will Google not like it (and penalise your Google ranking as a result), but most importantly your customers will be frustrated, and will be put off your site. Removing render-blocking Javascript and troubleshooting speed issues can be very time-consuming - not ideal when only a few of your team can handle this task anyway.
  • Then there’s the simple fact that Javascript runs exclusively on the browser, and you have to split the logic between server-side and client-side - which are on different stacks, and in different languages.

Of course the support for Javascript is plentiful, in terms of frameworks and libraries (maybe too plentiful - remember those competing frameworks!). But that still doesn’t help you rationalise your code, your tech stack, or the way your team operates.

“This is all very well, but what can I use instead of Javascript?”, I hear you ask.
Enter Microsoft Blazor.

3. Blazor is here to help

Microsoft Blazor is a new .NET framework that you can use to develop interactive web front ends. It is based on existing web technologies like HTML and CSS, and it allows you to use C# and Razor (the ASP.NET programming syntax) instead of Javascript.

There are two flavours of Blazor. One, Blazor Server, runs all the logic on the server, in the usual ASP.NET way. The version we’ve been waiting for, though, is Blazor WebAssembly, in which Single-Page-Apps (SPAs) written in .NET can run directly in the client browser. And that’s where things get very interesting.

In Blazor WebAssembly, both the client and the server code are written in .NET, allowing you to share code and libraries between both sides. Because it’s .NET code at both ends, you can reuse your existing server-side code and your existing libraries to create the client-side part of your application. So Blazor allows you to build reusable web UIs, on a stable platform, using .NET end-to-end.

Blazor also solves for speed: it runs your client-side C# code directly in the browser, at near-native speeds - this is thanks to WebAssembly, which ships in all major browsers now. No need for additional downloads or plugins: WebAssembly (WASM for short) is a new standard, the fourth language to run natively on modern browsers, bringing it to par with CSS, HTML, and JavaScript.

Blazor is also flexible. First, as we mentioned, there’s an option for Blazor to run all the logic on the server side if needed. Second, Blazor WebAssembly gives you a choice of languages to choose from, so it doesn’t require you to only use C# on the server side (anyone for F#)? In fact, you don’t even need to use .NET on the server side at all! If you already have a legacy back end written with PHP, Rails, or anything else, you can still write .NET client side code to run against it. Pretty neat, uh?

So you can see that if you’re a C# focused organization, Blazor represents a huge opportunity to expand out into front end development, and rationalise your tech stack.

2. You can simplify your tech stack and enhance your team’s productivity

There is nothing more frustrating than having a list of front end features waiting to be implemented, while your back end team sits idle! We’ve seen this happen too often to mention, when front end and back end stacks are different from each other: only some developers feel comfortable tackling the web interface features, and that means you effectively operate on reduced capacity.

Now that you know that you can adopt C# / .NET for your front end programming, not only can you rationalise your tech stack, but you can also now utilise your team at its maximum capacity. Because code and libraries are shared, it’s easier for a traditionally back-end engineer to start learning the front-end code - and you now have a path to turning all members of your team into full stack developers. This will result in a huge productivity boost: suddenly all your existing C# dev teams can start handling the web front end work as well as back-end services.

1. Switching to Blazor maximises your options

The best thing about Blazor is that it opens up your options for taking gradual control of your front end. If you don’t feel your own team is ready to go all-in with web development yet, then you can hand over the initial Blazor implementation to an outsource team. With that stable basis, your own development team can start dipping a toe in by reviewing the code, troubleshooting it, and gradually enhancing it. This gives you the option to bring your front end completely in-house later down the line, as your team will now have the skills needed to confidently expand and maintain your web code.

0. (Special bonus reason!) Sharing model code between client and server eliminates a lot of headaches.

One perhaps unexpected although obvious with hindsight aspect that our in-house devs really enjoy: you can write data transfer objects and models in a shared dll and use them in both client and server. No need for reverse engineering an object model out of swagger definitions or any of those other pain points - your front end and your back end are literally talking the same language - priceless!

If you want to start with Blazor, consider collaborating with a partner like Oscore - we would be more than happy to explore your options and get you started on the path of C# web development. Reach out to us today to chat about your project and requirements.