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):
Books: C# 12 and .NET 8 - Modern Cross-Platform Development Fundamentals - Eighth Edition: Start building websites and services with ASP.NET Core 8, Blazor, and EF Core 8 by Mark J Price
Web API Development with ASP.NET Core 8: Learn techniques, patterns, and tools for building high-performance, robust, and scalable web APIs by Xiaodi Yan
Turorials: series of tutorials on YouTube by IAmTimCorey and Shawn Wildermuth.
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".
Anyway, I came across a podcast featuring the author of "ASP.NET Core in Action", Andrew Lock, and he seems to know his stuff. I haven't read the book yet, but maybe this is the book you are looking for.
--
1: https://dotnetcore.show/season-6/navigating-the-aspnet-core-...
2: https://www.manning.com/books/asp-net-core-in-action-third-e...
(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.)
For .NET Backend/JS Frontend, look for resources that uses minimal APIs. MVC is also good but has a lot of backwards compatibility baggage that led to the creation of minimal APIs.
On the server you can run ASP.Net using Giraffe, which is a Functional Programming layer with comparable performance to C#.
On the front-end, you can write React in an true Functional Programming language.
And of course you can share F# code between frontend and backend.
This means that you can have a team of C# developers writing in a language they are familiar with, a team of node/TS developers writing React and a team of F# developers working on a pure functional core with all of the business logic. Write your validators in F# can you can share the same logic for a form in the UI and an API endpoint on the backend.
In my opinion having type inference, discriminated unions, computation expressions, et al., makes for a very concise and expressive way to model the core logic of an application.
(I don't mind outdated for .NET stuff, nearly everything from enterprise vendors looks like it just jumped out of WinXP anyway.)
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.
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.
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.
There is a difference: Silverlight was not open-source, whereas Blazor is open-source on both server-side and WebAssembly (WASM).
ASP.net MVC has reached maturity and is notably used in project like NopCommerce.
I also think wasm Blazor is a non-starter as well until WASM GC integration in the browsers gets fully integrated for C# targets.
I’ll look for an opportunity to give client Blazor a try.
In dotnet, it seems everyone uses the Microsoft "blessed" framework, until Microsoft does a full rewrite or loses interest - then everyone has to rewrite their stuff too.
There's no way Microsoft are the only ones capable of producing good library/framework ideas - so what gives?
If project goes belly up no one can pin it on you choosing something non standard.
So it is a feature of dotnet ecosystem not a bug “doing stuff the MSFT way”
ASP.NET Core is strong and overall better option when compared to FastAPI, RoR, Spring or Node.js with Express/Nest.js. EF Core with LINQ and safe SQL interpolation is one of if not the best ORMs that exist on the market across all programming languages.
This results in much weaker demand for alternatives, and combined with community that historically erred on the side of "out of box" choices, it's no surprise that there aren't really big viable alternatives to ASP.NET Core. There are for EF Core though - Dapper/DapperAOT and Linq2Db. Aside from that, most community libraries, both C# and F#, instead usually opt to build on top of them, like Fast-Endpoints or Giraffe/Oxpecker.
.NET could use a framework that is what Vert.X is to Spring, but even existing landscape is so much better than almost every other alternative, that it's difficult to complain, except, I suppose, when it comes to Identity and Authn/Authz in general that are more complex than ideal.
p.s.: I'm not saying that all "first-party" libraries are good. ASP.NET Core and EF Core, especially their "core" functionality are great. The surrounding selection of packages however can be hit or miss, and it's where a productive choice is to look for community libraries instead. It's an area that is slowly getting better.
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.