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.
Good to know, however updates are a job for my package manager. Imagine dig or awk phoning home for updates? I could see a flag to ask for it specifically.
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
Not for me. Printing HTTPie's version takes longer than to finish a real http request with xh. I suspect it's because I'm testing it on a relatively old server where the differences are even more pronounced.
[link redacted]
I'm using HTTPie 3.2.1 because Arch doesn't have the latest version available but based on the release notes that shouldn't make a difference.
> 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.
I understand why/how you use GitHub, but I don't understand linking to an empty repo from a HackerNews post. The product home page would have worked better.
We did multi platform apps when we still called them programs. We used some cross platform toolkits with either cross platform UIs that felt out of place everywhere or a layer that hooked to a common subset of the native ones, with maybe an option to go really native. We wrote C or C++, mostly.
Then HTML became that common subset of the UI and the browser JS runtime and rendering engine replaced the cross platform toolkit. Bloated, not optimized for space and time as it could be, etc, but very convenient.
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.
> 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].
Thanks for the response. Does the client (desktop app) support exporting the full exchange as txt? I would switch to HTTPie Desktop if this is supported.
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.
Thanks. So it is the same amount of steps as I have for Chrome now.
Please do consider adding a feature to export everything in one shot. It would save people like me a lot of clicks (for a lot of APIs across different environments).
at this page, https://httpie.io/desktop, there's a logo that says "open sores, open hearted, open minded." it's misleading, then. at least remove that part in the page.
Can you be more clear? Is the Desktop app going to be open-source in the future? If so, what license?
Do you intend to monetize this product? If so, how?
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.
> 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.
