Earlier quoted context omitted.
I think curlie is the middle ground and the best (IMO) in the space. A nicer CLI for interactive use and can use and output curl flags for scripting.
As a maintainer, I feel obligated to mention Hurl [1], a tool for testing HTTP with plain text and curl. It’s a wrapper around libcurl, in a single binary, with syntactic sugar for asserts. You can use it also like curl to give you an HTTP output. [1] https://hurl.dev
Show HN: A Swiss army knife for testing HTTP from the terminal
41–47 of 47 posts
Re: Show HN: A Swiss army knife for testing HTTP from the terminal
#42Earlier quoted context omitted.
the solution is not write CLIs in JavaScript, unless you have a JS-library that you also want to make available as a CLI packaging Node in a binary won't solve the problem of JavaScript's plagued ecosystem and in fact i'd rather prefer to be able to mitigate the issues/update packages myself rather than waiting for a new binary to release
I agree with your conclusion to not write cli tools in Javascript. However, packaging node in a binary is pretty much what electron does today, albeit with a GUI. Regardless, it's not a problem I wish to spend any effort to solve since it's not my problem and I've (we've) already dismissed the premise (writing CLI tools in js) lol.
Re: Show HN: A Swiss army knife for testing HTTP from the terminal
#43Re: Show HN: A Swiss army knife for testing HTTP from the terminal
#44Nice idea. NodeJS and thousands of NPM dependencies are a big no-go with a red flag on top, though. One of the things something like Go probably would have been a better choice for. See "bombardier" for example.
I mentioned elsewhere in the comments that we have a Docker image, and are working on other methods of installing the CLI to alleviate some of these dependency-related concerns.
Getting side tracked here, but there seems to be a common sentiment when it comes to Node.js that it's uniquely insecure. Node.js has indeed had some unfortunate press when it comes to supply-chain security, but every other runtime is susceptible to those attacks (PiPy, Gems, Maven, Rust Crates). Ultimately of course, if you choose to avoid using any software built on top of those stacks, that's your choice.
Artillery specifically is no different to any other Node.js-based project in how large the dependency tree is. VSCode for instance is used by millions of developers has 1.6k dependencies [1].
Re: Show HN: A Swiss army knife for testing HTTP from the terminal
#45does this require Node.JS? edit: it looks like you need to install 1276 npm dependencies to use this tool https://github.com/artilleryio/artillery/network/dependencie... i'll pass, the risk is unacceptable for value it offers, especially in corporate environments
Re: Show HN: A Swiss army knife for testing HTTP from the terminal
#46Earlier quoted context omitted.
> Think mini-curl with better UX for common use-cases, plus a couple of extra features. > it looks like you need to install 1276 npm dependencies to use this tool Sincere question (probably highlights my lack of understanding Node package management): how can this be a "mini" curl with that many dependencies?
“mini” in the sense that it doesn’t do everything that curl does. curl does a whole lot. this tool focuses on more common use cases and makes them friendlier. plus with request waterfalls and assertions it does things curl can’t do. the number of packages is a bit of a misnomer anyway. Artillery Probe is part of Artillery which does load testing, with multiple protocols, support for multi-step scenarios, publishing t…
Re: Show HN: A Swiss army knife for testing HTTP from the terminal
#47Nice idea. NodeJS and thousands of NPM dependencies are a big no-go with a red flag on top, though. One of the things something like Go probably would have been a better choice for. See "bombardier" for example.
Bombardier is cool, but serves a very different use case. I mentioned elsewhere in the comments that we have a Docker image, and are working on other methods of installing the CLI to alleviate some of these dependency-related concerns. Getting side tracked here, but there seems to be a common sentiment when it comes to Node.js that it's uniquely insecure. Node.js has indeed had some unfortunate press when it comes to…
Yes, of course. I was just taking an arbitrary example from my common HTTP toolbox.
> VSCode for instance is used by millions of developers has 1.6k dependencies [1].
VSCode is maintained by Microsoft plus a huge community and they are transparent about their process in regards of auditing/freezing dependencies.