Why I forked httpx

Original Article ↗ Hacker News Discussion ↗

Name Confusion and Initial Reactions

  • Multiple commenters initially confused httpx with htmx/htmlx, leading to misreading the article.
  • Some express nostalgia for the original httpx and disappointment it hasn’t become a stable, “v1” default HTTP client for Python.

Quality and Behavior of httpx

  • Some see httpx as promising but under-maintained, with long gaps between releases and ignored fixes.
  • Others are strongly critical: API seen as mediocre, performance and configurability as lacking, and maintainer behavior as risky for production (e.g., behavior changes or breakages without clear justification).
  • Specific complaints: thread-safety issues in production, no HTTP/3 support, awkward redirect defaults, and limited multiplexing.

Alternatives: niquests, aiohttp, pyreqwest, others

  • niquests gets repeated praise: perceived as much faster, better HTTP/2+ handling, closer to requests API, and smooth migration from httpx. Some companies report successful production switches.
  • aiohttp is praised as stable and well-established, but criticized for being HTTP/1‑centric and async-only.
  • pyreqwest is plugged as a high-performance client with an httpx compatibility layer and strong benchmarks.
  • Other tools/libraries (curl cffi, httpmorph, httpcloak, etc.) are mentioned in niche crawling contexts.

Forking, Governance, and Maintainer Burnout

  • Many argue that forking is appropriate when critical fixes aren’t released and maintainers block new maintainers while the project is widely depended on.
  • Others emphasize that open-source authors owe no obligations beyond the license; expectations of support or responsiveness are seen as entitlement.
  • A counterview holds that once a project becomes core infrastructure and takes sponsorship, there is at least a moral responsibility to delegate, transition, or communicate.
  • Suggestions include foundations or ecosystem support for key packages, and tools like modshim to layer fixes without full forks.

Python’s HTTP and Stdlib Gaps

  • Broad agreement that Python lacks a “friendly, async-ready, battle-tested” HTTP client in the standard library.
  • Fragmentation is seen as a consequence of HTTP complexity, async/HTTP2/HTTP3 demands, and reluctance to expand the stdlib after past “batteries included” pains.
  • Comparisons to other languages show that many also struggle with ergonomic, comprehensive HTTP clients.

Security, Naming, and Drama

  • Some worry the forked library could become a supply-chain target as it grows.
  • Mild concern about potentially confusing, near-identical naming vs. trademark issues; others note the name is generic and no clear trademark is evident.
  • Related project drama (around other Python HTTP/framework tools and MkDocs) is cited as part of a broader pattern of governance and interpersonal conflict in popular Python infrastructure.