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.
Why do you think this will be the case?
Couple that with the fact that interoping with JS can be a lot more annoying than just using JS
It's a one-time download that's smaller than the initial load of the Facebook feed
> 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.
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.
https://learn.microsoft.com/en-us/dotnet/core/deploying/trim...
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.
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.