K6 was released on GitHub not long ago in 2017 and since then has gained increasing popularity. Five years before then, in 2012, Gatling was released and also had very fast growth. You can see how active they have both become with the number of stack overflow questions and GitHub forks.
There are some clear differences between the K6 and Gatling. K6 is JavaScript-based and Gatling is Scala-based. K6 is developer-centric and Gatling is not. But in many ways, there are clear similarities between them in the most significant ways.
They are both open source. We’ll get into that more later. They are both easy to use and maintain and provide detailed reports with lots of useful charts. However, some would say that K6 is much easier to learn. They both interface with continuous integration (CI) through Jenkins and other frameworks. They can both be used with or without cloud services. And both have free and paid plans.
On the other hand, Apache JMeter has been around since 1998 which means that there is a bigger community of users, trainers, etc. That also means that almost any company that is in any way involved in the load testing and performance testing space, has integrated their products and services to support JMeter. And there is of course extensive documentation for all of it.
When you look at and read about K6, you hear that plugins are not needed because most features are natively supported. But K6 knows they can’t develop everything which is why they have plugin support, but it is relatively new and availability is sparse. For JMeter, plugin support is strong with the Plugin manager, and JMeterPlugins.org. Basically these become an extension of JMeter because of the very well-executed integration.
JMeter has over one hundred plugins. These have been developed by the worldwide JMeter community and by companies like BlazeMeter, Microsoft, UBIK Load Pack, etc.
One set of companies that tightly integrate with JMeter are the load testing platforms. Which means that companies like BlazeMeter, RedLine13 and others, can provide the integrated capabilities to scale on the cloud. If you decide in the future that another platform has better features or better pricing, you can simply take your JMeter scripts and run them elsewhere.
K6 doesn’t have a native distributed load testing mode. You can containerize it yourself and deploy it via Kubernetes, for instance, but it does require a more involved setup. The K6 team is also working on the K6 Operator, which makes setup significantly easier, but it is experimental and comes with drawbacks such as not supporting threshold synchronization between instances. For now, the easiest way to scale up on K6 is by using the paid service K6 Cloud, which reduces setup time and complexity.
All three of them claim that they are open source, and technically speaking they are. But one could say that K6 is proprietary because it uses AGPL. That means you can see the code, reference it in your projects, and make changes to it. However, AGPL operates under the premise of “copyleft”. This is of particular importance to organizations in that any derivative work (e.g., modifications, dependencies, etc.) falls under the governance of the AGPL. Any work that relies on this must also be made freely open source which can present obvious problems if the goal is to commercialize that work. In contrast both JMeter and Gatling use the much more permissive Apache 2.0 license, which is not a copyleft license and does not require derivative works to be made open source. These types of licenses offer much more flexibility, often making them more suitable for commercial endeavors.
Writing a test with K6 or Gatling requires writing code that must be vetted for functionality. Though with JMeter tests similarly you must also vet your tests to ensure that they run as intended. Starting out with code introduces an additional layer of complexity. When you use elements in JMeter such as controllers, samplers, and thread groups, there are more guarantees that the test will function in the manner intended. In contrast with other platforms that begin with code, there is more risk that these tests can behave in unintended ways. The trade-off however is in flexibility. A pure code test generally will give the greatest flexibility but require more time and more skill to develop. With structured frameworks like JMeter, construction of the test occurs in a GUI environment with some assurances that the components will behave in a predictable way. Test authors may also enjoy greater support and online resources when working with JMeter components versus troubleshooting tests that have been coded from scratch.