Cloudinary Blog

Get Ready for Cloudinary’s Next- Generation JavaScript SDKs

Announcing the Next Generation Cloudinary 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:

Copy to clipboard
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:

Copy to clipboard
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:

Copy to clipboard
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

Recent Blog Posts

Amplify Your Jamstack With Video

By Alex Patterson
Amplify Your Jamstack With Cloudinary Video

As defined by Amazon Web Services (AWS), Amplify is a set of products and tools with which mobile and front-end web developers can build and deploy AWS-powered, secure, and scalable full-stack apps. Also, you can efficiently configure their back ends, connect them to your app with just a few lines of code, and deploy static web apps in only three steps. Historically, because of their performance issues, managing images and videos is a daunting challenge for developers. Even though you can easily load media to an S3 bucket with AWS Amplify, transforming, compressing, and responsively delivering them is labor intensive and time consuming.

Read more
Cloudinary Helps Move James Hardie’s Experience Online

While COVID has affected most businesses, it has been particularly hard on those that sell products for the physical ‘brick and mortar’ world. One company that literally fits that bill is our Australian customer James Hardie, the largest global manufacturer of fibre cement products used in both domestic and commercial construction. These are materials that its buyers ideally want to see up close, in detail. When customers have questions, they expect personal service.

Read more
How to Build an Enhanced Gravatar Service, Part 2

Part 1 of this post defines the capabilities of an enhanced Gravatar service, which I named Clavatar, and describes the following initial steps for building it:

This post, part 2 of the series, explains how to make Clavatar work like Gravatar and to develop Clavatar’s capabilities of enabling requests for various versions of the images related to user accounts.

Read more
How to Build an Enhanced Gravatar Service, Part 1

The advent of web development since 25 years ago has given birth to an abundance of online services that help developers build apps efficiently and smoothly. Gravatar is a shining example of such a service. Built by WordPress, Gravatar generates globally recognized avatars. Fun fact: 80 percent of Gravatar users first came across that service when reading a WordPress blog.

Read more