Blazor vs Vue.js: What a C# Developer Actually Notices

Two frontends, one C# brain - what really differs, what is more alike than people admit, and what the job market says. Until 2019 my frontend was semantic HTML and CSS. Divs, classes, markup I could reason about. I was a backend developer and I was comfortable being one. Then two things happened. A company asked me to touch a Vue project, and Microsoft shipped Blazor. Over the following years I worked properly with both - Vue at two employers, Blazor on a personal project I still run. This is not a benchmark article. It is what the two feel like when your instincts are C# instincts. How I ended up in Vue In 2019 I joined Dolphin Software as a backend developer. Shortly after, they asked whether I could make some small changes to a frontend project. It had been written some time earlier by a remote developer in India, and it was written in Vue. The project was simple and the changes were light. I could have declined. I was curious instead. One detail I still remember: a surprising amount of the code lived inside quotation marks, as though it had been generated or processed by some tool rather than written by hand. I never found out what produced it. It was my first lesson in the real frontend experience, which is that you rarely start from an empty file. A year later I moved to one of the Ministry of Healthcare's agencies, during the coronavirus period. A large organisation means a museum of technologies: old ASP.NET pages, a lot of ASP.NET MVC, teams on Angular, teams on React. Vue was the main frontend technology when I arrived, and around two years later new projects started being written in React while the old ones stayed where they were. My project there was a storage system for pharmaceuticals. A set of users who could add, edit and delete drug records, with information about each one - when it was created, when it was imported, which company was behind it. Not a complex domain. A completely normal internal system, which is what most software actually is. We used Vue 2 with Vuetify, which is roughly Vue plus Material Design components. How I ended up in Blazor Blazor arrived with .NET Core 3.1, and I went straight to the Server model because it was the easy one. What struck me immediately was how much it resembled Razor Pages. I had written Razor. The syntax was familiar, the mental model was familiar, and Microsoft's documentation was good enough that I could find whatever I needed without hunting through forum threads. I tried WebAssembly out of curiosity and abandoned it. The build took a long time and the first load took a long time. If it was uncomfortable for me while developing, it was going to be worse for whoever visited the site. So VideoFloppy, my side project, is Blazor Server. It remains the only Blazor project I have shipped, and it is finished rather than abandoned, which I consider an important distinction. The similarities nobody mentions Most comparisons of these two treat them as opposites. From a backend seat they have more in common than that. Both are component-based. You build small pieces with their own markup, state and behaviour, and compose them. The file looks different; the thinking does not. Both have lifecycles. Something happens when a component appears, when its data changes, when it goes away. Once you know one, you are looking for the equivalent hook in the other rather than learning a new concept. Neither forces functional programming on you. This is the one I would emphasise to other backend developers. Vue with the Options API, and Blazor with plain C# classes, both let you write in the style you already think in. You are not obliged to restructure your brain around hooks and functional state management before you can render a table. And the same tooling serves both. If your API is a separate project, NSwag Studio will take the Swagger link and generate a client for you - TypeScript for the Vue side, C# for the Blazor side, from the same specification. You inject the generated client and call its methods like any other service. You will need to override the request method to attach authorization tokens to the header, and you can override the error handling too if you want to react to specific status codes. It is genuinely extendable, and it means the shape of your frontend-to-backend communication barely changes between the two. That last point is why both were approachable and why, for someone coming from C#, the distance between them is smaller than the distance between either of them and React. Where Blazor wins It is C#. Same language as the backend, same IDE, same debugger. Visual Studio is an excellent and fast environment and I never had to leave it. But the real advantage is subtler than "no JavaScript," and I want to be accurate here: I still use JavaScript. VideoFloppy uses Alertify for alerts and prompts - success messages, errors, the dialog asking for an album key. Blazor does not eliminate JavaScript. It reduces how often you need it. The genuine advantage was this: I did not have to learn Blazor and then build with it. Building was the learning. With a new framework there are two phases - study, then apply. Blazor collapsed them, because I already knew most of it under a different name. For someone with limited evenings, that is not a small thing. Where Vue wins Vue is light. It builds fast and it runs fast, and that compounds into real time saved across a working day. Blazor Server, by contrast, holds a connection to the server for every user, and Blazor WebAssembly makes people wait before anything appears. Vue's tooling gets complained about more than it deserves. Yes, there is npm, there are bundlers, there is a node_modules folder of alarming size. Honestly? It never hurt me. npm or yarn made no meaningful difference. It is a different config file from appsettings.json , not a different philosophy. And TypeScript deserves credit. Coming from C#, static typing in the frontend feels like someone finally opened a window. The friction The problem I remember most is specific to Blazor Server and worth knowing before you choose it: your code runs on the server, so requests from your Blazor layer to your own API arrive with the hosting IP, not the user's. Obvious once stated, not obvious at one in the morning. I solved it by capturing the client IP in the Blazor layer and passing it through encrypted. That is the shape of Blazor Server problems generally. Not "this is hard," but "this breaks in a way that would never occur to you, because rendering is happening somewhere other than where you assume." Debugging itself was fine in both. I built these projects before the AI boom, without a model to ask, and neither forced me into anything painful. The JavaScript ecosystem did bite me once, though not through Vue: VideoFloppy originally had a PayPal donation widget, which broke, and I moved to crypto payments instead. Third-party widgets are a risk in any frontend, in any language. What the job market says Here is the part that is difficult to write as someone who likes Blazor. I have seen essentially zero Blazor vacancies. Not few. I do not remember seeing one. Vue appears regularly in Eastern Europe - Poland especially, and I believe some of the Baltic states. In the UK and US, the frontend market is overwhelmingly React and Angular, and the same is true in Georgia. Here you will find plenty of both backend-only and full-stack roles, and the full-stack ones want React or Angular. And then the paradox: there are still vacancies for ASP.NET MVC and Razor Pages, because legacy systems need people to maintain them. The older technology has more demand than the newer one built on the same ideas. So which would I choose For a personal project, or an internal tool at a company already running .NET, where the team is backend-heavy and nobody wants to maintain a separate frontend stack: Blazor Server, without hesitation. It is genuinely pleasant, and for a C# developer the ramp-up is almost zero. For anything where other people will need to work on it, or where I might one day want to hire, or where first load time matters: Vue. That is an unsatisfying answer, because the technology I enjoyed more is the one I would recommend less often. But choosing a stack has never been only about the code. It is about who else can read it, who you can hire to extend it, and whether the thing you learned transfers to your next job. Blazor taught me a lot. Vue got me interviews. This article was originally published on Medium. Which side are you on - and has anyone here actually seen a Blazor vacancy? I'd genuinely like to be wrong about that part. 👇 Top comments (0)