Flask vs. Django: Worksheet to choose the right framework | Hacker News Reader

Flask vs. Django: Worksheet to choose the right framework

wakatime.com

71 pointswelder68 comments

One of my more favorite reasons to use Django would be - http://www.django-rest-framework.org/ - whose discoverable API browser is awesome and saves so much time in building out a great REST API with pagination, related resources, and so many other things (plus you can post from the API browser). A bit less so the built-in admin features, which are also nice at times. Possibly also the migrations system. I don't use Django templates, but the rest of it are pretty much great.

I almost started a very major project with Flask, but am glad I did not for how much work DJRF and South had saved.

http://python-eve.org/

For those who want a little context in-thread:

"Eve is an open source Python REST API framework designed for human beings. It allows to effortlessly build and deploy highly customizable, fully featured RESTful Web Services.

Eve is powered by Flask, Redis, Cerberus, Events and offers support for both MongoDB and SQL backends [*]."

I'll admit I have no idea about Eve, but having used Tastypie, the beauty of Django Rest Framework is its consistency with Django. The Serializers are very similar to forms, and the API views are very like Djangos generic class based views.

You could also use a Django Form to validate the data with Tastypie[1].

[1] - https://django-tastypie.readthedocs.org/en/latest/validation...

Not hard to throw http://swagger.io/ in front of most APIs to get that 'query in the browser' feature.

I had a look around a couple of month s back and I couldn't find anything like django-reversion.

I always fall back on my bastardized version of Greenspun's Tenth Rule.

In most real-world projects started using Flask - you end up reimplementing half of Django badly by the time you're finished.

Interesting, I take the opposite approach: As your project starts to grow, you end up ripping out the "batteries" of django and implementing other modules. The most notable one would be SQLAlchemy.

Yup. I switched to Flask mostly because I always ended up ripping Django apart:

- Jinja instead of Django templates.

- Custom (and sane) class-based views instead of Django's disgusting defaults.

- Custom class-based settings.

- There's no way to define app-only middleware in Django. Flask blueprints make it trivial.

However, 10 years later and no framework has come close to Django's true strength: built-in admin.

Just an FYI, the newest version of Django (1.8) now supports Jinja or Django templates by default and you can plugin other templating engines if you want.

Did you try to use Jinja2 templates in 1.8? There is hell of a bootstrapping to do until you can actually start working with these. Don't even try to use both at the same time within the same project. You'll end up crazy before you can make Django load the right template.

No I haven't, still on Django 1.6 at work but I keep up with the newest developments. That's a shame, from what I read it sounded like it was just a simple config setting that would allow you to use Jinja over Django templates.

You don't have to use Django's class-based generic views either. Nothing wrong with just inheriting from the base View if you really want.

You can also just skip the infinite inheritance and implement function-based views.

Interesting. Almost every experienced Django dev I know throws out the admin on their projects nowadays.

In favour of what?

I don't.

Exactly. I think that's why Flask needs more experienced devs for larger sites. This also means it's easier to hire Django devs.

I am curious about this. I like Djangos ORM for the basic stuff, but it doesn't work on even moderately complex queries (conditional aggregates are a serious loss). Would I gain much by going to SQL Alchewy over just using raw SQL, which is what I do at the moment? (bearing in mind replacing the Python ORM completely, and you will loose the admin, which I use heavily).

It's a pretty recent development, but have you tried Django 1.8's Conditional Aggregation and Conditional Expression features?

https://docs.djangoproject.com/en/1.8/ref/models/conditional...

Not yet, I usually stay with the latest stable version. Sounds good though. Its been long overdue.

In one project I worked on, I found this to be very true. We created an enterprise level application, with some constantly shifting specifications.

Flask vs Django was a huge point of contention between the two lead developers. One even quit over Django being chosen.

By the end of the project, we ended up using a ton of django's features. The business functional specifications changed, we did some research, and found out it would be easy to handle via slight extension of some already built-ins to django ex. template loaders,middleware,sites,and signals. It saved us a ton of time. I feel pretty safe saying I would use Flask for small very clearly specified projects, but otherwise I would probably choose Django.

When I started doing Django projects back in 2007 I certainly found Django very cumbersome - the lack of features in the ORM, the clumsy template language, the terrible authentication system (User.get_profile and so on). I preferred Pylons by a mile (the Flask/Pyramid of its day).

Django in 2015 though pretty much does everything I need. I still have gripes but when you factor in extras like the Django Rest Framework it's still my go-to for new projects unless it's something completely unusual.

For Python users looking for a very slim framework to build your API on, I'd highly recommend falcon https://falcon.readthedocs.org/en/latest/

It's built by the folks at Rackspace and it's super fast because you can build it using Cython and because it's just a very thin layer over wsgi. We switched over to it from Django and saw a 10x improvement in response time.

Django/Rails/etc are kitchen sinks. they are not optimized for "building an API", or speed for that matter. it's kind of silly to expect them to perform as well.

100% agree, but since they're so ubiquitous, I'm sure quite a few people out there do so without thinking twice.

you're right, i hope i didn't sound argumentative. i should clarify my own point too, and add that just because they are not "built for it", or are slower, doesn't mean they are inherently a bad choice either. it's really just what you need to optimize for.

so many ways to skin a cat...

This part seemed odd:

    Flask serves JSON responses slightly faster than Django.

    Flask: 60k
    Django: 12k

A 5x increase is slightly? Yes there is another slide zoomed out showing other frameworks much faster, but still, I'd take 5x over a poke-in-the-eye with a sharp stick if I cared at all about performance.

My point was, saving dev time and building faster is so important that it outweighs a slow framework.

I agree. I felt welder downplayed the increase but I am not too experienced of a dev ...

Those numbers are meaningless without knowing what the code is doing.

It says on the site, but it's basically just a "hello world" json response, so its just comparing the overhead for each web request.

And WSGI serves 12 times as many as Flask! /s

The questions and answers, for anyone who wants a summary:

1. Have you been coding for more than 5 years? (yes:'Flask', no:'Django')

2. Have you coded in Python for more than 3 years?(yes:'Django', no:'Flask')

3. Do you like reading Python code? (vs reading docs)(yes:'Flask', no:'Django')

4. Will you have an API? (yes:'Flask', no:'Django')

5. Will your site primarily have dynamic HTML pages? (yes:'Django', no:'Flask')

6. Will you use Service Oriented Architecture (SOA)? (yes:'Flask', no:'Django')

7. Using an SQL database? (yes:'Django', no:'Flask')

8. Want new devs to already know your conventions? (yes:'Django', no:'Flask')

> Complicated SQL queries are a piece of cake with Django's built-in ORM.

I disagree here or maybe "complicated SQL query" means something entirely different to me. I've found the ORM to be great for straightforward to reasonably involved queries. However the moment you start trying to improve the database performance, you need to drop to SQL. It's another story that SQL is a lot more difficult to maintain and not very DRY across modules.

This bit:

> Flask > Django for APIs. For example, a nested api resource in Flask is

> @app.route('/users/<string:user_id>/teams/<string:team_id>', methods=['GET', 'POST'])

> while with Django REST framework this is impossible.

> (drf-nested-routers helps but breaks unless you use only the most basic Django REST framework features.

Is this really true? For a start I've managed to build a complex app without needing nested routers (although they are cool). Second - I've used DRF extensions nested routers without finding any problems.

For me needing an API is a point in favour of using Django for a lot of use cases - you get an elegant declarative syntax and lots of batteries included.

It's not true at all. I've done nested routers in DRF plenty of times.

    router = DefaultRouter()
    router.register('users/(?P<user_id>\d+)/teams', UserTeamViewSet)

You can then access user_id via self.kwargs['user_id'] from within the viewset. And the team ID is implicitly added by the router to support list (and update), and retrieve (delete, put, patch) methods. user_id is also passed as a kwarg to the dispatched method (create, retrieve, etc...)

I don't get it either. The route definition is just an url with two arguments, right? Maybe I'm missing something...

I ended up extending DJRF to do nested collections, but I'd argue your REST topology would be better with one canonical resource and unique team IDs:

/teams/<id>/

It's fine to be able to add a user to a team by posting to a subcollection though, but there should only be one URL for the resource (IMHO).

drf-nested-routers only works with the most basic Fields. For example:

https://github.com/alanjds/drf-nested-routers/issues

Right now it's a hack that limits your api features, but might change in the future.

> Pirates use Flask, the Navy uses Django. WakaTime is a pirate

I don't understand this. According to Netcraft, the US Navy uses Active Server Pages and the UK Navy uses ASP.NET. While there could be Django somewhere in there, there's likely also someone in the US Navy using Flask. I wasn't able to find a source which says that US Navy has decided to use Django for most of its web development - I think it would be pretty surprising for the US Navy to switch to Python over a more traditional enterprise solution!

More likely this is some pop culture culture reference I don't get. Anyone care to explain?

It's the sort of thing someone says when they think they're an uber-l33t lean agile stealthy ninja rockstar webdevops disruptive buzzword buzzword, in my experience.

I don't think the title refers to the actual US Navy, but rather a "navy" vs "pirates" (as in people who use boats and occupy the open waters). The idea being that Django is more structured and much larger (as a navy usually is), where as Flask is smaller, etc...

http://www.folklore.org/StoryView.py?story=Pirate_Flag.txt

Not sure why this got downvoted... It 100% answers the question posed. Thanks Tosh!

Ahh! Yes, that's a perfect match for the given context. Thanks!

I question the assertion "Django is older and larger, but Flask has a more active community according to GitHub." Surely the number of stars and watchers don't mean that those people are active in the project. According to the github pulse reports for the last month:

> Flask (March 23, 2015 – April 23, 2015): Excluding merges, 19 authors have pushed 23 commits to master and 69 commits to all branches. On master, 16 files have changed and there have been 340 additions and 43 deletions.

> Django (March 23, 2015 – April 23, 2015): Excluding merges, 124 authors have pushed 189 commits to master and 608 commits to all branches. On master, 2,395 files have changed and there have been 25,689 additions and 84,146 deletions.

By those numbers it seems that Django has a much more active community, in the sense of making code changes. There are other types of activity than code commits, like support, conferences, etc. I don't get the sense that Flask is more active there either.

Edit: If it is meant as an allusion to the Mac/Apple][ era at Apple then activity is a poor measure - there was much more activity and general interest in the Apple ][ during the Mac development.

Part of the problem with comparing commits is the Django is more comprehensive. There is a larger "surface area" to make changes to.

The question really is, what's a useful way to determine which of two projects has a "more active community according to GitHub"? Is the number of stars/watchers a good enough proxy to use for decision making?

The projects I use are typically quite small, and my code is on Bitbucket, so I have effectively no experience in this.

Yeah. According to this Django is for enterprisy play-it-safe noobs.

Hmmmmm.

Author here. The Pirate/Navy title is a metaphor to say Django is rigid and Flask is flexible. You have to do things the Django way. With Flask, you can customize it easily.

P.S. My cofounder Priyanka said the Pirate Navy line thing when reading the post, and I thought it was an awesome title :)

Hehe, yes I remember saying it. Wasn't meant to be literal :-)

While I agree with this to an extent (I use Django on a daily basis) Django is pretty flexible.

If your app falls outside of a certain set of assumptions I would go for Flask (which I considered for a project we are working with). I would say that Flask apps need to be doing something special before Django is not considered.

I've been using django pretty much since 1.0 came out. Every project I start these days thats a web project, I use django.

The main reason why I use django is because o the ORM and the admin. If I were to do a project in Flask, I'd have to build mt own admin, and i'd have to use SQLAlchemy. I had to use SQLAlchemy once for a project and I hated it.The django ORM is much more straigh forward an easier to use, in my opinion. In my 10 years of using django ORM, I have had to "break out of the ORM" maybe once.

How do you manage with just one primary key column allowed by the ORM?

Some people argue that composite primary keys are an anti-pattern. They might be relationally pure but they make other things a lot harder.

I have a hunch that uuid's or other non-semantic primary keys are a good example of of 'practicality beats purity'.

I wish they added bottle.py [1] to the mix...

I'm a huge fan of bottle.py, it's simpler/cleaner, but does lack of fucntionalities and plugin. And you'll notice that it is much higher on the the JSON serialization chart at 13% (flask and django are at 5.7% and 1.1% respectively).

1: http://bottlepy.org/

Perhaps a bit off topic, but what's the reason Flask hasn't had a release in almost 2 years?

Probably because most of the commonly used components are maintained separately.

Sure, but there's been almost 700 commits. There must be something in there worth a release.

because Armin Ronacher (aka the_mitsuhiko here, the creator) doesn't use Flask that much any more, and there are not ver much contributors to it

https://github.com/mitsuhiko/flask/issues/1272

What about Python 3 adoption? Django feels a much safer bet in this regard.

"It's a tie! Read about Django vs Flask to make your own choice."

Thanks, this really helps a lot! LOL

What about Pyramid?

Personally, I like pyramid as a middle-ground between the two. More to get you started quickly a la Django; less to get in your way as you grow like flask. It tends to hit my needs right on the spot.

I can't access the site. Is it down? Blocked?

Anyone have a mirror?

Alternative url:

https://github.com/wakatime/wakatime-blog/blob/master/posts/...

The page loads for me just fine.

Reply on news.ycombinator.com