ASP.NET Core Blazor
learn.microsoft.com
learn.microsoft.com
Server is considerably easier to program with because it removes the complexity of making REST calls to a server component. It creates an illusion of seamless coupling between browser client and server methods. In reality, internet delay makes Blazor Server UIs unacceptably slow because UI interaction often results in a round trip call across the net. As well, every browser connection consumes significant resources on the server.
WASM is more difficult because of the need to use REST calls (typically) from a client project to the server side project. But the client side can be nearly entirely written in C#, targeting WASM and running in the browser - even including powerful .NET libraries (see NuGet repo.) The server code implements client services. Note that this should all sound very familiar with conventional web apps, except that a radically superior language is used instead of Javascript on the client side.
The ProTip is this: if you can make the choice, choose WASM. Even for an intranet app and despite the additional dev work.
I am talking about having to download >1MB in the best case before the site is functional. Simply unusable on slow mobile connections. React/Vue/etc. are often sub 100kB, you can even have something like Preact.js at 3kB if you want. I don't understand why this is seemingly not given more priority at MS: https://github.com/dotnet/aspnetcore/issues/41909 My prediction is that this will kill off the technology if they don't find a solution.
Just try dragging and dropping: https://blazordragdrop.azurewebsites.net/
The "best" I've seen has been like 100ms of latency.
I work on a startup that is on WASM (primarily desktop; little to no mobile usage, which limits the negatives of blazor wasm) and it's quite good. We were concerned about load time initially and asked users about the load time.
The response was "what load time". Blazor is good for the "right" kind of application, but like many see poor implementation due to limited documentation guidance or worked examples can severely degrade practical implementation.
Edit: And the most important advantage, next to productivity, is maintainability, without the entire JS/TS/Node toolkit.
You can also just use Blazor WASM, but I've had trouble setting up Windows Authentication when in Blazor Server it works out of the box.
Honestly, it's one of the issues I see with WASM as a whole. The JavaScript ecosystem is almost implicitly supportive of open source, since that's essentially what gets delivered to the browser. WASM feels like it take us back towards walled gardens where you have to buy Telerik or Dundas libraries to get the widget you want to use, and then find out they don't play nicely with some other part of your stack. For all but the must graphically intensive use cases, or companies that can afford to own their stack from the ground up, I see little reason to adopt it.
The thing my enterprise customers wanted to avoid was deploying software on their desktops. They didn't even like rolling out Office. Presumably Blazor eliminates that problem because the whole thing is delivered over http.
JS is basically a compilation target nowadays. Don’t tell me that a minified, tree-shaken JS file somehow helps open-source. Sure, .NET is definitely not the panacea of open-source, but that is not inherent in the technology, but the politics around.
When building internal applications, you can make many assumptions - where are your users and how good is their network connection, how many of them do you have - dozens? hundreds? maybe even thousands, but not millions, so scalability is not a problem. Whether the app will be used on a mobile phones or not. Will it be a problem if your application takes 20 seconds to open? :) If the employee will use it half of the day, then probably no.
My org does none of these so Blazor was a great option for us.
The same is not true for Blazor Webassembly, which operates as combination of client and server projects, typically communicating via standard REST calls.
For me the problem with TypeScript is not the language, JS/TS are fine for me, the problem is the entire toolchain - NodeJS, all the node_modules, configuration files, the need to compile.
Maybe Svelte, where they got rid of TypeScript and the types are now in JSDoc, could be a compromise.
DOMContentLoaded: 4.61s
Finish: 19.48s
https://pagespeed.web.dev/analysis?url=https%3A%2F%2Fwww.mud...
As others have pointed out, it is using the least efficient mode possible (HTTP 1.1 polling instead of WebSockets or WASM), so it is maximally sensitive to network latency. Unless you're physically near that particular Azure region, you'll have a bad experience.
Real-world usage of Blazor for Internet apps would typically use client-side WASM. Similarly, corporations might opt to use WebSockets over their private LAN, which is likely to provide very low latency and high bandwidth.
This demo app was accidentally deployed with the incorrect/default settings. It doesn't even have HTTP/2 enabled, let alone WebSockets, which are off by default: https://learn.microsoft.com/en-us/aspnet/core/signalr/publis...
Microsoft themselves mention that performance is expected to be bad with WebSockets off: https://learn.microsoft.com/en-us/aspnet/core/blazor/host-an...
When WebSockets are disabled, Azure App Service simulates a
real-time connection using HTTP Long Polling. HTTP Long Polling
is noticeably slower than running with WebSockets enabled, which
doesn't use polling to simulate a client-server connection.Best all-purpose language - only JS can seriously compete.
Blazor adds live updating of components via websocket using the Blazor Server opiton, or hosts the whole MVC web app in the browser if you are doing Blazor WASM.
To me it feels like a direct continuation of the last decade of ASP.NET development.
WebAssembly is a compilation target which stays. .NET went in the last years wherever it was needed. Because the market wanted it.
I have hope. And I have been with you on the journey.
Comparison to Blazor:
* https://frequal.com/java/TeaVmVsBlazorWasm1-0.html
* https://frequal.com/java/TeaVmVsBlazorChart.html
Flavour podcast: https://castini.frequal.com/cast/show/Flavourcast/f7e171e8-2...
Java Magazine article: https://blogs.oracle.com/content/published/api/v1.1/assets/C...
Real, fast-loading apps made with Flavour:
* Wordii, a 5-letter word game: https://frequal.com/wordii
* Tea Sampler: Demo app with code samples of coding with Flavour: https://frequal.com/tea-sampler/
What would be a Python equivalent?
I really disliked how much stuff the `blazorserver` project template created. A bunch of .razor files and .cshtml files (that had Razor code in them) in nested folders the contents of which were quite arcane. I wanted to scale it down to the absolute minimum needed, because I wouldn't need e.g. client-side routing, but the tutorials basically repeated setting up all this boilerplate without really explaining the basics.
I spent a couple of hours working backwards trying to simplify this, but didn't really succeed.
FWIW, I've worked with .NET since the 1.1 days so I tend to be used to their idioms.
Instead I made a Solid.js frontend hosted by in-process Kestrel and just used SignalR directly for all client/server communication. Somehow going into the JS/TS ecosystem (which I've worked a lot in too) had less friction. Very surprisingly, SignalR is not TypeScript friendly at all out-of-the-box. The frontend client could be source generated for sure, and I saw someone had made a tool for that, but still odd that it's not first party.
I can appreciate the idea of making an opinionated, scalable, production worthy template (if that is what this is), because in the JS/TS ecosystem the opposite is common with toy examples, but there is something to be said to offer a toy example to explain the underpinnings of the framework.
Well, there is this.... https://github.com/microsoft/fluentui-blazor
On the other hand Microsoft tends towards the other extreme. It seems to be continually at war with itself.
https://devblogs.microsoft.com/dotnet/use-net-7-from-any-jav...
Blazor is 2 things bundled together - a way of running .NET apps in the browser, via WebAssembly, and an SPA framework. Since .NET 7, it has become possible to use just the WebAssembly part. I prefer bundling .NET WASM, with a more traditional frontend framework, like React, since it doesn't suffer from all those issues others have mentioned in the thread. In addition, it's a battle-tested solution that most fronted devs are already familiar - the pool of devs writing kickass Blazor/ASP.NET Razor sites is comparatively tiny.
The other was rearchitecting a microservice-based app, where the .NET server basically only served as middle-man, calling into other various services. Eliminating this middle-man and integrating it into the client allowed us to serve the whole thing statically from CloudFront which massively simplified our infra situation.
I think where .NET shines is writing big, complex applications, for a simple CRUD app where the only thing I do is prod a database, I'd just go with a simple nodejs server.
In my experience, I tend to write all business logic in the back-end, and the front-end's job is mainly just presenting it to the user, so even with fancy SPAs, the bulk of the complexity lives in the back-end.
Keep in mind, that with all the super-duper trimming and size optimization options MS has added to .NET, the runtime is still multiple megabytes, so adding WASM .NET to your typical consumer website isn't super feasible, it's more for these niche use cases.
There isn't an easy way to move from WebForms to MVC because it's impossible.
(Medium-term migrations from ASP.NET MVC to ASP.NET Core, was more streamlined.)
That's outright amazing compared to any of the flash-in-the-pan JS front-end technologies. If you used the original AngularJS, for example, you got 10 or so years, and that's not an entire server-side framework.
Could you explain your perspective on Blazor?
...which basically restricts Blazor's use to corporate LAN environments, kiosk applications, and (maybe) PWAs - but it's otherwise completely unsuitable for use on the wider public Internet.
...but we know it'll end-up being used on the public web eventually anyway because developer time is worth more than the end user UX.
The far more common use-case is Blazor server-side which doesn't have this huge download overhead and works like server-side rendering in e.g. React, the download is approximately 150kb.
Isn't it like 1 second of scrolling through Instagram?
It’s important to clarify which model you’re working with when discussing Blazor. A lot of complaints seem to stem from using the Blazor server websocket model outside of its specific use cases. The web assembly and prerendered models are more comparable to modern developments in other ecosystems.
> I’d never use C# for web dev if I weren’t forced to
You get the power of Types with the flexibility of Express (as well as access to the entire node ecosystem), I like it.
It performs almost an order of magnitude worse than ASP.NET Core and isn't any simpler (TechEmpower; considering only the EF + PG non-middleware cases).
I feel like if a team is comfortable with TypeScript and considering Nest.js, C# and .NET Core Web APIs are not any harder, but you get much better throughput for your compute spend.
The reason being native browser support for JS and nothing else. Java assumes a powerful runtime and c# much less so. WASM is a godsend for interoperability in the browser and I personally hope it delivers us from the curre scourge in the long run.
- Server-side rendering is great for internal apps, or public facing ones where interactivity is minimal and you enforce websocket support. Lost connections are still messy, but a single codebase (literally) makes life very simple.
- Client-side rendering is great for internal apps, or public facing ones where users are fine with a reasonable-sized up-front traffic hit. Lost connections behave like with any other site, and you can still use shared code and libraries which work unchanged on client and server.
I quite like the latter. A DotNet solution with a client C# project, a server C# project, and shared code projects, with the server running an API and the client consuming it using shared models works well and supports end-to-end debugging.
I'm also looking forward to trying the DotNet 8 hybrid Blazor improvements.
That said, when doing C# I still prefer either plain ASP.Net MVC or a separate client hitting an ASP.Net Web API (pretty much the perfect mix of scalable performance and productive development).
Outside of that pond, there is a giant ocean of developers that work in enterprise and make a perfectly respectable income.
You can learn that on blazor and apply it elsewhere.
That being said I have worked with blazor since launch in 2019 and it's one of my least favorite SPA frameworks.
I went into [some detail](https://news.ycombinator.com/item?id=37798121) on another comment on this thread.
I agree with them on Blazor and I agree with you on dotnet (e.g. WebAPI) too. The two positions aren't mutually exclusive.
Being a Blazor developer will definitely be career limiting. I'd take almost any other skill set on a new hire (e.g. Angular, React, .Net MVC, Java, et al). The only thing it may beat is Web Forms/Visual Basic, because at least you'll know modern C# syntax. But I'm not allowing Blazor in any codebase I control.
Having said that, first job is a first job. Take that c# you learn to a REST backend job once you have a couple years experience.
We use F# on the front end (instead of TS), and thanks to the Fable compiler (which transpiles F# to JS, Python, Dart, PHP and Rust), most of the benefits of an Elm-style model in the UI can be ported to all sorts of different outputs languages. The rust target is in beta, but its promising because the WASM bundle size stands to be dramatically reduced compared to Blazor.
While the default is reactivity library for Elmish is React, you can swap in Avalonia/FuncUI (https://github.com/fsprojects/Avalonia.FuncUI) with just a little work as well.
blazortrain.com
The developer experience with blazor is lacking. Debugging tools aren't up to par with other dotnet SDKs. Hot reload only works when not debugging and only if you don't modify member signatures and a plethora of other conditions. Because of the afore mentioned the feedback loop during development can be slow. The razor editor doesn't support all the helpful actions you're used to with dotnet (e.g. cleaning up unused imports). Sometimes the razor editor gives really bizarre errors and you simply need to close Visual Studio and reopen for the. tk disappear
I dont mind the framework itself but there's a few design decisions that could have been better.
I think there are some good use cases for it though. AOT compilation to wasm is kinda neat for workloads that may benefit from that.
I also think that blazor server might just be the most novice friendly way to get I to web development because it abstracts away much of the web. that being said, the blazor server architecture has a plethora of drawbacks.
Most of the time I've seen that function used it was due to improperly written asynchronous code.
https://learn.microsoft.com/en-us/aspnet/core/blazor/?view=a...
(the even numbers are Long Term Support versions)
Microsoft needs to just buy Vercel. They invented TS, they should lean into the huge successes there.
For C# (which is another "big" language), people tend to overlook high quality first-party tutorials and documentation:
- https://learn.microsoft.com/en-us/dotnet/csharp/tour-of-csha...
- https://learn.microsoft.com/en-us/aspnet/core/getting-starte...
- https://learn.microsoft.com/en-us/dotnet (general sitemap of everything that's there)
Did they update the documentation layout?
Blazor has been around for 5 years or so now, and discussed before and this looks… the same?