jkbr

6 ms·

1.
Is the decline of reading poisoning our politics?(vox.com)
4 points by jkbr 1y ago|0 comments
2.
by jkbr 2y ago
Please see my reply here: https://news.ycombinator.com/item?id=41337485
3.
by jkbr 2y ago
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
4.
by jkbr 2y ago
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 l
5.
by jkbr 3y ago
Thanks!
6.
by jkbr 3y ago
Gotcha. Would you mind checking if you happen to have PyOpenSSL installed inside the Python environment HTTPie runs from?
7.
by jkbr 3y ago
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
8.
by jkbr 3y ago
Whoever posted it thought otherwise.
9.
by jkbr 3y ago
Are you the @prmoustache on GitHub with zero public repos?
10.
by jkbr 3y ago
> 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
11.
by jkbr 3y ago
As the first paragraph in the README says, we use the GitHub repo to host releases and issues.
12.
by jkbr 3y ago
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.
13.
by jkbr 3y ago
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 ch
14.
by jkbr 3y ago
> 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 o
15.
by jkbr 3y ago
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 exis
16.
by jkbr 3y ago
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&#x
17.
by jkbr 3y ago
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,
18.
by jkbr 3y ago
> 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, t
19.
by jkbr 3y ago
It’s a good idea — we’ll look into making it as simple as in HTTPie CLI. Thanks for the feedback.
20.
by jkbr 3y ago
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.
21.
by jkbr 3y ago
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 comman
22.
by jkbr 3y ago
> 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
23.
by jkbr 3y ago
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.)
24.
by jkbr 3y ago
> 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 somewh
25.
by jkbr 3y ago
Once the codebase and architecture stabilize, we’ll likely open source HTTPie Desktop too.
26.
by jkbr 4y ago
> 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.
27.
by jkbr 4y ago
Here’s how we do it: https://httpie.io/blog/changelog-0017#data-security
28.
by jkbr 5y ago
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&#x2
29.
by jkbr 5y ago
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:&#x2
30.
by jkbr 5y ago
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 wi

More ›