[linkdd]

Like I said, you don't need class-based views if you split your code correctly.

You have a function, which takes a request and URL parameters, and returns an HTTP response. You add some decorators to require an authenticated user and/or some permissions. That's it.

This is no different than flask views.

Mixins are an OOP pattern that promotes spaghetti code if not done carefully, especially in Python where there is no encapsulation.

ViewSets are from the Django REST Framework, this is simply all the boilerplate code that you copy/paste hundreds of times. And even that, you might not need it if your API is different enough from your database schema. Even more if you don't need an API.

There is nothing "magical", every single framework have a happy path, you should follow it if you decide to use this framework.

And no, Flask is not a framework, it is a library, much smaller scope, much more boilerplate code that you need to copy/paste, or you build your own framework on top of it.

Flask is about the freedom of choice while Django made the decisions for you 10 years ago. Having some experience with Rails, SpringBoot, Phoenix, Symphony, Laravel, Flask, Express, etc... it turns out that I don't want to make those decisions every single time, for every single project.

[agumonkey]

The boilerplate removal is nice but the logic seems distributed in obscure ways.

Or maybe it's culture non-fit. I'm not used to web dev/django habits.

[linkdd]

Which is why I put all the logic into a single place.

Extra methods on Django Models? Nope. A function in my business logic package which takes a model instance as parameter? Yes. Models should only contain data.

Huge views that do more than one thing? Nope. A function, or a class, in my business logic package which takes the request data (POST form, GET query string) and returns the data to feed to the template and/or the "state" needed to decide which template to render? Yes. Views should be small.

Also, split your templates, don't be afraid of `{% include %}` (which works well with HTMX as well).

This methodology also have another huge advantage. If you need to walk away from Django, you can. Your business logic won't change that much (there are not many difference between a Django Model instance and an SQLAlchemy model instance, or even a MongoEngine model instance). Your business logic knows nothing of HTTP or serialization.

Django, and Flask or any other framework are just the glue between the WSGI/ASGI and your business code.

If your code is async but your web framework isn't, you can still put a `asyncio.run` or `trio.run` inside your view, and you won't have to change a thing once you switch to an async web framework.

Basically, I use Django for:

  - the ORM
  - the Forms
  - the routing with urls.py
  - the settings management
  - the templating engine
  - the builtin User system
  - the builtin admin website
  - the vast ecosystem (django-anymail, django-tailwind, django-money, django-flags, django-social-auth, ...)

What I dislike about Flask is:

  - routing is tied up to the views (via a decorator)
  - the request object is a global singleton instead of a function parameter
  - no builtin admin website (this is just so useful to get things going at the beginning)
  - there is a lot of boilerplate to make the different extensions work together where django is just about adding a string to INSTALLED_APPS

[agumonkey]

Thanks for you thorough answer, I'll see how it goes for me in the coming months. I may find myself surprisingly happy.

btw, didn't django add routing decorators too ? I always prefered it to split file because .. it's a small amount of information that needs to be tracked separately mentally if in urls.py .. plus inclusion/sub-routes feel confusing (but that may only be me)

[linkdd]

It's a personal preference.

When I'm onboarding on a huge code base, someone from the frontend reports a bug, I'm like "ok so where does this URL go?", I open the urls.py (which can be split with include), and from there I navigate to the relevant piece of code quite easily.

But with routes as decorators, you need to know the structure of the code beforehand. Which can take some time if you're onboarding a new project.

IMHO, having the route next to the code managing the request does not add useful information to the code being modified.

Also, thanks to django-flags (a feature flag django extension), I can easily enable/disable routes with feature flags in the urls.py without overwhelming the "request handler" with irrelevant information.

But that's only a personal preference.

[agumonkey]

Interesting still