There are two major flavors of Blazor: Server and WASM.<p>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.<p>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.<p>The ProTip is this: if you can make the choice, choose WASM. Even for an intranet app and despite the additional dev work.
As someone who likes .NET I have never once seen a Blazor website that works well.<p>Just try dragging and dropping: <a href="https://blazordragdrop.azurewebsites.net/" rel="nofollow noreferrer">https://blazordragdrop.azurewebsites.net/</a><p>The "best" I've seen has been like 100ms of latency.
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.<p>Best all-purpose language - only JS can seriously compete.
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.
I you're after something similar (write a SPA in non-JS) but you prefer Java or Kotlin, check out Flavour: <a href="https://flavour.sourceforge.io/" rel="nofollow noreferrer">https://flavour.sourceforge.io/</a><p>Comparison to Blazor:<p>* <a href="https://frequal.com/java/TeaVmVsBlazorWasm1-0.html" rel="nofollow noreferrer">https://frequal.com/java/TeaVmVsBlazorWasm1-0.html</a><p>* <a href="https://frequal.com/java/TeaVmVsBlazorChart.html" rel="nofollow noreferrer">https://frequal.com/java/TeaVmVsBlazorChart.html</a><p>Flavour podcast: <a href="https://castini.frequal.com/cast/show/Flavourcast/f7e171e8-22de-4f3b-adbb-5462991343c5" rel="nofollow noreferrer">https://castini.frequal.com/cast/show/Flavourcast/f7e171e8-2...</a><p>Java Magazine article: <a href="https://blogs.oracle.com/content/published/api/v1.1/assets/CONT8F9404EB36BE4DBFB2A9E220E42ACCD7/native?cb=_cache_8644&channelToken=4d6a6a00a153413e9a7a992032379dbf" rel="nofollow noreferrer">https://blogs.oracle.com/content/published/api/v1.1/assets/C...</a><p>Real, fast-loading apps made with Flavour:<p>* Wordii, a 5-letter word game: <a href="https://frequal.com/wordii" rel="nofollow noreferrer">https://frequal.com/wordii</a><p>* Tea Sampler: Demo app with code samples of coding with Flavour: <a href="https://frequal.com/tea-sampler/" rel="nofollow noreferrer">https://frequal.com/tea-sampler/</a>
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.<p>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.<p>I spent a couple of hours working backwards trying to simplify this, but didn't really succeed.<p>FWIW, I've worked with .NET since the 1.1 days so I tend to be used to their idioms.<p>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.<p>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.
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.
Tbh, since the introduction of .NET 7 WebAssembly, Blazor isn't my preferred way of writing .NET apps in the browser.<p><a href="https://devblogs.microsoft.com/dotnet/use-net-7-from-any-javascript-app-in-net-7/" rel="nofollow noreferrer">https://devblogs.microsoft.com/dotnet/use-net-7-from-any-jav...</a><p>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.
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.
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.
Built a few things with Blazor (largely internal tooling). Feels like a cross between Meteor, WebForms, and Phoenix LiveView. Fast and simple.<p>- 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.<p>- 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.<p>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.<p>I'm also looking forward to trying the DotNet 8 hybrid Blazor improvements.<p>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).
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.
For those interested in .NET languages with alternative compilation targets, F#'s Elmish (<a href="https://elmish.github.io/elmish/" rel="nofollow noreferrer">https://elmish.github.io/elmish/</a>) is pretty unique.<p>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.<p>While the default is reactivity library for Elmish is React, you can swap in Avalonia/FuncUI (<a href="https://github.com/fsprojects/Avalonia.FuncUI">https://github.com/fsprojects/Avalonia.FuncUI</a>) with just a little work as well.
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.
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)
The OP linked to v7.0 document, but 8.0 is in RC1 and goes gold in four weeks:<p><a href="https://learn.microsoft.com/en-us/aspnet/core/blazor/?view=aspnetcore-8.0" rel="nofollow noreferrer">https://learn.microsoft.com/en-us/aspnet/core/blazor/?view=a...</a><p>(the even numbers are Long Term Support versions)
The amount I don't like this model is remarkable.<p>Microsoft needs to just buy Vercel. They invented TS, they should lean into the huge successes there.
? Is something new here?<p>Did they update the documentation layout?<p>Blazor has been around for 5 years or so now, and discussed before and this looks… the same?