Browser Version

[lukeed]

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

[armandabric]

• Some httpie options will need to be different in Node vs Browser
• Some httpie options will only work in Node and/or Browser

Can you be more precise on the difference between the node and the browser version?

Thanks for this post, I was interested in using httpie in the browser, but I will wait a little 😸

[lukeed]

@Spy-Seth Right now, it only looks like opts.redirect will be different across builds. While the server can perform (or not perform) a redirect, the underlying XHR request in the browser version can only follow redirects.

[paulocoghi]

Considering the high efficiency of your libraries, more than good, it would be awesome to have a browser version of httpie.

[paulocoghi]

And it would be the default http client on my (to be completed and announced) open source framework.

[paulocoghi]

I like a lot the way you work, and it is very similar to the way that *NIX systems works: very small and extremely efficient libraries that, together, can help you do almost everything. With excellence.

It's far more easy to maintain various single-purpose libraries that are the best on what they do, instead of maintain a huge general-purpose big library.

For this reason I will try to split my framework into small single-purpose parts before publishing because, unfortunately, it grew a lot.

[lukeed]

Thank you for the kind words @paulocoghi 🙌 I agree, so much easier to use (and replace) small modules that are easily understood.

Also, there's nothing with growth! Growth is what you want. The trick is to grow in an organized (possibly modular) and maintainable way.

As for the browser version of httpie, it's already done. I've been using it personally for a while and just haven't got around to publishing it. I will when I get home

[endel]

please, browser version, please! 😊

[endel]

@lukeed do you have an update on this? I'm going to need this pretty soon, would appreciate if you can manage to publish a browser version of this! Don't worry if you feel it's not feature complete, the community is here to help! :D

[lukeed]

@endel I'll release a @next version tonight :)

[endel]

Thanks @lukeed, I'll test as soon as you release it :)

[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]

For those of you trying out the browser/next version, please do let me know how (or if, lol) it's working for you. The @next phase is basically a rc – collectively feedback before cutting a new 2.0 stable

[endel]

So far so good @lukeed! 👏

I've just tried sending a PUT request with body arguments, and Chrome is throwing me this error: (requests is sent and response is received tho)

Refused to set unsafe header "content-length"

I think browsers add this header automatically.