jkbr

Please see my reply here: https://news.ycombinator.com/item?id=41337485

What is it that makes the web documentation atrocious in your view?

As for man pages, HTTPie has been shipping them since v3.2 [1].

Try `man http` or `http --manual`.

[1] https://httpie.io/blog/httpie-3.2.0#man-pages

HTTPie creator here. Just a clarification: HTTPie is still under the same management, and the CLI doesn’t have any telemetry. Little Snitch is probably warning you about requests to packages.httpie.io/latest.json [0]. That is done to let you know when a new version becomes available. It’s a static file hosted through GitHub pages [1] without any tracking. However, there’s currently a bug [2] that prevents the response from getting cached so that the request fires frequently for some users. It’s already fixed in a PR [3] and will be part of the upcoming release.

[0] https://github.com/httpie/cli/blob/master/httpie/internal/up...

[1] https://github.com/httpie/packages.httpie.io/blob/master/lat...

[2] https://github.com/httpie/cli/issues/1527

[3] https://github.com/httpie/cli/pull/1531

Thanks!

Gotcha. Would you mind checking if you happen to have PyOpenSSL installed inside the Python environment HTTPie runs from?

I don’t know when you last tested the start-up time, but we significantly improved it in HTTPie CLI 3.0 [0]. Now it’s still slower by ~0.1s.

    $ time http --version
    3.2.2

    real 0m0.113s
    user 0m0.087s
    sys 0m0.020s



    $ time xh --version
    xh 0.18.0
    -native-tls +rustls

    real 0m0.007s
    user 0m0.002s
    sys 0m0.002s

[0] https://httpie.io/blog/httpie-3.0.0#speed-ups

Whoever posted it thought otherwise.

Are you the @prmoustache on GitHub with zero public repos?

> Why is the license for this GUI tool so different than the license for their command line tool? The source isn’t even in this repository.

The desktop app is not ready to be open-sourced yet.

> There is 0% chance that this will avoid the route that POSTman and Insomnia have paved.

HTTPie has been around for 10+ years, and the new desktop product is built around the idea that we can do much better than the incumbents (from a much simpler interface and more pleasant UX to a more aligned set of incentives supporting incognito, free, as well as paying users/companies).

> WTF is it about these tools that the creators think will make us tolerate the sudden switch from free to paid? I am dead tired of watching this play out over and over.

What Postman and Insomnia did is not cool. But that does not mean it’s unavoidable. Even though it complicates development, we’re local-first from the very start. Accounts and sync are optional layers on top of it.

As the first paragraph in the README says, we use the GitHub repo to host releases and issues.

We have a PoC where the runtime is implemented in Python and the Electron and web apps use it through https://pyodide.org/. Still exploring but looks surprisingly viable.

We started httpie/desktop as a separate codebase but are working on unifying it with httpie/cli and our cloud to avoid multiple implementations by extracting a shared runtime that will be used everywhere. One of the interesting challenges here is that HTTPie Desktop is written in TypeScript while the rest is in Python.

> I think the issue is the posturing as open source, having a github repo with no code just to attract devs and look open source-y

As the first paragraph in the README says, we use the GitHub repo to host releases and issues.

Having it on GitHub under the same organization as our other projects that already are open-source is convenient for both us and our users — https://github.com/httpie.

> and even sharing it on HackerNews right after the issues with closed source by Postman too. Feels like an "open source alternative", but not really, hence the sketchy accusation.

The person who shared it is not related to HTTPie.

Given the quality of the discourse here, I almost wish they did not! ;-)

Yes, an Electron app is worse than a native app. An Electron app is also infinitely better then no app.

It's a trade-off.

Without Electron and the likes, a fraction of the apps that are now almost effortlessly cross-platform would exist for Linux, for example.

You probably don't need all of them. But we've created HTTPie Desktop based on the feedback of HTTPie CLI users over the past decade who wanted to have the same comfort on the desktop as they do in the terminal. The feedback we've been receiving from devs actually using has been incredible.

Hi Daan,

>> not open-source yet

> Can you be more clear? Is the Desktop app going to be open-source in the future? If so, what license?

Yes, but have no ETA or license choice yet.

> Do you intend to monetize this product? If so, how?

Yes. We strongly believe in a freemium where both free and premium users are happy. We’ll primarily monetize collaboration and enterprise features without cannibalizing free users. In this sense, we’re inspired by companies like GitHub or Figma. And in our case, free also includes users without an account.

> As a side note: I find it strange that you feel the product is not stable enough to share the code, but apparently stable enough to share the product itself.

Running an open-source project well is not easy and takes resources. Building a great product is hard on its own. Our primary goal is to design and build the best API product possible, so we direct all our energy there for now.

> You gave this exact same answer to me in your Discord a year ago. If nothing sketchy is going on why not just open source the thing?

We appreciate your interest, but we never gave an ETA. I do regret having made the intention public, though.

> At a minimum you should remove the banner at the bottom of the page claiming it's open source.

That’s a good point. As I wrote in another comment below: I’ve now updated the website template not to show the image with the slogan on this page. Thanks for the feedback.

It’s a good idea — we’ll look into making it as simple as in HTTPie CLI. Thanks for the feedback.

That’s a good point. I’ve now updated the website template not to show the image with the slogan on this page. Thanks for the feedback.

We show the request/response in two separate panes, each with a menu offering Copy and Download actions. So it’s possible; it’s just a matter of multiple clicks.

The desktop app also allows you to copy a corresponding HTTPie CLI command, which you can then enrich with --verbose, run in the terminal, and more easily copy the whole exchange output.

> There seems to be lack of a single word in English to describe this except the long phrase above. Anyone has good suggestion?

If you mean the request and response message pair, we call it "exchange" [0].

> It goes without saying that this is a hard requirement I have for any API client but sadly most ones I tried always lack some information somewhere.

Both HTTPie Desktop and HTTPie CLI allow you to see the entire exchange. In the CLI, you can use the --verbose flag [0]. In the desktop app, there’s a “Request” tab.

They both also support previewing the request without sending it. The CLI has --offline [1], and the Desktop has a live preview feature [2].

[0] https://httpie.io/docs/cli/what-parts-of-the-http-exchange-s...

[1] https://httpie.io/docs/cli/offline-mode

[2] https://raw.githubusercontent.com/httpie/desktop/master/.git...

As the first paragraph in the README says, we use the GitHub repo to host releases and issues.

(It’s not open-source yet as we first want to get the product, architecture, and codebase somewhat stable.)

> closed source (despite their website proudly claiming "Open source")

HTTPie CLI has been open-source for a decade. HTTPie Desktop has yet to be open-sourced. We first want to get the product, architecture, and codebase somewhat stable. As the README says, we use the GitHub repo to host releases and issues.

Once the codebase and architecture stabilize, we’ll likely open source HTTPie Desktop too.

> are there other sites that this extension should support?

Figma comes to mind. Perhaps the best approach would be to allow the user to define additional auto-close rules manually.

Here’s how we do it: https://httpie.io/blog/changelog-0017#data-security

We did look at `jo`, and also `jarg`[0], the W3C HTML JSON form syntax[1], and pretty much every other approach we could find. We had quite a few requirements that the new nested syntax had to meet: be simple/flexible, easy to read/write, backward/forward compatible, and play well with the rest of the HTTPie request language.

The final syntax is heavily inspired by the HTML JSON forms one. But we made it stricter, added type safety, and some other features. It also supports all the existing functionality like embedding raw JSON strings and JSON/text files by paths.

The final implementation[2] is completely custom. We have plans to ship it as a standalone tool as well, publish the test suite in a language-independent format and write a formal spec so that other tools can easily adopt it. This spec will eventually be a subset of one for the overall HTTPie request language, which is currently tied to our CLI implementation but we want to decouple it.

Happy to hear you like the desktop app!

[0] https://github.com/jdp/jarg

[1] https://www.w3.org/TR/html-json-forms/

[2] https://github.com/httpie/httpie/blob/master/httpie/cli/nest... — this is the path parser

HTTPie creator here. We’ve recently[0] added support for nested JSON[1] to the HTTPie request language, so you can now craft complex JSON request directly:

  $ http pie.dev/post test[a]=b test[c][e]:=3 test[l][]:=1

[0] https://httpie.io/blog/httpie-3.0.0

[1] https://httpie.io/docs/cli/nested-json

HTTPie founder here. These are valid concerns. There are two parts to this: 1/ What happens with HTTPie for Terminal, and 2/ how HTTPie for Web & Desktop and the overall platform will look like.

1/ HTTPie for Terminal will always be open-source and obviously free. The difference is that now we’re able to pay a talented developer to work on the project full-time (the recent 3.0 release is a result of that).

2/ We’re building a new platform with the same principles that made HTTPie for Terminal successful in mind: uncompromising simplicity, focus on productivity, and delightful user experience. We’re in the same space as Postman, but the idea is to be anything like. We’re striving to become what Linear is to Jira, Vercel to AWS, Figma to Adobe, etc. That is, to offer a much simpler and more focused product. Premium services for companies will be a natural extension of the single-player mode, and all incentives will be aligned in a way that doesn’t cannibalize the core experience.

HTTPie for Web & Desktop is in private beta. We’re shipping updates weekly and inviting people from the waitlist every day. As soon as we’ve tackled the few remaining things on our roadmap and polished some rough edges, it’ll become publicly available.