I made another one, in Ruby <a href="http:&#x2F;&#x2F;smartcropper.berk.es&#x2F;" rel="nofollow">http:&#x2F;&#x2F;smartcropper.berk.es&#x2F;</a>. And just like those other two, in need of love.<p>But the difference is that these are all running on a backend, while the JS version will probably run in the frontend.<p>I&#x27;m not sure what the right place for this would be, but frontend has some advantages and quite some disadvantages:<p>* It&#x27;s as slow as the devise running the JS. In mobile era that probably means a magnitute slower than even the cheapest DO server.<p>* You can&#x27;t reply on it, so if you want to ensure you receive, say, square images, you&#x27;ll need to validate and re-crop on backend again.<p>* It&#x27;s very error-prone. On a backend you can ensure versions of imagemagic or some other processing is there, on frontends: you&#x27;ll rely on the parsing in JS (very slow) or on the rendering of the client (unstable in the sense of: you don&#x27;t know where it works in what way, and if that will stay so)<p>* 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<p>Edit: bullet-point markup and realised a pro for doing this frontend.