You might get a less biased response from someone else, and I don't have much experience with JMeter, but: - k6 prioritizes modern developer experience. Tests

You might get a less biased response from someone else, and I don't have much experience with JMeter, but: - k6 prioritizes modern developer experience. Tests are written in JavaScript, run from the CLI and can be committed to the same repository along with unit and integration tests. As such it blurs the line between responsibilities of a traditional QA team and pushes for load/performance/stress testing to be done by application developers themselves. This enables developers to easily integrate k6 in their existing CI pipelines and run load tests early on in the development cycle rather than as an afterthought. - k6 is written in Go, so it's much easier to deploy and use as a static binary, which also brings considerable performance benefits over JMeter. You can see a detailed breakdown and comparison in this article[1], written by another commenter here and one of the original k6 authors: rlonn. :) OTOH JMeter is a much more mature tool and has many more integrations and protocol support than k6. We recently launched an extension system for k6[2] that allows developers to add support for other protocols or features via native Go libraries, but the ecosystem is still in its infancy. So if you don't mind the JMeter UX, its performance or need some of its features, by all means stick with JMeter. But I would encourage you to give k6 a try for yourself, as it was written precisely out of the same frustrations mentioned in the article. [1]: https://k6.io/blog/comparing-best-open-source-load-testing-tools https://k6.io/blog/comparing-best-open-source-load-testing-t... [2]: https://k6.io/blog/extending-k6-with-xk6 https://k6.io/blog/extending-k6-with-xk6