We're talking about Python frameworks, so "all of them". It's not like they're optimized to win req/s competitions or run on embedded nanocontrollers.
"Developer productivity" is so vague, I'd regard it as weasely if it would be in a framework's description.
What's the developers aim and workflow? Depending on that, you can probably make an argument for most frameworks on the list.
- Django is your all-batteries included framework for standard CRUD with an integrated admin interface. For "average" jobs that feeds the productivity.
- But then you can make the argument that this approach gets in the way if you deviate from the norm, and Flask is the new productive toy.
- And isn't all the hubbub about a "pythonic" style getting in the way? Web2Py has some magic that might not be mainstream, but is just bound to ramp up productivity! (No experience myself, just using this for the argument and for nostalgia when every mention of it brought the main developer in the thread, arguing about this, just like redux today)
- But hey, man, we're all doing JS frontends and just need a web scale API. Erm, okay, then Django Rest Framework? The various Flask addons? FastAPI?
- I'm an ex-00s-Java developer who misses writing XML by hand. What's best for my productivity? Well, what about the endless joys of writing YAML by hand! Use connexion...
Salt this discussion with complaints about speed (charge of the Rust brigade), deployment hassles (Gophers emerge from the ground) and the collective "this isn't static and thus we're doooomed!" outcries (erm, Haskell?).
(And from the Waldorf & Statler balcony, enterprise programmers who get paid by the hour, laughing about "productivity")
That's because it comes with a load of built in functionality.
I am sure Flasks documentation is a lot smaller but its essentially just a few parts of Django (it doesn't have a built in ORM from what I understand). Start adding in the documentation for SQL alchemy, documentation for an authentication library and whatever else you need and you will probably start getting something similar but without the guarantee that the pieces will play nicely together.
Having extensive docs is a very good thing, much better than having a short readme and then rely on stack overflow to eventually fill in the gaping holes.
It might be a lot of pages, but Django has some of the best documentation out there. Speaking as someone who had to recently use it for a project for the first time, it was very easy for me to find the information I needed in their docs.
Flask is pretty good. Stays out of your way and does what a framework must, and has some extras for forms etc.. if you want to use them. Tornado is fun to use, but less resources and libraries.
I started working with Django when it was pre 1.0 (0.96), as it was explicit in nature compared to Ruby on rails in 2003-4. Subsequently I tried flask and recently async framework. Our team still use flask just for one reason, it's a thin layer over wsgi making it easier and once application or service grows it can disappear completely.
So it has right level of abstraction making it between a library and framework and you can use it either as library or framework. The difference is "framwwork calls your code" and "your code calls library code". I like the second paradigm more.
In order to make job very easy to develop there are excellent libraries so I have used flask, sqlalchemy (direct no flasl-sqlalchemy), alembic, marshmallow, celery, machine learning libraries (sci-kit, tensorflow, keras) and few more.
For development use cherrypy to graft wsgi app and for production use gunicorn or uwsgi. Our team is extremely happy and our test coverage is 98% as we use code as libraries not asnframework, so it makes it easy to test rest API and celery task code.
Also when needed for performance (not often as most libraries are better tested and designed), did take away the library abstraction and write our own code.
I traditionally like using the libraries not the Flask integrations (as in your sqlalchemy example) however I do find myself using Flask Admin and Flask-WTForms, since while they do have downsides and you have to commit to using them, they do a lot for you.
I haven't checked out CherryPy, I should next hobby project.
Gunicorn is awesome, uWSGI is also good and feels more "production" to me.
My problem with those additional projects are that I am dependent on one another layer of abstraction and not sure if the team is able to continue to develop it if core developers abandon it. Thats the reason I prefer using libraries, which if not supported can be supported by my team or replaced if necessary.
We use Flask mostly for REST API, so flask-admin and WTForms do not add that much value as all those are done on client side SPA (I do not like SPA, but it makes job easier as same API is leveraged for integration and mobile app).
I find Tornado and Falcon really helpful in that manner, particularly when building REST(ful) APIs. Tornado used to be my go-to tool before discovering Starlette.
"Developer productivity" is so vague, I'd regard it as weasely if it would be in a framework's description.
What's the developers aim and workflow? Depending on that, you can probably make an argument for most frameworks on the list.
- Django is your all-batteries included framework for standard CRUD with an integrated admin interface. For "average" jobs that feeds the productivity.
- But then you can make the argument that this approach gets in the way if you deviate from the norm, and Flask is the new productive toy.
- And isn't all the hubbub about a "pythonic" style getting in the way? Web2Py has some magic that might not be mainstream, but is just bound to ramp up productivity! (No experience myself, just using this for the argument and for nostalgia when every mention of it brought the main developer in the thread, arguing about this, just like redux today)
- But hey, man, we're all doing JS frontends and just need a web scale API. Erm, okay, then Django Rest Framework? The various Flask addons? FastAPI?
- I'm an ex-00s-Java developer who misses writing XML by hand. What's best for my productivity? Well, what about the endless joys of writing YAML by hand! Use connexion...
Salt this discussion with complaints about speed (charge of the Rust brigade), deployment hassles (Gophers emerge from the ground) and the collective "this isn't static and thus we're doooomed!" outcries (erm, Haskell?).
(And from the Waldorf & Statler balcony, enterprise programmers who get paid by the hour, laughing about "productivity")