I made another one, in Ruby http://smartcropper.berk.es/ http://smartcropper.berk.es/. And just like those other two, in need of love. But the difference is th

I made another one, in Ruby http://smartcropper.berk.es/ http://smartcropper.berk.es/. And just like those other two, in need of love. 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.