Our comparison between Web MVC and WebFlux should contain some qualitative as well as quantitative indicators. One of the most common qualitative indicators that is measured is the learning curve. Web MVC is a well-known framework with more than ten years of active use in the enterprise arena. It relies on the most simple programming paradigm, which is the imperative programming paradigm. For a business, this means that if we start a new project based on plain Spring 5 and Web MVC, it will be much easier to find skilled developers and much cheaper to teach new ones. In contrast, with WebFlux, the situation will be significantly different. First of all, WebFlux is a new technology, which has not yet sufficiently proved itself and may potentially have a lot of bugs and vulnerabilities. The underlying asynchronous, non-blocking programming paradigm may also be a problem. First of all, it is hard to debug asynchronous, non-blocking code, as demonstrated by Netflix's experience of migrating Zuul to a new programming model.

Also, from a business perspective, it might be unreasonable to search for unbelievably highly-skilled engineers with in-depth knowledge of asynchronous and non-blocking programming, especially using the Netty stack. Teaching new developers from the beginning takes a lot of time and money and there is no guarantee that they will understand fully. Luckily, some parts of this problem are solved by using Reactor 3, which makes building meaningful transformation flows simpler and hides the hardest part of asynchronous programming. Unfortunately, Reactor does not solve all problems and, for businesses, such an unpredictable financial investment in people and risky technology may not be worth it.

Another vital point about qualitative analysis is the migration of an existing solution to a new reactive stack. Despite the fact that, from the very beginning of the framework's development, the Spring team have been doing their best to provide smooth migration, it is still hard to predict all migration cases. For example, those who rely on JSP, Apache Velocity, or similar server-side rendering technologies will be required to migrate the entire UI-related code. Moreover, a lot of modern frameworks rely on ThreadLocal, which makes the smooth movement to async, non-blocking programming challenging. Along with this, there are a lot of problems related to databases, which are covered in Chapter 7, Reactive Database Access.