Get Ready for Cloudinary’s Next- Generation JavaScript SDKs

Since its founding in 2012, Cloudinary has released software development kits (SDKs) in over a dozen languages and frameworks, adding feature after feature for numerous technologies. So far, those releases have proceeded in an evolutionary manner. We’re now overhauling them to serve developers even better, starting with the JavaScript (JS) SDK. For details, see our recent post on Cloudinary’s next-generation developer SDKs.

A New Dawn

While building SDKs, we always ask ourselves these three same questions:

• What’s the right balance between abstraction and primitives?
• How do we future-proof our internal features?
• How do we future-proof the JavaScript (JS) technology stack and browser updates?

The answers are ever more important because, to meet the requirement of backwards compatibility, once the decisions are made and development proceeds, backtracking would be an astronomical task..

Hence, we’re brainstorming how to improve our entire stack of JS SDKs by modernizing our toolkit.

Even though the process is still in the early stage, we’d like to share with you our current thinking and solicit your feedback.

Our SDK Goals

We’re aiming for four goals for our new SDKs:

simplicity, enhanced semantics, smaller bundle size, and code reuse.

Simplicity More Desirable Than Flexibility

Instead of offering a jack-of-all-trades SDK, we’ll focus on ease of use, which matters the most to developers. Ease of use is different things to different people, however. To us, it means that you can read your code as easily as running it.

As flexible as our APIs are, that flexibility comes at the price of readability. Consider this snippet:

tag = cl.image('sample.jpg', {
          crop: "scale",
          width: "auto:breakpoints",
        })

The current API accepts a map of configuration parameters, which, though easily extensible, are difficult to decipher in complex transformations.Plus, their seemingly unrelated properties (siblings) add to the confusion.

We propose the following instead for much-improved readability in output along with grouping of relevant properties:

Let img = New TransformableImage('sample.jpg')
    .addAction(scale().width('auto'))

In the current SDK, the relativity of the scale and width properties above is hidden. The new syntax clearly shows that they are related.

Furthermore, we plan to use types behind the scenes since all modern IDEs feature the much desired auto-completion capability.

Semantics As a First-Class Citizen

For optimum flexibility, the Cloudinary URL represents an expression, not functionality. The current SDK syntax bridges the functionality gap but falls short by merely renaming arguments and making them more accessible. Also lacking is an in-depth understanding of how the properties, such as scale and width interact.

As a contrast, the new SDK syntax takes semantics seriously. We’ll define all the operations that are performed on assets as actions, e.g., resizing, scaling, and adjusting assets. Along with proper namespaces, enhanced semantics translates to a superb developer experience, enabling you to discover features much more readily.

Minimum Bundle Size Through Tree Shaking

The large footprint of the SDK has long been a sour point at Cloudinary. As more features are added, the SDK bundle size correspondingly grows. Additionally, the current SDK is one-size-fits-all. Even if you use only a small subset of its features, you must download the entire package.

The new SDK will be ESM (ES Module) friendly, complete with full support for tree-shaking. That is, you bundle only what you use and throw away the rest.

Also, in the works are new plugins you can install instead of having to incorporate them in the main bundle. See this example:

Import * as Resize, {scale, resize, /* and more */  } from ‘@cloudinary/resize’

Share Functionality Across SDKs

Since our SDKs were not developed in unison, some features exist in multiple versions but with slight variations. For consistency and uniformity, we’ll unify all the code into shared libraries to support an ever-growing array of frameworks. That’s the right formula for proper growth!

The Endgame

For all that the above goals won’t be easy to achieve, we’re committed to delivering the best developer experience possible. After all, coding should be a delight, not a chore.

Our code has been open source from Day One so feel free to track its progress on GitHub.Above all, send us your thoughts.

We’ll be back soon with more updates.

The Cloudinary SDK team