I'd say performance in this benchmark is inversely related with how nice it is to express business logic in the respective language/framework, and that's a pretty big deal.
I worked with Netty at work for two years and it was a dream to use something like Express or Flask on the side, not having to worry sharing/disposing ByteBufs, not dealing with the weird in-channel/out-channel abstraction (vs simple middleware), not investigating how async-/thread-safe a given library was, etc.
It just all goes back to trade-offs. You're going to have different considerations if you're building a Caddy competitor vs a complex game server. Another consideration is how horizontally scalable you can be which is going to be different for a forum vs a websocket server.
Vert.X is a relatively light layer on top of Netty and it is quite nice to work with.
Spring WebFlux is also built on top of Netty, and missing some benchmarks, but I have no reason to think it would perform poorly. Its very easy to use for anyone with Spring experience.
The fastest frameworks are all nonblocking, like Express. They use streaming and reactive patterns, if it wasn't for Java's types everywhere some people wouldn't be able to tell the difference between Vert.X using RxJava and Express. The main design difference is that JS does non-blocking on a single core vs Java which does thread-per-core. Basically, in Java you can scale out non-blocking across all cores and still share memory when you want to.
If you don't want to deal with thread safety and non-blocking DropWizard performs quite well using traditional threads.
Just saying, performance and easy of use are not always exclusive. Maybe Vert.X didn't exist back when you were using Netty but these days it would be unthinkable to use Netty itself, the abstraction Vert.X provides is far easier to use and you don't really lose any performance.
Java's bad performance reputation is 90% due to old versions of Spring. Spring Boot has come a huge way, with performance maybe 100X better than Spring 4. Spring WebFlux takes this even farther with a Vert.X-like api, probably reaching near-Netty performance
Netty is network IO framework and is almost never used as is to develop web applications. You usually plug it in your framework or http library which abstract over it (or Jetty, or Apache, or Undertow, or ...).
Look at Composite Scores in Techempower benchmarks. Jooby, Micronaut, Ktor, Dropwizard, Http4k.. are all nice to work with and are all pluggable with different network IO frameworks like Netty for example. And they are not barebones http layers only optimised for speed, they come with a bit of batteries included but not that much that you battle the framework. They are less magic and more composable with other libraries where you can more easily know what is happening. Similar to Express and Flask. But even a heavyweight Spring framework is at the top. Flask is stuck at the bottom. Even express has bad results.
And, this is a personal preference, but having built production apps in both dynamically typed and statically typed languages, I prefer the latter for various reasons. Using Kotlin to write backend apps is really enjoyable for me.
Glanced through the Drogon documentation, and it seems about as simple as a C++ web framework can be.
Greenlighting on the other hand would definitely be confusing for your average java developer.
You have to write code very differently, if your goal is to not create any garbage.
The style will be familiar to the HFT folk, but it's interesting to see some of those same approaches used for http services.
What makes you say that Drogon isn’t pleasant to work with? Is it some specific framework APIs that can be improved (if yes, how?), or is it a general disdain against C++ and its syntax?
For example, https://github.com/an-tao/drogon (benchmark winner) or https://oci-pronghorn.gitbook.io/greenlightning/ just aren't pleasant to work with. For example, compare Green Lightning with http://sparkjava.com/ and look at how much slower Spark is while clearly being nicer to use.
I worked with Netty at work for two years and it was a dream to use something like Express or Flask on the side, not having to worry sharing/disposing ByteBufs, not dealing with the weird in-channel/out-channel abstraction (vs simple middleware), not investigating how async-/thread-safe a given library was, etc.
It just all goes back to trade-offs. You're going to have different considerations if you're building a Caddy competitor vs a complex game server. Another consideration is how horizontally scalable you can be which is going to be different for a forum vs a websocket server.