SFML historically was a little more accessible if you were an OOP programmer but a total beginner to working with audio/graphics/networking programming from a game perspective. You had to be OK with or devoted to OOP/classes, want a higher-level library with a few more batteries included (especially cross-platform input and networking) but less flexibility, don't need to target game consoles, don't want or need to work in C, and are primarily or only working in 2D.
That said, even for those uses SDL2 (much less SDL3) caught up to SFML about 6-7 years ago in usability issues for people without experience coding at that level. Circa 2015, SFML was the easier route to both performance and a working cross-platform binary. That hasn't been true for a long time now, even when SFML started to get refurbished around 2021/2022. The only times I've come across SFML since 2017/2018 have been projects migrating off of it and onto SDL 2 or 3.
It's good to have both SFML and SDL, among other C++ options and other-language frameworks. Even looking at 3.1, I don't think I'd recommend SFML now, especially not for the same reasons I might've done it 10 years ago. But it's good to see them modernizing anyway, and changes like this might make it easier to update and maintain old or abandoned projects that still use SFML.
As maintainer I won't be able to give you an unbiased response. The biggest difference is, that SFML is a C++ library.
What motivates me to work on SFML is, that we're building something separate from SDL. I don't think, we - as in the general developer world - do anyone a favor in consolidating everything into one library (why use X, when Y does the same?). Additionally, I think it's a very interesting "field" of trying to provide a common API across different OS; and sadly it seems to be an area where few resources exist and fewer developer actually understand it, as "everyone" just uses SDL. Finally, I really like the open and welcoming community we've built over the years and at the same time, I'm happy we're not getting as much attention/pressure as SDL.
Genuine question; why would I want to use this over SDL?
SFML historically was a little more accessible if you were an OOP programmer but a total beginner to working with audio/graphics/networking programming from a game perspective. You had to be OK with or devoted to OOP/classes, want a higher-level library with a few more batteries included (especially cross-platform input and networking) but less flexibility, don't need to target game consoles, don't want or need to work in C, and are primarily or only working in 2D.
That said, even for those uses SDL2 (much less SDL3) caught up to SFML about 6-7 years ago in usability issues for people without experience coding at that level. Circa 2015, SFML was the easier route to both performance and a working cross-platform binary. That hasn't been true for a long time now, even when SFML started to get refurbished around 2021/2022. The only times I've come across SFML since 2017/2018 have been projects migrating off of it and onto SDL 2 or 3.
It's good to have both SFML and SDL, among other C++ options and other-language frameworks. Even looking at 3.1, I don't think I'd recommend SFML now, especially not for the same reasons I might've done it 10 years ago. But it's good to see them modernizing anyway, and changes like this might make it easier to update and maintain old or abandoned projects that still use SFML.
As maintainer I won't be able to give you an unbiased response. The biggest difference is, that SFML is a C++ library.
What motivates me to work on SFML is, that we're building something separate from SDL. I don't think, we - as in the general developer world - do anyone a favor in consolidating everything into one library (why use X, when Y does the same?). Additionally, I think it's a very interesting "field" of trying to provide a common API across different OS; and sadly it seems to be an area where few resources exist and fewer developer actually understand it, as "everyone" just uses SDL. Finally, I really like the open and welcoming community we've built over the years and at the same time, I'm happy we're not getting as much attention/pressure as SDL.
If you are interested in a hybrid solution, I've been working on a fork of SFML which uses SDL as the backend, among many other improvements:
https://vittorioromeo.com/index/blog/vrsfml.html