It&#x27;s pretty much a given that the first few libraries solving problem X will have a sub-optimal API, especially if they aim to be both general (say read and display JPEG) and full-featured (support all the optional bits of the format or work efficiently in low-memory embedded situations, etc.) at the same time.<p>All of that while preserving the feel and idioms of the host language. This is key since it invalidates a lot of prior experience with similar APIs.<p>So until the &quot;right&quot; API coalesces from collective experience with the problem domain and APIs for similar libraries (read and display {TIFF, GIF, PNG, etc.} in $LANGUAGE) backward compatibility is <i>not</i> a feature you want.<p>Wait for the second or third wave of libraries where the problem is solved and understood in a nice idiomatic way for the language and its quirks.