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

The issue names no files or tests; start by reviewing the existing browser implementation and the package.json entry fields described here, then compare resolution in default, Rollup, and webpack configurations. Done would require settling whether the browser build belongs in httpie and defining the Node/browser package behavior.

Written by the indexing model from the issue text.