haha the idea comes from the fact that the tool is not opinionated - in the sense that yes its an API client but its also an editor, etc. So it a tool with infinite possibilities and can be as flexible as people want. So this is the idea: void-endlessness-freedom.

If it didn’t scare you alot, will you try it? :)

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).

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.

wow wow thanks! please spread the word!

yes in Voiden everything is a block though.

https://voiden.md/comparison

depends on what you want to focus on - for example I like the reusable blocks and the programmable interface + the idea of community plugins that extend the tool!

hey - thats great :) Happy you downloaded it :) curious to hear your feedback - I will send you a discord link as a message so its not seen as spamming.

Let me see if I understand your question: you mean how Voiden would look when its more mature?

What I am most excited about is that Voiden already does a few things differently from most API tools. Reusable blocks, plain-text everything, and the ability to go from testing to docs to publishing from a single source are already working and shaping how teams can work in a more consistent way.

There is still a lot ahead (for example I want to see what kind of plugins people come up with for the tool, or how AI will eventually play a bigger role) but the principles of Voiden (reusability, composability, plain text, collaboration through git, single source of truth etc.) are the ideas I believe will define and set a new tone/standard of how API tools should be.

I thought no one would ask :) just open sourced it a few weeks ago. But I promise I will never pay someone to praise it pretending to be a developer.

https://github.com/VoidenHQ/voiden

haha I dont know how to take this

haha indeed - modern has this “blinking lights” connotation. something that is shiny.

True story - once, in primary school, I went to a halloween party, where all the boys were dressed as batman and all the girls as macarena (guess my age). The host of the party was maybe the only one not dressed as batman.

He was wearing some weird jell in the hair, like a punk kind of thing, with a lot of strass, stars all over his body, some heart or thunder shaped big mirror glasses, a shiny jacket and the best looking blue mocasines I have ever seen. He also had a big radio antenna (??) coming through his nylon electric yellow vest.

I asked him: what are you dressed as? and he replied: “Modern”.

true :) I heard this actually even from ex insomnia folks - the direction could have been much different.

• bruno does have a paywall last time I checked :) but the point is not to have tool debates :) my main point is around overall philosophies and ways that new things are like older things with a small twist.