Hacker News Reader

Comment by LaGrange | Hacker News Reader

> 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.

View on HN

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.

> It will load slowly, work slowly

Why do you think this will be the case?

Well for Blazor Webassembly at least, you need to download the entire .NET runtime and WebAssembly isn't quite as fast as JS in browsers yet.

Couple that with the fact that interoping with JS can be a lot more annoying than just using JS

> Well for Blazor Webassembly at least, you need to download the entire .NET runtime

It's a one-time download that's smaller than the initial load of the Facebook feed

What about the CPU usage?

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.

Honestly I'm afraid you don't know what you're talking about. Blazor just isn't that experience and hasn't been for awhile.

Well color me convinced!

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.

Any data to back this up?

Any data to back _your_ claims up? Because, y'know, sure, all _we_ have is years of lived experience.

If your point is that companies run outdated, shitty computers connected over unreliable WiFi, _your_ corporate life experience has been vastly different than mine.

Blazor Hybrid looks promising to completely negate the load time for Blazor WASM.

Yes that does look promising for load time, but once the Webassembly is downloaded and being used, Non high end computers can easily choke.

.NET 8 is suppose to greatly improve AOT. Depending on your use case, you might be able to get around bundling the runtime entirely.

As far as I understand, .NET 8 AOT has nothing to do with the webassembly blob that gets served to the client.

They’re working on it. .NET 8 introduces the option to perform a degree of trimming on the AOT output. https://learn.microsoft.com/en-us/aspnet/core/blazor/host-an...

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

That's not true since .net 6

https://learn.microsoft.com/en-us/dotnet/core/deploying/trim...

Literally a quote of one of the dismissed drawbacks. The post didn't question whether the drawbacks are real, just said they're irrelevant.

Reply on news.ycombinator.com