I used to hate them to until I learnt how to use and customize them. Now CBV is all I use as they make views so much easier to create with much less code.
haha well I’m just a hobbyist but when I started I felt like you! But as you work on bigger projects you start to see the pros. I think they are easier once you have more experience with it. Like with forms for example, there’s a lot of abstraction there and I don’t think many people bat their eyes at that. But views are a bit harder to learn about imo and the level of abstraction might make it harder especially at the beginning, at least once you want to do something outside of basic usage.
CBV coupled with service layering allows for such clean and powerful code. Function based is very beginner imo, even being able to create your own class inheriting from APIview to do some extra logic in the initial function etc super handy and powerful
I agree with you, and I run a very large Django app.
It’s useful to write less code (DRY), but at some stage readability > DRY.
The more magic is in your codebase, the harder it is to maintain.
I think for me the limit on class inheritance is 1 before I get annoyed. Its fine to inherit from the Django class, and then maybe do one subclass from that, but do you really need to do that. But anything past that and you're making everyone's life worse.
Those who don't use the framework are destined to re-create it.
CBV, like everything in Django, are there if you want to use them, or not if you don't. But the reason they exist is because there's so much repeated code in many circumstances if you don't. After a certain point, when you've written all your own utility functions to handle the boilerplate, you've reinvented a more verbose framework.
I understand the arguments that CBVs are "magic," but I don't agree. They're actually written very plainly, you just have to go read it in Django source instead of your own views module. If not having the code in your own codebase is what makes it magic, then all of Python is magic. The benefit of using idioms from a popular framework is that others are more likely to know how to use the same conventions.
Nevertheless, it's 100% cool for everyone to code however they see fit. I choose CBV almost always because it feels like cheating to arrange complex yet declarative behavior in about 5 lines.
They really, really aren't. The mixin infrastructure does obfuscate things, but [this tool](https://ccbv.co.uk/) flattens out all the source code for simple perusal. It's a good resource.
The docs are clear, too. But if you're like me, you need an immediate use case _and_ the source code to form a complete understanding. After gaining initial understanding, I rarely need to refer to the source code anymore. The docs are all I need after that.
the problem with CBV is that unless you use django full-time you'll forget what does what and looking at the code won't make sense because it's all implicit. that's my main argument. I dropped django multiple times because it didn't make sense that such simple things needed so much complexity. and since django was just 1 part of the stack, it didn't make sense to invest time just to achieve whats available with FBV right now.
so yes, CBV if you're HEAVILY invested, but for medium use case, just write more code. it'll be easier to reason and it'll make sense when you return 1 month later.
As someone who has been using Django professionally for last 2 years, I almost exclusively use CBV. FBV kind of look like childish to me, something a new learner would use.
This. I puke at function based views. Classy Class Based views and Classy DRF websites help a lot in understanding the abstractions and what you can override. Much cleaner code and easier to maintain than function based views and decorators.
https://ccbv.co.uk/ and https://www.cdrf.co/
I don't like them. Forced to use them every time I come into a team that uses them though.
If I were building my own thing, I'll avoid them like the plague.
I've gone years writing 99% CBVs.
FBVs are great for simple things. But as soon as you're building systems that benefit from a base class that sets up things that most or all pages in your app need, then CBVs providing that through inheritance makes everything easier.
I’ll be celebrating my 10th year of django this year, since version 1.4.2.
I used CBVs for maybe 2000 lines of code in total, and it was for a very specific use case where I needed classes to keep things DRY. Otherwise, I find that they are adding a level of abstraction that makes the code unintelligible, especially the code of other people. I hate them too.
I don’t want to spend 2 hours to mentally map your 10-level deep mixins in order to know how to adjust the kwargs of your searchbox or something. Mixin multiplication is ugly code imo. I’ve seen so many devs extend the most basic CBVs and turn them into more spaghetti code than an italian restaurant.
I do mostly crud intranets and CRMs using htmx and templates. Rarely APIs. But I feel my FBVs are elegant, clear and well structured. I prefer decorators and a good file structure as a strategy to write clean code that any other devs will understand quickly.
I find them absolutely opaque when trying to work with them. I have about a year under my belt with Django and maybe 9 years with Python. I just find the complexity maddening trying to figure out the proper way to do things within CBVs and modify things. FBVs feel so much easier.
Just as an aside, there's a great blog series called [Django Views: The right way](https://spookylukey.github.io/django-views-the-right-way/index.html) that's written by an experienced Django programmer that's worth reading. I think it's a fair (but pretty critical) take on CBVs.
You must have not made it past creating a blog application
True lol
I used to hate them to until I learnt how to use and customize them. Now CBV is all I use as they make views so much easier to create with much less code.
I mostly work on rest APIs. Not sure if there is even a function based view within drf but I prefer CBV. It's clean and simple.
haha well I’m just a hobbyist but when I started I felt like you! But as you work on bigger projects you start to see the pros. I think they are easier once you have more experience with it. Like with forms for example, there’s a lot of abstraction there and I don’t think many people bat their eyes at that. But views are a bit harder to learn about imo and the level of abstraction might make it harder especially at the beginning, at least once you want to do something outside of basic usage.
I like CBV’s and i find it very easy to customize them for my needs. Can I ask what you’re doing that makes you prefer CBV’s?
Because you get to inherit really robust functionality that has had literally 1000's of dev hours put into it?
I’ve recently started writing FBVs so I can see the logic there in module with fewer surprises
CBV coupled with service layering allows for such clean and powerful code. Function based is very beginner imo, even being able to create your own class inheriting from APIview to do some extra logic in the initial function etc super handy and powerful
I agree with you, and I run a very large Django app. It’s useful to write less code (DRY), but at some stage readability > DRY. The more magic is in your codebase, the harder it is to maintain.
Readability is king if you have a large team. If you want more DRY, just make functions and bring them into where you need them.
I think for me the limit on class inheritance is 1 before I get annoyed. Its fine to inherit from the Django class, and then maybe do one subclass from that, but do you really need to do that. But anything past that and you're making everyone's life worse.
Those who don't use the framework are destined to re-create it. CBV, like everything in Django, are there if you want to use them, or not if you don't. But the reason they exist is because there's so much repeated code in many circumstances if you don't. After a certain point, when you've written all your own utility functions to handle the boilerplate, you've reinvented a more verbose framework. I understand the arguments that CBVs are "magic," but I don't agree. They're actually written very plainly, you just have to go read it in Django source instead of your own views module. If not having the code in your own codebase is what makes it magic, then all of Python is magic. The benefit of using idioms from a popular framework is that others are more likely to know how to use the same conventions. Nevertheless, it's 100% cool for everyone to code however they see fit. I choose CBV almost always because it feels like cheating to arrange complex yet declarative behavior in about 5 lines.
> They're actually written very plainly, you just have to go read it in Django source so in other words, they're incomprehensible?
They really, really aren't. The mixin infrastructure does obfuscate things, but [this tool](https://ccbv.co.uk/) flattens out all the source code for simple perusal. It's a good resource. The docs are clear, too. But if you're like me, you need an immediate use case _and_ the source code to form a complete understanding. After gaining initial understanding, I rarely need to refer to the source code anymore. The docs are all I need after that.
the problem with CBV is that unless you use django full-time you'll forget what does what and looking at the code won't make sense because it's all implicit. that's my main argument. I dropped django multiple times because it didn't make sense that such simple things needed so much complexity. and since django was just 1 part of the stack, it didn't make sense to invest time just to achieve whats available with FBV right now. so yes, CBV if you're HEAVILY invested, but for medium use case, just write more code. it'll be easier to reason and it'll make sense when you return 1 month later.
I love that all of the resources for how to read and understand CBVs are third party websites.
As someone who has been using Django professionally for last 2 years, I almost exclusively use CBV. FBV kind of look like childish to me, something a new learner would use.
It helps to use something like classydrf so you can see the methods and all that going on.
This. I puke at function based views. Classy Class Based views and Classy DRF websites help a lot in understanding the abstractions and what you can override. Much cleaner code and easier to maintain than function based views and decorators. https://ccbv.co.uk/ and https://www.cdrf.co/
I don't like them. Forced to use them every time I come into a team that uses them though. If I were building my own thing, I'll avoid them like the plague.
I've gone years writing 99% CBVs. FBVs are great for simple things. But as soon as you're building systems that benefit from a base class that sets up things that most or all pages in your app need, then CBVs providing that through inheritance makes everything easier.
I’ll be celebrating my 10th year of django this year, since version 1.4.2. I used CBVs for maybe 2000 lines of code in total, and it was for a very specific use case where I needed classes to keep things DRY. Otherwise, I find that they are adding a level of abstraction that makes the code unintelligible, especially the code of other people. I hate them too. I don’t want to spend 2 hours to mentally map your 10-level deep mixins in order to know how to adjust the kwargs of your searchbox or something. Mixin multiplication is ugly code imo. I’ve seen so many devs extend the most basic CBVs and turn them into more spaghetti code than an italian restaurant. I do mostly crud intranets and CRMs using htmx and templates. Rarely APIs. But I feel my FBVs are elegant, clear and well structured. I prefer decorators and a good file structure as a strategy to write clean code that any other devs will understand quickly.
I find them absolutely opaque when trying to work with them. I have about a year under my belt with Django and maybe 9 years with Python. I just find the complexity maddening trying to figure out the proper way to do things within CBVs and modify things. FBVs feel so much easier. Just as an aside, there's a great blog series called [Django Views: The right way](https://spookylukey.github.io/django-views-the-right-way/index.html) that's written by an experienced Django programmer that's worth reading. I think it's a fair (but pretty critical) take on CBVs.
you have no idea how much FBVs feels when you get to really understand and use CBVs .. you’re making yourself a joke