gschier

Hey, thanks for posting. I'm the creator of Yaak, so let me know if you have questions!

You really notice the startup delay with a large CLI written in something like NodeJS. Going from >100ms to ~0ms is a huge QoL improvement.

Hah, that's awesome to hear! That lock-in mess was a sad time for me. Let's take some of that marketshare away from Big Co

Yep, and thanks! For some reason companies keep thinking API clients are big business and ruin them with attempts to maximize profits.

As the creator of another free/offline/git-native API client Yaak (https://yaak.app) I just want to say this looks awesome!

It's refreshing to see a new API client that isn't just a reimplementation of Postman's interface.

Im not sure if they're technically considered EV but mine is linked to my corporation and I get no virus warnings at all during install.

This is not true. Or maybe it is but they missed me? I signed up with a brand new company without issue.

It's using Tauri, so Rust and ReactJS

That's the idea behind individual license. It's a non-transferable license that's cheaper than business.

Yes, that's the goal for the plugin system. The overall interface should not noticeably change from here on out.

I basically copied this. Yaak also has a perpetual fallback license.

Not sure, I haven't used it!

Just a basic server. Licenses are attached to paying users. The app checks the license against the server periodically to unsure it's still valid. It's not that complicated since I don't care about piracy.

Yes indeed. This is why I stared over with Yaak

Thanks, I just did a big overhaul on it and came up with something I'm very pleased with :)

No difference. You can see the build pipeline in the GitHub repository which builds directly from HEAD

Yaak used to not require a commercial use license (original plan was to do cloud sync), so "still" refers to the fact that the commercial use license now exists, but the open source nature hasn't changed. I'll update the wording there, thanks!

Ya, I feel like their need for growth is forcing them into it. I'm glad I only have to earn enough income for 1 person, not 1000.

Thanks! Let me know if there's anything missing :)

I'd say the only real differences are that (1) I know what I'm building from the start and (2) I can avoid the fundamental technical mistakes.

It's actually been way harder to gain traction this time, I think because APIs are no longer sexy and there are so many good tools out there.

I remember seeing another one while coming up with this, but now I can't remember what it was. It's definitely rare.

I agree, there's no way to know for sure. But I feel like I'm the least likely person to do this with Yaak since I learned from experience already.

It's definitely under consideration. Yaak has Request Chaining [1] to solve some of the use-cases that scripting is typically for, though, so there isn't a ton of demand for it.

[1] https://feedback.yaak.app/help/articles/7017237-request-chai...

The feedback board is linked in the readme! I do agree with your points and have been passively thinking of an overhaul to how environments work. It's one of the most important features and has so much potential (like activating multiple at once)

Hah, and you chose Yaak!

This is how it works now, though I need to make it more clear.

If you subscribe to the annual plan (or the monthly plan for 12 months) and cancel, you get a perpetual license, meaning you can continue using the current version indefinitely.

The end goal is generate a sustainable income for as long as possible, so I can enjoy life with my family.

Awesome! Let me know what you think.

I've been meaning to put some comparisons together!

Bruno is also a good local-first client but leans more toward Postman's market.

The main advantage Bruno has is the ability to run tests, and a CLI to do so.

Yaak supports more protocols (eg. gRPC and WebSocket), has plugins, and more powerful templating for doing things like generating UUIDs (also extendable via plugins).

Ya, the gamble of HN I guess. Thanks for saying so! It will be local friendly for as long as I'm working on it, and I'm in it for the long haul this time.

It's just personal preference. If you don't see the need for this type of tool in your workflow, you likely aren't the target user. It's very similar to GUI database clients. Sure, you could use the command line, but a lot of people need something more powerful.

I started with a folder of Curl requests / environment variables, but it quickly fell over when I needed more complex logic, OAuth, better organization, visual response previews, or anything else that came with my non-trivial use case.