> 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.
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.
> 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.
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.
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).
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/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)
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).
Maybe it's because I'm used to Rails, but there is really little magic in Django. One is even free to structure the code as one likes. Almost no mandatory directory structure. It's a beefier Flask but still straightforward. If I may come up with a criticism, there are too many complications that slow down development compared to Rails.
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.
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.
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.
Yep, forms smell of Java Struts. I was so happy to say goodbye to them when I started using Rails in 2006. Another Javism, templatetags, because they don't want we write Python in the templates. So every small customization takes x100 the time in the best tradition of early 2000 Java frameworks.
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.
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.