Browser Version
See original GitHub issueDisclaimer: The browser implementation is already done! I’m just deciding if it should be a part of httpie or be its own thing.
Should httpie
offer a browser implementation? I’ve received the request a few times already & have also seen some people try to use httpie
in the browser.
Unfortunately, if you do try to do that right now, it technically will work in a webpack setting, but it will only be because webpack injected multiple kBs worth of shims & polyfills 😱 That kinda defeats the point & needs fixing IMO.
So – again, should httpie
offer a browser implementation of itself? The API would be the same1 and would operate a lot like axios
, meaning that browser builds get the browser copy, and node builds get the Node.js version of axios
– all without changes needed from the dev.
1 some options will need to be different across versions
Details:
Most libraries will do a “runtime check” and load a version on the condition of something like process
being defined or not. This poses two major problems:
- This is not tree-shakeable
- Tools like webpack automatically shim Node globals like
process
with weak/empty objects. Because of this, the library’stypeof process === 'undefined' ? BROWSER : NODE
will not behave as expected.
To get around this, we’d have to make use of package.json
entry fields. While not a perfect system, most (all?) build tools have agreed on some standard keys, allowing `httpie to do the following:
"main"
– (Node) CommonJS format"module"
– (Node) ESModule format"browser"
– (Browser) ESModule2 format"unpkg"
– (Browser) UMD format
2 Now, as far as I can tell, there’s no rule nor standard as to what format the
"browser"
entry should be. Typically (and historically) this has been CommonJS format because that’s all JavaScript had. However, with the advent of ESM, webpack and Rollup actually accept ESM files through that entry point. I anticipated that only"module"
fields “unlocked” ESM parsing, but this was happily NOT the case! 🎉
The above allows Node and Browser environments to grab the appropriate files, with the added benefit of kicking off an unpkg.com access.
I’ve verified that the 4 entries resolve successfully in default and/or the most basic Rollup and webpack configurations. Absolutely nothing special was needed to make this happen!
PROs
- No accidental/broken browser usage
- No webpack shims & polyfills
- No extra client-side library for HTTP requests
- Same HTTP library API for clients & servers
- Browser version will be under 500 bytes
- Browser-
httpie
becomes accessible via unpkg.com
CONs
- Some
httpie
options will need to be different in Node vs Browser - Some
httpie
options will only work in Node and/or Browser - Browser builds will require
unpkg.com
link or FE tooling (Webpack, Rollup)
Please leave thoughts/comments below – I’d like to make this happen ASAP one way or another.
Thanks! 👋
Issue Analytics
- State:
- Created 5 years ago
- Reactions:8
- Comments:15 (7 by maintainers)
Top GitHub Comments
Now available under the
next
tag 🎉You should be able to just use it normally across any browser/server in any app. I’ve tested it with unconfigured webpack & basic Rollup setups. As this issue initially describes, the “browser” field outranks the “module” field, allowing you to get the correct version of
httpie
.There’s only a slight difference with how
timeout
behaves. I mentioned this discrepancy in #17 but so far there are mixed/unknown feelings about it. Maybe this will help us decide.There is now also a
fetch
mode for browsers & Worker environments. It uses the samehttpie
options & behaviors, just withfetch
under the hood. That said, that means this mode has a different support target – losing a lot of (older) browsers by default but extendinghttpie
to Worker and ServiceWorker contexts.Still currently only available in the
httpie@next
release.It’s still easy to maintain isomorphic/universal usage thru your bundler.
By default, you get the XHR version on browsers and the Node.js version in Node:
But now, if you want to swap out XHR for
fetch()
-based mode, you can inject a webpack/Rollup alias that mapshttpie
torequire.resolve('httpie/fetch/index.mjs')
. Since the API & usage are identical, nothing in your application code needs to change.