How I came to this point

I have many years of hands-on experience from developing browser-based user interfaces with ReactJS, which is a dominant JavaScript (and TypeScript) based library for doing just that. To be exact, I have been developing software almost on a daily basis with ReactJS since 2017. Before that, I used more primitive JavaScript libraries for UI development for about 7 years, beginning from around 2010. Before 2010, I implemented many browser-based user-interfaces with Flash-based Adobe Flex, from around year 2008 until 2010, when the announcement came from Apple that they would kill off Flash support in their browser. To me it appears that Adobe Flex was the precursor for ReactJS that would emerge years later. Adobe Flex was very similar to the early versions of ReactJS. From developer’s perspecive the major difference was that it used ActionScript3, not JavaScript, as the programming language. ActionScript3 was a programming language similar to JavaScript but it supported types. Therefore, ActionScript3 was actually something a bit similar to TypeScript programming language, which would emerge a decade later.

For these reasons, it felt natural for me to learn ReactJS when it came around in 2017. Years later, in June 2023 to be exact, a twist of fate blew me in to work on a project at Mobidiag (a Hologic company). I took the challenge and started coding with Blazor on .NET.
It was easy to get coding productively with Blazor. That’s mainly because Blazor is awesome but I was able to handle it because I was already familiar with C#. After all, I had been writing backend code with C# at Expak from March 2013 until March 2017. C#, on the other hand, was very similar to Java, which I already was familiar with since 1999. Anyway, Blazor was like a mixture of many things that I already knew. But most essentially it was like coding a ReactJS project with C#.

thrown-by-whirlwind

I really liked it with Blazor and .NET at Hologic. But three quarters later, I happened to be working at a desk next to an open window and a gust of whirlwind blew me away to another customer. After landing in that other place I looked around and saw new faces around me. They asked me to start coding for them with ReactJS and TypeScript. I said, give me a break it doesn’t work like that. Let me first grab a coffee and please give me that desk in the corner - not the one next to the window! So I found myself coding again with ReactJS. Just kidding! It wasn’t actually the whirlwind, it was the tram! :)

Anyways, it turned out that I had come to a pretty good place. It’s also great that I have been having an opportunity to bring my skillset on React up-to-date again. On the other hand I can compare it again with Blazor and .NET from a little different angle.

How I compare ReactJS and Blazor now

On JavaScript side, there are some really important libraries that make React programming a lot easier that I couldn’t find for Blazor. The first thing that comes to mind is the Styled Components library that really makes React coding fun because you can smoothly embed CSS in React components. Read my previous blog post to understand why I appreciate it so much! Another thing that disturbed me with Blazor that I could not find a proper state management library, which was a bit problematic yet not impossible to round-engineer. It scores for JavaScript for which there are many good state management libraries such as Zustand that I have been recently using. It’s noteworthy that by the time of writing this, Zustand has taken the crown from the previous king of the hill, Redux toolkit, which now has less than 3 million weekly downloads compared to Zustand’s over 4 million.

The ways how Blazor on .NET is superior

Having said these things about ReactJS, I feel compelled to praise Blazor for a few very important things which may tip the scales in its favour in certain sense. How you can manage your packages and subprojects in a .NET environment is superior to the mess of JavarScript and NodeJS.

Let’s say that you want to share code between your projects. A very typical situation is that you need to build multiple different versions of your software that all contain some special code yet also sharing some common code. Just google and you find many recipes to do that but it seems that all of them are in one or another way flawed. You got Yarn workspaces, Lerna workspaces, you got Vite, you got Webpack, you got multiple entry points etc. Should you use a monorepo or perhaps after all just Git submodules?

What you have is a really fragmented landscape for managing subprojects and shared code. There are hundreds of chefs offering their own recipes while messing up the kitchen with their own breaking changes. This is the JavaSript world.

There are Solutions

.NET is a more managed ecosystem than the JavaScript jungle. There are solutions - literally, those things called “solution files”. The way you can create projects as “solutions” and split them into sub-projects with solution files is a really neat and solid - ehm, solution, itself! Read more about .NET solution files and class libaries.

I even personally created an example for you about how to split a main project to two sub-projects. Checkout my Kalabaw Foods Demo App to demonstrate how I created a main project that is then split into two sub projects, the Frontend and the Database solutions.

Okay, enough for now. I’ll be back to problems and maybe even solutions! Until then!