I agree that the ASP.NET documentation is lacking in F# code samples (although the example you picked is a bad one as Razor doesn't support F#, and so naturally wouldn't have F# code samples). You might find that Giraffe is a more comfortable framework, as it's essentially an F#-ified shim on top of ASP.NET.
To me it's usually a synonym to the full-fat MVC with controllers, DI, everything. This is reinforced by most of the dotnet templates and documentation, which make it feel like if you ask for a banana you're given a gorilla and the entire forest whether you want it or not.
In comparison, if you look at Go you'll see the "net/http" package. It's the HTTP server. Extendable. Built in - not something to download from NuGet. Only does HTTP - not reinventing its own DI, configuration management, IIS, etc.
.NET supports as much ceremony as you want to deal with.
This is only true in theory, but couldn't be further away in reality.
Microsoft suffocates everything which is not built in-house 1), so there is absolutely no OSS ecosystem going on in .NET which would allow a choice of different non-ASP.NET web frameworks.
Other languages have a wealth of different web frameworks and some are super basic and lightweight and others are huge with batteries included.
You don't get that in .NET at all. Everything is ASP.NET Core, and ASP.NET Core is a typical Microsoft product - an attempt to build a one size fits all solution, the magic silver bullet to solve everyone's problems at once. Like with all silver bullets, when trying to please everybody you end up pleasing nobody.
1) Except F#. In F# you will find a more vibrant OSS community and non ASP.NET alternatives (most famously Suave), but only because Microsoft doesn't care about F#. Instead of creating an equal level playing field for C# and F# they are morphing C# into an F# hybrid and eventually will stop caring about F# even more than now.
ASP.NET is not a single monolithic thing, the Core evolution has made everything modular and you can plug and play the parts you want. You can use just routing to translate URLs to endpoints, or just the view engine, or just the serialization bindings, or just razor pages, or just MVC, or just low-level HTTP responses, or just GRPC, or anything else. The entire pipeline is a series of middleware, which itself layered on the Kestrel webserver, which itself is layered on low-level sockets wrapped with Pipelines and Memory APIs.
There is no one-size fits all, and asp.net explicitly recognizes and solves for it. The issue might be your expectation that there is a small/light and large/heavy framework. There isn't, you just make one to fit you.
It's probably a cover your ass situation, especially at the larger, more conservative, enterprise-y, non-tech companies .NET is frequently used at. No middle manager would get fired for suggesting to use a Microsoft developed & endorsed solution instead of using some hipster open source framework.
For ex, AFAIK, there was no community participation on DI Design and community feedback on DI design was rejected. Then it was made the default in ASP.NET.
https://blog.simpleinjector.org/2016/06/whats-wrong-with-the...
If your view of low ceremony is matching HTTP verbs to methods, you may happily code your own against the HTTP primitives; if you want a framework that abstracts the complexity and provides a shiny-happy path, you may have to allow for some ceremony. The tooling is the antidote to this.
I think the place you trip up here is in not wanting to use a batteries included approach, while using a framework that makes the necessary abstraction/complexity tradeoffs for projects of mid to large scale. The appropriate tradeoffs _cannot_ be one size fits all.
F#'s support is tricky, as the number of users here is dwarfed by those in C#; and although .NET supports this language diversity, there are no direct idiomatic 'conversions' possible between C# and F# in many cases. This multiplies the effort of providing documentation and examples. I too would like to see it treated as a first class citizen, and for that - the code is OSS.
You have hit the core of my issue here. I am more used to the node-express or golang's way of working where you start off with the smallest and simplest scaffolding and then add on the bits that you need. Rails and ASP .Net are not something I want to use for my small time projects.
Its probably unreasonable for me to expect .Net to be something completely different from what it really is, but I really hope that .Net grows up to enable other way of using it.
You can trim out a lot. Take a look at the techempower benchmarks to see examples of different usage of the framework.
Does it? The frameworks I use today are really, really simple. Polka on Node and Go + a few helper libraries. It's all really simple and clear what's going on, and I can solve problems of just about any complexity I've come across with just those basic tools.
As each of these orthogonal concerns starts drifting in, applications become more and more complex as they 'tack on' support for these in code, rather than having structures in place to allow for extensions and modifications.
Abstractions always have their cost. Complexity exists in the problem domain of the web, and always will. .NET Core is generally well architected in response to a long experience in enterprise and developer concerns. It's not a magical answer to every domain's requirements, but it's generally a damn good compromise ime.
This is a dangerous way to think about complexity management.
And for sure, they are all based on ASP.NET Core. ASP.NET Core is extremely modular which allows, e.g. a middleware stack like Sinatra being built on top of ASP.NET Core's Kestrel webserver (which ... cite once again Techempower benchmarks) beats everything nearby in the current situation. It would be a horrible choice to built a web server framework right now on .NET without using Kestrel. You will never achieve to get close to the performance of that.
Not very likely, but I think separating the two out would help the ecosystem a lot in the long run.
Look at the techempower benchmarks implementation .. they run as close as possible to Kestrel. They have variants with raw kestrel interface, some with low-level middleware (I guess with express like routing) and then full-blown MVC like comfort.
Here is the last techempower for it; https://www.techempower.com/benchmarks/#section=data-r19&hw=...
Also, F# is community owned to my understanding (up to the statement of a MS Research Employee and F# inventor Don Syme to say that the "Microsoft." prefix on ASP.NET Core are not open source community friendly) while C# is 100% design & developed by MS.
Which - IMHO - makes it very delicate for Microsoft to communicate well here.
More F# documentation and support from MS would be great, but IMHO F# examples in the BCL documentation would not be the best use of resources.
1. For a new comer to the language, this is still too much of a hurdle. 2. If I wanted to use F# only as a proxy for C#, then I would rather use C#. I want to write F# code in a functional first and idiomatic way.
This is the stock answer I have gotten in the .Net Community and as someone who wants to use F# for web apps, its a huge turn off. There are pretty much no tutorials, no recent articles and no performant native F# libraries out there. There is no push from MS to improve the situation. and the community is like - This is fine!
Expecting a new user to write c# code with "let" isn't going to fix that.
Giraffe [1] is the de facto standard F# web framework. It's a plugin on top of ASP.NET (for all the reasons described elsewhere - performance, security, ecosystem) that lets you write functional-style 'route >=> function' code without controllers.
If you want a more batteries-included approach, Saturn [2] builds on top of Giraffe to provide, well, more backend batteries (database layer, etc.)
Finally, the SAFE stack [3] are a set of project templates that combine the above with a F# frontend (via the Fable JS compiler) and some Azure deployment helpers.
I recently ran through the entire ecosystem thinking that there must be something akin to Sinatra (micro web framework) in .Net. Nope. Every single thing is built on top of ASP .net.
I did find a WIP library where they are trying to go for a low ceremony framework https://github.com/featherhttp/framework, but even that is built on top of ASP .net
For me the worst bit about .Net is their treatment of F#. IMO, it is one of the most practical and usable functional languages out there. But none of the official docs have anything on F# at all. Here is an example doc; see if you can find any code example for F#. https://docs.microsoft.com/en-us/aspnet/core/tutorials/razor...
Its always C#. And I have 0 interest in that kitchen sink language.
Between ASP.Net and C# being the entire world for .Net, I have really not much interest in using it for anything. There are plentiful of interesting languages and ecosystems that I can use for my small time projects.