5 ms·

honest,sincere question: i don't understand why people do this - build these frameworks. it's hundreds of independent labor hours and forgoes the key value pro

honest,sincere question: i don't understand why people do this - build these frameworks. it's hundreds of independent labor hours and forgoes the key value prop of python (or whatever language they're reimplementing the wheel in): the existing ecosystem. i would never use this over flask or django because the community around each of those frameworks. that includes plugins, docs, blog posts, SO posts, etc. further more i'm not going to trust that one shop will exist forever and maintain this framework to the same extent that django is maintained. so in effect by adopting this framework i take on the maintenance responsibility. but why would i ever do that? it's not interesting work (very little groundbreaking research left in the http server space i think), it's thankless, and it's just completely unnecessary - every time i submit a PR i'll be looking enviously at django foundation's latest release. so why would anyone write something like this and why would anyone ever adopt? if you're going for speed without ecosystem then just use Go or Java or C# to begin with. is it just NIH syndrome?

heavenlyblue 8y ago
Simply because any sufficiently old Django app has the same intro curve as any other (possibly customised) framework. Have you actually used Flask, by the way? Or the older version of it called Pyramid? The truth with it is that it's not only complex, but also doesn't prefer any of it's optional components. Any project you'll be building in it is going to be custom anyway.
- piquadrat 8y ago
  > Have you actually used Flask, by the way? Or the older version of it called Pyramid? Flask is in no way related to Pyramid. It came out of an April Fools joke in 2010 (http://lucumr.pocoo.org/2010/4/3/april-1st-post-mortem/ http://lucumr.pocoo.org/2010/4/3/april-1st-post-mortem/). Pyramid, OTOH comes out of the Plone/Zope communities (it used to be known as repoze.bfg).
- tiangolo 8y ago
  Yeah, in fact, up to FastAPI, my main stack was based on Flask with several plug-ins, and I created several project generators with all that. FastAPI learned a lot from many of these tools and techniques.
franey 8y ago
FastAPI extends Starlette, so the developer didn't build an entirely new framework from scratch. Encode, the team that develops Starlette, also develops Django REST Framework. They help make the Python web development ecosystem what it is.
- tiangolo 8y ago
  Exactly! FastAPI inherits a lot from Tom Christie's great work. Even the heaviest inspiration is form APIStar (now "deprecated" as a server). Built by him too.
tiangolo 8y ago
About reinventing the wheel, let me copy my answer from Reddit: Good question. I ask the same questions myself every time. And I avoided creating FastAPI for a long time. I tried a whole lot of tools. And FastAPI got inspiration from a lot of them. A more detailed explanation is here: https://fastapi.tiangolo.com/alternatives/ https://fastapi.tiangolo.com/alternatives/ More details about Flask and Django: About Flask: I created the mosts popular Docker images for Flask. I've been building APIs with Flask for a long time, with several teams, using many of its plug-ins, etc. All that learning was inherited by FastAPI. To reduce development time and effort. About Django: If you are building APIs with Django, chances are you are using Django-REST-Framework. It was built by Tom Christie. He then built APIStar, improving over what Django-REST-Framework could do. Then he had to stop building APIStar to dedicate himself to Starlette, the new super-fast microframework. FastAPI is heavily inspired by APIStar, and based on Starlette. And uses Python type hints even more. About plug-ins: If you refer to plugins to do: authentication, data validation, data serialization, documentation, automatic API docs, compatibility with all SQL and NoSQL, dependency injection, Websockets, Testing, GraphQL... it's all included. Even though it's a mini-framework. Most of the functionality that is normally achieved with plugins is included. Also, it's heavily integrated into the ASGI ecosystem, so, you have plug-ins to handle Django-Channels like Websockets, serverless deployments, Socket-IO, etc. Give it from 5 to 20 minutes. That's enough to decide if you like it or hate it.
linuxftw 8y ago
I wrote a web (WSGI) framework in python because I didn't care for the abstractions of some of the larger ones. It was a good bit of fun, and it was faster than anything else at the time. Much of the speed came from doing less out of the box. Additionally, it didn't attempt to handle any of the actual connection layer. Everything is done via the WSGI interface, which I think is a great abstraction.
- tiangolo 8y ago
  Yep, this is based on Starlette, which does more or less, what you did, but for ASGI.
tomchristie 8y ago
There's a pretty good reason there's a lot of folks building new frameworks for Python in this space right now: async. Unlike WSGI frameworks we're now able to support WebSockets, lightweight backgrounds tasks, super-high-throughput performance, and all sorts of other goodies, that Flask, Django et al. aren't necessarily able to excel in. Good news is that it's pretty likely that some of this may eventually feedback into Django, Flask, and others, but in the meantime it's a case of trying to bring the Python async ecosystem up to feature-parity with existing thread-concurrency frameworks as quickly as we possibly can.
- tiangolo 8y ago
  Thanks for chiming in @tomchristie!

heavenlyblue 8y ago

Simply because any sufficiently old Django app has the same intro curve as any other (possibly customised) framework. Have you actually used Flask, by the way? Or the older version of it called Pyramid? The truth with it is that it's not only complex, but also doesn't prefer any of it's optional components. Any project you'll be building in it is going to be custom anyway.

piquadrat 8y ago
> Have you actually used Flask, by the way? Or the older version of it called Pyramid? Flask is in no way related to Pyramid. It came out of an April Fools joke in 2010 (http://lucumr.pocoo.org/2010/4/3/april-1st-post-mortem/ http://lucumr.pocoo.org/2010/4/3/april-1st-post-mortem/). Pyramid, OTOH comes out of the Plone/Zope communities (it used to be known as repoze.bfg).
tiangolo 8y ago
Yeah, in fact, up to FastAPI, my main stack was based on Flask with several plug-ins, and I created several project generators with all that. FastAPI learned a lot from many of these tools and techniques.

franey 8y ago

FastAPI extends Starlette, so the developer didn't build an entirely new framework from scratch. Encode, the team that develops Starlette, also develops Django REST Framework. They help make the Python web development ecosystem what it is.

tiangolo 8y ago
Exactly! FastAPI inherits a lot from Tom Christie's great work. Even the heaviest inspiration is form APIStar (now "deprecated" as a server). Built by him too.

tiangolo 8y ago

About reinventing the wheel, let me copy my answer from Reddit: Good question. I ask the same questions myself every time. And I avoided creating FastAPI for a long time. I tried a whole lot of tools. And FastAPI got inspiration from a lot of them. A more detailed explanation is here: https://fastapi.tiangolo.com/alternatives/ https://fastapi.tiangolo.com/alternatives/ More details about Flask and Django: About Flask: I created the mosts popular Docker images for Flask. I've been building APIs with Flask for a long time, with several teams, using many of its plug-ins, etc. All that learning was inherited by FastAPI. To reduce development time and effort. About Django: If you are building APIs with Django, chances are you are using Django-REST-Framework. It was built by Tom Christie. He then built APIStar, improving over what Django-REST-Framework could do. Then he had to stop building APIStar to dedicate himself to Starlette, the new super-fast microframework. FastAPI is heavily inspired by APIStar, and based on Starlette. And uses Python type hints even more. About plug-ins: If you refer to plugins to do: authentication, data validation, data serialization, documentation, automatic API docs, compatibility with all SQL and NoSQL, dependency injection, Websockets, Testing, GraphQL... it's all included. Even though it's a mini-framework. Most of the functionality that is normally achieved with plugins is included. Also, it's heavily integrated into the ASGI ecosystem, so, you have plug-ins to handle Django-Channels like Websockets, serverless deployments, Socket-IO, etc. Give it from 5 to 20 minutes. That's enough to decide if you like it or hate it.

linuxftw 8y ago

I wrote a web (WSGI) framework in python because I didn't care for the abstractions of some of the larger ones. It was a good bit of fun, and it was faster than anything else at the time. Much of the speed came from doing less out of the box. Additionally, it didn't attempt to handle any of the actual connection layer. Everything is done via the WSGI interface, which I think is a great abstraction.

tiangolo 8y ago
Yep, this is based on Starlette, which does more or less, what you did, but for ASGI.

tomchristie 8y ago

There's a pretty good reason there's a lot of folks building new frameworks for Python in this space right now: async. Unlike WSGI frameworks we're now able to support WebSockets, lightweight backgrounds tasks, super-high-throughput performance, and all sorts of other goodies, that Flask, Django et al. aren't necessarily able to excel in. Good news is that it's pretty likely that some of this may eventually feedback into Django, Flask, and others, but in the meantime it's a case of trying to bring the Python async ecosystem up to feature-parity with existing thread-concurrency frameworks as quickly as we possibly can.

tiangolo 8y ago
Thanks for chiming in @tomchristie!