4 ms·
A few months ago I wanted to make a really simple web frontend hosted by a WinForms app (don't ask), and tried Blazor Server since it was going to be used by a
by moogly 3y ago
A few months ago I wanted to make a really simple web frontend hosted by a WinForms app (don't ask), and tried Blazor Server since it was going to be used by a single user on a local network.
I really disliked how much stuff the `blazorserver` project template created. A bunch of .razor files and .cshtml files (that had Razor code in them) in nested folders the contents of which were quite arcane. I wanted to scale it down to the absolute minimum needed, because I wouldn't need e.g. client-side routing, but the tutorials basically repeated setting up all this boilerplate without really explaining the basics.
I spent a couple of hours working backwards trying to simplify this, but didn't really succeed.
FWIW, I've worked with .NET since the 1.1 days so I tend to be used to their idioms.
Instead I made a Solid.js frontend hosted by in-process Kestrel and just used SignalR directly for all client/server communication. Somehow going into the JS/TS ecosystem (which I've worked a lot in too) had less friction. Very surprisingly, SignalR is not TypeScript friendly at all out-of-the-box. The frontend client could be source generated for sure, and I saw someone had made a tool for that, but still odd that it's not first party.
I can appreciate the idea of making an opinionated, scalable, production worthy template (if that is what this is), because in the JS/TS ecosystem the opposite is common with toy examples, but there is something to be said to offer a toy example to explain the underpinnings of the framework.