Dear Blazor, I met you when you were still in your infancy. I started playing with you when you could barely stand up...

The Promise

Even though you were still frail, your ambition was exciting: to allow developers to create web, desktop, and mobile applications using only C# and Razor. Not bad at all. It was a bit like dreaming of becoming an astronaut when you grow up. 🧑‍🚀

You started with the web, promising to dethrone JavaScript and do much better than that old-timer. You promised that developers only need to know C# and Razor to create efficient web applications, whether they run on the server or the browser. No more complications to make a SPA communicate with the server. You, developer, create your components in Razor and all the logic in C#. The framework will take care of transforming everything into an application that runs on a web server or in a browser. Don't worry. Everything will happen behind the scenes in a linear and transparent manner. 🚀

Old Memories

Who knows why, but those promises brought to my mind something already seen: memories that I thought I had completely erased resurfaced. The promise of Web Forms resurfaced in my memory: a unified paradigm for web development, whether the application logic runs on the server or the client. The framework would have taken care of doing the right thing. This promise created quite a few disappointments at that time. Many developers who were approaching Web programming for the first time got confused. But perhaps now things have changed, times are different, we have different technologies. Blazor is not Web Forms. 🤔

What a Wonderful World

You, Blazor, have made it possible to create fantastic applications that run on the server and on the browser. You enabled components that can be shared between the server and the client. And your followers are not few. You have enchanted many. Not just those who hated JavaScript - that was easy - you also attracted those who were familiar with JavaScript. In short, your dream was within reach.

You enabled the reuse of the same Razor components in MAUI to create desktop and mobile applications, as you promised. Many .NET developers have started to idolize you. 😍

With .NET 8, you've gone further. Not only can developers use the same programming model to build server and client applications, but now they can decide at the level of individual components whether it should run on the server or the client. They can even decide that a component starts as a server component and becomes a client component. Crazy stuff! 🤯

A Crack in the Wall

Even though I have followed your growth, I can't say I know you well. I only played with you in a limited scope. I have a narrow view of you, I admit it. But the little I got to know about you left me a bit puzzled.

Ok. Many of the promises you made, you kept. But from what I could see, there are aspects that resemble me - no offense - more like a big deception. 😒

You promised that we wouldn't have to worry about JavaScript anymore, but every now and then there are things that you don't allow us to do. And so we inevitably have to communicate with the old man through JSInterop, and it's not a walk in the park.

You promised a unified programming model, where we didn't have to come up with tricks to circumvent programming problems that the not-so-simple coexistence of JavaScript and HTML has accustomed us to. I would have been a unified and consistent model where we create a component and don't need to worry about how and where it will be rendered and executed. The framework will handle everything.

So, we write an interactive auto component that needs to make an HTTP call to the server. Follow all the simple rules, but it doesn't work. Why? You also have to register HttpClient on the server. But why? Due to how the framework works under the hood. 😨

And what about the combination of render mode and interactivity management? How should I go about making my application today? Interactive WebAssembly or Interactive Server? But maybe it's better Global Interactive Auto, so it takes care of everything. The best way to get a headache is the day something doesn't work and you can't go back. As someone said, Blazor is absolutely amazing, until it’s not.

Then, you want to add support for authentication. A fairly common operation. Which application is without authentication nowadays? You enter a nightmare. How do I transfer the authentication state between the server and the client parts of a Blazor application? Well, just implement a few classes here and there. Why? Didn't you promise us that there wouldn't be any more need for tricks and gimmicks to do simple things? Yes, but this depends on how the framework works. 😞

Ok, now with .NET 9 you've simplified it, but only after your supporters went crazy trying to get the server and client to communicate about the authentication state. And in any case, it’s still a developer’s burden to tell you what to do to make them transfer the serialized authentication state. But wasn't the framework supposed to take care of these details?

A Big Deception?

What about the programming model you promised us? You had promised us that it was no longer necessary to know how JavaScript works, its interaction with HTML, etc. You had promised us a simple and unified model — a model that abstracts the underlying complications: HTTP, HTML, JavaScript, AJAX, etc.

I feel like you replaced a complex model based on standard stuff with YOUR model. Now, instead of knowing how HTTP, HTML, and JavaScript work, I have to understand how YOU work internally to create my applications. And then I wonder: where is the gain? 🤔

P.S. This letter is not meant to be a complaint against the work done by the Blazor team. It is merely an invitation to not trust abstractions when they are pushed too far. Not all complexity can be hidden behind an abstraction. Even if the model proposed by an abstraction seems to work, you always need to have an idea of how things work under the hood when they don't behave as expected. Be enthusiastic, yet pragmatic.