Journey to 1 Million Gradio Users!

5 years ago, we launched Gradio as a simple Python library to let researchers at Stanford easily demo computer vision models with a web interface.

Today, Gradio is used by >1 million developers each month to build and share AI web apps. This includes some of the most popular open-source projects of all time, like Automatic1111 , Oobabooga’s Text Generation WebUI , Dall-E Mini , and LLaMA-Factory .

How did we get here? How did Gradio keep growing in the very crowded field of open-source Python libraries? I get this question a lot from folks who are building their own open-source libraries. This post distills some of the lessons that I have learned over the past few years:

Customization-maintenance trap : high-level abstractions are easy to use, but users request extra parameters to customize them, which in turn leads to increased maintenance burden since every abstraction and parameter needs to be implemented, maintained, and tested to avoid bugs.

Instead of building many high-level classes to support different use cases, we built a low-level API called Gradio Blocks that let users assemble applications from modular components, events, and layouts. Despite generally being more work to use, gr.Blocks today represents 80% of the usage of Gradio—including the highly popular apps mentioned above.

The best ambassador for your library is not you, but an enthusiastic user. It follows, then, that you should find ways for users to share your library or its products as part of their workflow. Gradio’s early growth was fueled by our “share links” feature (which created a temporary public link for your Gradio app in a single line of code). Instead of having to worry about packaging or hosting their code on a web server with the right kind of compute, Gradio users could share their apps with colleagues immediately.

In the crowded ecosystem of Python web libraries, we are frequently asked, "How is Gradio different from X?" Our concise answer—that Gradio is optimized for machine learning web apps—is memorable and fundamentally accurate. Each Gradio app ships with features particularly suited to ML workflows, such as a built-in queue that can manage long-running ML tasks efficiently, even with thousands of concurrent users. The components we have designed are specifically tailored to ML use cases. On the other hand, for a long time, Gradio did not even include features like link buttons, simply because our core users never needed it. By narrowing our focus, Gradio quickly became the go-to choice among machine learning developers—the default "UI for AI."

When we first launched Gradio, we offered only one high-level class ( gr.Interface ), which created a complete web app from a single Python function. We quickly realized that developers wanted to create other kinds of apps (e.g. multi-step workflows, chatbots, streaming applications), but as we started listing out the apps users wanted to build, we realized what we needed to do: go lower.

With a small team, a focus on low-level abstractions has necessarily meant that we could not chase many tempting, high-level abstractions. But this focus saved us from two common pitfalls:

The productivity illusion : using high-level abstractions seems like less work, until a user needs functionality that is not supported (which can be hard to predict at the beginning of a project), forcing the developer to do a costly rewrite.