[joaodlf]

This is probably quite unpopular, seeing as the FastAPI docs have been so praised in the past... but I really dislike how FastAPI is documented, which has really put me off of the project.

The FastAPI docs read like a full project, a very dense project. Sometimes you just want to learn about a specific feature, but you walk into a page that assumes you have the context of the previous chapters, that puts me off a lot.

I also dislike how some of the documentation is absolutely enormous (the SQL chapters is one example), but I suspect this might have to do with the not-so-simple approach FastAPI takes, as opposed to Flask, which is indeed very simple.

I really can't join the crowd here. I don't think FastAPI is a replacement for Flask, even when async is taken out of the equation. Flask has some weird quirks to it (like "g"), but it really is a beautiful and simple API for the web.

[misnome]

I like FastAPI and using it feels nice.

But it could _really_ do with some "Reference" documentation. Sometimes I just want to know exactly what a call does or what the various parameters mean.

[a1445c8b]

I agree. There are generally 4 types of documentation as per the diagram in this page[0] and FastAPI’s solely focuses on the top left quadrant and falls flat on the lower right.

[0] https://documentation.divio.com/

[CharlieDavies]

I agree with you entirely about the issues with the docs, there is no API reference, and Tiangolo has rejected PRs with automated documentation before. I by no means think the project is perfect, but I think it is a better starting point for most small projects. I just don't see any advantage to Flask at this point unless you specifically want to use one of tiny handful of Flask-X packages that are actually worthwhile.

[timojeajea]

One major advantage Flask has over FastAPI is maturity. FastAPI has 1000+ open issues on Github vs 14 for Flask. That is quite scary.

[wdroz]

It's interesting the see the number of open issues of popular python projects:

Pytorch, 8400

Pandas, 3400

Tensorflow, 2100

jupyter notebook, 2000

scikit-learn, 1500

pytest, 720

requests, 170

The outlier seem to be Flask.

[timojeajea]

You picked mainly data science python projects. It would make more sense to compare with other python web frameworks.

django, 1101 open, 32662 closed

cherrypy, 218 open, 1505 closed

starlette, 31 open, 570 closed

pyramid, 70 open, 966 closed

falcon, 168 open, 789 closed

flask, 14 open, 2318 closed

fastapi, 1044 open, 1855 closed

Fast api has one of the worst ratio regarding open/closed issues.

[wdroz]

I wanted to add django but their issues aren't on github as they are using their own system. IMO an external issue tracker lead to a higher barrier to create new issues, so this isn't not necessary fair.

Also fastapi allows people to ask questions with the issues. On the 1000+ open issues, 826 are tagged as question.

It's hard to find a fair metric. Open/close ratio rewards older project with fluctuating/stable popularity. Fastapi popularity is still growing[0], so having some difficulties to work on issues is expected.

[0] -- https://trends.google.com/trends/explore?date=today%205-y&q=...