Ask HN: How did Django land on such abomination of MVC naming scheme?

MVC is itself a bad naming scheme. At least in the mid-2000s the thing web-based MVC had in common was that all your endpoints went through some function which could render a different template based on the circumstances: for instance re-draw the form with error messages or display a message saying the submit was successful.

(I’d be afraid a young dev would have no idea this is possible without using React or Vue)

That generation of “MVC” systems stole the name of a very different UI coding paradigm from Smalltalk more than a decade ago. It is common for a web MVC system to be missing one of the letters which is not a problem because they work fine, it’s just they still call it MVC.

And what is a model anyway? The “anemic domain model” is the industry standard, whether it is a POJO in Java or

  { customerId: 5, name: “Alice” }

in JavaScript there is some piece of data describing a situation. It does not have to be an ‘object’ or adhere to any particular discipline because it can. In fact, there are disciplines around treating data as data in the abstract as opposed to a set of objects that provide affordances. SQL, Immutability, a defined set of operators such as “add a member to this list” which can be bound to events or sent over the wire or be done or not done on the digression of the system, etc.

The “view” is usually well defined but the “controller” is the balance-of-system and doesn’t have to have any particular structure at all.

There are, as the saying goes, only two truly hard problems in programming:

1) naming things

2) cache invalidation

3) off-by-one errors

It was, I'm sure, named hastily while they were in the earliest stages of development, thinking primarily about what the code would do and not much about what to name it. Renaming things later was never the highest priority, and then eventually far too much was built on it to change things.

The problem is, if you actually spend a lot of time at the beginning thinking about the name, you may not do much better, because software architecture often turns out to be somewhat different than the original plan. Naming things at the beginning fails for the same reason detailed product specs at the beginning often fails, but unlike functionality, names are rarely changed later once the situation is better understood.

I think MVC is a general concept / pattern and doesn't need to be reflected exactly in order to be useful. In case of Django (and other frameworks like Phoenix), the "view" is not necessarily a template .. can be a JSON response, CBOR or something else entirely.

The notion of a "controller" is also quite flexible. It accommodates "whatever logic we need to interpret the user's request and respond with the right thing". Is everything part of the controller? Is there some kind of a domain/business logic layer as well? All up to you really.