> 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.
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.
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.
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.
If your point is that companies run outdated, shitty computers connected over unreliable WiFi, _your_ corporate life experience has been vastly different than mine.
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
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.