But neither seems to get as much love as they need, so always good to have more players.
But the difference is that these are all running on a backend, while the JS version will probably run in the frontend.
I'm not sure what the right place for this would be, but frontend has some advantages and quite some disadvantages:
* It's as slow as the devise running the JS. In mobile era that probably means a magnitute slower than even the cheapest DO server.
* You can't reply on it, so if you want to ensure you receive, say, square images, you'll need to validate and re-crop on backend again.
* It's very error-prone. On a backend you can ensure versions of imagemagic or some other processing is there, on frontends: you'll rely on the parsing in JS (very slow) or on the rendering of the client (unstable in the sense of: you don't know where it works in what way, and if that will stay so)
* It is distributed. My smartcropper for Ruby is heavy, memory-gobbling, and slow (partly the fault of the bad code, It is long due some refactoring). It is near impossible to run without some async-job system. Whereas, a cropper in the frontend scales nicely across users, because each user brings their own processing-power
Edit: bullet-point markup and realised a pro for doing this frontend.