if you havent used blazor before there are some downsides.
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.
Reposts are allowed after a year without significant attention, and it's not uncommon for them to gain traction. Blazor may be old news to you, but it appears there are a lot of people who are still interested or who are learning about it for the first time.
If they made an easy way for us to move from asp web forms to blazor that'd be ideal. Not bringing web forms to core is fine but without giving us an easy way to migrate to blazor is a big problem imo. There are still a ton of apps and big code bases that run on web forms.
WebForms code cannot be ported over because WebForms' entire architecture is built around a stateful view-layer over stateless server-side code. It's fundamentally broken and incompatible with how the web works (simply look at how WebForms' PostBack system breaks the browser back button and makes it impossible to link to pages or content that can only be accessed via PostBack).
There isn't an easy way to move from WebForms to MVC because it's impossible.
The sheer amount of greenfield code being written today so dwarfs all the legacy code out there (especially that under consideration for upgrade) that Microsoft has just focused full steam ahead on the former. It’s hard to disagree with the business logic there.
(Medium-term migrations from ASP.NET MVC to ASP.NET Core, was more streamlined.)
Yes, agree. But at the same time we could agree that microsoft left their older customers with a dead end solution costing a fortune or even imporrible to upgrade. They would be unwise to take microsoft recommendation again but corps seem to continue to do so..
To be fair, WebForms is 20 years old. It requires .NET Framework, but Microsoft just released another version (4.8.1) of that last year even though they said they were done with 4.8 back in 2019. By the time it's totally dead, companies will have been able to get a quarter of a century out of that tech.
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.
I’m too busy being angry at Microsoft for abandoning SWF, WPF, and UWP without providing an amazing replacement to worry about how they treated webforms.
That’s terrible advice. You’re assuming all the world is identical to Silicon Valley and its startup culture of bashing things with open source rocks instead of just buying a proprietary power tool.
Outside of that pond, there is a giant ocean of developers that work in enterprise and make a perfectly respectable income.
I wouldn't say it's necessarily bad advice. Even in the enterprise where .NET has the most adoption, most people building web apps are doing so with JS/TS. I really doubt Blazor will get big enough so as to be the primary way people build web UIs. Doesn't mean it's not worth learning, but I would agree that a junior shouldn't focus on Blazor first.
Indeed, within an enterprise environment featuring a pre-established C# backend, I've discovered that Blazor, particularly Blazor Server, offers exceptional productivity. It essentially facilitates the deployment of a web front end with minimal overhead.
They were talking about Blazor. You're talking about dotnet as a whole.
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.
This is nonsense. If you're a junior developer, don't listen to advice from people who claim that your career will be "stunted" by learning non-traditional frameworks.
I agree. I think frameworks that hide the client server interplay are bad. This type of technology teaches magical thinking that doesn't live up to its promises as soon as you go a little off the beaten path and is more frustration than it's worth.
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.
This is because it's the server version. This is equivalent to liveview websites that have roundtrip latency. Do you know if there is a wasm hosted version of this?
Yeah, the issues here appear to be developer related. The docs offer less practical guidance than they should on proper deployment of blazor applications.
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.
It’s deployed on an all-Microsoft stack and despite that it’s not working. Do MS still makes you think you need to pay for an Azure service to have WS in your app? It used to be the case.
Blazor is not intended for websites, it is intended for enterprise, intranet CRUD applications with interactive forms, tables, etc. Especially if you already have .Net on the backend. I just finished one such application on Blazor Server and it works great. Programming was easy having previous experience with Angular.
Edit: And the most important advantage, next to productivity, is maintainability, without the entire JS/TS/Node toolkit.
No. This website is slow because its a liveview style websocket on each drag and drop action. A wasm implementation would not exhibit these characteristics.
On the other hand, remote work is very popular today, but if employees want to work remotely, it's their problem to have a good internet. I tested the Blazor server on a poor cellular network where packets could be lost or there were random long delays in packet delivery, and the application was unstable. It was better to set long-polling and enable compression, which is disabled by default. This is also a problem with websockets - messages are not compressed. Long polling again was less resposnsive on good internet connection. I'm curious how this would work in various configurations of quic/http3.
In Blazor Server, for things like drag and drop or any mouse movement events, you should avoid tying them to server-side handlers, but you can also just write JavaScript code. The backend needs to know what to render, not necessarily where, you can keep it on the frontend.
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.
Getting these kinds of applications out of Silverlight or desktop apps was one of the greatest steps forward I've seen in at least a couple large enterprise shops - and Blazor definitely feels like a step back in that regard.
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.
>Getting these kinds of applications out of Silverlight or desktop apps was one of the greatest steps forward I've seen in at least a couple large enterprise shops - and Blazor definitely feels like a step back in that regard.
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.
> The JavaScript ecosystem is almost implicitly supportive of open source
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.
How does that work in the modern age of ubiquitous cloud, BYOd, international corporations and global hiring pools? In this world, there's basically no difference between internal and external websites, maybe except for authentication and/or needing a VPN to access, which just exacerbates these problems.
My applications run on intranet/VPN behind IIS with Windows Authentication. If not WA, I would always choose Blazor Wasm, it gives you more control over what you do.
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.
Blazor Server is completely inappropriate for an internet facing site.
The same is not true for Blazor Webassembly, which operates as combination of client and server projects, typically communicating via standard REST calls.
Nope. Being able to write in C# using a vast array of C# libraries in the browser is orders of magnitude better than writing in JS or even TS. C# is enormously superior to JS and superior to TS.
If you care more about development experience than users, that's fine, but in the case of SPA, JS frameworks will be faster and lighter.
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.
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.
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.
Avoid blazer like the plague. I use it in my work and the only reason why is because everyone uses C# and can’t be bothered to learn a second language. Take a wild guess which company that is. It’s an awful architecture that only exists because some exec at Microsoft willed it into existence. There’s a reason why Java doesn’t get used to program real website front ends and I’d never use C# for web dev if I weren’t forced to.
Blazor is based on a build of .NET (CLR + BCL) for WASM - though it is highly optimized and unused code is aggressively removed from the WASM bundles it still means your users will need to download (at least) 6MB of WASM while your SPA loads - which makes Angular look anorexic in comparison.
...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 .Net team has made pretty significant strides in minimizing the bundle size and I would expect that to continue. It’s now also possible to combine pre-rendering and streaming with web assembly to improve the loading experience.
You're talking specifically about Blazor client-side framework which is designed for e.g. games or drawing apps where 6mb of downloads isn't particularly onerous.
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.
Angular has really improved in this area, the addition of standalone components mean your initial payload can be very small indeed, and then just lazy load the rest as/if you need it.
We evaluated a few options and settled on Blazor after tiring of the build chain and dependency complexity of the TypeScript world. So far, it’s been nothing but a breath of fresh air to work with.
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'm currently working on a large blazor project, and it's pretty much been the same experience as all other shitty microsoft frameworks i've used, where its super nice to work with at first when there isn't too much complexity or edge cases, and all the magic under the hood makes everything super convenient and you find yourself asking why everyone doesn't use this for everything, but by the time the application is too big to consider scrapping it or rewriting it with different technologies, the cracks start to show and it's so much work to even develop the rest of it that you start looking for another job
> I’d never use C# for web dev if I weren’t forced to
.NET Web API is where it's at. I built an Express backend today and it feels primitive. The new minimal templates Web API templates are really good and even easier to get rolling than Express.
I've used Nest and what really got me was that it seemed like a weird compromise.
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.
> There’s a reason why Java doesn’t get used to program real website front ends.
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.
Java is/was heavily used in the browser. GWT is actually a thing. Since Google dropped it, it lost a lot of users basically. But there are still some big users.
Microsoft’s history with UI frameworks has been challenging, with experiences from WPF, Silverlight, and UWP leaving some developers, including myself, hesitant. It would be great to see consistent and long-term support in this area before committing to their UI solutions again. I won’t be burnt again.
This is a direct descendent of ASP.NET MVC which is like 14 years old.
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.
I've been using ASP.NET MVC since the preview and wouldn't touch this. It actually feels more like the old ASPX web forms where the components were inscrutable black boxes. Ultimately, I think it's actually better to have separation between UI, client-side state persistence and server-side frameworks.
It does feel like web forms, complete with the life cycle methods (component instead of page/control in this case). I built an internal application for a client and it felt like a fusion of react and web forms.
Kind of absurd the company that invented TypeScript does not embrace it at all on the frontend. No native web framework, no frontend component libraries, all while the past 20 years have suffered from wave after wave of questionably supported framework where Microsoft could have easily filled the void. Even React has been abandoned by Meta. Frameworks like Next.js and SvelteKit are eating Microsoft's lunch in the new full stack world. Entity Framework is the only thing I really miss.
Native, not WebForms 2.0. If WebForms was made in javascript to begin with we'd have a stable 20 year old UI framework right now rather than 20 years of disaster after disaster. It really does take a big tech company with a zillion developers to create good frameworks and tools that survive for decades. Things you can build on confidently and not have to worry about when you'll have to do the next rewrite. No one is writing SQL or C# worried about some new version obsoleting all their code or those platforms being abandoned.
I don’t think any company with the size of MS can have a unified tech stack strategy. Inevitably, competing departments will push different technologies.
Leave vercel alone, hehe. On a serious note, I've been trying to learn .Net & C# for a long time but didn't know where to start. I took a different route and learned other languages (py, js/ts, R, Dart, Swift) and now I don't know if it's worth learning it just for the sake of it.
To be fair, out of these TS/JS and Swift stand out like pretty big ecosystems and languages, I don't know how one developer can fully "learn" all of them to a high proficiency level in a reasonable time.
For C# (which is another "big" language), people tend to overlook high quality first-party tutorials and documentation:
If you had to pick only one language to work with and trendiness wasn't a factor, C# is the best choice. Best docs, extremely wide use case coverage, great professional community, great balance between performance, speed, and ease of use.
Best all-purpose language - only JS can seriously compete.
Blazor is excellent! The entire JavaScript ecosystem is so fragile and volatile, you will get JS-fatigue very quickly. Each time you change projects you have to learn completely new JS libraries, frameworks, tool, etc. No such problems with Blazor.
Haven't touched Blazor in 2 years. In the context of blazor server, what's the recommended pattern for state management?
Does it make sense to use MVVM (e.g. via MVVM Community Toolkit for source generated observable properties etc) or plain C# objects would suffice with manually calling StateHasChanged() whenever necessary? (I guess that since rerenders are driven by DOM events the situations where manually calling StateHasChanged() is quite low)
I've been using blazor since release in 2019 and can count on one hand the amount of times a call to StateHasChanged() was used and actually needed when doing a peer review
Most of the time I've seen that function used it was due to improperly written asynchronous code.
There are two major flavors of Blazor: Server and WASM.
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.
Also, since .NET 8 (which will be released next month), there is a new way of using Blazor which combines "normal" SSR (same you'd get with ASP.NET MVC or Razor Pages), Server/WASM functionality and stream rendering. Meaning you'll be able to get the best of all worlds (SSR speed and SEO, and Server/WASM interactivity), all at in one place.
And there is Blazor Hybrid. Which is basically a electron shell / Cordova approach where a web view hosts the UI and the rest is in the regular .NET process on windows, Android, Mac and iOS. Maybe Linux not sure. It is currently a minimum of 4-5 different modes. Blazor is a beast.
I agree that WASM is the better option. In my opinion it is however not viable for public-facing sites. The bundle size even if you pull all the tricks is just too big.
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.
A few months ago I wanted to make a really simple web frontend hosted by a WinForms app (don't ask), and tried Blazor Server since it was going to be used by a single user on a local network.
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.
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.
That is interesting! Do you find that setup useful for CRUD-style apps too? What parts of your application would typically be written in WASM then? I am asking because if I look at my usecases, I mostly see rendering logic done by a JS framework and a restful API that does little more than serving the frontend by querying the DB and mapping between models.
Well, I had 2 apps written this style in recent memory. One was adapting an existing app with a React frontend and a .NET backend to work in an air-gapped place - we just replaced all the backend calls to calls into the WASM runtime, which did its thing internally.
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.
While Blazor is a great migration path for Web Forms, it does little for companies with clear FE / BE separation across development teams, where .NET is restricted to SSR/SSG and APIs.
Built a few things with Blazor (largely internal tooling). Feels like a cross between Meteor, WebForms, and Phoenix LiveView. Fast and simple.
- 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).
For those interested in .NET languages with alternative compilation targets, F#'s Elmish (https://elmish.github.io/elmish/) is pretty unique.
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.
128 comments
[ 3.2 ms ] story [ 142 ms ] threadblazortrain.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.
Did they update the documentation layout?
Blazor has been around for 5 years or so now, and discussed before and this looks… the same?
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.
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?
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.
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.
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...
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.
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.
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.
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.
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)
Best all-purpose language - only JS can seriously compete.
https://learn.microsoft.com/en-us/aspnet/core/blazor/?view=a...
(the even numbers are Long Term Support versions)
Most of the time I've seen that function used it was due to improperly written asynchronous code.
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.
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.
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.
- 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).
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.