Top 5 Python web frameworks to know
There are plenty of Python web frameworks on public repositories. Yet, if you ask even a seasoned Python developer, they would probably only be able to name a few frameworks they’ve heard about and even less they’ve actually worked with. Why is that?
Python is extremely popular these days so no wonder that you can find a lot of frameworks: from the relatively small to truly large, from those which are commonly known to those which never escaped their 0.0.1 release and are used only by a handful of people.
The question is, which of them are worth checking out? Which ones are stable, reliable and properly tested?
First candidate: Django
Django has been among us since July 2005, but prior to that, it had internal releases - when it was first pushed out to the public, it was number 8825. While I’m writing this article, It has over 40k GitHub stars and over 30,000 commits, developed by almost 2,000 authors. Actually, those stats are growing each day, so the next time you look at them, they will be much higher. Why is Django so popular? Most likely because of the low entry barriers.
There are a few factors that have helped Django gain such popularity. Many of them are common to all Python web frameworks, like the fact that Python is a language that is extremely easy to learn. It has, of course, some quirks that not everyone might like, such as being very rigorous with indentation or “magic methods”. But is this even applicable to Django? And if not, how could that be?
From one perspective, Django is settled deeply in the Python language. But just like Python itself, it is a framework that follows a philosophy of being a “batteries-included” tool. This means that if by some chance your needs are similar to very common web programming demands, writing code feels like writing configuration to classes and functions that are already set up.
Django - what has changed for better
Django is good for rapid development of applications, but “rapid development” can be used to describe the growth of Django itself. Its 2.2 release was made public April 1, 2019 and since then we have had a few minor versions with a lot of bug fixes (it doesn’t mean that there are a lot of bugs in Django, more that it’s not an abandoned project and it still has a lot of developer attention), and the previous major release was in August 2018.
Since the early versions of Django, web development has become easier with:
- simplified URL routes,
- tremendous improvement through introducing window expression for our databases,
- subquery expressions,
- template-based widget rendering,
- additional permissions for users that can be managed from the admin site,
…and many more.
What still needs to be done in Django
As mentioned earlier, Django follows a “batteries-included” paradigm. Of course, such an approach has both pros and cons. No one can ignore the fact that living inside Django is like living inside a conglomerate of cities. They are tightly coupled, they serve a greater purpose and overall, they are altogether pretty consistent. But the learning curve for a whole package is steep, because of the number of pieces that add up to the whole Django environment.
And yes, some pieces of the system can be replaced, but everything seems to be easier as long as you follow “the path”: Django ORM as ORM, DRF as rest framework, generic classes for generic purpose views. Do we need to change anything?
Supposedly, it would be beneficial to have Django components more loosely coupled and more easily replaceable. It’s mostly a matter of well-defined and predictable API. Django seems to be almost there, but the size of the whole project makes it harder to apply some immediate solutions and every change in the Django ecosystem is a process.
Flask: microframework for those with micro needs
Everyone has heard of microservices architecture. It is a project architecture style standing in opposition to those monolithic applications that are hard to maintain and have long and self-blocking deployment cycles, disallowing different developers from working on different parts of the whole system.
Flask is a web framework that has established its position on the market almost as well as Django. It was considered a great option for learning the principles of REST architecture, even though it doesn’t require REST at all. Also, despite being a micro-framework, it’s not per-se micro-service oriented (the bigger paradigm gets outside of the brackets of HTTP-oriented web services). Can you grow with Flask? Yes, in fact it’s even mentioned on the project’s main site by the framework authors.
What is Flask good for then? Just like Django, it’s great for rapid development, but there is an area where Flask really shines: prototyping and developing prototypes further.
A hello world app is as simple as:
from flask import Flask app = Flask(**name**) @app.route("/") def hello(): return "Hello World!"
What is even more important is that the whole ecosystem of Flask-oriented libraries can be used to develop successful applications in a modern way, according to the best design patterns and practices. Flask RESTful, flask-sqlalchemy, flask-cors, flask-heroku, flask-rest-jsonapi, and many, many more from the list of curated extensions meet all possible needs for professional web services.
A project in Flask can even be as complex as one created in Django, but Flask has a major difference to Django: Flask is minimal and relies on the experience of a professional developer who is able to choose its toolset on their own.
Does Flask still have anyone’s attention?
Yes and no. Many professional teams still use Flask for building microservices or small apps. For sure, there are still companies that invest their time in building applications or libraries on top of Flask’s web app abilities.
But looking at the release notes, there’s not much fuss around it, speaking euphemistically. Is that a bad thing? We need to keep in mind that Flask is minimalistic and always will be. For that kind of project it’s not that necessary to have a big community of developers around the core project itself - but it’s surely important to have a community of people creating various extensions for it - which is exactly the thing that is happening with Flask now.
Falcon: Unburdening APIs for over 6.16 x 10**(-2) centuries
It is said that a good developer is a person who doesn’t necessarily know popular frameworks, but knows different paradigms, good practices and perspectives, and is able to apply them accordingly to the situation - choosing the “correct” solution, or to put it better: the “optimal”.
If we’re looking for community support and stable releases, Django is a good option. When creating microservices, Flask might come to our mind first. But what if we’re seeking speed and the ability to service many requests in a short period of time? Is Python even applicable in such cases?
Python is a programming language, but to be more accurate, it’s a concept described formally by a language that might be implemented in many ways. Speaking of Python, most of the time we’re thinking about CPython, the core implementation of this language that establishes many of the standards and gives the direction of further development for the language. But there are many other implementations that beat CPython on different fields.
One of them is Cython - a Python language implementation that compiles to C. A natural-born-killer in terms of speed.
Are you looking for a C-compiled web framework? Consider using Falcon. It’s relatively young, it’s definitely REST-oriented and it is very easy to develop with.
In a way, Falcon is similar to Flask. It’s lightweight, not as complex as Django and is good for developing smaller apps. The documentation is a little worse than Flask, but there are some examples that help to start development.
There are plenty of articles on the Internet comparing Falcon to Flask. Some in favor of Falcon, some pointing out that there’s no big difference between the two.
Fun Falcon fact: there is a PHP framework which has been quite popular over the last few years with an extremely similar name: Phalcon PHP.
Sanic: when async/await comes to the table
In the last few years, the Python world has been transformed due to the introduction of async/await syntax and the unbelievable popularity explosion of asynchronous programming.
The whole idea is not entirely new but is now somehow trendy, and has created many changes to the Python language and underlying implementation. Based on the idea of generators, coroutines have been wrapped with the gears of Python, introducing a completely new syntax for context managers, functions, methods and all pieces of code that can be non-blocking. It has influenced the Python ecosystem so much, as seen in the growing popularity of the async version of popular libraries: db connectors, http clients, and… web frameworks.
Sanic is an example of this movement. A lightweight, Flask-like library based on uvloop (more on uvloop here), that supports async/await syntax and modern Python versions.
This time, the documentation is huge. Maybe it’s not comparable to Django’s docs, but it’s far better than any other competitor. We can learn about installing Sanic, logging, routing, versioning, blueprints, static files and middlewares simply from the documentation. Code samples are included in each section: probably one of the best things to include in documentation.
Is Sanic worth trying? Looking at its growing popularity, definitely: almost 13k GitHub stars, over 1,000 forks and a growing number of authors speak to its popularity and that amount of attention guarantees that it won’t vanish unexpectedly.
Fifth player: do we know him?
From one perspective, it’s not easy to pick the top five web frameworks to know. Being lazy, we can always choose popular ones, keeping in mind that popularity, once obtained, never fades quickly and probably those frameworks which are popular today will still be popular in a few years from now.
But the IT world isn’t frozen. It’s filled with curious people always looking for an innovation and a better and smarter way of doing things.
Looking for promising frameworks for the next few years, there are a couple of choices more vibrant or visible than others. Personally, I’m still really looking forward to Vibora, which was gaining traction a while ago.
Looking at the other available “steady players” on the market, I would go with few “honorable mentions”: Tornado, Pyramid (previously known as Pylons) and Bottle. Each of these has its own group of people still interested in the development of a well-known project, as well as a community of people ready to use them in production.
The decision - which one is best? - is strictly related to the purpose of your upcoming project - this should always be taken into consideration at the very beginning of developing anything - but it’s always worth learning something new.