Blazor WebAssembly on Azure Static Web Apps | Hacker News Reader

Blazor WebAssembly on Azure Static Web Apps

hanselman.com

74 pointstaytus24 comments

What’s the client bundle size for a “Hello World” in Blazor WebAssembly? Last I checked it was ~2.5MB, which makes it a non-starter for public-facing web apps, imo.

Depends which. An online trading platform? Possibly. But great for internal applications.

I’d argue internal applications are _the only_ acceptable use case for Blazor. I only mention it because this quote from the article strikes me as mildly disingenuous:

> An app like this can basically scale forever, cheaply. It can put the browser to work (which was basically hanging out waiting for anglebrackets anyway) >

It’s no more scalable than any other SPA framework as an Azure Static Web App, but it does require shipping a .Net runtime to every user. I’m surprised there’s rarely a mention of this important consideration in the discussions I’ve seen around Blazor.

My understanding is that they do (or will do) some tree shaking to only transmit the bits of the runtime that are actually used. It's not like you will download a 60MB binary on every refresh. And it's not like a typical SPA doesn't come with its own bloat of js libraries. I do expect it so be slightly heavier. But to the point that a user will notice?

Yep, and that's what the "2.5MB" in my original post referred to. So, a Blazor app that does nothing but print "Hello world" to the screen is as heavy as a horrendously bloated SPA that presumably does something of value.

Yes the user will notice, just the same as they notice that horrendously bloated SPAs are slow.

But that’s a slightly orthogonal problem. SPAs being misused is clearly an issue. A blog has no business being an SPA. But in the domains where SPAs make sense, I don’t know that it is going to be much heavier. Think webmail, online collaboration tools, trading platforms, etc.

2.5MB doesn't seem like much for baseline overhead (assuming there's no tree shaking). After all, the incremental amounts for more complex apps might be small if most of the framework is already mostly contained in the 2.5MB (not sure if it is). Imagine being able to run CAD software or other apps with complex desktop UIs in the browser.

I just tried loading NYTimes.com and it was 7.48MB.

My Gmail page is 9.31MB.

A blank Google Doc is 16.92MB.

That said, the (very impressive) Pixilart web app is only 1.91MB.

https://www.pixilart.com/draw

Out with JAMstack and in with CSAMstack?

Web Assembly is independent from MS / C# / .NET.

You can use your fancy lang and emit WASM.

WAMstack

i wonder when we'll see some good UI frameworks that eschew CSS/HTML in favour of writing pixels directly to the screen

Qt has already been compiled to run in the browser, and that's a very well-known high-quality UI framework from C++ land.

http://vps2.etotheipiplusone.com:30176/redmine/projects/emsc...

My first reaction to parent was "what toolkit would be great to target WASM with", second was "let's scan the replies..."

Qt in browser gets me excited :)

Here is one, https://platform.uno/

I have started working on something along these lines. I don't write pixels directly to the screen and I am continuing to use the browser and all of its capability, but I have abstracted the client viewport as a 2d surface that I can set arbitrary pixels on from the server. There is a tiled diff mechanism w/ JPEG compression in between client and server for more efficient real-time update of dirty parts of the view. 100% of client events are processed server-side. All the client browser does is display whatever tile it is told to as quickly as possible.

Biggest advantage is response time on complex views, followed by the ability to guarantee pixel-perfect presentation on any device capable of websockets and jpeg decoding. Caching of content is on a final tile basis rather than full viewport. This increases the hit-rate substantially, as tiles are not at fixed pixel boundaries, but rather aligned with logical UI elements. Fixed sized elements will more likely produce the same final tile(s) with equivalent SHA256 regardless of client device. Hashing is performed in terms of the UI element's properties (dimensions, size, text, color, etc), so cache lookups can be made along these lines.

Biggest downside is latency - This approach has a similar practicality envelope as Google Stadia, et. al. WRT distance from datacenter. 2nd biggest downside is the fact that this technique is fundamentally incompatible with classic web development ideologies and requires new ways of thinking about solving problems. I personally find this last point to be a benefit, but I recognize it would prevent wider adoption in the community.

I pray you’ll never need to display blocks of text, or do anything with text input. Font rendering and text editing are no joke, and browsers do it well with HTML + CSS.

Latency might be the biggest downside for your specific use case, but I’d urge anyone tempted to roll their own browser renderer to properly consider text-related concerns first.

I currently use System.Drawing to produce text segments.

I am not attempting to replace HTML/CSS or pass the Acid3 test. I am just going for something that would be sufficient for purposes of building highly-responsive internal business dashboards and other utilitarian applications where predictable and fast layout is more important than arbitrary style support.

It's more likely that some good non-web UI frameworks will write WASM-based backends, so that your pre-existing code works in a browser box with all of the good and bad that came with Java, Silverlight, etc...

When developers get creative with fully custom GUI drawing then the user is often rewarded with dodgy text rendering.

Flutter is basically this.

Isn’t this basically what Flutter is?

Sounds like an accessibility nightmare.

Reply on news.ycombinator.com