I view Flask as interesting from an architectural standpoint only. It helped me understand Python better. I liked its test suites, use of string imports, and code quality.
When I wanted to get work done, Django did everything. It had a great ORM system, form handling, views, and a template engine.
I can't think of any benefits Jinja2 (Flask's template library) has over Django templates. Maybe Jinja2 performs a bit faster.
SQLAlchemy, while it's awesome (and I do use it a la carte), isn't much better than Django's ORM in the big scheme of things. In fact, the use of the QuerySet object across Django and its third party package ecosystem makes playing with your data a lot easier.
I never had the dream of "microservices" pan out. Most applications I make end up being monolithic more or less, heh. Any non-trivial application I've dealt with outgrown Flask quickly. In fact, they outgrow Django. In a large application, I maintain a lot of code that does't touch the web framework at all.
Unfortunately, Flask's extension ecosystem seems to focus more on reinventing Django than supporting its unique strengths as a microframework.
Even in that case, I'm not experiencing any temptation to go to Flask. Two django websites right now with pretty big codebases. One of them has huge backend non-django codebase (which I keep in a separate git repo). Since there's still a need for templates, authentication, rdbms, permission systems, and so on, I still use django and create apps to act as a front-end for the libraries.
> Since it don't try to be responsible for everything from ORM to HTTP, it actually is capable of serving as a thin web layer for existing non-web functionality. At least in theory.
Yep, that's what my intuition was, formerly. Then I realized I needed an ORM since the website needed auth (whether or not it was a legacy db, "unmanaged" in django parlance). Then those users only should have rights to view/update/create certain things - so that means permissions.
> Unfortunately, Flask's extension ecosystem seems to focus more on reinventing Django than supporting its unique strengths as a microframework.
What do you mean by this?
Inevitably most web development tasks will have the developer reinventing Django.
The issue is, at least in my experience, these libraries that just need a quick and dirty front-end, have never stayed that way, heh. Let's just use that slice as an example. Still, in the event that included web interface became non-trivial, the benefit of using Flask quickly turns to reinventing stuff that'd be done easily with Django.
My bigger issue is, the microframework dream hasn't worked for me in PHP or Python. Except once: When I was doing Facebook Page campaigns at Social Amp. Those campaigns were ephemeral, and since they were just designed to be thrown out after a month, a microframework worked quite well.
Flask is only needed if your architecture is extremely weird in a way that would have you fighting Django in the core of the app. If you can find a way to wrap the core in Django without letting Django's opinions inside, then still, it probably makes sense to just use Django.
I don't know how hard that is; I haven't done enough real work with Django. But when I tried to write an onion-style app with Flask + extensions, I found the ecosystem's architectural assumptions were still fighting me the way you hear Flask converts talk about their struggles with Django. Some of it was probably my fault, but still.
So if you have a problem Django doesn't want to solve, and that problem can be solved by Flask without extensions, maybe Flask makes sense. But almost certainly you don't.