In my previous job, I was on a team using Vue.js for the frontend and ASP.NET Core for the backend. I quickly got tired of the internal plumbing, package management, build configuration, and all the other things not related to the actual functionality of the app that Vue (v2) required at the time. So, when I started my own company last year, I quickly jumped on Blazor Server, which has been an absolute joy from a developer productivity perspective.
You can build really rich interactive experiences in Blazor at a fraction of the time required to build the same thing with the standard JavaScript SPA architecture. However, now that we have many customers using the application in production, we're starting to see some of the not-so-pleasant side of Blazor Server. When experiencing a lot of requests, the experience is degraded for all users of the app. In addition, it's not very good at re-establishing the WebSocket connection if it fails, giving a poor impression to the user. Though, I'm impressed with the latency—we're hosted in Europe and have customers in New Zealand who use the app without any latency issues whatsoever.
I'm excited about the auto-rendering mode, which looks pretty straightforward. I don't really buy the author's argument that it introduces an extra layer of complexity—we're still light years away from the complexity that a modern JavaScript SPA involves. For small teams with just a couple of full-stack developers, Blazor is still one of the best and most productive stacks, in my opinion.
> However, now that we have many customers using the application in production, we're starting to see some of the not-so-pleasant side of Blazor Server. When experiencing a lot of requests, the experience is degraded for all users of the app. In addition, it's not very good at re-establishing the WebSocket connection if it fails, giving a poor impression to the user.
We've been using Blazor server for ~3 years now and have had similar experience. We only use it for internally-facing administration sites, and even then it's still quite annoying to hear team members complain about the inevitable reconnecting to website warning, even when everyone knows exactly why its happening.
This experience with using websockets to move state between client and server has pushed us away from the idea that the client could ever be made responsible for any meaningful amount of state. In our current stack, we return final server-side rendered HTML and handle multipart form posts. There are no more websockets in our stack. Everything is stateless HTTP interactions - the client only manages a session token.
SPA was a fun experiment, but I am completely over it. If you are trying to fix some weird UX quirk, reach for a little bit of javascript. Don't throw away everything else that works over something small. There was a time when I would have agreed that you need frameworks, but that time has long since passed.
In 2023, approaches like PHP feel more valid than ever. I know way more about what doesn't work than what does these days. If you want something like PHP but you don't know where to start, you should think really deeply about what PHP is actually doing and if your preferred programming language does not also have a similar string interpolation concept.
Isn't a Blazor application a giant blob of WASM/Javascript? I understand that Blazor is more designed for internal line-of-business applications that require porting to the web (and would otherwise be a .net application running on windows xp), but it seems pretty untenable to use it as a framework for the web.
Blazor - until .NET 8 - came in Blazor Server and Blazoe Webassembly variants.
Blazor Server renders the DOM at the server and sends it to the browser. The server also holds on to some state for each client - notably the "current DOM" - so that it can calculate diffs on changes and only send the diffs to the browser.
Blazor Webassembly does the rendering in Webassembly in the browser. The .NET stack runs in the browser. Here, the code renders and diffs in the browser and the the diffs are applied to the DOM as well.
This also means that the same components can run either server-side or client-side. They basically all end up computing DOM diffs and applying those diffs to the actual DOM. Pretty neat, actually.
Each model has it's pro and cons. Blazor Server initialized really quickly and relies on minimal Javascript in the browser. But it creates load and server affinity on the server. Blazor Webassembly offloads all rendering to the browser, but at the cost of an initial load of the code.
In .NET 8 these can now be blended, and a new "auto" mode allows a component to be initially server-side and then client-side when the webassembly code has downloaded.
In addition to that is now (.NET 8) also the static server side rendering (and "enhanced navigation") which you could say is server side components without the "circuit" server affinity and server state of each client. Static server side rendering has some limitations on how interactive they can be - i.e. changing the DOM.
"The server also holds on to some state for each client"
If this is how Blazor is architected. Then I have no interests in using this and really anyone doing any type of web development shouldn't bother with this. Internal apps eventually need to be used externally. This is a time bomb waiting to explode on the users and the developers.
I use VueJS with Asp.net Core with multi-page single load architecture. Meaning once a page is loaded all other data is loaded through ajax. But the app is made of multiple pages. Over 10 years of being a web developer has brought me to this setup. Client UI state should stay on the client. All other state should be saved to the server. All communication should be stateless.
> This is a time bomb waiting to explode on the users and the developers.
I'm just saying a lot of the target they are aiming to replace is VBA applications slapped on top of Access DBs, and Lovecraftian nightmares born out unholy fornication of Batch scripts and unintelligible spreadsheet formula.
I'm not saying your wrong, just pointing out that even if this is a ticking time bomb it's a ticking time bomb that is using conventional explosives replacing a cesium based nuclear time bomb that is already counting down the seconds.
It can be hosted by either WebAssembly or by the server (in which case the server will render the DOM and send diffs to the client over a WebSocket connection). Blazor Server probably isn't the best choice for a popular SaaS app, mainly because of its dependency on WebSocket connections and less-than-perfect reconnection logic.
I'm optimistic about the auto-rendering mode, which will serve the app via Blazor Server (using a WebSocket connection) the first time the user hits the app. It will download the WebAssembly DLLs in the background so that the next time the user comes by, they will get the WebAssembly-hosted version. It's an interesting mix combining the best of both worlds (hopefully).
As a backend dev, I love the technology. The problem is that you have to choose between a not-so-scalable solution (Server, signalR) or a minimum 2mb initial payload (WASM) that can easily go to 5mb.
Interested on how many concurrent users you have for Server to be a problem. Can you elaborate more on your performance issues?
I may have made a mistake in designing the architecture of our app. Since we're a small team, I opted for a big ol' monolith, hosting our APIs on the same server as our Blazor Server app. We normally serve a few hundreds requests per second on our APIs, which is totally fine. However, sometimes we got some spikes up to thousands of requests per second, which has the unfortunate consequence that our Blazor Server app becomes laggy and starts to drop WebSocket connections frequently. So, now, we are in the process of moving our API controllers to another project, which will be hosted on a separate server.
Sounds like you did everything right then. Started off simple, now your business is taking off, failures aren't catastrophic (they're grey, not black, from what it sounds like) and splitting out a component shouldn't be too hard, so you'll be ready for more scale soon. All while maintaining the business!
.NET 8 solves that exact problem as far as I can see. You can opt into auto mode and it uses server side Blazor until the client downloads all assets, then in subsequent visits it uses the WASM runtime. Seems to be a good compromise.
Is 5MB a real problems? Theoretically it may look big, but I have seen many websites much bigger, not to mention all video/image we download are already skewing download by a lot. Considering runtime is cached for long time, I don't see a real blocker. First page render would be an issue but SSR solves that.
Well if you want to make small fast loading html pages with a minimal js library, and end up at a few hundred KB that you can understand, profile and optimize, then that is impossible with blazor. So it's a very real problem.
If you want 5mb blobs and do not care about what is going on inside, how to optimize or reduce the memory and bandwidth usage, then it's not a problem, works just as well as the websites you have seen, with 200 node dependencies.
> I quickly got tired of the internal plumbing, package management, build configuration, and all the other things not related to the actual functionality of the app that Vue (v2) required at the time.
I don’t understand this. I’ve used v2 since before release and it’s never been anything more than an initial setup of 5m and then build your app?
I share your perspective. It is the most productive environment I have seen in many years. Blazor WASM for internal company applications, PWA or Blazor Hybrid (basically Cordova/Electron Shell just with C#) is just awesome.
I share the article's fear of overloading the technology, but do not see it overall that negative.
In my experience, long polling is more stable and you can enable transfer compression. Maybe it would be good in Blazor to disable the persistent connection completely, having only requests and responses. Often we just want to call a backend method and update the view in response.
> In my previous job, I was on a team using Vue.js for the frontend and ASP.NET Core for the backend. I quickly got tired of the internal plumbing, package management, build configuration, and all the other things not related to the actual functionality of the app that Vue (v2) required at the time.
Oh, hey, I have something relevant to say about this setup. Currently I'm bootstrapping a platform with .NET Core on the back end and Vue 3 on the front end.
In short:
- .NET is one of those boring workhorse choices, like Java - it's pretty stable, the performance is good, the type system is decent, IDEs are as good as it gets (Rider, VS), can run on Windows or Linux with no issues, there is an ecosystem that feels very coherent (more focus on ASP.NET than something like Spring in Java, because there's fragmentation around that, Dropwizard, Quarkus, VertX and so on)
- Vue feels really nice to work with, the Composition API feels simpler than React, the developer ergonomics are fine, the documentation is nice, packages like Pinia, VueUse and VueRequest keep things simple, in addition to something like PrimeVue giving lots of UI components that you can use to iterate out of the box
- however, while I think that the SPA approach can be nice to keep the front end separate from whatever technology you use on the back end, it comes at a cost of duplicating your data model and the interfaces between them (REST endpoint and client, for example), in addition to needing to think about how to deploy it all (separate domains vs context paths on the same domain, CSP, CORS etc.), though it's mostly doable
- I did definitely run into problems with Vue not being the single most popular choice out there, for example I wanted to integrate Mapbox maps and the VueMapbox package is for Vue 2 only, whereas Vue 3 Mapbox GL breaks when you try to integrate it with mapbox-gl-directions. Eventually I switched over to Vue Map (Leaflet based) with leaflet-control-geocoder and leaflet-routing-machine but even those tended to break, because adding markers for a calculated route makes the map break when you zoom in/out, due to it losing a reference to the map JS object; in the end I just used patch-package to fix a few lines of code that didn't work in the offending packages instead of forking/building them myself, but that's a bit of a dirty hack
In short, I think that .NET is pretty good, Vue is pretty good, but the JS ecosystem feels like it works well only sometimes, even for reasonably popular solutions. On that note, I'm all for trying out things like Blazor, but then again my past experiences with Java and something like JSP/JSF/PrimeFaces/Vaadin have soured my perspective a bit (which is also why I prefer to keep the front end decoupled from the back end as much as possible, sometimes to my own dismay).
Honestly, it sometimes feels like picking anything that's not React is shooting yourself in the foot because everyone's building their libraries/packages/integrations for React. At the same time, I don't really enjoy React much at all.
I spent a decade with C# and .Net and even in its current form which is easily the best it’s ever been I vastly prefer to work with Typescript.
Yes, you do need to set up some rather strong governance around it for it to work for multiple teams, but you should really be doing that with any technology, and once you do, it’s just excellent. Part of the reason for this is that it’s basically designed from the ground up to require that you build and maintain “template” projects, have strong linting, testing and pipeline governance, so there is a lot of freedom to make it work easily for your organisation exactly the way you want it to. Typescript is obviously not alone in this, but it’s far less opinionated than something like .Net.
The main reason is that .Net always becomes burdensome once you start using it’s included batteries. This isn’t really an issue with C# as much at it is an issue with it’s libraries. Take OData and Entity Framework as an example, the .Net magic behind them sort of share the same model builder, but they do so differently. What this means is that a lot of the cool OData features like patch doesn’t actually work with EF, meaning you’ll either have to rewrite a lot of the model builder (don’t) or have to work around it. .Net has always sort of been like that. It variates between being 50-90% “done” but it never really gets there until it moves on. Like EF, much of the EF 7 road map isn’t implemented yet, but here we are, moving on to EF8.
I think for a lot of use cases it’s a wonderful technology, and Blazor will probably be awesome until Microsoft moves on, but at least around here, it’s also a technology that doesn’t really see adoption in anything but small-midsized companies, and in my opinion, .Net is part of what hinders growth. Obviously not a huge contributor, but once you step out of where it excels, you’re just going to have to fight .Net so much harder than you will with Typescript. Which is sort of interesting considering they are both Microsoft products which align more and more. That being said, it’s not like it’s bad either.
It seems a little disingenuous of you not to mention how I never hide the fact that it's an issue with the batteries. I'd also say that considering how great OData's patch is with the modelbuilder it's actually EF that's being bad in this case.
I enjoyed using ServiceStack. Write your data model in the C# API, run a tiny CLI command and it spits out Typescript definitions to match your data model.
> however, while I think that the SPA approach can be nice to keep the front end separate from whatever technology you use on the back end, it comes at a cost of duplicating your data model and the interfaces between them
Can you elaborate on this? I'm not sure I get it, because once you have your view model in asp.net, it seems like it should be easy to derive a JS/TS model from it using various techniques (reflection, source generators, etc.).
All the dis-advantages are not relevant for enterprise LOB apps, which Blazor is best suited for.
Millions of .NET developers across the enterprise world are heaving a sigh of relief to never have to touch JS and be cozy and comfortable in their .NET ecosystem.
With the latest addition of fully SSR, Blazor is also well suited for CMS, Blogs, Content Mills, small web apps, portfolio sites, etc.
But, as a developer who has done exactly one complex web app for a client, let me tell you, the ability to use C# models, directly from your domain, in web app markup code, using Razor components is a god send. I don't have to maintain the cognitive overhead of translating domain models into JSON models and vice versa.
For me, just the fact that I don't have to deal with JS bullshit and ecosystem including node/npm hellhole is a win for me. Before these shiny JS frameworks came along, .NET already had great UI component libraries as well including syncfusion (my favorite) and many others.
I only do VueJS when I do use JS but man I can't wait to not write any code in JS.
Yea, I've been using Blazor in .NET 8 through the previews and it's really nice.
The Server Side Rendering is fast like any server-rendered stuff. Enhanced Navigation means that pages load even faster since they're just using `fetch` to get the next page and swapping the content (like Turbo in Rails). When I need some interactivity, the page still renders from the server and then the browser downloads the WASM in the background.
With .NET 8, Blazor is really ready. It isn't perfect, but it's so productive for me and the downsides are really minimal. Plus, it'll likely get a lot better with .NET 9 in a year because of WASM-GC (and post-MVP improvements to WASM-GC). With WASM-GC, .NET won't need to ship a garbage collector and WASM-based stuff won't need to copy between WASM and JS for DOM manipulations.
Since people might want the "minimal" downsides, I'll put them here. If you're using Blazor SSR with WASM, after the first interactive page renders for the first time, there's a second or two before the interactivity is actually available while it downloads the WASM (on interactive components, not links or anything). If you were making a Facebook clone, it'd mean that the "like" button on posts wouldn't work for a second or two. This is pretty minimal for two reasons. First, it's just the first page load of the first interactive page. After that, the WASM is cached in the browser. Second, most of the time people need a few seconds to read the content before using an interactive bit. All of the navigation and such works instantly, but an interactive bit like a "like" button takes a second or two.
If you want to get rid of that, you can use interactive-auto. This means that the first interactive page load will use a web socket and the interactive bits will be done with Blazor Server. It'll download the WASM in the background and switch to WASM for future page loads so you don't need the web socket for the vast majority of your stuff. However, web sockets do create a certain amount of hassle since you need to make sure that any proxies in-between handle web sockets and that you consistently route the user to the correct backend if you're load balancing.
To me, those downsides are minimal and don't have a lot of user impact for me. This is in contrast with Blazor in .NET 7 where I'd have to choose using a web socket all the time or having a big WASM payload that meant the page didn't render for a few seconds and gave users a crappy experience.
If you're primarily creating something that would be server-rendered (like Rails or Django), Blazor offers that with the additional nicety that you can add interactive elements without needing to deal with JS. That isn't meant as a "JS is crappy" comment, but to note that having to deal with another ecosystem where you need to duplicate your models and keep them in sync, having to deal with another build system or glue things together yourself, etc. is a pain when it isn't your main focus. So many sites end up with a full front-end stack and all the hassle involved because they need a couple pages or want to keep a consistent component system. Blazor means that you don't have to go that route.
> I don't have to maintain the cognitive overhead of translating domain models into JSON models and vice versa.
I’m more happy about not having to maintain working knowledge of two sets of IDEs, build tools, CI/CD pipelines, hosting models and testing framework and conventions.
I use swashbuckle and swagger-typescript-api to automatically scrape my controllers and generate API calls and TS types every time I rebuild. No hassle or overhead at all. No need for converters or anything.
I've been using this now for several projects, it's a great way to have all the power of TS for client side and C# for server side.
You get end-to-end type safety (even better once you connect it to EF Core since you get it all ways to your DB).
With this setup with hot-reload (currently broken in .NET 8 [0]), productivity is really, really good. Like tRPC but with one of the most powerful ORMs out there right now.
I do the same in Django with drf-spectacular. I have a precommit hook that autogenerates (fairly thin) TypeScript schemas and routes on commit. This is not take merit from LOB devs who want to use C# back-to-front. I will use it as an argument to those who say that this is why you should go full TypeScript on any new web project though.
The problem is, all of this stuff will probably be dead in a few years. I think they would be better off working within established paradigms rather than trying to do something completely new. How about, for example, making it as easy as possible to use React with a C# backend?
You get a little closer with Fable to compile F# to JavaScript. It lets you model your domain using F# types (which are just as good as – if not better than – C# types) and then you can use them both from your C# backend and F# or JavaScript frontend (whichever you prefer.)
It does require you to faff about with toolchains for building frontend code though (WebPack and the like), and it's not always completely seamless, but if you want to invest in a shared domain model it's the most compatible I've been able to go at least.
Silverlight's phase-out primarily stemmed from the browser ecosystem's shift away from plugins. It's worth noting that Silverlight 5 was supported until October 2021, a decade after its release, indicating substantial longevity despite the changing landscape.
Ok first thing first - allow me to vent my existential frustration with few off the cuff (mostly rhetorical) questions ...
You call decade a substantial longevity?
Is this some kind of a joke?
Is your ability to assess being held hostage by js ecosystem expererience?
But seriously - I expect a bit more from platform that could potentially waste my life and my venture. I am still happily supporting some Java (and JSF) code that I have written for clients 15 years ago (don't you just love that sweet support fees that you get mostly for being alive and breathing ?). Meanwhile my friend that build whole company around product written in silverlight almost went bankrupt. Now after few years working in AI (going into it a bit too soon) he is trying to create same product in ... yes you guessed it, Blazor.
Maybe some people do not learn from their mistakes :)?
Yes, I would call that fairly substantial considering its underlying architecture is no longer viable -- not because of Microsoft's fault, but as the industry as whole moved away from the plugin-based AIR.
Silverlight was somewhat of a unique situation, as it was a platform where it heavily relied on the platform that was phasing out. (And to clarify, that "decade" is the period that Microsoft was committed to support for latest Silverlight 5. Their first version was released in 2007, so it had about 14 years of history.)
As with Java or any other languages, you can still run it if the environment it runs can be resurrected. (I would not connect that to the internet, though)
And many parts of what actually powered Silverlight still thrive in a form of .Net.
I mean where they can support, Microsoft tends to keep its compatibility fairly intact, for instance modern Windows still can run many of the 32-bit binaries from early days. (And you even could do the same for 16-bit apps on a 32-bit platform, not sure if that's still possible, though.)
The difference is that Blazor is built on web standards (WebAssembly), not a proprietary technology. Sure, Microsoft could discontinue support for Blazor, but WebAssembly will keep running. C#/Blazor are not the only technologies using WebAssembly. I personally wouldn't use Blazor for a public facing website, and would only use it for an internal LOB app where I know I can dictate what browser technologies can be used, as well as knowing the binary blob for the runtime will be cached in most users' browsers. I still use traditional MVC structure with C# for applications that will have a variety of users over different connection types, and use progressive enhancement with JavaScript for things that enhance the user experience (for example, creating multiple items of some type on screen, instead of only being able to create one at a time like with a standard form). The thing is, I've already separated out my application logic so that I can change the front-end technology at any time. That really shouldn't have anything to do with Blazor, and is just a way to make sure your application can adapt to future front-end technologies.
No knock on C# or Java developers meant here, however I find that C# and Java Developers find 10 years of support not long enough, nearly every other ecosystem you're lucky if you get 3 year time horizons of backward compatibility and/or support.
WinForms can still be used with all of the stagnant issues. Had a faulty touchscreen driver on Windows 10 that only affected the touchscreen event messaging in a WinForms application. Had to wire directly into the messaging pump, construct a custom event system, and override the WinForms event system for everything to work properly.
Also had to wire a custom touchscreen event system for WPF because the Microsoft method would latch on to UI components with quick taps and press with sliding. This caused buttons to stay pressed while no fingers where on the screen.
I cannot recommend WinForms or WPF or UWP. Microsoft is bad at GUI application frameworks. It was recently that they finally shipped VS2022 with proper WinForms designer support and the ability to move away from VS2019. I still need to close and reopen VS2022 daily for WinForms and WPF development.
QT, GTK or some other framework gives the ability for cross platform solutions without being anchored to Window OS. Non Microsoft GUI frameworks are also faster and better when deterministic response time is needed and ability to run on low powered computers.
Win32 is the main Windows API, and MFC, besides fixing HDPI issues, the hard reality is that after crashing the whole WinRT/UWP story for C++ developers, there is nothing left on the Microsoft ecosystem for doing GUI in C++.
Silverlight, WPF, OData (was amazing for hooking your backend up to client-side tables, rubbish at everything else), WWF (Windows Workflow Foundation), WCF (thank god).
All dead.
And those are just the ones I can think of from the top of my head.
Plus the terrible excel VBA replacement they made, then abandoned, and now it's some fiddly javascript mess.
I'm sure there's a ton more people can add. Those are just the ones I personally wasted time on.
And let's not forget Window Mobile!
Edit: They've also gone through a stupid amount of changes in the asp.net MVC model in quite a short time. Plus constantly seem to overhaul their consistently overcomplicated authentication/authorization system. The state it's in at the moment is shockingly bad.
The difference is that they stop talking about it, their presence fades away in conference and developer blogs, and eventually from Visual Studio installation workloads.
Thats not always true, they keep some stuff that is a success for a long time, but they are also not afraid to drop there failures like ActiveX, SilverLight, VBScript, ...
Those are terrible examples tbh. A lot of businesses would sign immediately if they knew something was going to be supported for > 20 years. Additionally, vbscript owners should have long migrated to eg. Powershell
Oh, that's handy, I thought MS had stopped supporting it. Good to know that it's still going. I thought they had dropped support in one of the .NET Core versions, before .NET 5+.
Thanks for linking that. The video description mentions they added WinForms to .NET Core in 3.0; maybe I was remembering the .NET Core 2.1/2.2 timeframe, when it wasn't supported in Core?
I believe prior to .NET Core 3.0, you could have a WinForms application in .NET Core, but the WinForms designer was not available in Visual Studio. While it was possible, having to build a GUI in WinForms without the designer is utter hell.
Let's say it does: It leaves behind a WebAPI backend that [new hotness] can utilize. WebAPI is an agnostic protocol.
What does Blazor leave behind? Nothing reusable at all. It is a proprietary server hosting proprietary connections via proprietary pipeline. Plus sometimes inscrutable WebAssembly. Just go ask all the companies STILL stuck on Web Forms or Silverlight how that worked out for them the last times? Exactly.
Friends don't let friends buy into proprietary backends that muddy the water between UI/API layers. Stick to WebAPI and put whatever you want in front. That way you can migrate either front OR back independently of one another (and or do piecemeal migrations).
PS - This has nothing to do with "Microsoft bad." This has to do with standard protocols between front/back Vs bespoke stuff. I'd also criticize the short-sightedness if another company offered the same thing.
Best practices would dictate that you still build WebAPIs for your Blazor apps, to avoid that potentially happening. It will also give you a clean separation of concerns in your application. Even when I build a traditional MVC application, I still built out my API as a separate layer so I can change out the front-end in the future.
We're discussing which abstraction is between the backend/front end. You said, to use Blazor safely, I also need to deploy WebAPI. I said you therefore need to test and develop it all twice: Blazor and WebAPI.
So you would build a solution that combined both using Blazor? I still don't understand, this is just like if you were to build a WebAPI and a front-end JavaScript SPA, except Blazor is your JavaScript SPA. You have your unit tests for your WebAPI, and you have your tests for your JavaScript SPA (in this case Blazor, but fill in Vue or React, etc.). You could then write integration tests if you wished, but there isn't any more testing or development process than if you were building a WebAPI with a traditional JavaScript SPA. Blazor is just affording you the ability to use C# rather than JavaScript.
If you were to include your business logic directly into your Blazor application, then you are setting yourself up to run into the exact same issues that you faced with WebForms, if Blazor were to be discontinued. You stated, "Stick to WebAPI and put whatever you want in front. That way you can migrate either front OR back independently of one another (and or do piecemeal migrations)." Blazor is what you put in front. Blazor gets discontinued, you put a standard JavaScript framework in front. The amount of code written and the amount of tests written should be the same whether you use Blazor or React/Vue/Angular/Svelte/JS Framework of the week. What you get with Blazor is the ability to do all your front-end in C#. I think you are going at it as if you build old WebForms or Silverlight, and I just don't see why you would do that knowing full well that front-end tech changes rapidly.
I used to be a frontend coder, but am no longer. In part this is because I couldn't bring myself to keep up with the constant ecosystem churn of the JS world. I recently worked at a company that was trying to migrate from Vue 2 to Vue 3. It was not going quickly. Is Vue going to even be around in a few years, or will React eat it entirely? Or will react itself be eaten by Svelte? I have no idea, I'm not involved in these things. But after watching how such things play out for a couple of decades, my conclusion is that if you are building for the web, you should use whatever you are comfortable with and what provides the features you want now, because there's no way to know what things will look like a few years down the road. Even if the framework you chose sticks around, you may end up doing a rewrite because of other concerns or throw the whole thing away altogether.
.NET Framework has not been EOL'd, so you can still build applications in WebForms. Silverlight was killed off by browsers no longer supporting plugins, that really wasn't a Microsoft decision. Flash is no longer available either, and had nothing to do with Microsoft.
You can't be blamed for having that opinion given history. But Blazor is I think standing on the graves of those previous attempts and is looking extremely strong - it is as of even a year ago mature, well supported, and a deep ecosystem.
I think it's pretty safe to be optimistic at this point.
> All the dis-advantages are not relevant for enterprise LOB apps, which Blazor is best suited for.
The disadvantages: the _actual user_ is going to have a horrible time with the application. It will load slowly, work slowly, probably break the moment you inevitably will have to touch JS, and if the browser the user hates anyway is out of sync with the forced updates, the entire thing will blow up.
But enterprise LOB don't care.
> I don't have to maintain the cognitive overhead of translating domain models into JSON models and vice versa.
Every single time I've seen this attitude, it turned out that actually it just meant you're going to have a worse time when you inevitably had to do that translating.
Java web applets aren't new. "Using models directly from the domain" is not new.
Even when the runtime is friendly, the latter is a bad idea.
Serious question - do you know this to be in fact true of Blazor specifically, with real life comparisons, or is this just conjecture based on analogous frameworks?
This is silly. I mean sure, I did try out Blazor - and ended up unimpressed despite otherwise quite liking C#/.Net - but ultimately it's Blazor making extraordinary claims.
And some of what I wrote is about the programming model itself - by now my experience is that domain models should generally stay on a whiteboard - it's quite rare that's actually what's more convenient in any specific place in the codebase. Trying to "streamline" that tends to end up just introducing even more complexity due to poor abstraction match.
I have no experience of Blazor, but the architecture of Blazor server is exactly what Phoenix LiveView (Elixir) does, and that works extremely well.
Unless your interactivity is at the level of Gmail or Google Docs, or you really care about designing for very high latency flakey connections then LiveView is great and works very reliably with a good user experience. Even on a phone with a cellular connection going through tunnels it's actually better than a lot of JS apps because it handles the reconnection (and visualisation) much more cleanly than most JS apps.
Facebook loads a lot of information. I don't think we should be comparing the download size of a hello world app with loading dozens of images on a facebook feed.
plus in LOB apps very likely to be in the browsers cache already. And dont forget buisness workstations are usually connected via at least 1GBit Ethernet.
I'm not who you're replying to but designing for excess resources is the kind of thinking that leads to slow software.
> And dont forget business workstations are usually connected via at least 1GBit Ethernet.
NOPE! More likely they are WiFi connected Dell shitboxes running Windows 11 with 8GB of memory, half of which is taken up by all the browser tabs, Teams, Office, and the 30 horrible little programs that IT deploys via group policy.
Speed matters. The user is probably running your code + 30 other things. Don't assume your page is the only thing they care about.
If your point is that companies run outdated, shitty computers connected over unreliable WiFi, _your_ corporate life experience has been vastly different than mine.
Actually dotnet wasm can be further trimmed in .net 8. but for most non rtl people the biggest improvement will be to reduce the locale bundle. Sadly it’s not possible to specify which ones you want.
Also it’s not possible to bundle DLLs/webcil. I.e the dotnet compiler will be shipped to the client thus you will also get shipped lots of dlls
I feel like your comment touched a million different places so I'll try to compose my arguments in a compact manner, hopefully to make some sense.
> All the dis-advantages are not relevant for enterprise LOB apps, which Blazor is best suited for.
Where does this conclusion come from? At least from my humble experience,I've been doing them for ~10 years with various tools, both JS and Blazor/Razor Pages and the fact that they "work" does not mean they stand on solid ground.
I've written apps in Blazor, yet I don't understand its existence. Most apps, even LOB as you said, Razor Pages are more than enough. Razor Pages are amazing. What seems to me to be the source of the problem is the whole mentality:
> But, as a developer who has done exactly one complex web app for a client, let me tell you, the ability to use C# models, directly from your domain, in web app markup code, using Razor components is a god send...
You can ship server side generated HTML with Razor and just LEARN a bit of JS. I don't understand the allergy of the so called "back end" developers with JS. Yes it's shitty. Yes it feels better writing C#. I also like my bike more than my car. Will I take my bike to drive 500km? No. There's a time and place for everything.
I feel efforts like Blazor just fight against the (unfortunate yet inevitable) current that JS is the only language that can manipulate DOM. I really think all of us should be open to use whatever makes sense for the job, even if it occasionally makes us feel uncomfortable. This is the dev community I want to be a part of.
> I don't understand the allergy of the so called "back end" developers with JS
I think what many people are complaining about is that they actually dislike UI development and all the ambiguity and complexity. "JS" just catches blame for this. Modern JS and esp. TypeScript are pretty good languages, or at least comparable.
A lot of these server side UI toolkits avoid some of the complexity by supporting basic UIs and flows, e.g. List/Show/Edit (which is fine in many cases), but to do complex UIs that many modern apps need, it's a huge pain. Worse situation to dev is forcing 80% of the functionality via server side, then the last 20% you ask "front end" to wedge in with jQuery style development.
As someone who suffers from this allergy, I'll chime in with 2 additional thoughts:
It's not just that UI development is more ambiguous, it is the fact that it is difficult to make text-based code fit it. This is doubly (or maybe logarithmicaly) so when responsive (same code fit different screens). HTML, XAML, HAML, etc all require a lot of code. Reusability mechanisms (like components, etc) help this but it is a world of difference from what BE devs are comfortable with.
Thought #2: I'd guess BE devs like to just code, and the FE frameworks have a reputation of getting in the way of that. This is a less certain thought, so welcome opposition, but seems at least like part of the emotional reaction a BE dev would have to FE work.
Clay is very malleable and has all sorts of wonderful properties. As a building material it has fundamental limitations as it’s less suited for tensile loads.
It’s funny, because you can continue the analogy and compare optionally typed languages (like TypeScript) to adding wood/rebar to a brick building, allowing it to go vertical.
A good example: the Chrysler building sports 3 million specially made bricks for its facade. By blending both materials, you receive the thermal and maintenance benefits of brick with structural integrity of steel.
.NET 8 comes with Blazor United (renamed to simply Blazor) that combines the Blazor Server and Blazor WebAssembly frameworks.
For client side components C# code is compiled into WebAssembly that manipulates the DOM just like JS.
Today with Blazor Server, the main drawback is the slight delay you can get when you click something. .NET8 essentially blends Server and WebAssembly and solves the problem, even giving you the best of both worlds since WebAssembly has high first load times, .NET8 Blazor loads initially with Server side and provides client side after it loads all resources.
I consider myself more of a backend person but I feel I can deal with JS much easier than CSS. I learnt both in 15 yrs ago so compatibility with IE was crucial. Slap jquery on, stick to style guidelines so that variables are named consistently, avoid dependencies and it feels okish. There isn't anything like that to help with CSS though.
As a backend dev primarily, learning CSS Grid really helped me filter out a lot of the BS.
It's a UI framework that is 20 years too late, and with "lean" JS frameworks that are emerging, a lot of this UI development legacy can die a horrible death as far as I am concerned.
Agreed. I mean really in the spirit of get er done the AS400 is the pinnacle of UI for these sorts of things. I've worked with other things, even WinForm apps, Access things, Excel sheets that were turned into portable apps, and of course web pages. Green screen allowed 99% of things to get done faster with 1000% less fuss.
My first job required maintaining a very old informix 4gl app. The trained users could fly in that thing! Seeing clunky webapps with a bunch of clunky laggy UI components doesn't seem worth it for trained internal users
At my old job non-technical people would navigate about as well as they would with a mouse and a graphical-based interface, because the graphical interface didn't provide any additional value. For those people it took the same time whether read instructions and press key or read instructions and click button. Trained people were definitely faster, and often the user would type ahead of the terminal (with no ill effects) because they were inputting data close to their speed of thought about the process [0].
The point is, for this situation a text-based terminal offered no downsides and many benefits compared to a graphical UI. I suspect the same is true for a lot of other business solutions.
I've heard it argued before that graphical systems are easier to use, but in my day-to-day experience in the trenches with others who actually used the systems this argument was simply not true. I've also seen it hinted that graphical systems seemed more modern, so they got less emotional disdain. That rings more true to me. And really if I were in charge of such things I would acknowledge emotional disdain - even misplaced - may well count for something in the overall business picture.
Also, and maybe most importantly, if the green screen needed a new feature or bugfix, there was one person at corporate that would do that. They had about a half dozen devs working on other things but she was the go-to for the green screen features. So I imagine it's harder to hire people for those sorts of systems nowadays. However it was also interesting for me to note that one person didn't seem stressed out or overly busy and the system never had a major crash or bugfix. So, tradeoffs.
[0] The terminal was actually hosted inside a wrapper app inside Windows 7. So I ended up using AutoHotKey to great effect to get even more efficiency gains.
* edit: added footnote explaining how AutoHotKey could be talked about in same breath as green-screen dumb terminals.
It's still relevant when MS decide to drop it and focus on yet another new shiny web-framework, like the 10 - or whatever number previous they've built - in the past 20 years. And, let's face it, they're not very good at it. If they were they wouldn't need to shelve so many previous attempts. Or, they decide to completely upend the entire ecosystem (Framework → Core) which then makes all previous web-frameworks (built by them) defunct.
Enterprises with sense would either roll their own, that they can then have complete control of forever, or try and find a framework that has staying power (although I realise even that is difficult).
I think running C# in the browser has benefits, for sure, but they should just stick to making that. And get out of the web-framework game for good to allow the community to create something exceptional - and, you know, play nice with others (other frameworks).
> When it comes to web, MS has been focused on ASP.NET since forever.
What's your definition of 'forever'? Are you talking about ASP, or ASP.NET, or ASP.NET Core? Or, Web Forms, MVC1, MVC2, MVC3, Silverlight, 'minimal APIs'? ...
Honestly, it's just one clusterfuck after another.
---
EDIT: There's a number of sub-comments here that seem to be missing the point. So, I'll expand here:
* For those who are questioning my right to have an opinion on this and doubting my expertise: I have used .NET since version 1. I founded a company in 2004 and have been responsible for building an enormous web-app product in the .NET world (since before jquery era, basically). I've seen all these frameworks come and go.
* For those who are saying "whatabout JS". Am I not allowed to have an opinion on the ever changing landscape of .NET web-app development without first criticising the 1000s of open-source developments?
* For those saying they've done migrations in the past. I'm pleased for you. Now try it with an application of over 500 pages when you have other things to be getting on with. Especially if you're not eager to jump to the latest and greatest every time a new one comes out, then you have a big problem of jumping multiple steps. Or, especially when they rip the entire ecosystem away (.NET Framework → .NET Core) meaning a big fix-up job for those migrating. I'd love to know what the collective economic impact of MS changing their minds every few years is.
But, finally, this is not about migration per se. This is about the poor quality of the frameworks themselves. Microsoft just follow the latest trends once they get going and then build half-assed versions that try to completely lock you into their world. They try to destroy everything that is the web so they can stop you leaving their ecosystem. This has profound problems for the consumer of these frameworks when MS drop it and go after something else. The Minimal APIs is a good example of bandwagon jumping, they've seen the trends to more functional-style APIs, and then they go and implement it in a horrible half-functional/half-OO ugly way. There are so many gaps in it due to its design that it's already obvious that it won't last (in its current form at least).
In 'JS land' it may not be the prettiest of ecosystems to work with, but JS written 20 years ago will probably still run today. Frameworks written 20 years ago can still be used. Support may go away, but that doesn't precipitate a rewriting of your UI layer. Anyone developing software for the long-term, which is professional software houses, should be wary of relying on anything MS build (outside of the language itself and its tooling, which is excellent).
Personally, I'd never bet the house on a MS web framework again. We ended up rolling our own, which was much more advanced than most web-frameworks (at the time) and stayed written (well, until .NET Core came along!).
A lot of these frameworks either composed together or had an upgrade path where it made sense. Plus if you're structuring your application right in .net, that web layer becomes another interface. I have taken an application across a few of those with some fuss, but you're covering 20+ years of development there.
The tooling ecosystem around JS is nuts. Packages (npm etc) hardly have any backward compatibility. You install a package today. In 3 months, that code won't build. The errors want you to go take a cryptography course to understand WTF is happening.
And I am not even talking about the language itself YET. ANd no, why should I be forced to use Typescript ? Yet another layer.
And I did I get to the 100s of config files that need to be set just so I can run "npm build" ? Webpack, Vite, blah blah.
> You install a package today. In 3 months, that code won't build.
Skill issue. Like I do that regularly. And I'm not even particularly great at frontend tech, so after 3 months I need to hit the docs to actually change anything. But the build pipeline works just fine.
> And I did I get to the 100s of config files that need to be set just so I can run "npm build" ?
..."webpack.config.ts", "package.json" and "package-lock.json" is not 100s. I mean I've seen places with, like, _a dozen_, but those folks could do the same to bash scripts and Python, some people are just messy about it.
Your way of upgrading front-end tech, where you need to hit the docs, sounds exactly like moving from the different .NET technologies to the latest version. I still tend to build out classic MVC applications, and use JavaScript only for progressive enhancement. I've been able to move from .NET Framework to the different versions of .NET Core, and now just .NET. I just follow the documentation, Microsoft has great documentation on how to upgrade. It just sounds like you are more familiar with working with front-end tech, and I would hazard a guess that you are actually much better at it than you either let on, or believe you are (Impostor syndrome, I get it all the time until it's crunch time, and then you just get things done).
I'm not trying to convince you to change technologies, but if you're familiar with a specific process, it's always going to be easier to follow that process than something you're not familiar with. This is coming from someone that still uses Grunt for their front-end build pipeline. It's not the newest, but it's still well supported, and I know it very well and can pull off a lot with it.
> Your way of upgrading front-end tech, where you need to hit the docs, sounds exactly like moving from the different .NET technologies to the latest version.
What front-end tech, everything is typescript.
Also not upgrading. I need to read the readme file because I didn't run the software in 3 months. Point is, it will _still run_. It might need a few updates for security reason, but it will _not_ magically stop working.
> It just sounds like you are more familiar with working with front-end tech,
No. I'm a full-stacker, but very much focused on backend, and actually mostly in Python. But nodejs + typescript actually works well enough that, even with _decades_ of Python experience, I now need a proper reason to pick it over typescript for a new thing.
> I'm not trying to convince you to change technologies, but if you're familiar with a specific process, it's always going to be easier to follow that process than something you're not familiar with.
Yep. Maybe the reason why some folks struggle so hard with running their old JS stacks, rather than some .net superiority?
Despite working with .Net for decades, I've not jumped to blazor.
The reasons are varied, many of which are well articulated in the article, but the most notable throughout various workplaces I've worked at, there's been a hesitance to jump on MS web frameworks in fear of a repeat of silverlight.
Silverlight burned a lot of small businesses hard, almost everywhere I've worked has had a silverlight horror story of a project they experimented in it with only for it to languish. So now they either have some outdated dependencies they'll never update or had to re-write it back into something else.
Even without silverlight concerns, most .net places I've worked have very much been legacy focused. This might be my own culture fit at interviews so I end up with places with lots of legacy of course.
But these giant legacy systems already have a plethora of mixed web technologies from ASP.net webforms, asp.net MVC, through .net core MVC, and many others. The willingness to add another different technology into the mix isn't relished.
For small companies, the cost of migrating older projects to new technologies is a significant burden which gets ignored for as long as it can be reasonably done so.
> there's been a hesitance to jump on MS web frameworks in fear of a repeat of silverlight.
That's not really fair to MS since all the web frameworks which were born in that era (Adobe's AIR, JavaFX as a web tech, etc.) died because IE died. And also because Apple killed off browser plugins since they didn't work on the iPhone. Chrome and Firefox took over and there was no longer a need to use browser plugins for SPA's. HTML, CSS and Javascript finally got the features needed to create a proper SPA.
While JavaFX did live on outside of the browser both Adobe RIA and Silverlight were far worse positioned for life outside of the browser (even though both claimed to be usable outside of the browser). Simply because JavaFX was meant to replace Java Swing.
JavaFX never really became a thing, because even at Sun it had a bumpy start with the scripting based language before it got rebooted into Java, just before Sun went down.
Oracle isn't a GUI company, beyond the stuff needed for their database products and IDEs, so they also didn't invest that much into it.
Thus most of the Java ecosystem, kept targeting Swing, and for the extent native desktop applications are still around, Swing is good enough.
Android is its own thing, so even one less reason to care about JavaFX.
You can say that, but at the same time, whenever people complain about technology changing, leaving them behind, they usually mean tech by Microsoft.
The reason Java and JavaFX survived is that they went Open Source, with a large FOSS ecosystem, targetting FOSS operating systems as well, all while there still was interest. And their maintenance and evolution continued. Adobe RIA and Flash were proprietary platforms, just like Silverlight.
In fairness, projects that survive tend to be FOSS, and AFAIK, .NET Blazor is open source. OTOH, the .NET ecosystem tends to prefer Microsoft's solutions, with alternatives languishing, they basically killed Xamarin's projects, and they have had several noteworthy conflicts with the FOSS community. So the jury is still out on whether Microsoft's projects can escape the deprecation curse.
---
The lesson here, for all, if you want for your knowledge and work to stay relevant, look towards Open-Source platforms and open standards. If seeking stability, the older, the better, actually. FOSS platforms age like fine wine.
> Xamarin.Android, Xamarin.iOS, Xamarin.Mac are now integrated directly into .NET (starting with .NET 6) as Android, iOS, and Mac for .NET. If you're building with these project types today, they should be upgraded to .NET SDK-style projects for continued support.
> Xamarin.Forms has evolved into .NET Multi-platform App UI (MAUI) and existing Xamarin.Forms projects should be migrated to .NET MAUI.
So to those of you using Xamarin: how painful it is? How compatible Xamarin.Forms or not is with .NET MAUI? Are they totally different tech?
How easy/hard it is to go from Xamarin.{Android,iOS,Mac} to .NET6+ ?
Maui on the other hand is a turd. It’s such a pain to work with, workloads just plain suck. And if you install . Net 7 and your project targets 6, It will download .net 7 workloads and fail to build. Then 8 comes out and same problem. Have to pin the SDK.
And by the time Maui starts to mature and work, they will announce a new framework and the cycle starts again. I still don’t understand why they couldn’t keep working on WPF instead of cranking out a new framework every three years.
It's not just web frameworks - it's all MS UI frameworks. On the desktop there WinForms, WPF, UWP, WinUI, Blazor, MAUI... it's really seems like a mess with no clear direction.
> That's not really fair to MS since all the web frameworks which were born in that era (Adobe's AIR, JavaFX as a web tech, etc.) died because IE died. And also because Apple killed off browser plugins since they didn't work on the iPhone.
Who could have foreseen that hitching your horse to derpy, single-vendor RIA frameworks that were closed source proprietary and worked on the basis of shoving foreign content into the browser to get it to do non-Web things was a bad idea? Oh wait, anyone.
In that vein, in response to the earlier remarks by the original commenter:
> Silverlight burned a lot of small businesses hard, almost everywhere I've worked has had a silverlight horror story of a project they experimented in it with only for it to languish. So now they either have some outdated dependencies they'll never update or had to re-write it back into something else.
Yeah, good. That pain is well-deserved. Almost self-inflicted, even.
Oh, me too. So much now-obsolete knowledge accumulated!
Flash was always going to die someday though, as HTML/JS caught up with it. In the end it was killed (arguably) prematurely, but it probably wouldn't have lasted more than another 5-6 years anyway.
Silverlight, I think, was worse - only a few years between initial launch and discontinuation. Pretty much every client app based on Silverlight would have had to have been rewritten from the ground up within a couple of years of completion.
I try to learn lessons, in life. One of them is to not rely much on any Microsoft technology that's less than 10 years old.
> Flash was always going to die someday though, as HTML/JS caught up with it.
I'm not sure that would happen. I think Flash would evolve to just "compile" to HMTL/JS. IOS/Android could be other targets as well, once they found a way that would not upset the Eye of Apple.
Not if Adobe was developing it. Flash was terrible for performance and battery life, and it was wedded to the classic fixed-size window with a keyboard and mouse. Even Android users who had access hated it.
Now, it’s possible that some of that could’ve improved (battery life would’ve been hard due to the scene timing model) but Adobe just isn’t a platform company. They didn’t even want to fix the security problems, much less all of their half-assed APIs - they were even worse than Sun for announcing ambitious frameworks duplicating built-in OS features, shipping the easiest 40%, and then letting it stagnate because there was no way fixing the hard stuff would get them a second keynote.
I like .NET, and I believe Blazor represents an unique capability for that tech stack, but using Blazor essentially means eschewing all the traditional web stack tooling that was built up around TS/JS during the past decade for proprietary Microsoft weirdness.
Call it Blazor weirdness then. This obviously wasn’t a swipe at Microsoft being closed, just a point that Blazor stuff is not general standard web stuff.
I was helping to maintain an Adobe Flex system a few years back. It really sucks when your framework is simply obsolete like that. I don't know how to protect against that with the rate of change.
I have to disagree. What you describe is every legacy stack and 20 years evolvement. Java with how many EE systems. JS with how many SPA frameworks. Python I know too little. Go/Rust are too young to have history.
Silverlight was an obvious bust from the beginning, no one with longevity in mind jumped on that ship and fought against anyone pitching it at the time (mostly inexperienced devs, sales people, and tech companies looking to make a quick buck). Anything plug-in based was already on the chopping block by the time it came out. Blazor WASM is, at least, as safe a bet as any popular JS framework. If .NET was still a Windows only thing, I'd stick with the JS frameworks, but now that it's cross platform, I've got no problem choosing Blazor over any other UI framework that just as easily might need a full rewrite in a few years.
I've been working on a large-ish Blazor (Server) application for about a year. The choice to use Blazor was not mine, but I went into it with an open mind. For context, I have used React and Angular in the past.
I will never used Blazor again.
Performance is not good, with CPU always at some base level, even when idle. My machines fan is always cranking while developing it. Hot reload does not work consistently (on like 25% of the time), and when it does, it is slow, so it might as well not work at all. Everything in Blazor just feels half-baked.
I'm old enough to remember things like "ActiveX Documents" and Silverlight, where were other attempts by Microsoft to provide a way for people not to have to learn and use a proper front end framework, and I think Blazor will end up on the scrap heap with them.
Microsoft has a bad habit of touting the next big thing for developers to use and then abandoning it several years later. This feels like that to me.
Am using Blazor WASM in our shop and absolutely loving it once deployed. The hot reload and other development headaches are -really- painful, but just being able to use our existing C# libraries everywhere has been a game-changer for us.
The article (which basically says Blazor is a bit cumbersome and pointless) has plenty of truth (and a few half-truths) to it but it's assuming that you're using it in a context where pure js + html would just be much better for the end user (wait, isn't pure native better for the end user..).
What it doesn't really tackle is the productivity from the developer perspective, very little mental context switching, code re-use/sharing with backend models etc (api models, validation etc) and the surprisingly productive nature of the Razor templating language. It's a combination that makes sense for developers, less so for end users. Most end users for these apps will be corporate intranets (love that the article mentions SEO, yeah right). When these same corporate users were using monolithic WPF apps, did anyone care then? If you're replacing a shared spreadsheet cooked up by Tim on the data analytics team, how much does JS really matter.
Consider if the same Devs opted for react or angular etc, would the end users actually care?
Ultimately it's up to the businesses to decide if this makes sense and the technology is driven mainly by developer sentiment, which circles back. If this is an easy way to make corporate apps, then why not.
People don't realize this. Blazor is about the developer. I am a `DevOps/Backend` guy and in my previous job some internal tools were made with Blazor.
It was such a joy to work with. Productivity was so high. You add Blazor Radzen components[1] or Syncfusion[2] and suddenly feels like magic. Super complex grid tables can filter, re-order columns, aggregate them and much more functionality for free in 10 lines or fewer.
I cannot recommend enough to people to give it a try. This technology enabled me to do a repair shop software in 1-2 month on my spare time. From customers to emitting bills in PDF. Zero JS and just using the basics grids from bootstrap CSS to make it responsive. As a non frontend developer, this was heaven.
Clearly. And that's exactly where the most salient criticism of it comes from: prioritizing the pleasure of the programmer during the development process over everything else, including the experience of the person who actually has to put up with using the thing—all while providing cover for the vendor who bid on the job to argue that they've fulfilled all the requirements so what are you upset about if it's a little janky? Classic enterprise crapware mindset.
Same role, this is exactly why have I kept myself focused on .NET and Java frameworks for Web development, or CMS in those platforms, and mostly leave SPA stuff for the FE team.
Native desktop development is another matter, though.
It's funny you're being downvoted, I've used Blazor on less important side projects and I love it for the same reasons, but a subset of HN hates it because their uBlock Origin no-Js anti-tracker cookieless oddball browsers choke on it.
Interestingly enough Google's crawlers don't even choke on it: my fully SignalR based site was indexed soon after getting a spike in traffic without an issue.
Does it annoy me that leaving the tab and coming back can kill the app? Sure. But often times I reach for it when I otherwise wouldn't have built a thing at all.
Most normal people will take an app with hair edges they can use over nothing so I'm going to keep reaching for it from time to time
No, people hate it because it's a massive downgrade in UX, especially the wasm variant, just because backend devs don't want to use the right tools for the job. I'm fine with it in internal apps, but public facing apps using blazor would be horrible for the users, which is why it is thankfully very rare to see.
Javascript seems downright lightweight and unbloated compared to shipping an entire dot net runtime for a crud form app. For what it's worth, I don't care about turning off javaScript or even bloat in general, but this is extreme.
That's not how the right tool for the job works: the tool that results in the smallest bundle size and the most impressive web metrics is absolutely worthless if 99% of the value in what you're making is it existing and the creator of said tool doesn't feel like building out a SPA.
Of the tens of thousands of people who found my tool useful, the only people who ever complained where Hacker News users, and the tool simply would not exist if I had gone and wasted my time spinning up Next, realizing the app router is garbage, RSC has no place in most React apps, then going back to pages router, then rediscovering how awful NextAuth is, then...
Which is exactly how some of my otherwise interesting side projects die too.
Thanks for your feedback. It sounds like you are saying that Blazor was created mainly for internal corporate apps on their intranet, but I don't think that is quite what Microsoft envisions when they market Blazor. Perhaps that is where you concluded that Blazor has its only real place, possibly for the exact reasons which I've listed in the article?
> If you're replacing a shared spreadsheet cooked up by Tim on the data analytics team, how much does JS really matter.
I take your point, but from my experience replacing an internal spreadsheet which most non engineers know exactly how it works and does mostly everything they need/want with a custom SPA so 5 people in an organisation can do a task differently has never been a good use of developer resources or improved productivity.
Blazor Server is even better for corporate intranet applications. Building monitoring/operations apps is insanely easy when you can just connect your UI components directly to a singleton state on the backend. I wouldn't even consider anything else if my job was to make an app for a group of users who all sit in the same room.
Coming from the other side, this compatibility is why NodeJS is still very popular on the back-end. It makes sense for companies to try and stick to one programming language and / or ecosystem, else you end up with two disciplines within your company.
http://boringtechnology.club/ 's slides show the problem pretty well. I'm not saying companies should stick to one technology, since the "golden hammer" is also not a good idea, but that the technology choices should be taken with care and consideration of things like hiring.
Blazor is the definition of boring technology through and through. Use it in MVC mode and get ergonomics that date back to the early 2000s with a hiring pool so deep you can't ever find the bottom of it
Strange discussion here. I'm a developer in everything for 20 years and the last 7 probably in large JS/TS applications.
I switched to Blazor Server for the last year in a new company and it has a montrous amount of benefits.
First of all, do not pretend that you are Google or Facebook. This is a repeated mental illness that developers suffer from. No won't face any performance issues. The contrary, Blazor is blazing fast.
However, there are couple of issues when it comes to interactivity with javascript frameworks. Until .net 7 you could use every JsRuntime.JsInvoke... something like that to invoke JS function.
In .net 8 they changed something and you cannot use it like that anymore or you get strange subtle errors when you get "too" dynamic. I'm figuring it out right now. But other than that you have a gigantic .net stack with build-in support ORM, RateLimiter, Caching, Distributed-Caching, MVC, WebAPI, ... The list of features is infinite.
I like the Leptos approach more.
Smaller binaries,lessoverhead, website already works completely during loading WASM and turns on client side rendering once it is loaded.
At a previous job we adopted Blazor WASM in order to rewrite an interal React-based app that was basically a hardware test ticketing system + asset tracker. It was very productive, ended up feeling more responsive to users (after the initial page load which was definitely worse) and allowed us to share some code from the WPF app it integrated with. Adding more complex features was much easier than it would have been with React (the years of C# experience on the team was much higher than the JS/TS experience).
I think like most MS products it suffered from being not quite ready for production when they claimed. We started using it in dotnet 6 and there were a lot of features that I ended up implementing or rough edges I worked around myself that were subsequently included / fixed in the dotnet 7 version.
I am hopeful that WASM GC + dotnet linking & trimming + the auto thing mentioned in the article will make it an acceptable choice for public-facing websites as currently I'm not sure how well I could justify it despite my personal feelings on JS vs C#.
I am eager to try Fable at some point though, probably on a personal project first.
I take the opposite view, as a recent Blazor convert since the just released .NET 8 we're now recommending Blazor for any new .NET Web App (excl. CDN Hostable, SSG websites).
I was short on Blazor before .NET 8 and could only seriously recommend it for Internal Apps since the compromises for using either of Blazor's Server or WASM Interactivity delivered a poor UX for Intranet hosted Apps as covered by this post.
However that's changed in .NET 8 Blazor's default Static Rendering where you're effectively able to develop traditional Server Rendered Apps like Razor Pages/MVC but with Blazor's superior component model, advanced features like Streaming Rendering and its built-in (smart) Enhanced Navigation which gives simple Server Rendered App's SPA-like responsiveness without any of npm's build tool complexity, need to manage separate client routing, heavy client state, npm dependencies, large JS bundles, etc.
Even better is that you no longer need to use Blazor Interactivity for any Web App features, e.g. which we avoid in our "Blazor Vue" (100% SSR) Tailwind template that progressively enhances statically rendered Blazor content with Vue.js. I cover this approach in detail in our ".NET 8's Best Blazor" [1] blog post.
As it embraces the simplicity of "No Build" JavaScript Modules (i.e. avoiding npm deps + build tools) it's now become my preferred approach for most .NET Web Apps.
Blazor Diffusion [2] is an example App built using this template, originally developed in Blazor Server, deployed as WASM but now converted to "Blazor SSR + Vue", source code available at [3].
Very interesting, and the first time I might have been nearly sold on it. Maybe next new project I'll try it out.
Razor pages with JavaScript on the front end and automatic diffing on the backend is definitely appealing. As much as I don't like the idea in general of serverside session state.
By the way, I think if you used a light-dom framework like alpine or petite-vue you would avoid most of the issues with the page not recalculating the front-end state on navigation.
> By the way, I think if you used a light-dom framework like alpine or petite-vue you would avoid most of the issues with the page not recalculating the front-end state on navigation.
Unfortunately it's how Blazor Enhanced Navigation works where it compares the rendered content of the new page and diffs in the changes so I'm not expecting it to work by default (i.e. without adopting a workaround) with any JS FX that dynamically generates the UI as it'll get replaced back into an empty div when Blazor patches in the new page elements.
Also I wouldn't recommend "lite-dom" FX's like PetiteVue which has basically been unmaintained since 2021, has poor composition/component model and pretty glaring bugs/limitations you're likely to hit very quickly for any complex UI. We ended up having to rewrite all our Built-in UIs [1] with Vue 3 [2] to overcome its limitations. The 40kb increase in minified/compressed .js size vs vue.min.js is not worth the pain of working within its limitations.
I did that same rewrite (alpinejs to vue3) in a project of mine. I did it for CSP reasons rather than performance/behaviour limitations despite spending quite a while getting recursive generation to work.
The next project has less untrusted input and a simpler datamodel so I went with alpine again and I've not had any issues whatsoever.
Good to know about the bugs/abandonment of petit-vue. Admittedly, I probably shouldn't have recommended it above without having used it.
I'm sorry, but WTF? You spend 5 paragraphs talking about how great Blazor Server-Side Rendering is and then throw a "+ Vue" right at the end? WTF? So it's not SSR at all!? How are you avoiding npm and JavaScript builds when you're literally using Vue? That little example app you showed has ~3500 lines of JavaScript in it ...
It is 100% using Blazor SSR, i.e. uses Blazor Static Rendering on all Blazor Pages and never uses Blazor Server or WebAssembly Interactive render modes.
> How are you avoiding npm and JavaScript builds when you're literally using Vue?
Because all interactivity is implemented by progressively enhancing Blazor Static Rendered pages with an ESM build of vue.min.js, which doesn't require any npm dependencies or any build tools. Vue.js is a dependency-free 60kb gzip download loaded directly by browsers using its native JavaScript Modules and Import Maps support, i.e. same approach DHH has moved to [1] for all his new Rails Apps precisely because it lets you develop modern Web Apps without any npm dependencies or build tools since it uses the Browsers native module support for loading JavaScript modules.
> That little example app you showed has ~3500 lines of JavaScript in it ...
https://blazordiffusion.com is an example of how you can build highly interactive Web Applications without ever needing to resort to Blazor Web Assembly or Blazor Server Sockets for any interactivity features. For a more traditional Web Application that's primarily server rendered, including a markdown powered Blog and Auto CRUD UIs which uses pockets of Vue.js for any components requiring interactivity, checkout a Live Demo of the empty (100% SSR) blazor-vue template [2]:
A lot of people seem to think that front-end and back-end developers are intrinsically different people. This would be the reason why full-stack frameworks (Kotlin for JavaScript, Scala.js, JavaScript backends, and now Blazor) never really take off.
I find this rather strange. I can understand that people specialize, but it's not like typical application front-end or back-ends are rocket science and require a PhD or something. I have seen back-end developers create ugly, near unusable, user interfaces, and I have seen front-end developers write Hello, World!s that would deadlock. However, if both would take some time to pick up a few hints here and there, would they not turn into proficient full-stack developers?
Am I this misguided? Or is there another reason for these full-stack frameworks to never get the traction they deserve?
Because I can learn javascript, and work at myriad companies using any backend language. Or I can learn Blazor and work at the half dozen firms deploying it to production (maybe there are more in Europe).
It's about learning C# .NET and working at the many, many companies who use .NET in some capacity for their various needs like desktop apps, data processing services, etc, and of course web with Blazor. I can take my existing skillset in C# .NET and apply it to many different things.
I find no lack of companies hiring C# .NET devs in the midwest.
Yeah and then why don’t devs learn to administer their own databases as well. While they’re at it, writing some QA test cases can’t be all that hard. Continuous integration is pretty straightforward to set up so that as well. To be fair, it’s rather formulaic to come up with UI designs as well. Also security, load balancing and requirement docs just take a little dabbling to learn.
And are you hiring? Does your situation represent the bulk of available opportunities for developers looking for work? I think it's not, which is why these frameworks don't gain traction relative to javascript, which is portable to any backend stack.
Why stop there? Programmers are the ones most familiar with the software, they should be selling it. If they don’t have time they can hire more programmers, HR is easy… also they can automate the salary and procurement systems.
Here's a blunt truth: No one can be an expert at everything.
The parent comment asked:
> However, if both would take some time to pick up a few hints here and there, would they not turn into proficient full-stack developers?
...and the answer depends on what 'proficient' means to you.
Are you a small scale startup, prototyping, indie -> everyone does everything, when it fails, its not big deal. Then probably yes, that level of proficiency is ok.
However, at a larger scale, where failure has a tangible cost, is it ok if a 'fullstack' developer (ie. javascript dev) breaks the database and people can't buy things any more? What about if a DBA with a smattering of js makes it so that mobile safari doesn't work anymore and people can't login?
It's probably not OK.
If you want reliable output, you have to partition responsibility to people who know what they're doing.
That means specialization.
Of course, learning a smattering of other tools / technologies and ways of working is great for personal development, but at some point, someone has to be responsible for making sure that things don't explode.
...and, if you're prepared to be the guy responsible on paper for making sure no security incidents ever happen, that's cool if you have those skills; but it's fair to say that expecting a designer who spent 1/2 a day reading the OWASP website is maybe not the best choice for that role.
They are simply not an expert in that field.
It's not a matter of opinion; it's a matter of risk management. It is fundamentally risky not to partition responsibility to domain experts. Every company has to decide how to manage that risk... but it does exist; and companies that don't acknowledge it usually seem to suddenly be much more interested in it after they have an incident.
They are worth while to learn but if you work for a corporation and they gradually cut people while loading you up with more and more work you’d get sour too.
That's my issue as well; over the years I've developed some insight in visual design and UX, but it's not my strong point and I don't want to be responsible for design. Luckily, I've always worked with designers and people who are better at CSS.
My point is, I've done front-end for most of my career without having to do design work.
> over the years I've developed some insight in visual design and UX … Luckily, I've always worked with designers and people who are better at CSS
These two things are completely tangential. Translating a design into well structured HTML/CSS should not require any UX or design experience. In the same way, you don’t need to know HTML/CSS to create a good design and UX.
I don't know why you would consider JS/TS backends to be niche - they are fairly mainstream by this time.
You also need to distinguish between larger frameworks and compile-to-js/wasm languages here.
As for the rest, I think the bigger reason they don't get traction is that one one hand they don't work well for incremental adoption and on the other they introduction friction when integrating with the wider ecosystem. This hampers adoption for both new and established codebases.
If I am starting a greenfield project from scratch, I am likely working with uncertain/changing requirements and need to move fast. If I choose something like Blazor/Vaadin etc., I am not sure how much effort will be needed if I need to integrate a third party Gantt component, or a month calendar view, or a leaflet map etc. in future. Unless I am already super-sold on said language/tech, it is likely not the best use of my time to do a comprehensive evaluation right now because I don't entirely know the scope of the project - I'd rather want to spend that time building something minimal that I can push out and get some user feedback. But when the need arises I don't want to get locked into a scenario where suddenly I need to spend a few days dedicatedly writing a custom integration or manually declare types for a complex third party library. So I end up writing a TS SPA because every notable UI library at this point is known to work well with it.
In contrast, if I am evolving a brownfield project which already has quite a bit of legacy, I am constrained by the set of choices already made in past. Eg. I am likely not going to introduce a C# layer in a large java application to take advantage of blazor. It makes sense only if I have a C# app, and the frontend developers of said app (who may or may not be same as the backend developers) are equally enthusiastic about C#.
Even if I have multiple microservices and each of them can use whatever tech the maintainers of said service want, in order to use Blazor the team still has to be enthusiastic about adopting not just Blazor and C# but also the wider C# ecosystem including ORMs, caching, logging libraries etc. and all of that ends up being a substantial learning curve for a team with deadlines. Each of these constraints funnels down the developer subset likely to adopt this tech further down and down.
So all in all, adopting a large fullstack framework is not just a matter of willingness to learn - it is also about how much work I need to do for integrating third party libraries, how much does my write-compile-preview feedback time suffers, how may I have to adjust my dependency system, what other choices the said framework imposes upon me etc.
In contrast, if I want to try out a small self-contained reusable library/component it is much easier to incrementally adopt or experiment with in a new or old project.
We've created the need front-end and back-end developer distinction by creating overly complex front-end build systems, and overly complex SPA frameworks.
I have the complete opposite view. I'm a fullstack dev, so I'm comfortable using Javascript and a backend language.
JS replacements like Blazor clearly serve backend engineers who don't want to deal with JS. That's fine, and it's a valid way of developing, but it's clear that using JS with C# is a more holistic way of developing.
I'm comfortable with Javascript. I'm not comfortable with constantly having to change and upgrade my code or build system for the next breaking change in Webpack or in an unreadable complex Typescript typing, or the spider web of React libraries.
Doing nothing is not an option either, because that bites you in the ass as well because that newer Node runtime turns out not to support a deprecated md5 hash function the outdated Webpack in this project, which only gets a few weeks attention per year, relied on.
Now I only have Blazor for my frontend with a little bit of gulp to compile some dart-sass with design tokens and do some minification on some glue javascript.
I’ve worked with Blazor for about a year. It can be extremely productive for writing real internal business applications. “Backend” people can easily make interactive user interfaces and utilize their C# skills.
I think the threat to Blazor is that productivity in general in organizations is not enough prioritized in comparison to dogmas or current trends. For example that now a days you “should” have a separate front end team and that front end team “loves” technology X (for example React).
That's my experience too, it's near perfect for internal tools like admin panels, where you don't necessarily need to hire dedicated front-end engineers. UI might be a bit ugly, but that's okay for internal use. Usually, admin panels end up having a weird assortment of buttons the real frontend doesn't even need, so creating REST API dedicated for that, and then React frontend to go with it is not time well spent.
This also depends on your backend engineers or whoever ends up maintaining the internal tools, are they comfortable using Blazor or not?
If you need frontend engineers and designers then going with React and the mainstream is wiser.
Although it is not that difficult for a front end dev to spend a week of time or so to create a custom styled component library in Blazor for your company and get things looking good and branded by default.
At the very end of the blogpost the author asks why not compile C# to JavaScript, like F# (Fable) does? The author thinks that would be the best solution overall, and is surprised it has not happened yet.
But this will not necessarily be any better than compiling to wasm. It avoids the .NET interpreter, which decreases the download, but it will still need to bundle a lot of library support code. And getting the language semantics exactly right - including features like C# finalizers which do not have direct support in JS - is tricky, unlike with wasm. And it won't benefit from the speed of the wasm implementation in AOT mode (which Blazor supports), which can be much faster than JS.
Compiling to JS definitely still makes sense in some cases, but it isn't an idea that Microsoft or the .NET community has somehow overlooked. It has been done and it has its own tradeoffs.
Trying to program the web front end like you do the API backend feels like an antipattern. I'm all for productivity but you eventually hit issues that cannot be resolved because the client/serverness of your solution has been abstracted away from you. Those of us with WebForms scars remember those days.
Like the article suggests right at the end, I want a C#-compile-to-wasm with new language structures for common web browser features such as shadow DOM. Perhaps also without the .NET core lump unless you really need it - and even then importing only the dependencies you need. I almost love Typescript but only because I spend my life wishing it was really C#.
Blazor looks cool but it's not quite native enough to client/server. I've been burnt by Silverlight and have a lots of ReactJS at work so the benefit isn't quite worth the cost and risk. I wonder if in a future role I might be tasked with a greenfield app for which it's a brilliant fit but I can't see that in any of the SME roles I've had so far.
I believe there is a simple lesson to be learned from all ambitious frameworks of the past that now lie in ruins covered in sand.
It's wise to decouple the front and back-ends. Run away from tools that pretend you can do everything within one single framework. Run away from tools that make it more complicated to decouple both. Manage front and back separately. Develop them separately. If it takes a full article to explain a technology, it's probably too complicated.
Having maintained both JavaScript SPAs and Blazor apps for the past 4 years, I disagree with the article's point about Blazor being more complex. I've had way more issues keeping JS tooling running and having to spend time fixing issues when I upgrade packages. Things really get fun when you have to produce an SBOM for security audit. You can generally get by with way fewer dependencies in a Blazor app and the build process starts simple and can get as complex as you want it to be.
Another point not mentioned in the article is that Blazor can also run directly on local hardware - desktop or mobile. This doesn't use WASM or web sockets and runs at full native speed. This is a big deal where I work since we can run the exact same UI on kiosks as well as on a web site, with essentially the backend swapped out.
I'll take this opportunity to plug one of my personal projects, a graphical (node-based) regex editor written Blazor WASM: https://github.com/jcparkyn/nodexr
Since other web frameworks struggle with performance optimizations for a decade (see Angular, React), Blazor seems like something you wouldn't pick unless you didn't care much about performance (mostly network traffic I suppose)
But for teams that already have invested in .NET and need to migrate desktop apps to the cloud, this seems pretty reasonable.
There are millions of boring corporate apps that need something like that, and most of us work on those boring companies, rather than "on the edge" of tech...
Also it's much harder to reverese engineer WASM than de-obfuscate JS so maybe there's another use case for Blazor (and WASM in general)..?
I used Blazor Server to build a hobby project of mine [1] and must say I am pleasantly surprised. Not having to build a separate client and duplicating code and models is really nice. I use my project daily and it is surprisingly fast to use, and the dropped connection does not bother me too much.
I would not recommend using it for anything other than smaller applications where users are expected to have a steady connection though. But for smaller applications it’s a nice alternative, cutting some of the effort required to get an application out there.
Seems like an awful lot of complexity and significant compromises just to get to use C# instead of TS or JS.
I wonder what the practical scalability difference there is between streaming updates over a web-socket connection and streaming updates over a long-lived HTTP connection. It sounds like the same exact thing.
Hopefully it can keep the complexity of auto mode under the hood.. I don't think app devs want to deal with code that behaves differently depending on whether webassembly files are cached or not.
People are willing to compromise and put up with a lot of complexity if it gets them out of having to engage with JavaScript and its supporting ecosystems.
Performance:
Blazor WASM lags behind traditional JavaScript frameworks in terms of performance. The WebAssembly runtime is still generally slower than optimised JavaScript code for compute-intensive workloads.
Almost correct. compute-intensive workloads are (often/theoretically) faster in wasm, but the horrible js marshaling which is still required kills most/all benefits. Current wasm GC implementations don't fix this.
There was a sort of a equivalent - GWT. And it was really good and ahead of the time: it covered intermediate API out of the box, provided quite nice way to develop FE in plain Java, it was async, it allowed common BE and FE codebase.
I think that's missing from this discussion is why so much effort is being put into Blazor. Why would anyone use or even build a framework with 4 rendering modes? The answer is that the on the ground developer experience of writing interactive applications in Blazor is extremely nice. In an ideal world, Blazor feels like how web development should be. If you've never used it then you'll have no idea what I mean.
I'm not using it in production yet for many of the reasons discussed in this article although I may revisit it again in .NET 8. The newest modes might actually push it over the top for applications that I develop. I wish there were no downsides because it just is so very nice to code in.
I miss SSR JSPs. I worked on a b2b2c marketplace, the caching and performance of SSR for routine pages was a godsend. We also used a "widget" architecture pattern with reusable components.
We then hired a front end architect who replaced all widgets with react components, changed our checkout to full CSR React, our latency raised for all users, we lost 5% conversion on checkouts that never recovered, then the next step was to build a React service to help render the React, and moved CSR React to SSR React service.
We now have 2 teams to support this. I get there are a list of other tradeoffs but I really miss JSPs.
The whole discussion around why a .NET shop might choose Blazor over Javascript ecosystem misses these critical things when it comes to developer experience:
1. Antivirus scans — it will take a lot more time for an antivirus to scan the tens of thousands of files in node_modules than whatever dotnet is doing. Especially on Windows
2. Corporate proxy support — the story of proxy support and importing custom certificates for the MITM proxy is still pretty much horrible (although improved since middle-2010s) in the Javascript ecosystem. dotnet is not perfect here and still has some warts in some specific tools, but much much better.
If antivirus scanners come up at any point when the topic is things that are "critical" to the developer experience (let alone as the very first thing), that's a really telling baseline—the tip of the iceberg as far as indicators of organizational dysfunction go. You might as well be speaking from a place where every employee starts the day with a nailgun fired through the palm of their hand and then they spend their time gushing over lunch about how Acme Co. has the best woodsaws out of all the woodsaws because theirs are the ones that let you really get in there and cut away most of the plank—so you're just walking around with a medium chunk of wood fixed to the back of your hand, of course, instead of the whole board. Nuts.
Not sure that I follow... From what I have understood, a lot of corporations have these kind of set ups in place to avoid downloading malicious software, limit the possible impact of malware, monitor employees and so on. And it is clear that no development team can change policy for whole organization — so why shouldn't developers choose the kind of tooling which allows them to deliver within the constraints of the organization?
You are taking it as a given that developers are making these choices at organizations where it is normal for them to have to fire a nailgun through the palms of their hands at the beginning of the day. I'm saying that when developers are making these choices they should be doing so at organizations where it is a given that they don't have to do that.
Windows Defender handles node_modules fine, and if you're dumb enough to choose something other than Windows Defender on ... Windows ... that's on you.
Sorry, but you seem to be missing the context here — this is an environment where these kind of decisions are not made by the developers, but are in the hands of other departments. So the choice of antivirus or other corpoware or disabling the antivirus is not something that the development team has any say in.
Yes, how dumb of me to not make a completely weird request to interview the corporate IT department of my job after I had been laid off for two months and was struggling to find anything in my area.
In the one illustration, there's just an extra disembodied hand sitting on the one guy's laptop. Another one has one finger branching from another instead of connecting to the palm. Is your illustrator okay?
This article is really odd. The long lists of disadvantages feel a lot like the lists of disadvantages that ChatGPT produce, where relevant disadvantages will be placed right next to things that are wildly inapplicable to whatever I'm doing. And the whole list is extremely impersonal - there isn't a single reference to the product(s) that the author worked on, so it's impossible to tell if the downsides are even real downsides or not.
I develop company's internal tooling using Blazor Server, and have developed moderately complex and data intensive applications. As a former React Developer who has spent most of his time working with Node.js and JavaScript tooling, Using Blazor WA and Server felt like a breath of fresh air. C# is joy to write and everything fits very well with existing enterprisy Microsoft services.
State management is pain in React, until you install 3rd party libraries (Jotai, Zustand etc.), each value needs to be bound individually.
Dotnet command line felt very snappy compared to npm/pnpm.On my crappy company laptop, when a nextjs application dev server starts, my blazor server app has already opened a browser tab with website running locally. efcore is also good.
Overall working with blazor felt like working with Vue/Svelte, but with faster performance on backend. Nowadays I only touch React if strictly necessary.
A couple of observations: Blazor plays well with any back-end technology, not just a .NET server-side. That should be a no-brainer for developers, but its an assurance that non-devs need.
Secondly, performance issues apart, JS-interop is really easy to pull off. That is good news for the non-puritan, pragmatic programmer. We understand that it will take a while before Blazor libraries catch up to the large number of options available for Angular and React. Until then, Blazor + JS-interop is a great solution that covers all scenarios in the vast majority of cases.
For the last year, amongst other things, we have been building a high-performance online trading platform using Blazor, Spring Boot and GCP. No insurmountable issues so far!
Tangentially to the topic of the blogpost, has anyone else noticed that many recent articles on Hacker News feature AI-generated illustrations? They seem to have a unique, AI-specific style and that weird "uncanny valley" like quality where you can easily tell it was, in fact, a machine generated thing?
I used DALL-E 3 to generate the images. I always wanted to include more images in my blog posts, because I personally (and I might be wrong) feel like it sometimes helps to better tell a story or explain a sentiment which you hold as the author. But as a hobby blogger you don't get to have nice illustrations or graphics without paying an arm and leg for something which is just a free blog post. So yeah, I used AI for it and I love it. Also I'm not a native English speaker and I'll admit that I use AI a lot in recent months where I type up my badly worded text ridden with a lot of grammar mistakes and then feed it into a prompt to help me smoothen things out. I actually think I'd be stupid not to do it and I don't see it much different to a book author writing a book and then sending the script to a team of editors who do exactly the same thing, just that now it's a computer doing it faster. I have no shame in admitting this :)
This feels like a move to be more like Rails, and I'm there for it. The problem with Microsoft is that, every time I think, hey, this new thing might be useful for such-and-such kind of app or problem, by the time I get around to trying to use it, they've moved on to something else.
Anyone tried Blazor in production? I checked it out (BRIEFLY) back when it was released, and it looked pretty cool - but there was really not a whole lot of info back then. It's been 4-5 years now, so I'm curious if anyone has actually integrated it into prod
I knocked up a quick prototype for a friend about 4 years ago (client side blazor wasm .net core 3.0) and he turned it into a successful small business. About 15 simple screens communicating with restful services all in one solution. He found some cheap developers to hack on it for some extra screens but he eventually unpicked their work. The amazing thing is the system is so simple that he, a someone new to programming, could make sense of it and change it without help. I took a look at it the other day and the entire app just ticks along without a problem.
Tbh, I’ve never understood the appeal of server side blazor. High latency is too risky and you may never know that your clients are experiencing it. This hybrid approach in .net 8 is interesting but for a business app, initial load time is a once off thing and only a few seconds anyway. Kind of like an installer in a way.
I have a few criticisms though. I work almost exclusively on Linux now and it was extremely painful to try get an old .net project up and running because Microsoft aggressively sunset old .net versions. 4 years is not that long ago and I didn’t want to go through the pain of upgrading to the latest to make a few minor changes. So I had to dust off an old pc and use that. I understand that the .net core era was a turbulent time for change so maybe that’s why. But dammit, at least leave the old SDK’s up for a decade for this very reason!
Ironically, the slowest part of the system is the hosted sql server instance that is prohibitively expensive to run at a half decent speed with laughably low volumes of data. What a captured market that is when you can simply spin up a free PostgreSQL instance on the same vm and be done with it.
Anyway, to answer your question. Yes, it can be used in production. This one has 3 production instances and is used by about 30 people on a daily basis.
> But dammit, at least leave the old SDK’s up for a decade for this very reason!
You can get .NET Framework 4.8 from the Visual Studio installer, no problem. It's not even marked as deprecated. If you know where to look, all the other versions are available, too.
Downloading older builds remains an option, and scaffolding the environment for your chosen version is simplified by their scripts. I've successfully installed six versions, ranging from 2 to 8, side by side using this method.
===>>> YES. It takes a bit to wrap your head around, but functional programming is actually very good for UI's.
==>> "As I reach the end of this blog post I want to finish on a positive note. I dare to say it, but could C# learn another thing from F#? Thanks to Fable, an F# to JavaScript transpiler, F# developers have been able to create rich interactive SPAs using F# for quite some time. Developed in 2016, Fable was originally built on top of Babel, an ECMAScript 2015+ to JavaScript compiler. Wouldn't something similar work for C#? As I see it this could pave the way for a very appealing C# framework that circumvents the complexities around WASM and SignalR."
There actually are several C# to JavaScript transpilers out there but none are well-maintained with a strong following (compared to Fable). Some examples are...
It's not really different. If you use .razor files it hides the way state mutation works so it superficially looks more imperative (I guess so it isn't scary to people who are used to server rendered razor templates in asp.net) but it's basically the same as MVU/react/elmish/whatever in f#/fable just without explicit update messages.
You can trivially build something that looks exactly like elm/elmish on top of blazor if you just organize your code that way.
Also, I like fable but you have to be careful about what .net features you use because it's transpiled and the standard library is reimplemented (there's lots of stuff that hasn't been implemented). Blazor has better compatibility and you can use pretty much anything in .net and even native code that has been compiled to WASM.
So 1) there's no good reason to abandon blazor for something more like fable in terms of being transpiled to javascript, since wasm will only be more mature, and 2) if you want something that looks more functional like f# with elmish you can easily get that on top of blazor.
(There is even something similar to fable/elmish on top of blazor for f# (Bolero) but you could do the same thing in c# too).
I'm still weary of using Blazor in anything serious/long term. I've been burnt before by MS, leaving me with a tech that's both hard to continue using and hard to get rid of if need be.
I had quite a lot of faith in Blazor back in 2017, at the time I was still working mainly with C#, but then instead of getting better and more robust it went down the tangent of trying to do everything, all at once... But not in the "batteries-included" sense, instead more like in the bloated, unwieldy, and poorly documented.
In the end I moved on, started working with Rails and not long ago we got Hotwire, which fares pretty well with Blazor, or Liveview...
Shameless plug: https://skymass.dev is a js/ts version of Blazor. It is a batteries-included, code-first solution for creating high quality business web apps by simply writing a single-dependency backend process. Please be gentle as it’s in beta.
I find it hard to justify/invest the time needed to really dig into Blazor. Everywhere I go/look, buisnesses are stuck on mature solutions utilizing ASP.NET MVC 4 or 5 + Entity Framework (non-core). Just upgrading beyond that requires a lot of migration work, let alone rearchitecting for the new and shiny Blazor.
Curious to try SSR to see if it can dethrone SvelteKit for me. SK is pretty great, though the backend side feels under-baked a bit compared to FastAPI.
Regardless, I’m pleased to see more contestants try to wrest mindshare away from JS culture. Cambrian explosion or something!
You might be confusing it with another part of ASP.NET Core like web APIs, which are generally super fast. Performance has never been a strong point for Blazor, except for the recent AOT support which has its own issues.
Honestly I'm pretty happy with just the stack: server html jsx templates + htmx boost + css view transitions. It's simple, easy to troubleshoot, fast to build, and crucially provides most of the important benefits of a SPA (seamless updates) without hardly any frontend JS.
Wanted to give htmx a try. I have a form, in which multiple text editors can be added. Apparently here we need an endpoint to deliver the extra field and I can tell htmx where to append it, so some extra work but okay.
Then the user should be able to click a button and the additional text editor should disappear.
> Oh for that you need this custom language called hyperscript, it's so easy to get st...
Probably worth keeping in mind where WASM itself actually is.
The ability to run anything without having to do your own memory management is only just landing now (already in Chrome, next release of Firefox announced today and Safari as per usual is nowhere to be seen and is behind the curve again).
So when you think about what that very first generation of frameworks is going to even look like, it’s safe to say that most of them don’t yet exist.
The only one I know of is Flutter which is going all in on a path that’s genuinely independent of HTML and CSS and going straight to canvas and WebGPU via WASM.
But even that is still a few months away. Blazor takes an interesting approach in that it’s basically one foot in both camps in that it sticks to HTML/CSS and uses DOM rendering to handle the UI while still letting developers stick the overwhelming majority of their application logic in C#.
It is impossible currently, as WASM only allows for compute, everything else relies on the host, and exported functions to be called by the WASM code.
There are some plans to support DOM directly from WASM, but at the pace Webassembly features get into the browsers, it is years away if it ever gets done.
You can build really rich interactive experiences in Blazor at a fraction of the time required to build the same thing with the standard JavaScript SPA architecture. However, now that we have many customers using the application in production, we're starting to see some of the not-so-pleasant side of Blazor Server. When experiencing a lot of requests, the experience is degraded for all users of the app. In addition, it's not very good at re-establishing the WebSocket connection if it fails, giving a poor impression to the user. Though, I'm impressed with the latency—we're hosted in Europe and have customers in New Zealand who use the app without any latency issues whatsoever.
I'm excited about the auto-rendering mode, which looks pretty straightforward. I don't really buy the author's argument that it introduces an extra layer of complexity—we're still light years away from the complexity that a modern JavaScript SPA involves. For small teams with just a couple of full-stack developers, Blazor is still one of the best and most productive stacks, in my opinion.