Improve README with the differentiators from other HTTP clients

[sethmlarson]

See: https://twitter.com/cooperlees/status/1161466340286185472

We're doing awesome things, we should make sure users know why they should use our library. :)

[fbidu]

Do you think it would be better to provide something like a comparison table or some code samples right on the readme comparing the alternatives?

[sethmlarson]

Would be nice to answer the question "Why HTTPX versus A, B, or C?" better in the README. Even if it's just a small section.

[lovelydinosaur]

Copying this from https://github.com/encode/httpx/issues/1216 so that we've got some better context here...

The notable candidates here are requests, urllib3, aiohttp, and asks.

• https://requests.readthedocs.io/en/master/
• https://urllib3.readthedocs.io/en/latest/
• https://docs.aiohttp.org/en/stable/client.html
• https://github.com/theelous3/asks

Main headliners here for HTTPX are...

• Supports HTTP/1.1 &* HTTP/2
• Supports both synchronous and async I/O
• Supports alternate async backends besides asyncio (trio, and soon curio)
• Supports calling into ASGI and WSGI applications without I/O
• Designed for compatibility with requests, with a docs section outlining any points where the API differs.

(And some other stuff that's out on the horizon, too)

They're not the same project because we were approaching a whole bunch of complex areas (such as how to build an HTTP client that supports both sync + async usages) that needed a clean slate, and the freedom to iterate on the design.

However we've put a stack of effort into making sure that the low-level transport layer is really tightly spec'ed as a standalone package - httpcore. Something we'd be very interested in would be figuring out with other projects if there's any mileage in figuring out if their clients would be able to use httpcore as their transport layer. In order to:

• Bring HTTP/2 support to those projects, with less effort than would otherwise be required.
• Be able to consolidate our efforts on the core networking layer, while still being able to provide different client libraries on top of that, and not break API for existing users.

We've not really reached out to folks about that yet since we've been focusing on getting to a 1.0 release first, but it might be an area worth exploring.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[lovelydinosaur]

Still valid thx, @stale bot.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.