If I'm deciding what library to use, I'm not only concerned with whether it meets my needs today, but also whether it will meet my needs in a year or two. I don't necessarily know what those will be but I want to know that the core libraries I'm relying on will keep up with the industry so that my application isn't left behind without a costly rewrite.
Just as a simple example, if my competition is using a non-dead rendering library and their UI is twice as fast as mine as a result, I'm not going to be happy.
On the other hand, your competition may be using a dead rendering library and have a UI that is twice as fast as a result.
Recent commits doesn't indicate much in terms of security, fit for use, or quality. All it indicates is recent commits, and hints at reachability of the authors if you need to ask them about their intent (if code is unclear) or for license alternatives (if the license is unsuitable).
Then (in the hypothetical) you should use what your competition uses and not use Cairo; Cairo wouldn't be vying for your attention, and Cairo doesn't make money when you use it so wouldn't care what you use. If there's a FOSS competitor worth leaving for, that means the environment is healthy.
Says the one who made the best/most_complex open source one rather than use QPainter ;)
But really, QPainter suffers from a lot of the same issues as Cairo (and then some). The main "problem" with them is that they are CPU bound. Both of them have OpenGL backends, but they are not "really" faster. There is also the fact that the Qt Company doesn't invest in it anymore since QtQuick2 was released. Because of that, it doesn't get some of the newer Skia features. So Cairo/QPainter are pretty good at server side rendering. Qt was never popular for that use case. Cairo used to own that market, but it's usage is declining due to the maintenance inactivity issues. Also, once upon a time Cairo was used in Firefox and Chrome, so it's SVGs tend to be rendered more accurately in modern browsers than Qt ones.
Skia itself is an unsustainable library to depend on. Its API and behaviour isn't stable. Google doesn't really care about non-Google use cases, so the CMake is broken 90%+ of the time. It adds a large maintenance burden on projects trying to use it. Distributions also hate it for being impossible to package reliably. In turn, it makes hard for smaller projects to migrate away from Cairo because users have an easier time getting their hands on Cairo than Skia.
(bias disclaimer: I worked with both as a KDE dev and as the AwesomeWM co-maintainer, a Cairo based project. A lot of the recent unreleased Cairo commits originates from the AwesomeWM community, but not from me)
The js programmers and their ilk form our opinions these days and they certainly don't care about needs in more than a year because they hope to sell their wares by then and move on.
Isn’t that the purpose of flagging something as depreciated? It’s a warning for you and a warning for people currently using it that it may/will go away in the future.
Just as a simple example, if my competition is using a non-dead rendering library and their UI is twice as fast as mine as a result, I'm not going to be happy.