Very useful, especially since CBV have terrible ergonomics. They have hidden code path, state and flow everywhere in their thousands methods, MRO to follow, the

Very useful, especially since CBV have terrible ergonomics. They have hidden code path, state and flow everywhere in their thousands methods, MRO to follow, they are verbose and hard to debug (good luck putting a breakpoint in the right place). I miss generic function views, but you can almost use CBV like them: in your view fuction, do "return YourCBV.as_view(params)" and you are good to go. Much easier than subclassing. Of course, with FastAPI, we know that there an even better API for that: DI. It's more composable, easier to follow, to test and with less side effects. django-ninja (https://github.com/vitalik/django-ninja/ https://github.com/vitalik/django-ninja/) already offers a lot of that for Django, and I hope it will become a huge success. It is however, currently thinking of using classes somewhere to reuse init view code, so I made a proposal to extend the API design around more flexible approacheshttps://github.com/vitalik/django-ninja/issues/15#issuecomment-1030673844 https://github.com/vitalik/django-ninja/issues/15#issuecomme... I'm against OOP, I use it myself, but you should use it for what it's good at: multiple operations around a central state, crafting an api with __dunder__ methods, and namespacing related data and operations.