The future of Flask

Flask turned 10 in 2020.

Unlike previous years, 2020 has seen major changes to the Python web framework ecosystem, with the release of a new Django version that provides significant async support, and the rise of FastAPI as a contender for the best Python microframework title.

As a result of this, Flask's popularity has taken a hit, at least in Europe, but I'd bet the US market is experiencing something similar. Django recently surpassed Flask as the Python web framework with the most stars on Github after struggling to keep up for years, and it currently has almost 1000 more stars. Both Django and FastAPI are growing faster in popularity, with FastAPI seeing some explosive growth.

It's hard to expect Flask itself to change as an answer to this. Its goal is to be minimal and stable, and it does that well. However, it seems that if Flask wants to still be a marketable technology in 3 or 4 years, it has to be improved in some way.

What do you think that Flask needs to still be a hot framework in the long run? In my opinion getting an async API would be a huge improvement.

13 thoughts on “The future of Flask”

  1. Something to consider is why people choose to use Flask in the first place.

    Number one: it’s lightweight and highly customisable. I actually believe in this day and age that gives Flask a real differentiator between Django for projects that don’t want or need the full capabilites of a heavyweight framework. I’d say this is especially true for APIs connecting to frontend frameworks. A lot of the functionality of a more advanced framework are wasted when you’re segmenting your front and back end.

    Taking this a step further, being light and easy to deploy is great for things like ML model deployment, where, again, you don’t need or want an extensive framework to essentially host a couple of backend processes.

    Number two: use case. I’ve looked at FastAPI and it would be good to try it out. For pure speed or async behaviour, we do need to question if a python API is the way forward. Node and Golang seem to be extremely popular for server side components that are all about speed and so you’ve got to consider that, for those folks where pure performance is what they need, they might not choose Python as the language in the first place.

    Number three: documentation and age. So final point is that, if you’re set on a python backend, and you want to decide on a framework, Django and Flask have you covered on a whole TON of documentation, examples, tutorials and extensions that have been tried and tested. If you start a personal project, fine, try cool new stuff, but I think a lot of major projects will still look to deploy on technologies that have a deep community base and a proven track record.

    Tldr: Flask is better for some projects than Django, Flask and Django will still attract users because of them being proven technologies, if you want pure speed, maybe don’t use Python.

  2. In my experience Flask is primarily used in a micro services architecture, or as the API for backend data science functions. Definitely worth sticking with it if you see yourself in these environments.

  3. I was about to post a whole essay about how Flask and Django will go the way of the dodo in the coming decade but to be honest, I have no idea what’s going to happen.

    Flask and Django are good at what they were designed for. But at the same time, what they were designed for–web dev–has changed a lot over the past decade and both projects haven’t really seen radical changes in that period. We’ve seen the advent of microservice architectures, REST APIs, NoSQL databases, feature-rich frontend JS frameworks and asynchronous backends. These things are *everywhere* and trying to adapt Flask/Django to that always feels tacked on and you will always have vestigial components like template rendering and Django’s ORM that you simply cannot remove. We’ve also seen the rise of new frameworks and entirely new languages that were born from that ecosystem and do it natively.

    Then again, things might change again. Maybe monolithic architectures will become the bee’s knees again, maybe people will rediscover the value of relational databases. Who knows. I’m fine with anything as long as we don’t go back to things like ASP/JSP.

  4. FastAPI seems promising, but the extensions and tools are not yet mature. The references are also a bit limited at the moment, in case you stumble on roadblocks. I’ve checked fastapi-utils but it doesn’t feel like it’s there yet. Maybe give it a couple of 3-5yrs more.

    For flask, i think embracing ASGI should be a roadmap. My hunch is phoenix-liveview and blazor would be the next big thing. If flask has this, it would really be huge advantage.

  5. async and docs

    fastapi is unparalleled when it comes to code-first approach. you develop the api, you have state of the art documentation for free. but that means you need to bring all metadata to the interface.

  6. I’ve never understood ‘Github stars’ as a measure of popularity or even usage. I ‘star’ things on Github/Bitbucket all the time—but rarely use any of them. It’s just a ‘this sounds interesting, I’ll take a look later’. Or maybe I filed a defect and am following the thread.

    So few people that actually use tools like Flask care about these bizarre ‘popularity’ measures. It’s like measuring what people wear by looking at how many like a Kardashian fashion tweet has.

  7. I started with flask, but few months in I a moved to fastAPI. Been new to python/programming fastAPI just seemed a better option for me and was simple to get setup.

    The learning curve was getting started with react and JS for a front end but after many months things are starting to come together.

    Though I’ll definitely give it to flask as a great framework.

  8. well i can say for most of the python web projects im working on FastAPI is just used for the API end points and flask for every thing else
    it would be nice it flask blueprint system worked a bit more like FastAPI’s router where you can have nested and i dont know if you can do this in flask but in fast API you can mount any wsgi app made in python to it

  9. > and the rise of FastAPI as a contender for the best Python microframework title.

    Are these tools even comparable?

    I never heard of FastAPI until you mentioned it but going by their documentation it’s for building APIs and not everyone is building APIs with a SPA front-end, therefore there’s plenty of reasons to stick with Flask.

    I know I’m super happy building server rendered template driven apps while sprinkling in JS as needed. This strategy can go a long ways and it’s a proven model that works for both small and large apps.


Leave a Comment