what do you mean beyond the skill level?

awesome!

depends on the size of your team I guess? Postman used to really be the default API client for serious API testing. https://kaluvuri.com/blog/when-the-category-leader-stalls/

And yes curl is great and is a big inspiration for Voiden. In fact we built it inspired by curl and obsidian.

The problem I see with curl is that real API work is almost never just one request typed into a terminal like some kind of beautifully minimalist Unix haiku. It involves auth, environments, copied headers, reused payload fragments, request chains, documentation, testing, debugging, sharing examples with teammates, reviewing changes in Git, and trying not to break prod because you forgot to swap one token or one base URL.

At that point you can not “just use curl” right?. You use curl plus other things. Curl plus shell scripts, curl plus notes, curl plus env files, plus copied commands from Slack, plus random JSON files, plus tribal knowledge etc etc… Which is fine I guess but isnt it at some point super annoying and hard to collaborate on? That is the gap that I see this tool (Voiden) trying to solve.

So for me it is not “curl vs Voiden.” curl is a low-level execution tool. Voiden is a workspace for actual API work: writing requests, organizing them, reusing pieces, documenting them, testing them, versioning them in Git, and not duplicating the same headers/body/auth setup 45 times :)

does this resonate?

what do you currently use? what are the limitations of what you tried and were not happy with?

yeah, around 11k installs so far - and a few committed and opinionated contributors :) - hope you give it a try.

cynically true :)

yes thats a good idea, we actually made an FAQ that sits with our docs…I want to monitor to see if this helps people navigate some of these questions:)

hm…great points, thanks for taking the time to answer.

From the perspective of a user, why would they care about development speed?

Yes, the tool is already developed but it will continue evolving right? I mean, we almost make 2-3 releases every month since we shipped the first version and then open sourced. So the speed still counts. Plus, the users who create the tickets and expect them to be tackled are actually developers themselves. So yeah, the ability to deliver (at a good pace) to these folks matters a lot.

However - YES, if at some point the tool is at a state that the speed becomes less meaningful or useful, then indeed a change might be needed?

As for platform consistency, again, why would the user care?

Yes, since our users are Dev (and QA) folks, we thought that yeah, maybe someone could have different systems for work vs home vs side project (as you said). But another aspect that we thought is teams and collaboration. We didn’t want to have a scenario in which a team can not use it before some of the devs are using macs, others linux vs the QA folks using windows etc.

What I’m getting at is that the concerns of developers will not always be equally concerning to users.

Thats the heart of the discussion:) I guess because our users are also developers. :)

nice metaphor:) but unlike a car, these Electron processes aren’t slowly eating your tires or draining your oil. Maybe a better metaphor would be that the car you rent comes with a few extra cup holders you that you didn’t ask for? :)

thanks! well, the feedback and the questions did not come from lemmy per se but in general. And yes, I agree with you. People do have strong opinions and this is more a question for me - as I often feel that perhaps there is some “better” way to explain or show the impact of the decision. (and explain the trade off). But I think that ultimately you are saying one simple (but very important) thing: that you can not please everyone :)

Yeah, honestly, sometimes I feel frustrated trying to explain it, because I know some people will never be satisfied. I just want to be transparent about the tradeoffs and let people SEE the actual usage (even if it will indeed not convince everyone).

so there could be an option “select a texan taxi driver” irrespective of where you are in the world

yap…thats the thing…you never know…the interesting conversations can only happen only when we are open and ready to accept also the banal ones :)

thats super sad…I dont have a problem with someone not wanting chit chat but isnt better to just say “hey, today I am not in much mood to talk” or to show it and to make it happen without explicitly selecting it in an app…

its just very black mirror esque

we are indeed looking at the docs again. To begin with we focused on the tool itself so some of the examples that you see can indeed be worth revisiting and re writing. :) But I hope you can focus and zoom in to the tool itself and see how this can help you with your API workflows.

True. Background of the story of how I learnt is in my tai chi class where I asked the teacher if they also do king fu there. And they told me that well tai chi is also part of kung fu.

what about people that are not JS?

You either die a hero or live long enough to become the villain?

Apologies…missed that. Yeah this is what we are currently working on - part of the next release actually :)

I actually agree with most of your premise.

Voiden is not coming from “people are too scared of the terminal, let’s save them with buttons.” It comes from almost the opposite direction. A lot of us are terminal people too. The problem is not that curl, hurl, scripts, OpenAPI, or plain code are bad. The problem is that API work tends to get fragmented across too many places once it becomes real.

You have raw requests in one place, auth logic in another, docs somewhere else, examples in Slack, test cases somewhere else again, and then different teams consuming different versions of what is supposedly the same API. That’s the mess we care about.

So the goal with Voiden is not to replace power-user workflows but to give them a better structure, while also making that same source of truth usable by the rest of the team, including people who are not living in the terminal all day, or simply have different preferences.

That is also why composability matters so much to us. Reusable headers, auth, query params, payload fragments, shared blocks, documentation alongside execution , not because curl cannot do requests, but mainly because nobody wants to maintain the same slightly different request 100 times across scripts, docs, and collections.

And on the “UI tools become dead ends” point: yes, that is the trap we are trying to avoid. We do not want a bespoke black-box UI where if there is no button, you are stuck. The idea is to have one source of truth that can still work for power users, can be versioned in Git, can be shared, can be documented properly, and can evolve into automation/CLI/agent workflows as well.

So from my side it is not “UI versus terminal.” That debate is honestly a bit too small. What if we reframe this to: “Can we have one composable, reviewable, reusable representation of API work that serves both the terminal-native people and the wider team without duplicating everything across five tools?”

That is basically the whole bet.

So yeah, I get the skepticism. I have it too. The world does not need another glossy “API client” that turns into a toy the moment you step outside the happy path.

The point of Voiden is precisely to avoid that fate. I am sure you will see how radically different Voiden’s take is, if you just give it a spin for a few mins. In a world full of postman clones - we want Voiden to really stand out with a different approach to api tooling. :)