Rendering Blazor components to a string: Exploring the .NET 8 preview – Part 9 | Hacker News Reader

Rendering Blazor components to a string: Exploring the .NET 8 preview – Part 9

andrewlock.net

22 pointsstevefan19998 comments

I've been using Blazor/Razor for a while and I have to say that I will generally be avoiding it moving forward.

It is really sad to me that the VS2022 experience around hacky, PHP-style string interpolation (e.g. @$"<html>{site goes here}</html>") is far superior to the experience of editing cshtml-style files exactly as prescribed by the vendor.

I've got some razor components that will simply crash VS2022 about 25% of the time. They aren't particularly large components, but you can feel some monumental, visceral amount of inertia behind these file types every time you try to work with them in the official editor.

Maybe dev experience is better over in vscode land, but I don't really care. There are enough other downsides to this web ecosystem to generally avoid it.

To be clear - I otherwise absolutely love everything .NET/C#/AspNetCore. Blazor and UI (MAUI) are their only real weak points, IMO. If you are willing to get your hands a little dirty as described above, you can sidestep entire mountains of depreciable chaos.

Having VS2022 crash is certainly not expected or normal. I appreciate it must be pretty frustrating. If there’s any way you can submit a VS Feedback item when that happens, or post repro steps to the dotnet/aspnetcore GitHub repo, we’d definitely want to investigate.

Having myself sent VS Feedback in the past with video and other references and gotten no positive response except a bot closing for lack of evidence it's hard to care about reporting issues anymore. Much like other MS feedback hubs they feel more like spots to absorb issues rather than address anything meaningful.

VS has been going in the wrong direction for years, and I’ve been a happy rider customer for years. Give it a try before tossing the baby with the bath water.

I've used blazor on a couple larger projects, mostly wasm blazor, and have used components in hacky ways on occasion (reflection, interpolation, etc). Some of these components are pretty large and I have never once had a crash from those projects in any IDE, be it VS2022, Rider, or the trash that is VS for Mac. Not downplaying your experience, just saying blazor projects have been very solid to work with on my end.

Throwing my hat in saying I agree with you. There are certainly aspects of Blazor that need to be improved, though. Sometimes Intellisense has an aneurism and syntax highlighting completely breaks. Debugging needs some TLC in instances where exceptions are thrown in the JS console instead of being caught by the VS debugger.

I have experienced _some_ performance problems, but only when I don't have enough resources for VS to gobble up. Should it be lighter? Absolutely. It's not like I can't get work done though.

To me this is just another iteration of WebForms: the final rendered component looks nothing like the code you put in.

I've been wary of Blazor from the beginning because it looks to me worse than WebForms, it looks like a resurrection and return to some of the biggest mistakes of ASP Classic. I had to dredge legacy apps out of ASP Classic and got more than enough of my share of runat="server" and runat="client" in weird mixtures of markup and code to feel from the beginning of discussions of Blazor that it looked like Razor wanted to be ASP Classic for developers that have forgotten ASP Classic (despite it still being almost half of the ASP.NET name and why you still have to add .NET to your search queries to avoid incredibly bad old ASP Classic help/advice).

Reply on news.ycombinator.com