[otherme123]

I was forced to fall on this trap once: a guy has a small Flask app up and running, and he asked for help to implement: an ORM with migrations, an Admin and form validation (among other things that had nothing to do with Django such file parsing).

I suggested to migrate the app from Flask to Django while it was small and simple, but he refused for Django is "too big and complicated". OK, then. We ended up creating a monstrosity of Flask half-assed packages to include functionality that is already included in Django (think cache, csrf, admin...), plus WTForms, plus SQLAlchemy, plus Alembic, hard to test, hard to keep updated, hard to deploy, and so complex that it turned non-migrable to Django. Development felt like walking through mud.

[andybak]

I like to paraphrase Greenspun's Tenth Law in this context:

"Any sufficiently complicated Flask app contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of Django"

[wirthjason]

I love the paraphrased quote. It’s a bit ironic in that Python programmers love the batteries included standard library but quickly jettison that idea when it comes to Django vs Flask.

Flask’s marketing of a simple route decorator makes it seem light weight but once you add everything else it becomes Django.

[dagw]

but he refused for Django is "too big and complicated". OK, then. We ended up creating a monstrosity of Flask half-assed packages to include functionality that is already included in Django (think cache, csrf, admin...), plus WTForms, plus SQLAlchemy, plus Alembic, hard to test, hard to keep updated, hard to deploy...

Heh. I've done that. Impressive how quickly you can go from "I literally need three or four REST end points to let users query this SQLite database" to, well that.