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.
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.
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.
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.
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.
why this couldn’t be SOMEONE’S ELSE passion project
- For Rust apps: https://github.com/tauri-apps/tauri
- For Go apps: https://github.com/wailsapp/wails
[1] https://rubymamistvalove.com/blog/orchids.mp4
Only thing I don't like about Bruno is that you cannot generate a documentation from your api call tests.
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?
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.
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.
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.
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).
EDIT: There's one called Posting which seems to be the most popular: https://github.com/darrenburns/posting
I think Electron gets a bad rep mostly because big companies use it to build low quality apps.
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.
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
Looking forward to having to move to something else, again.. sigh
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.
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.
Understandable, but feals like being tricked into something.
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.
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
> 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?
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.
This is the feature I use the most.
I found an issue asking for the same feature: https://github.com/Huachao/vscode-restclient/issues/1311
If the tool suits, I would also need to write a converter from Bruno files to it.
For those who prefer an efficient command line tool
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!
I don't want a 300MB electron client doing GET/POST work, especially those with hidden telemetry on.
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...
[1]: https://hurl.dev
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.
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.
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 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
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.
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.
curl and invoke-restmethod and hurl etc.
It's the GUI tools that keep getting monetised.
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.
"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.
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?
We moved out from Postman to use JMeter, since back then the feature was not available.
Pretty happy to see it here again.
Honestly sounds like an LLM generated that readme.
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?
[1] https://yaak.app