Blazor relies on dynamically generated JS Bridges and WASM, where as GWT just generated JavaScript from Java Bindings. Seems similar on the surface, however the difference being that Blazor is trying to leverage direct compilation of C# constructs directly to WASM whenever possible, and supplementing that with some JavaScript interop, as opposed to trans-piling things directly to JS itself, as with GWT.
1. As you described, compile C# to WASM, download a blob and run client side
2. Run the C# server side, send the client a thin page and a SignalR pipe back up to the server
With 2 it's more like react SSR (as in the mode where react components run on the server, not SSG where they run on the server and just emit static HTML). When i looked through the docs, 2 was the primary mode for now.
The benefits claimed were you don't need a modern browser, i think the thin shell + signalR combo works gracefully back as far as IE9 or something silly, also you don't need much processing power on the client because the signalR pipe is just a conduit for pre-rendered HTML generated by a blazor component running server side.
The down side is that for every client, there's a websocket (or long polling connection) for every client to the server.
There are a lot of ways to trim the size. All in sure, its 2 MB I think, for the entire .NET runtime. However there are a few mitigating steps that really do have a dramatic difference in terms of how big the WASM runtime is.
If you setup the compiler with trimming enabled[0] it gets significantly smaller. You can also lazy load assemblies by route[1] to further restrict the upfront cost.
Of course, this is not acceptable for the average web page by any means. This is really intended for behind the login type applications where you load up the initial runtime once and its cached heavily for the rest of the applications lifecycle by the user. This is really targeted at true applications-in-the-browser type situations.
Blazor server side works too, though everything then has to run via a SignalR connection and can be a bit more flaky at scale.
Runtime performance however, I actually don't find it to be a bottleneck. The apps I've built with Blazor are pretty fast. I haven't worked with it in 9 months though.
On the highest level, yeah, it really is just more modern.
In practice though, its also flexibility. GWT shoehorned you to do certain things a certain way and only that way, where as Blazor only limits you based on what calls and modules can be safely converted to run against the WASM driven runtime. Which means you aren't limited to a specific list of ways to solve a problem, its more (and increasingly so) flexible than that. So for instance, GWT has specific widgets[0] that you should use to represent the use interface, Blazor doesn't limit you to just Blazor compatible widgets (there are some though, because at some point the abstraction runs out of juice). You can use regular conventions and classes too, like the normal .NET HTTP client stack, regular data classes etc. You can also re-use Razor components, most of the time.
To be clear though, Blazor isn't a panacea, it has its own caveats and downsides, however I think its really innovative in terms of concept and execution. For anything behind a login its a pretty sensible choice IMO. I wouldn't go making your marketing / info / purely static pages with it though. server side rendering or pre-rendering is a much better choice there.
Also worth mentioning, on top of all that, is Blazor can cross compile to native applications too, like iOS and Android, with (largely) the same codebase.
Isn't that just "GWT-like"?