Comment by no_wizard | Hacker News Reader

Comment by no_wizard | Hacker News Reader

Parent Full thread

counter point: Microsoft is leading the charge with Blazor, bringing full single stacks to the front-end for the first time for non JavaScript developers.

For applications its hard to see why this model wouldn't be more preferential. Most .NET applications are monolithic in nature (though you can enforce really good module separation with relatively minimal effort IME). You can look at Rust too, for its developing some Blazor-like frameworks. I could imagine for example, the next GMail being written like this, or other deeply interactive applications.

I think people want to work in a singular language / framework more than anything else. One of the reasons I think JavaScript still prevails today, is it was the first language community to largely achieve this in an accessible manner. Others are now coming forward.

I think pre-rendering is still the best approach to truly static content though, using web components to progressively enhance features of a page for light interactivity, this is one area they really shine.

I could be very wrong though!

What I've feel is ignored in the community is that actual backend development never reached a point of wide adoption with javascript/node. Certainly node and alikes are used to deliver front end code, as front end api or api layer in between. But the vast majority of backend development remained in the power of established tech. The (natural) attempt of JS tech to push into backends, led to some accidental constructs, a mix of JS and other techonologies which may act more like walls then bridges. Tech stack responsibility is blurred because of JS's omnipresence, which leads to several problems. I think some people start to realize that JS is a useful front end platform but must not be the default tool for a backend platform.

I seriously hope MSFT is committed to pushing Blazor. It's has the potential to stand above the other "unified back end front end" technologies.

Unfortunately Blazor hype has really died down the last couple of years and I'm starting to get Silverlight vibes from it, which doesn't bode well...

I think MAUI is in part built on the back of Blazor. They might converge, but I don't think its underlying model is going anywhere.

I don't work at MSFT though, so YMMV? I don't think its going to end up like Silverlight. They seem pretty committed to not back pedaling anymore like that, they know it hurt them so much, at least thats the message I been getting from MSFT developer relations, is an some admittance they really borked their DX by going through such rapid turnover of UI frameworks and such.

No it is not, MAUI is having the option to support Blazor via WebWidgets as a kind of Electron competition, which probably only the Blazor team themselves see as an advantage.

MAUI by itself is Xamarin ported to run on top of .NET Core (now .NET 5+), with WinUI as backend on Windows.

In what concerns UI Frameworks coming out of Redmond, it looks like pretty messy civil war right now.

> Blazor-like

Isn't that just "GWT-like"?

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.

That makes sense. But it doesn't seem a very significant difference on the face of it. More modern implementation of same idea?

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.

[0]: https://www.gwtproject.org/doc/latest/DevGuideUiWidgets.html

AIUI Blazor is 2 models today

    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.

Isn't option 1 more like compile .NET interpreter to WASM and ship with your dlls resulting in huge download and terrible runtime performance?

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.

[0]: https://docs.microsoft.com/en-us/aspnet/core/blazor/host-and...

[1]: https://docs.microsoft.com/en-us/aspnet/core/blazor/webassem...

Hm, that sounds a little like meteor. Thanks for the explanation.

Reply on news.ycombinator.com