Skip to content

Improve README with the differentiators from other HTTP clients #207

Closed

Description

@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. :)

Activity

  1. fbidu commented on Aug 14, 2019

    @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?

  2. sethmlarson commented on Aug 15, 2019

    @sethmlarson
    ContributorAuthor

    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.

  3. added this to the v1.0 milestone on Sep 15, 2019
  4. removed this from the v1.0 milestone on May 17, 2020
  5. lovelydinosaur commented on Aug 25, 2020

    @lovelydinosaur
    Member

    Copying this from #1216 so that we've got some better context here...

    The notable candidates here are requests, urllib3, aiohttp, and 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.

  6. stale commented on Feb 20, 2022

    @stale

    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.

  7. lovelydinosaur commented on Feb 21, 2022

    @lovelydinosaur
    Member

    Still valid thx, @Stale bot.

  8. stale commented on Mar 25, 2022

    @stale

    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.

  9. stale commented on Oct 15, 2022

    @stale

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    docsChanges to the documentationwontfix

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions