8 ms·

> I've had the "pleasure" of working with other large projects built on flask and ever time it gets to a certain size I wonder why we didn't just use Django. A

> I've had the "pleasure" of working with other large projects built on flask and ever time it gets to a certain size I wonder why we didn't just use Django. Actually, I've had the exact opposite experience. I like using Django for small and mid-sized projects, because with Flask I have to spend time adding all these extra libraries for universally required functionality on a quick app whereas, with Django it's plug and go. However, the larger the project gets, the more I like Flask since I have near total control and understanding of the app. There's no digging into Django internals to make some obscure customization. Then again, it's been several years since I last used Django, so it may have changed for the better here.

danpalmer 8y ago
For what it’s worth, on a Django codebase of 180k lines, 100k lines of templates, 1000 URLs, 380 “apps”, 350 models, we have a nice coherent structure across the whole codebase that makes us really productive. I haven’t seen a Flask code bass do this anywhere near as well. They all seem to end up becoming very different and tricky to onboard new devs onto because they are so custom. Django hides some complexity, but we haven’t found many pets we can’t effectively customise, and the architecture at scale is great, something I haven’t seen in many other places.
- travisjungroth 8y ago
  What does that Django project do?
  - danpalmer 8y ago
    https://www.thread.com/ https://www.thread.com/ Curated ecommerce, a CRM like system for stylist, order management, fulfilment and distribution.
- ernesto7 8y ago
  Do you mind explaining what that structure is? I always find the standard Django structure of everything is an "app" difficult to navigate once the codebase gets larger.
  - danpalmer 8y ago
    As much as I'd rather not plug my own talk, it's probably going to give you more information than I could ever get in a reply here. https://thread.engineering/scaling-django-codebases-pycon-uk-2017-91c166fcb926 https://thread.engineering/scaling-django-codebases-pycon-uk...
- jnbiche 8y ago
  > I haven’t seen a Flask code bass do this anywhere near as well. They all seem to end up becoming very different and tricky to onboard new devs onto because they are so custom. While some Flask web applications may use different file organization schemes, any large app will use blueprints. Blueprints are fairly standardized and easy to understand. I personally find Flask blueprints easier to follow than Django apps, but they're pretty similar.
pbreit 8y ago
Similar experience for me. Django is pretty thick with quite a bit of (confusing, to me) magic. Flask comes without very basic components that are required for pretty much any website (user accounts, db access, etc).
- blattimwind 8y ago
  Between Django and Flask, Pyramid is often forgotten. It seems like the only one of the three that has been genuinely designed to be extended (vs. Flask's approach of "here you have a magic-global variable (that's magically working like a stack of dicts), go put some stuff into it"); a good example would be renderers. In Django it's still kinda awkward to use other/multiple templating engines; Flask doesn't really help. Pyramid on the other hand has a simple and extensible interface to support multiple templates and other renderers ( https://docs.pylonsproject.org/projects/pyramid/en/latest/narr/renderers.html https://docs.pylonsproject.org/projects/pyramid/en/latest/na... ). This is a common theme with Pyramid. Another is avoiding global state; they're quite successful at that (vs. "I declare my entire app/blueprint within a function"-Flask and "I don't know how this works, it's just like magic. I go to my model class and, BAM, suddenly I'm connected to some database"-Django). (Other examples where the other two's solution feel rather lackluster to me include middleware vs. view derivers, view predicates, the routing system and the security area)
  - theptip 8y ago
    I've been meaning to look into Pyramid, it does sound like it avoids some of the worst of both Flask and Django. Any areas that Pyramid doesn't do well at?
    - blattimwind 8y ago
      It has nothing like the django admin and no forms handling is built into it. Creating a project from scratch is a bit cumbersome (like flask), but good cookiecutters exist (e.g. the pyramid-sqlalchemy one).
    - pbreit 8y ago
robohamburger 8y ago
Agreed. Also, unless django has changed peaking under the hood is a nightmare. Forms and the ORM (and really the whole framework) is giant ball of mud.
- leetrout 8y ago
  It's not changed much. Some things are a bit better (model's Meta is now documented and not considered "private") but largely I have grown to enjoy the benefits of picking the right tools (SQLAlchemy, Jinja2) and luckily Django is doing a lot better at making things pluggable and you can use Jinja2 as a first class citizen now.
- scrollaway 8y ago
  Forms are a nightmare to work with. It's a component in Django I systematically avoid, even when using actual forms. Nowadays I use DRF for everything though. Serializers > Forms. And React > Templates. As for the ORM, I long for a world where the ORM is replaceable by SQLAlchemy. Django's ORM is nice and simple, but as soon as you want typed complex queries, SQLAlchemy is really good.
  - blorenz 8y ago
    Agreed. Django Forms' hay-day was back in the Request/Response rendering of page state era of the web. They introduced the ability to bind data for validation, rendering in the Template, programmatic generation based on Model and sanitization of form input data. They still can be utilized loosey-goosey on the backend in the world of APIs. Why bother when better tooling now exists? The use-case of Forms now is the Admin side of the house where they can facilitate the CRUD of the Models.
    - Rjevski 8y ago
      Just wondering, what do you use instead of Forms for non-Javascript websites?
      - scrollaway 8y ago

danpalmer 8y ago

For what it’s worth, on a Django codebase of 180k lines, 100k lines of templates, 1000 URLs, 380 “apps”, 350 models, we have a nice coherent structure across the whole codebase that makes us really productive. I haven’t seen a Flask code bass do this anywhere near as well. They all seem to end up becoming very different and tricky to onboard new devs onto because they are so custom. Django hides some complexity, but we haven’t found many pets we can’t effectively customise, and the architecture at scale is great, something I haven’t seen in many other places.

travisjungroth 8y ago
What does that Django project do?
- danpalmer 8y ago
  https://www.thread.com/ https://www.thread.com/ Curated ecommerce, a CRM like system for stylist, order management, fulfilment and distribution.
ernesto7 8y ago
Do you mind explaining what that structure is? I always find the standard Django structure of everything is an "app" difficult to navigate once the codebase gets larger.
- danpalmer 8y ago
  As much as I'd rather not plug my own talk, it's probably going to give you more information than I could ever get in a reply here. https://thread.engineering/scaling-django-codebases-pycon-uk-2017-91c166fcb926 https://thread.engineering/scaling-django-codebases-pycon-uk...
jnbiche 8y ago
> I haven’t seen a Flask code bass do this anywhere near as well. They all seem to end up becoming very different and tricky to onboard new devs onto because they are so custom. While some Flask web applications may use different file organization schemes, any large app will use blueprints. Blueprints are fairly standardized and easy to understand. I personally find Flask blueprints easier to follow than Django apps, but they're pretty similar.

pbreit 8y ago

Similar experience for me. Django is pretty thick with quite a bit of (confusing, to me) magic. Flask comes without very basic components that are required for pretty much any website (user accounts, db access, etc).

blattimwind 8y ago
Between Django and Flask, Pyramid is often forgotten. It seems like the only one of the three that has been genuinely designed to be extended (vs. Flask's approach of "here you have a magic-global variable (that's magically working like a stack of dicts), go put some stuff into it"); a good example would be renderers. In Django it's still kinda awkward to use other/multiple templating engines; Flask doesn't really help. Pyramid on the other hand has a simple and extensible interface to support multiple templates and other renderers ( https://docs.pylonsproject.org/projects/pyramid/en/latest/narr/renderers.html https://docs.pylonsproject.org/projects/pyramid/en/latest/na... ). This is a common theme with Pyramid. Another is avoiding global state; they're quite successful at that (vs. "I declare my entire app/blueprint within a function"-Flask and "I don't know how this works, it's just like magic. I go to my model class and, BAM, suddenly I'm connected to some database"-Django). (Other examples where the other two's solution feel rather lackluster to me include middleware vs. view derivers, view predicates, the routing system and the security area)
- theptip 8y ago
  I've been meaning to look into Pyramid, it does sound like it avoids some of the worst of both Flask and Django. Any areas that Pyramid doesn't do well at?
  - blattimwind 8y ago
    It has nothing like the django admin and no forms handling is built into it. Creating a project from scratch is a bit cumbersome (like flask), but good cookiecutters exist (e.g. the pyramid-sqlalchemy one).
  - pbreit 8y ago

robohamburger 8y ago

Agreed. Also, unless django has changed peaking under the hood is a nightmare. Forms and the ORM (and really the whole framework) is giant ball of mud.

leetrout 8y ago
It's not changed much. Some things are a bit better (model's Meta is now documented and not considered "private") but largely I have grown to enjoy the benefits of picking the right tools (SQLAlchemy, Jinja2) and luckily Django is doing a lot better at making things pluggable and you can use Jinja2 as a first class citizen now.
scrollaway 8y ago
Forms are a nightmare to work with. It's a component in Django I systematically avoid, even when using actual forms. Nowadays I use DRF for everything though. Serializers > Forms. And React > Templates. As for the ORM, I long for a world where the ORM is replaceable by SQLAlchemy. Django's ORM is nice and simple, but as soon as you want typed complex queries, SQLAlchemy is really good.
- blorenz 8y ago
  Agreed. Django Forms' hay-day was back in the Request/Response rendering of page state era of the web. They introduced the ability to bind data for validation, rendering in the Template, programmatic generation based on Model and sanitization of form input data. They still can be utilized loosey-goosey on the backend in the world of APIs. Why bother when better tooling now exists? The use-case of Forms now is the Admin side of the house where they can facilitate the CRUD of the Models.
  - Rjevski 8y ago
    Just wondering, what do you use instead of Forms for non-Javascript websites?
    - scrollaway 8y ago