- It is both 'out of my way' and flexible enough to scale up. I.e. you can start with a 5 LOC hello world, but it still handles a large app with lots of components well (Blueprints).
- It doesn't force a data model / DB onto me - I can just plug in whatever I have (unlike Django).
- It doesn't even force a templating engine onto me - I always use mustache instead of jinja2 (it's extremely tiny, tidy and portable to any language, so it's much easier to port code to other devices / platforms).
- wanna just get started? `sudo pip install Flask && python ./hello.py` --> served on localhost:5000. I recently started a project while in a meeting with someone complaining about some complex app we had - built a prototype with him together that could replace the entire thing and solves problems we had in 2h. Having a foolproof starting point without any configuration and then being able to build up from there is essential.
> It doesn't force a data model / DB onto me - I can just plug in whatever I have (unlike Django).
Django doesn't force a data model onto you anymore than Flask does - nobody is forcing you to use the Django ORM. Any database code you write for a Flask app could be re-used in a Django app.
What the Django ORM does do is allow you to write portable apps and extensions. For example, suppose someone writes an extension for Flask that uses SQLAlchemy. If I'm writing a Flask app and only have a Mongo database available, I can't use that extension. On the other hand, if someone uses the Django ORM to write that extension, as long as I have a Django backend for my database, I can use their extension. It abstracts away the underlying datastore. Besides just which database you are using, you can also write a variety of code that works with Django models. Now granted, this abstraction can be severely leaky and flawed at times, but it's still quite powerful overall. Django provides a conventional, standard way to address the issue of interacting with data in a general way. Again, nobody is forcing you to use it, because you can just bypass the ORM and write your database code directly. It's just a powerful paradigm if you do embrace it.
1) I'm still probably using the ORM. I was just noting that for any data that the ORM doesn't fit well, you don't have to use it.
2) Why is Flask "lighter weight" than Django? From my perspective, as soon as you start writing a real app, you end up reinventing all these basic things like file layout using your own conventions, instead of a standard one that people are familiar with. The mental burden of figuring out your special snowflake conventions makes it 'heavier' weight to me. But again, personal preference :) Flask is obviously much better for really simple stuff, and does provide a great framework for extensions, even if I still lean towards Django.
In terms of utility and productivity, it all depends on what you want to achieve, of course, and I imagine that Django is a better choice in many cases, but when you already have the wheels you feel like you'd need to re-invent, and those wheels aren't the bells and whistles Django already offers I think I'd prefer using Flask.
It may be because I do not use flask enough either. I spent a little over a year working on a production flask app with a small team and I still feel no where closer in solidifying best practices and design patterns with flask.
I think flask is great, like sinatra, for small apps. But I would never consider it for 'big' apps that represented more than half a dozen api endpoints and some sort of in-depth feature set.
Above that size, unless it's super simple, you'll pay the price in tech debt. While our api has worked up until this point, we're gonna scrap it for a Rails api-only app because we need convention + orm + other things to scale not just the app, but the team. There probably is a way to do this in flask, but 95% of our team are Rails guys, so it just makes more sense to go with q company wide maintainable system vs. what's there now.
For small/single devs working on small projects, flask (and sinatra) are great.
When starting with Django the data model is quite inflexible and difficult to work with. Especially the primary key issues.