Browser Version

Disclaimer: 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 same¹ 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.

¹ 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:

1. This is not tree-shakeable
2. Tools like webpack automatically shim Node globals like process with weak/empty objects. Because of this, the library’s typeof 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) ESModule² format
• "unpkg" – (Browser) UMD format

² 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! 👋

[lukeed]

Now available under the next tag 🎉

npm install httpie@next

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.

[lukeed]

There is now also a fetch mode for browsers & Worker environments. It uses the same httpie options & behaviors, just with fetch under the hood. That said, that means this mode has a different support target – losing a lot of (older) browsers by default but extending httpie to Worker and ServiceWorker contexts.

Still currently only available in the httpie@next release.

import { send } from 'httpie/fetch';

try {
  const res = await send('POST', '/foobar', { msg: 'i work in workers now!' })
  console.log(res.data);
} catch (err) {
  // Any 4xx - 5xx status code
  console.error('Error: ', err);
}

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:

import { send } from 'httpie';

But now, if you want to swap out XHR for fetch()-based mode, you can inject a webpack/Rollup alias that maps httpie to require.resolve('httpie/fetch/index.mjs'). Since the API & usage are identical, nothing in your application code needs to change.