Hoppscotch: Open source alternative to Postman / Insomnia | Hacker News Reader

Hoppscotch: Open source alternative to Postman / Insomnia

github.com

177 pointsthe_arun126 comments

Without sounding like every other developer who hates on electron, I would really appreciate an http client with a Gui that was lighter, like iced or slint.

I appreciate the versatility of electron and it giving us beautiful and usable apps but I have 16 GB of ram, I can't upgrade it and I genuinely have multi second hangs after I have 3 instances of VSCode, Firefox and Chrome open along with Bruno.

Bruno is nice because unlike postman all the calls are defined in files that you can add to the git of your project.

Only thing I don't like about Bruno is that you cannot generate a documentation from your api call tests.

Are there non-binary versions of Bruno?

https://github.com/usebruno/bruno has the source code. It's a node app so i guess by binary you mean a way to run it without the normal electron wrapper? You should be able to run it standalone though i've never tried it outside it's normal distribution method.

Bruno was supposed to free us from the other bad guy, then they added a subscription too. Fuck Bruno I guess.

I find this funny from people that make their living from $$ from software! Lol

But apart from that Bruno is open source (MIT), you can fork it and have it anyway you want…

The paid option seems just like the traditional open source model of make software free but offer enterprise support. And given that CTOs tent to want to pay for stuff (postman is terrible nowadays but is still picked and paid for) why would Bruno straight up say no to money?

Open-source is about having the whole stuff, not restrictions on "Embed Bruno into your SDLC with deeper Git integration, automation."

What I do resent is the fact that Bruno was a reaction to shitty restrictions from another application, and they did the same thing a few months/years later.

I'm not sure how adding a subscription is 'the same thing'. Postman forced all of your data to be stored in their cloud, and held it hostage for $1,000/user/year.

Bruno seems to charge somewhere between 70-130 dollars user/year for unlocking GUI features. The same features are all accessible via the terminal or IDE.

> Without sounding like every other developer who hates on electron

Electron is hated for very good reasons. Postman in particular is just so insanely bloated and sluggish, it's painful to use on anything that doesn't have a higher end CPU.

Sounds like you're looking for https://yaak.app/.

that's close but it uses Tauri, which maybe lighter than electron but we're still running an instance of a web browser/web view

There's a TUI application out there that might be up your alley, but I can't remember what it's called...

EDIT: There's one called Posting which seems to be the most popular: https://github.com/darrenburns/posting

https://github.com/LucasPickering/slumber is also a good TUI alternative

Yes, Tauri isn't that much different than Electron. I also bundles Node JS to power Yaak's plugin system, which makes it even more similar.

I think Electron gets a bad rep mostly because big companies use it to build low quality apps.

Tauri doesn’t bundle Chromium and Node. My app bundle is 10MB and it even bundles a sidecar binary in Go. A hello world electron bundle is 100+ MB.

Ya the bundle size is different for sure. The memory usage isn't far off though, since it's still a web app.

Why is webview a problem? I hear this a lot but not sure why (with the exception of gtk WebKit on Linux which has legit perf issues). We’re on web right now and I’ve never heard anyone complain hackernews is sluggish and that they want a native app instead (or rather 5 native apps minimum for the big OSs).

This is mostly the case because most solutions provide more than the bare minimum of DOM rendering and event binding that a web view originally entails. Once you "accidentally" ship an entire browser inside your app, you've opened up more vectors for vulnerabilities—such is the price of humanity's hubris in attempting omnipotence.

Then second aspect is the "well-hidden" JS runtime or the general dislike of Javascript, but this point has been explained by other commenters well enough.

> Once you "accidentally" ship an entire browser inside your app

That’s not needed. Generally there’s a webview available on the system of choice. All major platforms have it, including mobile and many Linux distros.

> vulnerabilities

Such as? I mean yes if you load remote content with local access to FS etc (although that’s not within the webview). But you don’t need to (nor should you).

I haven't tried it but there is Posting in a TUI: https://github.com/darrenburns/posting

> Without sounding like every other developer who hates on electron, I would really appreciate an http client with a Gui that was lighter, like iced or slint.

How much would you be willing to pay for such a client?

I'm not being facetious, I'd really rather like to know, because as an independent developer, every single time I suggest a native application using native widgets to a client, they choose the HTML interface rather than a Qt or similar based interface.

The easily doable pretty animations in CSS in a 800MB-in-RAM-while-running application is, to paying clients, preferable than a 50MB-in-RAM-while-running that doesn't have the fancy spinning, tilting, animated wizz-bangs.

I have been writing software professionally since the mid-90s; I can do you a quick GUI-based cross-platform HTTP send+receive application based on libcurl in about 2 weeks. Looking at the minimum I need to make to pay my bills, I need purchasers paying a cumulative 1000USD for this effort, so 10x buyers @ $100, or 100 buyers @ $10, and so forth.

And, of course, I'd expect to only be able to sell it for a short while, if it is popular, until a clone starts up with $40k worth of SEO and advertising money.

The software you want can be had, and the skill to make it exists, in a timeframe that is feasible, but the economics are just not there.

This is a good business perspective, but I don’t really see why this couldn’t be someone’s open source passion project. The comment wasn’t really implying that they needed a paid tool, just a tool that suits their needs and is lightweight. Plenty of the software I use on a daily basis is open source software where you could argue that the economics shouldn’t have been there.

> Plenty of the software I use on a daily basis is open source software where you could argue that the economics shouldn’t have been there.

Me too. But the problem with "the economics just aren't there" means that if I cannot get, just from word-of-mouth (say, a Show HN post) 100 users @ $10 once-off lifetime purchase, then this is not a product that is in demand anyway. An open-source/free product that is exactly the same would similarly receive no love from users.

IOW, if not enough users exist for this product at $10, not enough users exist for this product at $0. Your passion product will still result in the dev burning out on the fact that no one wants their passion enough.

Doesn’t that depend on the buyer? I can think of several products that I would only use if free, and would go without if it was $1, $5, or $10. E.g. todo list apps, time tracker apps, budgeting apps.

I think you can argue that, if you have enough demand at $10, that you’ll have enough at $0, but I don’t see how not having demand at $10 implies that you won’t have demand at $0, since usually making something cheaper can change buyer’s minds.

> Doesn’t that depend on the buyer? I can think of several products that I would only use if free, and would go without if it was $1, $5, or $10. E.g. todo list apps, time tracker apps, budgeting apps.

My point is not that the user would go without. My point is that if your product is not desirable or differentiated enough that enough people would pay $10 for it, then making it free won't help because it will be lost in a sea of clones that already existed before you even started working on your product.

After all, look at your list - todo list apps, time tracker apps and budgeting apps; you cannot, in the sea of free competition right now, deliver a desirable enough app in any of those classes, unless it provides so much value over and above the others that many people are willing to shell out $10 for it.

IOW, if the product does not provide enough value for some people to pay $10 for it, making it $0 won't make a difference because it doesn't provide anything over and above the entrenched free offerings.

You see the problem in your comment:

why this couldn’t be SOMEONE’S ELSE passion project

I think you can also easily do the pretty animations in a 50mb in ram "native" application

Yes, you can, especially if you use Qt with QML like I do[1][2][3].

[1] https://rubymamistvalove.com/blog/orchids.mp4

[2] https://rubymamistvalove.com/block-editor

[3] https://www.get-notes.com/

Wow! The blog post was an inspiring read. Thank you for showing what’s possible.

I'm glad to hear that, thanks!

HTML/CSS can still be used for the frontend even without Electron. Some frameworks use the OS bundled web renderer instead:

- For Rust apps: https://github.com/tauri-apps/tauri

- For Go apps: https://github.com/wailsapp/wails

I know it misses the sweetspot you are looking for, but have you tried curl?

uvx posting

https://posting.sh

I just wrote my own [1] and I will be Sure that this one will never be monetised

[1] https://github.com/warmuuh/milkman

Absolute GitHub.

Nice. And the project is mature too. Don't know why I've never heard of it until now. Thank you.

Nice and kudos for your efforts.

For convincing people it never being monetized this is not enough.

You'll need

1. A copyleft license (to prevent the Redis case)

2. No CLA (to prevent unilateral relicensing)

3. A large enough and diverse enough set of contributors that makes relicensing unpractical enough for user to believe it will never happen

The industry has largely moved to [Bruno](https://github.com/usebruno/bruno)

Yes, But.

It doesn't seem like the worst - yet - but Bruno also ramped up their monetization. So far it seems survivable. But given how things have gone before, it's unclear how viable Bruno will really remain.

https://news.ycombinator.com/item?id=42170934

Hmm, I didn’t hear about this! What about that lifetime Bruno thing that was $9? I’m pretty sure I bought that. Is that just nothing now or what does that get me?

Bruno's pricing has changed recently, the lifetime offer is not available anymore. Prices tiers are: free, $6/month, $11/month [1]. Bruno's developers explained it was necessary to sustain Bruno's growth.

[1]: https://www.usebruno.com/pricing

> growth

It's an http client... Itonically I think curl has grown to become so pervasive that it's common parlance to "curl something" to a large extent because haxx thankfully has a radically different approach.

HTTPie is imo the best one now.

Been on the old CLI version of HTTPie for years now. Or are you talking about the GUI version?

Yeah I started using the GUI version, there’s a standalone app or the in browser one. I don’t know why all of these web request clients have been trying to sell enterprise features instead of just giving you a gui to make a quick request.

Are these applications forever doomed? First Postman, then Insomnia, now Bruno...

I moved to Bruno for being local, but even before being polished, I see it's taking the cloud route

How so? In their README they specifically state:

> Bruno is offline-only. There are no plans to add cloud-sync to Bruno, ever. We value your data privacy and believe it should stay on your device. Read our long-term vision here <https://github.com/usebruno/bruno/discussions/269>.

I glanced over that github discussion and don't see where they've gone back on that statement. Am I just missing where they've taken the cloud route?

They haven’t, yet. https://royathan.com/blog/the-api-client-hunt/

The industry being who? Because this is the first time I've heard of Bruno? And what does it do that the others don't?

You should ask instead "What does it NOT do that the others do?"

I just care what it does.

How does you arrive at a conclusion like this? Based on what metrics?

Bruno slowly changed the policy from "we are all free" to "we are mostly free" to "pay for feature A, B, C"

Understandable, but feals like being tricked into something.

this is (at least) the third time we've seen this in this exact space: Postman, Insomnia, Bruno.

At this point I just use the REST client extension in VS Code (Rider has one too) or HURL. The lack of GUI makes it a little tougher for new people, but file-based is nice, and in the end I have much stronger skills & understanding in the area.

They explicitly sold themselves as an Insomnia alt.

Here is their usage graph: https://star-history.com/#usebruno/bruno&Date

Insomnia introduced account shenanigans around the end of Sept 23: https://github.com/Kong/insomnia/discussions/6590

The features you pay for are just GUI features. All of the things are still accessible in the terminal or IDE.

My whole organization picked up Bruno after the whole Postman fiasco. I've found Bruno to be very unpolished and buggy. We've run into bugs where the UI will show one value, but when the request sends it uses a previously overwritten variable.

Looking forward to having to move to something else, again.. sigh

Insomnia creator has a new one called Yaak that is open source.

If you use a VSCode-based editor, a good alternative can be the "REST Client" extension: https://marketplace.visualstudio.com/items?itemName=humao.re...

I’ve been burned a few times by these clients — difficult backups, changing licensing/commercial terms, hard to version — so now I prefer a few simple .http files that I can version in Git and easily read, even if the extension disappears.

That extension is excellent! Been using it for few years already

Can you save the full request details and full response details in one click as one file with this extension?

This is the feature I use the most.

Just tried. You can save the full response to a single file with one click, but it doesn’t include the original request.

I found an issue asking for the same feature: https://github.com/Huachao/vscode-restclient/issues/1311

it’s so good. no context switching with a different app. also, there’s a fairly compatible version for emacs with the same name.

Terminal based: https://posting.sh/

Looks cool, I will try it. How are collections stored? My use case involves programatically generating collections.

If the tool suits, I would also need to write a converter from Bruno files to it.

That’s incredible, amazes me that you can get a GUI like this in terminal. Next someone will put doom in the terminal

https://github.com/cryptocode/terminal-doom

https://www.androidauthority.com/android-16-linux-terminal-d... :-)

Hurl https://github.com/Orange-OpenSource/hurl

For those who prefer an efficient command line tool

I've landed on the REST extension in VS Code for development and interactive work, and Hurl for more test/automation stuff. Both take a little more effort to get setup but way more productive than the typical Postman workflows I see.

Idk if they have it yet, but last time I used the VS Code REST extension it still didn't support pre/post request scripting (which is already insanely fragmented syntactically across Postman/Insomnia/Bruno).

For any long-term things that would normally be in a Postman collection and distributed to others / outside teams, I usually end up with folder-separated Hurl scripts (similar to your use).

I can totally see how the REST extension is way easier for point & shoot from within VSCode though!

Am I the only one who use CURL over such tools?

I don't want a 300MB electron client doing GET/POST work, especially those with hidden telemetry on.

The more experience I get, the more I prefer it

You may like Hurl [1]: it's an Open source cli based on curl (libcurl to be exact), to run and test HTTP requests with plain text (I'm one of the maintainers). We recently add --curl option to come back to curl. Give it a shout!

[1]: https://hurl.dev

Recently tried out hurl for a project to show how abstract tests can be run in a specific environment. Great tool, it will definitely stay as part of my standard toolset.

I've recently used Hurl to create a test suite for migrating a complex Nginx configuration to Caddy and it was a great choice!

I ran Caddy replacing the upstreams with mockbin-like services (don't remember which one I used) so it would respond with information about the request made by the proxy, so Hurl could make assertions on that.

I guess it really depends on your usecase.

If you're just _hacking_ a few simple calls, curl is the way to go.

But if you're working in a team, with multiple environments, with complex payloads, authentication, doing dozens of API calls everyday... Having a software able to manage libraries of endpoints, parameters, simple environment switching, included auth, sharing between team members... is a big time saver.

I personally prefer IntelliJ's HTTP Client[0] since I always have my IDE open, the files are not obfuscated in a gibberish format and can be versioned/shared through Git. But when I start working on an existing project, having a Postman collection to rely on is a huge time-saver, instead of having to go down in-existent API docs or trying to infer from the code itself.

[0]: https://www.jetbrains.com/help/idea/http-client-in-product-c...

This and also when you newly join a team it is more productive to start using the tooling what they are using and move to preferred tooling once familiar with the API endpoints.

I always use curl, jq, etc. It's so simple and straightforward. But I would be lying if I claimed it to be easy to convince my teammates to use the same toolset I use.

Some ppl “just need to press a button” so i’ve been told. I like httpie, but curl and wget could hardly be more mature tools.

This is one application where I simply prefer a GUI for most of the use cases. All the various components of an HTTP call are visually better represented as far as I am concerned. Often enough it is also specifically the payload on both sides I am specifically interested in and viewing them side by side and making quick adjustments is just my personal preferences.

In the year 2024 with 8 cores, 32gb of ram and 4tb of storage available the electron overhead generally also doesn't really matter that much to me. Though this doesn't seem to be an electron app either, rather a PWA. Which makes me wonder how well it works with all CORS limitations you are facing in the browser.

Not that I have anything against CURL either, when I am working in a CLI (for example on a server) it is the perfect tool.

I use a jupyter notebook and Python with requests.

The problem with all these tools is you pretty quickly end up basically wanting full programmability...at which point, Python is just easier and more flexible.

Combine that with uv for on-demand script dependencies and it's also completely shareable and manageable.

I'm not a fan of curl. I like the idea of "simple is better" but I don't like working with just curl. i need a bit of squish

I cannot express in words how much as an engineer I am sick of every app people suggest to me needing an entire quasi-visualized OS running behind it, written in the shittiest language ever to grace our cursed machines, just to render text and perform web requests.

No, you are not the only professional among the amateurs/hobbyists.

I know that sounds offensive, but let's be real, nothing wrong with using AI to code or using a gui to learn about the underlying protocol. But it is what it is

Curl is nice but its syntax leaves a lot to be desired. It's also hard to distribute to others a "collection" of them, as you're going to end up with troubleshooting questions from less-technical users, especially when it comes to multi-request items that require pre/post response processing.

I've run the open source version of Insomnia (https://github.com/ArchGPT/insomnium) for a while, but as that project is no longer actively maintained, I may give this a look.

The Insomnia creator has also started https://Yaak.app, which uses Tauri instead of electron iirc.

Wait so he sold his product and they didn't put a NCC on him?

He sold it some time ago. Either it expired, he negotiated out of it, or there was never much of one to begin with. My guess it was a little of all three. I think a lot of what Kong wanted with it already happened - it seems to have helped them grow. They still have it and it's still helping but I don't think Yaak is that big of a threat to it. Kong still has a major API client in a space that has room for more than one.

It feels like they were after a similar strategy as when Fiddler was sold. They can control the narative and likely use it as an onramp to their other (much more expensive) products when developers introduce any of their tolling into the enterprise.

There is also https://httpie.io

I've been using it for a while. Coming from postman it's exactly what I was looking for. Just the features I need, no bloat.

Also Bruno https://github.com/usebruno/bruno

I believe both Bruno and Hoppscotch are "open core" with expensive paid plans for additional/enterprise functionality, and they limit community-contributed functionality in the open source versions to avoid competing with the commercial versions.

How's Paw for macOS? https://paw.cloud/

The app is called “RapidAPI” after it got bought, now apparently the team got bought by Nokia so would not buy into it too much at this point. It used to be a nice native app.

What is https://httpyac.github.io/ missing in comparison to postman, insomnia or hopscotch? I really like being able to run .http files as unit tests in ci as well as during debugging.

https://httpyac.github.io/guide/#feature-comparisons

Wait, wasn't insomnia supposed to be an open source alternative to postman?

Yeah, but they went the cloud-first enshittification route like a year and a half ago.

https://github.com/Kong/insomnia/issues/6577

I still use Insomnium, a (dead) fork of Insomnia that removed all the telemetry on a version of Insomnia just before this nonsense occurred.

Then Bruno positioned itself as the fix for the enshittification, and then did it itself.

btw, JetBrains IDEs have built-in HTTP-client. Not so GUI rich, but very convenient for development and no need for a separate if you're already using the IDE https://www.jetbrains.com/help/idea/http-client-in-product-c...

A big plus imo is that you can check in and version control the files alongside your application. Very convenient when working on micro services in a team.

Why not Cartero (https://cartero.danirod.es) ?

Ah, the cycle of REST clients. Start useful, get bloated, enshittify, alternative pops up.

The CLI tools have a great record.

curl and invoke-restmethod and hurl etc.

It's the GUI tools that keep getting monetised.

https://github.com/hoppscotch/hoppscotch/pull/3266#issuecomm...

Going to leave this here for shady practices. A pull request was declined by the CEO since they were planning to build an OIDC feature into the enterprise plan.

This is really weak. I'm all for benevolent dictators ruling their projects to protect the conceptual integrity - until that means anti-user behaviour to only enrich themselves.

"But we need to do this to survive!"

no you don't; every handy tool with many substitutes doesn't need to be a startup, especially when your competitive difference is temporarily not doing the thing you're now going to do.

If you use JetBrains IDEs, check out the JetClient plugin (https://jetclient.io/). It's similar to the Bruno and ThunderClient extension for VS Code.

To save some people a click: it requires a subscription.

That's incorrect. JetClient has a free tier that doesn't require a subscription, an email, or a credit card. You can even install it on the free IntelliJ Community Edition without a JetBrains account. Only the Pro tier requires a subscription—just like most API clients. But the free version includes many features and is comparable to Bruno's free tier, not just basic functionality.

I have a question about those tools.

One thing I really like in the SoapUI, is the ability to have mocks(for both REST and XML), so I can mock the responses of some of the requests. Any of those other opensource alternatives have that option?

Hoppscotch is a very cool product and now they also support the mTLS authentication, which was a long-awaited one.

We moved out from Postman to use JMeter, since back then the feature was not available.

Pretty happy to see it here again.

Jmeter is old and awkward, yet so powerful. Great for performance testing.

I'm sure glad the readme explained all the http request methods and that request are made quickly and in real time.

Honestly sounds like an LLM generated that readme.

I prefer Bruno

Isn’t insomnia open source?

Leaving this here as it's by the creator of Insomnia: https://yaak.app/

>> The offline-first API client you'll love

so I get I can run it offline, and call local (dev) apis, but is this really the major feature we want & need? How are people going to react when he pulls the same bait and switch for their API tooling a second time?

The reason I started Yaak was because of what happened after I sold it. What makes you think I'd do that again?

Stopping by here to stay thank you. Yaak is excellent.

Thanks, I'm glad you like it!

Try Yaak!

wish they had gRPC support

I've been working on Yaak [1] which supports gRPC. Websockets are also now live in the current beta.

[1] https://yaak.app

Reply on news.ycombinator.com