From the Django Documentation

In the beginning there was only the view function contract, Django passed your function an HttpRequest and expected back an HttpResponse. This was the extent of what Django provided. Early on it was recognized that there were common idioms and patterns found in view development. Function-based generic views were introduced to abstract these patterns and ease view development for the common cases. The problem with function-based generic views is that while they covered the simple cases well, there was no way to extend or customize them beyond some configuration options, limiting their usefulness in many real-world applications. Class-based generic views were created with the same objective as function-based generic views, to make view development easier. However, the way the solution is implemented, through the use of mixins, provides a toolkit that results in class-based generic views being more extensible and flexible than their function-based counterparts.strong text

CodePudding user response：

Class-based views in Django is excellent. They are very abstract and sort of handle many things on their own. They can also be altered to fit what you want to implement, but function-based views are very explicit, and often more straightforward if you're going to implement something different or complicated stuff. This may show you why some people like to use function-based views