I agree with most of what the author advocates for. However, I'd like to point out that the first priority while building a startup is to get everything working fast.
If your idea works, there'd be a lot of users/clients, you'll probably get funding and you can go ahead and re-write your code to your specific use cases with a larger and better team.
The author mentions some really great and valid points on improving code quality of which I disagree with using FBVs over CBVs. Maintaining Class Based Views is inherently easier than maintaining FBVs. CBVs are well-defined and can be modified more easily in lesser amount of time essentially performing the same tasks as FBVs for a particular logic.
However, when using APIs, I do think that FBVs are more clear in some cases and have better readability. At the same time though, CBVs make sense when you're performing only one of GET, POST, or DELETE operations.
Inheritance is not as hard to figure out in these classes as the author claims it is. In some cases, it might become overwhelming but that is not going to happen at all if your app never grows which leads me to my original point, you need to build whatever you are working on fast.
CBVs, fat models ( which I also suggest using ) are easier to implement than writing more code in scattered FBVs.
Why do I suggest fat models?
Adding well defined methods that relate to the context of your model inside your model, in my opinion, increases readability and makes testing easier.
Again, the goal is to build and grow a startup. You can always implement entirely different approach that works specifically for your use-case later. Even then, I think CBVs would be useful.
The issue with fat models is that if you use DB models and then put business logic in there (assuming that's what you mean by fat models), things fail pretty quickly.
But like you rightly point out here that is not a good reason to avoid class based views. They can be simple to understand and maintain.
What I've found useful is to maintain a two level hierarchy. I've used the term "view models" to describe the classes that feed into CBVs and "db models" for django models.
They could both be dataclasses with declarative mapping between the two, so you don't write the tedious code of parsing database results into view models.
If your idea works, there'd be a lot of users/clients, you'll probably get funding and you can go ahead and re-write your code to your specific use cases with a larger and better team.
The author mentions some really great and valid points on improving code quality of which I disagree with using FBVs over CBVs. Maintaining Class Based Views is inherently easier than maintaining FBVs. CBVs are well-defined and can be modified more easily in lesser amount of time essentially performing the same tasks as FBVs for a particular logic.
However, when using APIs, I do think that FBVs are more clear in some cases and have better readability. At the same time though, CBVs make sense when you're performing only one of GET, POST, or DELETE operations.
Inheritance is not as hard to figure out in these classes as the author claims it is. In some cases, it might become overwhelming but that is not going to happen at all if your app never grows which leads me to my original point, you need to build whatever you are working on fast.
CBVs, fat models ( which I also suggest using ) are easier to implement than writing more code in scattered FBVs.
Why do I suggest fat models? Adding well defined methods that relate to the context of your model inside your model, in my opinion, increases readability and makes testing easier.
Again, the goal is to build and grow a startup. You can always implement entirely different approach that works specifically for your use-case later. Even then, I think CBVs would be useful.