Hacker News Reader

Comment by sfn42 | Hacker News Reader

> Expecting your average front-end logic to be compiled in WebAssembly does not make much sense.

Why not? .NET Blazor and others already do that. In my eyes this was the whole hype of WASM. Replace JS. I don't give a crap about running node/java/whatever in the browser, why would i want that? I can run those outside the browser. I mean sure if you have some use case for it that's fine and I'm glad WASM lets you do it but I really don't see why most devs would care about that. We use the browser for browsing the web and displaying our websites.

To me the browser is for displaying websites and I make websites but I loathe JS. So being able to make websites without JS is awesome.

View on HN

Because people don't want to load 300MB for a simple website (and this is blocking the first render, not just loading in the background).

Not every language is a good source for targeting WASM, in the sense that you don't want to bring a whole standard library, custom runtime etc with you.

High-level languages may fare better if their GC is compatible with Wasm's GC model, though, as in that case the resulting binaries could be quite small. I believe Java-to-wasm binaries can be quite lean for that reason.

In c#'s case, it's probably mostly blazor's implementation, but it's not a good fit in this form for every kind of website (but very nice for e.g. an internal admin site and the like)

A modern blazor wasm app is nowhere near 300mb. There are techniques to reduce this size like tree shaking. There's no need to include lots of unused libraries.

Modern Blazor can do server side rendering for SEO/crawlers and fast first load similar to next.js, and seamlessly transition to client side rendering or interactive server side rendering afterwards.

Your info/opinion may be based on earlier iterations of Blazor.

300MB is nonsense, we are at 2MB compressed with https://minfx.ai

   > we are at 2MB compressed with https://minfx.ai

That's still pretty bloated. That's enough size to fit an entire Android application a few years ago (before AndroidX) and simple Windows/Linux applications. I'll agree that it's justified if you're optimizing for runtime performance rather than first-load, which seems to be appropriate for your product, right?!

What is this 2 MB for? It would be interesting to hear about your WebAssembly performance story!

Regarding the website homepage itself: it weighs around 767.32 kB uncompressed in my testing, most of which is an unoptimized 200+kB JPEG file and some insanely large web fonts (which honestly are unnecessary, the website looks _pretty good_ and could load much faster without them).

It does, but honestly besides people missing out on WebForms and Silverlight, it has very little uptake.

Thats not too surprising as most web developers are JS developers. I'm sure JS will stay dominant at least a while longer, but in the .NET world Blazor is quite popular as far as web frameworks go. I imagine it will keep gaining popularity.

Not really, most of my .NET project assignments use Angular/React with .NET MVC/Minimal APIs.

Additionally Blazor is a bad fit for .NET CMS and commerce platforms, none of them supports it for rendering components.

Reply on news.ycombinator.com