Most active commenters
  • hakanderyal(5)

←back to thread

201 points olvy0 | 12 comments | | HN request time: 0.002s | source | bottom
Show context
blackoil ◴[] No.41878798[source]
Anyone knows of a comprehensive book/tutorial to learn end to end web development in dotnet. Most I have found are elementary, outdated or poor quality.
replies(5): >>41878995 #>>41879009 #>>41879030 #>>41879834 #>>41879860 #
littlecranky67 ◴[] No.41879009[source]
That is because all the hot-and-new in .NET web development is Blazor, and it is not really popular outside of Microsoft's Blogosphere (and IMHO never will be and go down the same way as Silverlight did). The "venerable" technologies are still present in .NET 9 and still work, get maintained etc.

Doing web dev in .NET nowadays for me is mostly creating HTTP/JSON/REST APIs and using whatever FE framework you like to interface it (for me that is React or NextJS). The keyword you want to search for is "ASP.NET WebApi" or - more modern - "ASP.NET minimal API".

You could still do .NET MVC server-side rendering using "Razor" (the markup language in ASP.NET MVC - search for "ASP.NET MVC Razor".

replies(4): >>41879547 #>>41882023 #>>41882374 #>>41883629 #
WorldMaker ◴[] No.41879547[source]
Blazor for better and worse can't have the same ending as Silverlight did. In Server Mode it is just Razor + SignalR for HTMX-style frontends that sort of live update/"magic RPC". In Client Mode it is just Razor as a virtual DOM-ish framework running directly in Web Assembly (wasm) in the Browser. At the end of the day Client Blazor is much more like writing front end websites with Elm than writing websites for the Silverlight plugin.

(Hybrid Blazor where you use both server and client possibly in the exact same assembly/project is where most of the worst Blazor mistakes lie, but those aren't the mistakes of Silverlight, those are the mistakes of ASP Classic before .NET where you can be easily confused by new versions of the which bit of this is `runat="server"` and which bit is `runat="client"` and easily and accidentally create wild RPC ravioli/spaghetti code.)

replies(1): >>41879816 #
1. hakanderyal ◴[] No.41879816[source]
Do you know of any performant, quality examples of Blazor out in the wild? All the examples I've seen have unacceptable UX by modern standards.
replies(3): >>41880226 #>>41880506 #>>41880871 #
2. m_fayer ◴[] No.41880226[source]
https://github.com/Webreaper/Damselfly
3. parineum ◴[] No.41880506[source]
> All the examples I've seen have unacceptable UX by modern standards.

What does that have to do with Blazor?

One could easily write outdated UX in React if they so choose.

replies(1): >>41880577 #
4. hakanderyal ◴[] No.41880577[source]
It's the slowness/sluggishness, not the looks. Most of the time even a simple interaction like clicking a checkbox takes ~1-2 seconds, which probably comes from tracking the state on server.

(I don't mind outdated for .NET stuff, nearly everything from enterprise vendors looks like it just jumped out of WinXP anyway.)

replies(2): >>41880907 #>>41883643 #
5. WorldMaker ◴[] No.41880871[source]
Certainly I also can't imagine how you would get strong performance out of Server Blazor in real world/Enterprise conditions. RPC busses are going to RPC and roundtrips are still roundtrips even when SignalR-backed web sockets. Flooding UDP web sockets with HTML chunks isn't necessarily a great idea, even if HTTP3 (QUIC) kind of/mostly succeeds at it, but SignalR as good as it is certainly isn't HTTP3.

On the other hand, Client Blazor has huge initial overhead (it compiles a form of the entire .NET platform in WASM; you can golf it down a bit, but it's still an entire runtime and GC and most of a standard lib depending on what your app does, and its dependencies), but once it is loaded it can be as performant as just about any other Virtual DOM-like (modulo the overhead between DOM/JS and WASM, but that overhead is surprisingly small in current browsers and seems to only get smaller as browsers continue to optimize WASM scenarios).

I don't think I'd recommend it for most consumer-facing websites any time soon, but in my experience Client Blazor is still much better than Angular for performance in an Enterprise/Internal App scenario.

replies(2): >>41882841 #>>41888399 #
6. parineum ◴[] No.41880907{3}[source]
I've never seen that behavior, even in the preview/beta versions. That example is less complicated than the sample project that you get when you create a brand new project from the visual studio template (it's something like increment a counter on the server side via button clicks iirc).

There were definitely some quirks and issues early on but they've done a pretty good job at smoothing that stuff out since it's gone through two LTS version of .NET.

The pipeline for something like that is click->js/wasm websocket->server code->websocket->ui updates. If you're doing something absurd on the back end when a checkbox is clicked, sure 1-2 seconds but that's a developer problem, not a Blazor problem. If you put me in front of a React app, I'd probably do something stupid like that too because I don't have much experience with it.

I suspect your complaint is more related to .NET/Blazor making it easier for less experienced developers to develop a working site/page with a lot of spaghetti where that same developer would struggle to create the same page in another ecosystem. If you compare to equally senior/experienced developers in different frameworks, I suspect you'd see the same basic performance from the two platforms up until a scale that very few of us are actually working in. Blazor can be quite fast if you don't write bad code.

I find a lot of the complaints about .NET to be that it enables developers who write bad code to get things done inefficiently instead of not being productive at all. IMO, having senior developers doing code reviews is pretty essential if you have junior developers on a team but the ability to build something, even if poor, can really accelerate the learning process when a senior person can look at a complete project, point out the issues and show the difference that the corrections make.

Sorry for the rant and sorry if this doesn't really apply to you specifically.

replies(1): >>41881105 #
7. hakanderyal ◴[] No.41881105{4}[source]
I get where you are coming from, and I'm on the same page. I'm not complaining about Blazor, I'm complaining about not finding any good examples. That's why I'm asking around.

I'm looking for something that will make me "wow, Blazor can be used to build great apps!" or "ok has advantages over the React/Vue etc. equivalent".

Because if there aren't any, in similar thinking with parent, I'm afraid that it won't catch up and it'll go the way of silverlight, so I refuse to invest any time.

replies(1): >>41881704 #
8. CrimsonCape ◴[] No.41881704{5}[source]
The best Blazor app i've seen is nodexr.

https://www.nodexr.net/

https://github.com/Jcparkyn/nodexr

replies(1): >>41883563 #
9. hakanderyal ◴[] No.41882841[source]
Thanks, that confirms my initial findings.

I’ll look for an opportunity to give client Blazor a try.

10. hakanderyal ◴[] No.41883563{6}[source]
That's what I was looking for, thanks!
11. aksss ◴[] No.41883643{3}[source]
> 1-2 seconds

Something is wrong there, probably someone is screwing up form validation in their component framework or something, but IME that’s not a Blazor thing.

12. CyanLite2 ◴[] No.41888399[source]
Blazor Server in an enterprise (intranet) is extremely fast because the network is extremely fast.

Across the Internet, it's still quite fast if you use Azure SignalR service, which is effectively a globally distributed CDN. Most commercial apps use this service.

Blazor WASM is better than I thought it would be. My company has built a healthcare SaaS app that has ~5k daily users on it and no one has complained about the initial rendering and download time to pull down 25MB on the initial load. This sounds like a lot but with modern broadband, 5G, and CDNs, this takes about a second or two.