Hacker News Reader

ASP.NET is pretty bare bones, all by itself. It's pretty much just a simple pipeline of request handlers with DI support (which is also optional). MVC, routing, Razor - all unnecessary if you don't want to use them.

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.

A lot of this thread feels like Microsoft's terrible naming having not surprising negative consequences. "ASP.NET" can mean so many things to so many people.

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.

You can use .NET without ASP.NET. You also don't have to use all of ASP.NET either, it just comes with a full featureset and the default templates are configured for easy productivity. You can bind directly to sockets and write TCP responses using the fantastic memory and networking code, or use the robust Kestrel webserver to write low-level HTTP responses, or go up the stack and let it handle everything while you only deal with objects.

.NET supports as much ceremony as you want to deal with.

> You can use .NET without ASP.NET. You also don't have to use all of ASP.NET either, it just comes with a full featureset and the default templates are configured for easy productivity

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.

It's completely true in reality. I've used .NET for the last 4 startups and use various layers as needed for performance and flexibility. I know many other people and companies doing the same, and it's one of the main advantages of how much .NET gives you to pick and choose from.

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.

I'd say it's the community that suffocates everything not developed by Microsoft, not Microsoft itself directly.

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.

On the first part - I agree - and it's exactly this (MS's overwhelming influence on forcing direction) that keeps the .NET ecosystem back.

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...

Well they're basically turning C# into Scala, and Scala is (rightfully) dead/dying, can't die fast enough IMO, so maybe they are just hastening the demise of C# so F# can take the throne.

Low ceremony? Complexity in real world applications requires complexity in the frameworks that address them. Users will be more disappointed by simplicity that leaves them addressing complexity without guardrails, conventions, and tooling support.

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.

> 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

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.

(ASP).NET is also like that. The default templates just include more to start with since the platform is designed to scale to many scenarios and features.

You can trim out a lot. Take a look at the techempower benchmarks to see examples of different usage of the framework.

> Complexity in real world applications requires complexity in the frameworks that address them.

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.

XSRF, rate limiting, permissions/RBAC, feature toggles/TIP, analytics, profiling, silly examples like recent samesite changes - Just a few examples, and that's without touching the developer tooling.

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.

Every one of those things is just composable middleware in the Node/Go stacks, and I think in Phoenix and most FP stacks. Middleware composition seems like the right approach to me.

.NET Core shares your opinion. Many of these are just registered/configured by default.

> “ Complexity in real world applications requires complexity in the frameworks that address them.”

This is a dangerous way to think about complexity management.

Why is it dangerous?

This falls under the principle of "Complexity has to go somewhere".

NancyFX was a Sinatra Port for .NET Framework. I belief the current .NET Core variant is called Carter.

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.

Yeah. I want to be able to use Kestrel without using ASP .NET.

Not very likely, but I think separating the two out would help the ecosystem a lot in the long run.

It is technically separated out. Just shipped with .NET Core in a big framework bundle called ASP.NET Core (which is in all containers etc anyway).

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.

Thanks for the pointer. I will check it out

Suave is a low ceremony web framework for .NET

I really liked Suave, but its performance I fear was too low to realistically use it for my project.

Here is the last techempower for it; https://www.techempower.com/benchmarks/#section=data-r19&hw=...

You could still use Nancy. It sucks a whole lot less than the pile of abstractions that have been built into ASP.NET lately.

API's are the same for F# and C#, so it should be trivial to translate the code examples from C# into F#. Just remove the curly braces and change "var" into "let".

F# deserves more love in their communication. Definitely. F# appeals to many, however, from a product management perspective (aka MS perspective) there is a ratio of 100 C# dev to 1 F# devs (MS showed statistics once on it).

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.

They also have a few high profile personalities that are pretty much into the "us vs them" towards C# developers and Microsoft, which turns off many enterprise developers to even bother with F#.

This would remove the benefit of functional idioms, and mitigate any advantages the differing approaches have. F# and C# and not just syntactically different.

True, but the code examples in the BCL documentation is to show how to use the API, not to teach the languages. See something like F# for Fun and Profit https://fsharpforfunandprofit.com/ to learn to write idiomatic F#.

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.

two problems here;

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.

> There are pretty much no tutorials, no recent articles and no performant native F# libraries out there.

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.

[1] https://giraffe.wiki/docs

[2] https://saturnframework.org

[3] https://safe-stack.github.io/