question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

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

  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) 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:open
  • Created 5 years ago
  • Reactions:8
  • Comments:15 (7 by maintainers)

github_iconTop GitHub Comments

6reactions
lukeedcommented, May 22, 2019

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.

5reactions
lukeedcommented, Feb 5, 2020

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.

Read more comments on GitHub >

github_iconTop Results From Across the Web

What browser? My browser? Is my browser out of date?
This website saves you all the complicated steps to figuring out what versions of software you have, what features you have enabled &...
Read more >
What browser am I using?
Your browser is a software application that lets you visit web pages on the Internet. Popular browsers include Google Chrome, Firefox, Safari, and...
Read more >
Overview of (almost all) major browsers - Browser-Update.org
Overview of (almost all) major browsers ; Chrome, Google, 108.0 ; Opera, Opera Software, 93.0.4585.37 ; Safari, Apple, 15.6 ; Yandex Browser, Yandex,...
Read more >
How to Find the Version of an Internet Browser - Computer Hope
Use the Computer Hope System information online tool to view your browser version, plugin versions, and more. Google Chrome; Mozilla Firefox ...
Read more >
Browser Check - Update my Browser
Detect your current browser and checks if it is up to date. Provides site owners with an easy widget to inform visitors of...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found