

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? :)


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


you can keep an eyes on our github issues cause these languages will come soon!


thats true right? we are also coming from the same boat.
btw now we are adding shell script as well…different devs need different capabilities.
so did you try Voiden? anything interesting or any feedback to share ?


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.


thanks for sharing!


cool - what would then be on the very top of what you would like to use? :)


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.
I have added the link! It’s free to watch


wow wow thanks! please spread the word!


yes in Voiden everything is a block though.


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!


awesome, thanks for sharing.
feel free to play around and tell me what you thought - especially around the reusable blocks: most devs we talk with consider this to be the most “different” thing and what is more different than other clients… For me its this one too + the plain text files all the way from specs, tests, docs, context etc…


yay - feel free to add few of these QoL tweaks here: https://github.com/VoidenHQ/voiden/issues


Hey :) Voiden is not a rich text editor (non offense to rich text editors). It is executable API docs: requests, docs, and explanations that all live in Markdown… and actually run. (Yes, your docs that do stuff). As far as I know it is the first tool to collapse design, testing, and documentation into one file, one format, one workflow. If you know another tool that does this, I genuinely want to hear about it (definitely not trying to be cocky, just curious :)
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. :)