Django vs Flask for a long-term project

Question

I am looking for a comparison of django and flask for a project that will live for a long time, and will need to be maintained, built upon and grow as the months progress.

I am considering Flask + SQLAlchemy or django.

I do not need batteries, as I usually end up having to modify them, so it is fine if I have to re-implement a couple of wheels to make it do exactly what I need.

I prefer the coding style of flask, I do prefer how it is middle ground between a full-stack framework and a mear WSGI layer.

My largest reservation is the dependability of flask. Flask/Werkzeug are built from a one man team, if he drops the ball on the project I doubt someone would be able to replace him. Django has a whole community behind it and there is no worry of it ever not having developers to maintain it.

Django does include alot of batteries, and feels bloated when working with it. I also do prefer SQLAlchemy over the django ORM.

In the end my preferences do not matter, I am concerned about the long-term maintenance of the application, scalability, reliability and its ability to grow and adapt to the quickly changes business rules (they could change every 2 weeks to every month) while keeping its slim figure.

Answer 1

Personally I love flask, I can see some scope for reservations but big picture:

• It's only 750 LOC and 750 low four figures of code and comments. You can get your head around it if something stops working for whatever reason. Below the flask layer there are clean, highly swappable libraries.
• I wouldn't sweat the small developer core. Werkzeug routing and jinja templating, for example, are so overwhelmingly pleasant that someone will pick up the torch if these guys move on to bigger and better things (like graduating college!) And also it is just a thing with open source that there are often stars whose contributions are monstrously disproportionate to the size of the community that benefits from their work; think John Resig, Miguel de Icaza, Graham Dumpleton or Adrian Holovaty, for that matter. I wouldn't be surprised if some day we look back on these kids Armin Ronacher in that way.
• If you are lucky enough not to be forced to work with some unlovable enterprise framework all day, don't neglect the opportunity you have been given to dig into the guts of something that you love.

Answer 2

If you go with django, then in the long term, you will have to replace almost every single component of django with something else, the only remaining part will be the url mapper.

Answer 3

I don't think the «one man» argument should prevent you using something that fits your mind and Flask is built on well maintained libraries like werkzeug and jinja. At some point we all do things differently at different times because we get experience and knowledge to make these different decisions.

BTW I just discovered repoze.bfg a few days ago and they propose in their screencasts section a tutorial named «Groundhog» where they build a clone of the microframework Flask.

http://bfg.repoze.org/videos

What's great here is that you can use Flask approach while doing things other ways if you need it. For sure it's harder to get started but in the end you'll know how things are working and can grow as your needs change.

Answer 4

There are many pros and cons for both, but the main point to my eyes is: if you need an admin, go Django. If you can get rid or have no need of it, go FLask/SQLAlchemy.

Answer 5

Django makes the trivial easy(er) and the not so trivial way too hard especially for long term project were requirements may diverge from what Django has been designed to do primarily. You will then have to jump through so many hoops to get where you wanted that ... I concur with hasen j :P

Answer 6

The only real potential problem is the bus factor, should it actually become one, anyone from the Pocoo team could pick up the project leadership. Given the reputation Pocoo and all it's projects have I doubt that pretty much anything short of a fatal accident will give someone reason enough to "leave".

Answer 7

I'd actually recommend Pylons, I've used it for a project or two now.

It's lightweight (but includes very useful batteries, such as Pagination), uses SQLAlchemy for it's ORM (if you want to include it, it's optional), and is well structured (more like RoR in terms of organization).

It also works with multiple templating engines.

I had originally coded one of my projects in Flask, but found that it was getting too big and bloated (more so my fault), and I was trying to structure it like Pylons (when I actually discovered that Pylons does this for you automagically).