> I'm of the opinion that this is the future of web development

Maybe but not with C#. Rust is a much better language for compiling to WASM. Leptos achieves something similar to Blazor with a fraction of the CPU and bytes.

https://leptos.dev/

Blazor is much slower client-side than even the worse JS solution. Scroll to the right to see it compares:

https://krausest.github.io/js-framework-benchmark/current.ht...

I would love to be able to handle all my web stack with C# but unfortunately the WASM bundles are too heavy for most use cases. Plus the DX for frontend is not even as good as it was with JS and Webpack like a decade ago. And these days the bar is much higher with Vite.

Rust is unnecessarily low-level for the vast majority of things that a web app would be doing. There's no reason to struggle with the borrow checker in that kind of code when tracing GC is available and makes things so much easier.

Leptos is cool, but the lack of UI component libraries really hurts.

Same for on every WASM solution out there. I don't want to rewrite for the 1000th time a date picker, accordion, card, tab bar...

I just want to throw new Accordion() on my code and, optionally, override some CSS to make it match the customer palette and go solve hard problems.

> I would love to be able to handle all my web stack with C# but unfortunately the WASM bundles are too heavy for most use cases.

This strikes me as a premature optimization. Most use cases? I'm interested if you have any examples.

> Rust is a much better language for compiling to WASM.

Why's that?

Because rust actually compiles the code to native binaries. C# kind of started doing it some time ago, but AOT still has various limitations and edge cases. Blazor doesn't even compile your code into wasm - it ships the whole dotnet runtime as wasm and runs your app as bytecode. This means massive downloads regardless how simple your code is.

There's relatively recent AOT for Blazor, but even that has to ship all the managed DLLs and part of runtime for the runtime reflection / metadata support.

> Most use cases? I'm interested if you have any examples.

Basically anything isn't an in-house tool. Captive users don't have much of an alternative.

Blazor is specially bad for anything that is public and/or needs to run on mobile.

> This strikes me as a premature optimization

Avoiding shipping 10-20MB of WASM code is not premature optimization... it's just common sense.

I can agree that for C# teams it might be better to use Blazor but objectively JS/TS solutions are just better. Again, look at the objective hard data:

https://krausest.github.io/js-framework-benchmark/current.ht...

Blazor uses 45x the memory compared to vanilla JS and up to 3000x the KBs.

> I don't use Blazor, but your point is still about solving a "problem" that might not exist.

So you think a priori it's fine to shove MBs of code to a mobile user?

And, if you get into that situation with Blazor, what's the plan for solving the problem? Other than moving features to JS.

> Do you have examples of this?

I don't have any links at hand but the JS benchmarks I linked uses 4MB of uncompressed code (12MB with the AOT version) just for displaying a table and changing the data.

Here's a demo that's sending like 2MB of Blazor code for a button that updates some text:

https://blazor-demo.github.io/Counter

Here's someone using dotnet 9 reporting a 17MB download and 67MB with AOT:

https://www.reddit.com/r/Blazor/comments/1kse00c/blazor_wasm...

> So you think a priori it's fine to shove MBs of code to a mobile user?

I think we have to consider whether or not that matters.

> Here's a demo that's sending like 2MB of Blazor code for a button that updates some text:

Okay, but then what is the size increase if you have a full app? Is it 2MB per button (obviously not).

My point is you are so focused on things that may or may not matter. So saying its useless for most usecases is a terrible position.

Because Rust doesn't need a GC

At one company we had a contractor come in say I can totally build a simple IoT dashboard with a few buttons and wanted to use Blazor. I used Phoenix LiveView, on rpi3’s and later rpi4’s just fine. So Blazor sounded similar and figured it’d be fine.

However Blazor just totally tanked the RPi that had 4gb of ram. It took minutes to load a web page when it did load.

Of course that was years ago. Hopefully Blazor got better. Given that starting point I’d doubt it’ll ever match Elixir LiveView in efficiency.

IMHO, other systems will to struggle to replicate Elixir’s LiveView due to BEAMs design using preemptive actors. It’s not impossible, just that’d it’d take a lot of work to match the responsiveness and resource usage.

Currently I’m using Nim on backend and front end using a Karax SPA. It’s pretty nice sharing the same code on front end and backend!

> However Blazor just totally tanked the RPi that had 4gb of ram. It took minutes to load a web page when it did load.

Sounds like Blazor Server, if WASM was used, that shouldn't have been the case. I'm not very surprised considering how insanely efficient the BEAM is with memory.

Why anyone would choose to use the Razor syntax at any time is beyond me, let alone for the web. There is no need to make it so complicated, HTML is interpreted.

As the article says :

> HTMX leaves it up to the developer to impose discipline on their code, however they see fit.

He said that like it's a bad thing. I really dislike those frameworks like Angular for example who simply say "You need to do it the Angular way". That just slows down innovation or clever ideas that solve little problems. Instead if there is a slow framework (looking at some peoples react implementations, Cloudflare recently [0]) Well you probably wont consider it or just see it as a "quirk" of the framework.

[0] https://blog.cloudflare.com/deep-dive-into-cloudflares-sept-...

There is no "blazor" way as far as I can tell, we've been rewriting our logic and structure since when everyone started on this project nobody knew how to structure Blazor, moving forward we are following best practices from React projects to an extent in order to better organize and keep components tidier.

Blazor will die like Sliverlight. Just learn HTML, CSS and Javascript.

Yeah, I'm very wary about putting all my eggs in Microsoft's basket after what I've seen.

They have a pretty extensive history of encouraging everyone to get on the wagon only to drive it straight into the nearest ditch. You can't trust a company that competes with its own customers.

I know all three, and I'm not seeing it dying any time soon. WebAssembly is not going anywhere, neither are dynamic back-end systems. I have drastically less issues with my front-end while using Blazor compared to just doing raw JavaScript. I've built everything from a PWA from scratch using Vanilla JS, to an iFrame Frenzy web app a client paid us top dollar to build.

Silverlight was proprietary, Blazor is MIT licensed and using open web technologies that are NOT going anywhere any time soon. We just had another major upgrade to Web Assembly's spec not that long ago.

So what? It is just another tool in the toolbox. A tool that someone already invested in webdev can pick up in a week or two.

Which is kind of return to WebForms, GWT and JSF ways of working, only the implementation is a bit different than on the 2000's.

We moved into MVC approach, because of the headaches that it used to be having to debug all the generated stuff from what the browser actually supports as built-in technology.

I don't see that bright future for Blazor, other than a few .NET shops that don't want to learn native browser technology.

The debugging experience and the lack of context shift when going from thinking about how C# works to JavaScript (and all its zillion quirks!) is insanely better. I can put a breakpoint for the front-end and debug it just fine withing VS. I do wish Microsoft would finally open source their debugger, since I've heard loads of complaints about it being proprietary still.

> Zillions of quirks

A bit hyperbolic, if you use a modern linter like biome or eslint it can warn you of the few that may cause issues.

I'm not sure I've run into such a state yet, are you using Blazor without any UI component libraries? I am using MUDBlazor, genuinely curious what you're running into.

I used it enough to understand how it works, compare it with my WebForms, GWT and JSF experience since their early days in 2001 onwards, and decide to stick with MVC, and browser native stack.

Additionally, our agency is polyglot, and in no way frontend teams are going to start doing Blazor instead of their favourite framework of the month.

Blazor and Phoenix both seem the most intuitive for me also, especially when building complex frontends that require a lot of business logic. Being able to ditch the JS for that kind of work is amazing.

Tried Blazor, but found it too complicated and heavy for my needs.

I've had more success with Phoenix/LiveView.

Blazor at work to keep the lights on, Phoenix at home to keep my sanity :D

Blazor suffers from needing to lift the entire .net runtime into wasm. So first you download a gazillion resources that reimplement .net core/runtime/memory/garbage collector/whatever into the page. An eternity later your hello world can finally run.

Though they did manage to really shave the runtime off somehow. It used to load megabytes and megabytes of data.

> numerous web frameworks should they invest in tech similar to Blazor. Phoenix's LiveView also comes to mind.

Phoenix live view sends minimal diffs that get applied to the DOM. It doesn't have "components that run in the client and on the server". Everything is done on the server, with very specific extension points into JS

Definitely - I think what's really interesting is that there is clearly a kind of "attractor" which all of these frameworks are pulled toward. That's kind of mainly what I was trying to aim at with the blog post - MESH isn't a solution at all, it's more I built it to show why it would go that way, i.e. the same way LiveView etc. and of course Blazor went. My question is: is there a form of this that could be merged back into the HTML spec itself and supported by the browsers? My gut says there isn't, by the way.

There are definitely some parts that are common between these that it could be nice to propagate to the standard. https://alexanderpetros.com/triptych/ lists some of them but I'm not certain how specific to htmx it is or how much it apply to the different variants.

Yeah I wasn't trying to take away from what you wrote, just sharing my experience with a different framework. :) Please, use and work with what keeps you productive!

Alex where on god's green earth is your scroll bar?

At a previous job they were moving away from Blazor (which bummed me out, I love the philosophy) because every time they deployed it broke sessions/disconnected all active users.

Sounds like Blazor Server limitations.

I've made some toys with Blazor; my teams are using Vaadin at a Java shop, now. Not exactly the same implementation, but a similar idea: express front end code using the backend language.

Blazor is fucking terrible. In principle it works in some use cases, the the library is designed horribly and it's very difficult to implement well behaved components. It's like a half-baked react 10 implementation.

I am torn about SSR. I see the advantages but I hate the workflow so so much... Also tightly coupling the views to your backend is something I really hate.

I want to stay flexible, a completely independent frontend and a completely independent backend.

I tried Phoenix for about 7 months this year and ultimately quit due to it feeling clunky and unintuitive, same with Livewire or any other SSR templating solution I've found.

If there's SSR templating that is actually enjoyable to work with (from a DX perspective), I'd happily try it. Sadly nothing feels as good as just building web components.

Try Datastar, it leans into web components, and they're working on a plug-in that integrates web components with Datastar. For example, I believe the star field on the front page of it's site is a web component.

https://data-star.dev/

We write only front-end logic on our Blazor components now, and use services to glue the front-end to the back-end which is the recommended way is my understanding. It's really nice, especially when you pull in something similar to MudBlazor.