Yup. Been using it for a very complex data app. Its awesome.

You can choose Wasm for LOB apps or on fast connections.

You can choose Server hosting for apps that have about 100,000 users at a time. Mind you, that is 100,000 users concurrently. Which should be more than enough for most apps.

There are plans to reduce bundle size and server side resources, coming in .NET 5.

As per Microsoft Benchmarks[1], it should cost about 100 USD per month (3 years, reserved instances, paid upfront) to handle 20,000 concurrent users. (This price is not including database, storage, etc). That comes to about 0.18 USD per user, for 3 years. (cost of serving app to 1 user for 3 years in total). Which seems pretty reasonable, especially if you have a decent, paid app. The cost comes down even more, if only a %age of your users are online concurrently.

On Digital Ocean, a similar machine, would cost about 40 USD a month. For 3 years, total cost for 1 users will be 0.072 USD

[1] - https://devblogs.microsoft.com/aspnet/blazor-server-in-net-c...

Blazor is certainly a very interesting and promising piece of technology. However, Blazor Server hosting mode is prone to latency issues and requires always-on connection to run an applications (so, no offline mode). On the other hand, the alternative Blazor WebAssembly mode requires clients to download a sizeable mix of .NET runtime and other system DLLs on the first use of the application (even a lightweight demo application with almost zero app-specific resources requires a download of 6+ MB of data in DEBUG mode and 2+ MB in RELEASE mode). Of course, relevant Microsoft teams work hard on further minimizing the size of the system bundle, but there are obvious limits to efforts in this regard.

Is offline mode widely used? I remember it being released to great excitement and then I never heard about it again. I assumed it died out when being offline became too much of an edge-case for your average user to be worth dealing with.

I have no idea about how widely used the offline mode is, but I'm curious to find out, should people run across relevant statistics.

I would describe it as more of a "tail end" case, a small percentage of use cases, but a long list of users.

I believe the runtime is under 1 MB before compression. As you stated, they're working hard to reduce that size.

At the same time, while not condoning it, I just scrolled to the bottom of Amazon's front page and downloaded over 30 MB.

I think that "under 1 MB" represents the size of .NET runtime proper. However, additional required system DLLs increase the download size of a minimal application to the numbers I cited above [1]. Anyway, your example of Amazon's front page is interesting and is a good point (even though, in my quick test out of curiosity, relevant download size resulted in 2.2 MB [not authenticated] and 9.2 MB [authenticated] - quite a bit less, but still ...).

[1] https://blog.ndepend.com/blazor-internals-you-need-to-know

2 MB should not be an issue nowadays. Considering 5G roll out & substantial coverage in most mature markets, in say, 2 - 3 years, 2 MB is acceptable.

Remember, that 2+ MB is the download size of a bare-bones application. Relevant sizes for real-world applications, obviously, would be bigger (though, depending on the total size, the Blazor part might or might not be essential).

Download sizes are definitely a problem but they’re not really a Blazor-specific issue these days. Also I would be curious to learn about the relative density of JavaScript bloat vs Blazor download sizes because the .NET class library is much more feature rich before adding dependencies and I could imagine bundle sizes actually being smaller for similar functionality above a certain point. But you’re right that it’s probably never going to get as small as a pure HTML + CSS app with progressive enhancement and minimal JavaScript.

Fair enough. Thank you for sharing your thoughts.

While this may be true in most first world countries, 2mb are still a lot in development regions (and sadly also in Germany)

Are the latency issues specific to Blazor Server or are they inherent in any framework that uses this pattern, like LiveView?

It doesn't seem like there's any major difference so it's interesting that latency is perceived as being a reason not to use blazor server in production but not as such with liveview.

The audience for Blazor Server is probably an order of magnitude larger than the audience for LiveView, and it's mostly not the Hacker News crowd that needs to be won over, but the large enterprise with half a million lines of Web Forms that has grown into an unmaintainable behemoth.

Inherent in any framework that uses a connection to transmit diffed DOM nodes.

yeah, that's what I thought. it's certainly the achilles heel of this technique.

Last time I looked it couldn't run in the browser, and there was no ETA, has that changed?

Yes it runs in the browser. I have several clients with Blazor webassembly apps running in production right now.

Nice, if you don't mind me asking, what sort of apps are they? I'd like to use Blazor for my next project

And best of all, both Server and WebAssembly has a lot in common, so it is possible to make that movment as needed. (I often prototype in server, as it's a lot easier to debug, too!)

If you are using Blazor Server, you don't have to even think about REST APIs. Depending on your app, that might be good or bad. But if you primarily target browsers on Desktop, you can tremendously improve productivity, because you can directly use C# POCO Models for UI and backend data services.

Not if you use Blazor Server.

ASP.NET core is still all the same over-engineered enterprise baggage you see in the Java world.

It's not. You can literally have a simple "hello world" app in a handful of lines or code if you want.

I have to wonder if you actually use ASP.NET Core yourself, because ASP.NET Core 3 is, IMO, fantastic. ASP.NET used to be a bit clunky, and lacking in extensibility points, and a lot of people used alternatives like Nancy instead. Nancy officially stopped development around a year back, largely because dotnet devs just don't need it anymore. I was a long-time Nancy fan myself, ASP.NET Core 3 has all the best bits and more.

And you don't need to stick with the typical paradigm on controllers in one folder, views in another etc - feature folders work great. Hell, you don't even really need to use controllers, if Razor Pages are your thing.

it smokes Spring in benchmarks, often by a factor of 10x or more, and on plaintext it's 50x faster than spring and even with the fastest Rust/C++ frameworks, so must be some awfully light baggage

Admittedly I don't have a lot of experience with enterprise web development in Java but I love working with ASP.NET Core and I think it's come a long way since the mess of Web Forms and classic ASP.

What makes you think so? I'm actually curious