I think both of you are right, just talking about slightly different layers of the problem.
curl absolutely works (and it rocks!). Shell scripts absolutely work. For terminal-native teams, that can be a great setup.
But this feels a bit like two very old debates mashed together: terminal/Vim vs Git GUI, and Emacs vs IDEs. Yes, some people are perfectly happy doing everything from primitives - git in the terminal (i hope by the majority), editing in Vim, wiring things together with scripts, maybe extending Emacs until it becomes a small civilization :D. That is a real workflow, and for the people who like it, often a very effective one.
But the existence of that lower-level workflow does not make higher-level tooling pointless. It just means different people and teams want different layers of abstraction on top of the same underlying capability.
So I do not think the real question is “can curl do it?” it can, for sure!. The real question is whether raw requests plus scripts are the best shared working model once API work starts involving reuse, documentation, onboarding, review, collaboration, and people outside the terminal-native crowd. For some teams, yes. For many teams, not really.
That is where something like Voiden, starts to make sense to me. Not as a replacement for curl (at the end they are all making a simple API request), but as a way to make API work more modular, composable, and shareable without everything turning into a pile of scripts, copied commands, and scattered docs.
But the bigger problem i see is when simple tooling (or rather what should be simple) become super bloated - and are super opinionated and take away the flexibility from users - and they end up having to design their workflows around how a tool works. Voiden i guess is taking the less opinionated stance - and trying to give all the freedom - with markdown, offline and programmable interfaces etc etc… but let’s see.
I think both of you are right, just talking about slightly different layers of the problem.
curl absolutely works (and it rocks!). Shell scripts absolutely work. For terminal-native teams, that can be a great setup.
But this feels a bit like two very old debates mashed together: terminal/Vim vs Git GUI, and Emacs vs IDEs. Yes, some people are perfectly happy doing everything from primitives - git in the terminal (i hope by the majority), editing in Vim, wiring things together with scripts, maybe extending Emacs until it becomes a small civilization :D. That is a real workflow, and for the people who like it, often a very effective one.
But the existence of that lower-level workflow does not make higher-level tooling pointless. It just means different people and teams want different layers of abstraction on top of the same underlying capability.
So I do not think the real question is “can curl do it?” it can, for sure!. The real question is whether raw requests plus scripts are the best shared working model once API work starts involving reuse, documentation, onboarding, review, collaboration, and people outside the terminal-native crowd. For some teams, yes. For many teams, not really.
That is where something like Voiden, starts to make sense to me. Not as a replacement for curl (at the end they are all making a simple API request), but as a way to make API work more modular, composable, and shareable without everything turning into a pile of scripts, copied commands, and scattered docs.
But the bigger problem i see is when simple tooling (or rather what should be simple) become super bloated - and are super opinionated and take away the flexibility from users - and they end up having to design their workflows around how a tool works. Voiden i guess is taking the less opinionated stance - and trying to give all the freedom - with markdown, offline and programmable interfaces etc etc… but let’s see.