Comment by troughway | Hacker News Reader

Comment by troughway | Hacker News Reader

Parent Full thread

This is a little bit premature of me to posit however I have a good feeling about tech like Blazor.

In particular Blazor offers two interesting approaches (“hosting models”):

1) a websocket-based HTML sync layer, basically shipping over the smallest amounts of render state from the back-end. This is as close as you get to having, essentially, a server-side rendered page that is then updated in real time.

2) a wasm based approach where the whole application is delivered to the browser and you make the API calls.

Both have you writing majority of the code in C# and Razor templating syntax. Yes, you make an argument that well it’s technically still JS running it. But this becomes an implementation detail that will be ironed out, because technically the browser is written in C++, but we look beyond all that. And so on and so forth.

Now, I’m not saying I expect the world to move to .NET. Far from it. I have been preaching for a language agnostic browser execution engine so that I can write not only my logic, but my layout and styling in whatever language I want to, whether it’s Ruby or F# or Lisp, and have the browser execute it via its own internal “assembly code”. Except I’ve been parroting this idea since mid-2000s and we have at last finally started down that road.

I think this is where we are headed, and I don’t think it’s far fetched.

Blazor currently has to haul its runtime over the wire before it can do anything so a non-starter for anything performance-sensitive.

Did you miss this part:

>1) a websocket-based HTML sync layer, basically shipping over the smallest amounts of render state from the back-end. This is as close as you get to having, essentially, a server-side rendered page that is then updated in real time.

Also it's not like you have to load the runtime more than once. So it's not that it's a non-starter for anything performance sensitive--it's a non-starter for anything that can't download a 2MB file up front (I believe their goal is to get it down to half that size) if you want to use the WASM version of Blazor instead of the websocket-based HTML sync layer version.

Compared to React + React DOM at 109k unzipped Blazor's runtime at 2MB is a significant hike in download size so unsuitable for older devices and constrained bandwidth networks.

1. Being too large for constrained bandwidth networks hardly makes it a non starter for anything performance sensitive unless you have a very narrow definition of performance.

2. 2MB includes bootstrap CSS and they are working on getting that number down.

3. 2MB is only the Wasm version of Blazor. You don’t have to use that version if it doesn’t fit your use case.

I don't have to use it but Wasm Blazor is the version everyone is shouting about. Well, everybody at the Microsoft hype machine that is.

Go to the Blazor homepage. Right there on the front page--the 2nd bullet point is "Run on WebAssembly or the server".

Most people I've talked to using Blazor are in fact using Blazor server not Blazor WASM.

Reply on news.ycombinator.com