[asdajksah2123]

Front end development may have a lot of frameworks, etc., but so much less magic than .Net.

What makes .Net so much harder (especially ASP.Net) are the new features but also all the magic that makes discoverability so hard.

Front end frameworks tend to follow similar patterns, and where they differ, they usually advertise the difference between the standards heavily.

But also, since they are genuinely different frameworks, it's easier to search the differences etc. So, if I open a Vue application codebase, I know almost immediately that it's a Vue application and not a React one. I can google vue and figure out (most likely from their getting started page) exactly all I need to know to get started.

If I enter an ASP.Net codebase, on the other hand, I have no idea whether I'm looking at ASP.Net Pages, .Net WebAPI, .Net WebServices, or more often than not, some combination of all of them. Throw in some Dependency Injection, with a combination of IOC containers used in the same project, and it's a massive lift to know what even to Google for.

[metaltyphoon]

I hear this word all the time “magic”. Can you describe what it means with concrete example for other stacks?

[ewjt]

Magic means “hidden complexity”, AKA “abstraction”. The negative connotation is that sometimes you can’t figure out why your software is behaving a certain way and what you need to do about it.

The positive connotation is that you write less code with less cognitive overhead.

Generally I prefer ASP.NET over things like Spring and Ruby on Rails because it has less magic, despite being clearly inspired by both of those.

Here’s a concrete ASP.NET example: You can put an [ApiController] attribute on your controllers and it can change the structure of error responses, among other things. [1]

I don’t agree with some of the other parent points. For example, the comments on “multiple dependency injection container” —- ASP.NET is pretty prescriptive on DI patterns. That sounds like someone made a decision to add complexity, which is on them.

[1] https://stackoverflow.com/a/66546105

[metaltyphoon]

So "non magic" means to write everything then? Because the example you showed you have to understand a language feature, attributes. Then see the source code, which is open, and how it's being used.

So, are Rust macros, or C macros, C++ templating magic or it's just means "I don't want to know how this works therefore it's magic"?

[cerved]

Http request handling in asp.net mvc. The uri, type and parameter serialization is a magic mess.

How do you PUT { "foo" : { "bar" : "baz" }} to ping/pong/yolo?

You create a controller class, PingController, you create a method PutPong, then you give up and proceed to cry blood

[guhidalg]

It seems you had a bad time learning ASP.NET, but in my experience what you're asking for is not difficult at all.

You have to: 1. [Optional] Define a DTO that deserializes { "foo" : { "bar" : "baz" }} to an object 2. Write a class that subclasses Controller 3. Write a method, call it whatever you want, that accepts a JObject or one of your DTO types. 4. Add the attribute [HttpPut("ping/pong/yolo")] to tell the framework this method should be bound to PUTs for that path. 5. Write your business logic.

Is that blood-crying inducing? No.

[cerved]

Without decent documentation, it is.

[aliswe]

something like

app.MapPut("ping/pong/yolo", ctx => ...);

and in there you read the Body as string ... it should be a one liner?

[neonsunset]

app.MapPut("ping/pong/yolo", ([FromBody] Payload request) => {...});

record Payload(Foo Foo);

record Foo(string Bar);

or

app.MapPut("ping/pong/yolo", (JsonElement json) => {...});

Basically, just avoid outdated blog posts and articles :D

[cerved]

this looks like asp.net core

[neonsunset]

No one in their sane mind would use ASP.NET for new projects (it is legacy and a business risk) nowadays so it's reasonable to assume that everyone means ASP.NET Core given the .NET 7 context.

[cerved]

the context was asp.net mvc specifically