Starting point
- Mercury
- Your existing Jupyter notebook (.ipynb)
- Gradio
- A function and interface written for the app
Python app framework comparison · Reviewed August 2026
Mercury vs Gradio
Both turn Python into a shareable web app with no frontend work. Mercury serves the notebook itself—cells, narrative, and outputs, in order. Gradio serves an interface you define in code, wired to functions you supply.
MSales performance
Live app
Revenue
$1.28M
+18%
Orders
8,429
+12%
Margin
31.4%
+3.2%
Monthly revenue
Interactive Plotly chartReport insight: Revenue grew 18% year over year, led by enterprise accounts in Europe.
Published from a notebook
The short answer
The durable difference is the source artifact: Mercury publishes a notebook; Gradio runs an interface defined in Python code.
- Mercury keeps cells, narrative, outputs, and controls in notebook order.
- Gradio wires interface components to functions and events.
- Both support authentication and managed deployment paths.
- Choose based on the artifact you want to maintain after publishing.
Quick answer
These frameworks are optimized for different jobs
Mercury publishes the analytical workflow as the application. Gradio is optimized for collecting inputs, calling a function or model, and presenting its outputs.
Reuse existing analysis
- Mercury
- Keep analysis, charts, Markdown, and model code together
- Gradio
- Adapt the relevant logic to interface functions and events
Application scope
- Mercury
- Complete dashboards, reports, forms, tools, and chat in one notebook
- Gradio
- Focused model demos, multimedia interfaces, and chat apps
Data visualization
- Mercury
- Keep Plotly, Matplotlib, Altair, tables, KPIs, and narrative together
- Gradio
- Display plots as function outputs or compose them in Blocks
Reports and dashboards
- Mercury
- A core use case: publish the complete analytical notebook
- Gradio
- Possible with Blocks, but not the primary workflow
Customization
- Mercury
- Ready-made themes plus configurable colors, typography, layout, widgets, and app chrome
- Gradio
- Themes, CSS, and component-level styling for a purpose-built interface
Protected apps
- Mercury
- Publish private applications behind a login screen
- Gradio
- Use launch(auth=...) or publish a private Hugging Face Space
Managed deployment
- Mercury
- Publish from MLJAR Studio or upload notebook files to MLJAR Platform
- Gradio
- Deploy to Hugging Face Spaces, including free hosting options
Simple API
- Mercury
- Widgets added directly to notebook cells
- Gradio
- gr.Interface(fn, inputs, outputs)
Advanced control
- Mercury
- The same reactive widget model throughout
- Gradio
- gr.Blocks() with explicit event listeners
Execution model
- Mercury
- Cells below a changed widget rerun
- Gradio
- A bound function runs when its event fires
Callbacks
- Mercury
- None offered or needed
- Gradio
- Inferred by Interface and ChatInterface; explicit in Blocks
Notebook preview
- Mercury
- Live application preview in JupyterLab and MLJAR Studio
- Gradio
- Interfaces can display inline in notebooks after launch
State management
- Mercury
- Ordinary notebook variables above the widget
- Gradio
- gr.State() passed through event functions
Chat and streaming
- Mercury
- Chat, ChatInput, Message, and append_markdown()
- Gradio
- ChatInterface with a generator function for streaming
License
- Mercury
- Apache-2.0
- Gradio
- Apache-2.0
Hosting
- Mercury
- Self-host with Docker or use MLJAR Cloud
- Gradio
- Self-host or deploy to Hugging Face Spaces
Best fit
- Mercury
- Notebook-based dashboards, tools, reports, and chat
- Gradio
- Focused ML demos, multimedia interfaces, and chat apps
The starting point
A complete analytical notebook or a purpose-built function
The difference becomes clear when the application needs filters, calculations, charts, tables, and explanatory text—not merely one output.
sales-dashboard.ipynb · Mercury
[1]
import mercury as mr
import pandas as pd
import plotly.express as px
sales = pd.read_csv("sales.csv")[2]
mr.Markdown("# Sales dashboard")
region = mr.Select(
value="All regions",
choices=["All regions", "Europe", "Americas"],
label="Region",
)[3]
filtered = (
sales
if region.value == "All regions"
else sales[sales["region"] == region.value]
)
mr.Indicator(
value=f"${filtered['revenue'].sum():,.0f}",
label="Revenue",
variant="teal",
)
fig = px.line(
filtered,
x="month",
y="revenue",
color="region",
title="Monthly revenue",
)
fig.show()The notebook remains the dashboard: inputs, calculations, charts, and report narrative stay together.
sales-interface.py · Gradio
import gradio as gr
import pandas as pd
import plotly.express as px
def build_report(csv_file, region):
sales = pd.read_csv(csv_file)
if region != "All regions":
sales = sales[sales["region"] == region]
revenue = f"${sales['revenue'].sum():,.0f}"
chart = px.line(
sales,
x="month",
y="revenue",
color="region",
title="Monthly revenue",
)
return revenue, chart
demo = gr.Interface(
fn=build_report,
inputs=[
gr.File(label="Sales CSV", type="filepath"),
gr.Dropdown(
["All regions", "Europe", "Americas"],
value="All regions",
label="Region",
),
],
outputs=[
gr.Textbox(label="Revenue"),
gr.Plot(label="Monthly revenue"),
],
)
demo.launch()Gradio reorganizes the same work around a function with declared inputs and outputs.
Gradio’s concise API is a strength when an interface exists to call one function. For a substantial dashboard or report, however, the application usually contains many analytical steps and outputs. Mercury preserves that notebook structure instead of reorganizing the work around interface handlers.
Publish and protect
From notebook to private web app
Mercury does not stop at rendering an interface. Publish the complete notebook as a web application and put it behind a login screen for authorized users.
- Share confidential dashboards and internal reports without exposing the notebook editor.
- Control access to business tools, customer data, and analytical results.
- Give non-technical users a clean application while the Python remains in the notebook.
Private Mercury application
Access protected
Deployment
Publish in one click—or upload the notebook
Choose the path that matches how you work. The output is the same: a ready-to-share Mercury web application.
Publish from MLJAR Studio
Use the direct integration in MLJAR Studio. Click Publish from the notebook workflow and deploy the Mercury app without assembling hosting infrastructure.
Upload notebook files
Not using MLJAR Studio? Upload the .ipynb file, supporting data, and requirements.txt. MLJAR Platform prepares the web application.
Choose who can access it
Publish a public application or protect an internal dashboard, report, or tool behind a login screen.
Mercury customization
Make the notebook app look like your product
Mercury includes ready-made styles and a compact config.toml setup for colors, typography, surfaces, widgets, navigation, and app details. Start with a theme and adapt it without maintaining a separate frontend.
Minimal Light
A clean, neutral application theme for reports and everyday dashboards.
Editorial Serif
A publication-style theme for research, reports, and narrative analysis.
Dark Ops
A high-contrast dark theme for operational dashboards and internal tools.
The Python notebook stays the same while the application shell can match a business dashboard, published report, or internal product.
Explore Mercury stylesChat apps
Mercury keeps chat inside the complete notebook workflow
Use the same reactive notebook model for the conversation, retrieval, analysis, charts, and controls instead of separating the chat into a dedicated interface function.
chat.ipynb · Mercury
[1]
import mercury as mr[2]
chat = mr.Chat()
prompt = mr.ChatInput()[3]
if prompt.value:
user_msg = mr.Message(
prompt.value,
role="user",
)
chat.add(user_msg)
response_msg = mr.Message(
f"Echo: {prompt.value}",
role="assistant",
)
chat.add(response_msg)Mercury exposes the message objects directly inside the notebook's reactive flow.
chat.py · Gradio
import gradio as gr
def echo(message, history):
return message
demo = gr.ChatInterface(fn=echo)
demo.launch()ChatInterface builds a standalone chat UI around one response function.
Mercury uses the same reactive approach for ChatInput, a filter such as Select, and form inputs inside the same notebook. You can keep retrieval results, supporting charts, evaluation, and explanatory content alongside the conversation without adopting another application structure.
For a pure standalone chatbot, Gradio’s ChatInterface is more concise. It supplies the conversation structure and history to a response function automatically. Mercury preserves the notebook as the source when the conversation belongs inside an analysis that should remain the published artifact.
Decision guide
Notebook as the app, or an app that calls your code
Both turn Python into a shareable web app with no frontend work. Mercury serves the notebook itself—cells, narrative, and outputs, in order. Gradio serves an interface you define in code, wired to functions you supply.
Choose Mercury if
- The analysis already lives in a notebook and you want to publish it, not port it.
- The output is a document as much as an interface—sections, commentary, tables, and charts read top to bottom.
- You want non-developers to update the app by editing the notebook.
- You want charts, Markdown, tables, and generated files to remain in their notebook order.
- You are publishing many notebooks as one branded site rather than one app per URL.
- Widgets should rerun the cells below them, keeping the notebook linear instead of callback-driven.
Choose Gradio if
- The app is an interface to a model—text in, prediction out—and there is no surrounding narrative.
- You want temporary public share links for quick review without deploying anything.
- You need ML-native components for image, audio, video, token streaming, or request queuing under load.
- You are already in the Hugging Face ecosystem and want the app next to the model or dataset.
- You want the app callable as an API endpoint by other programs, not only by people.
- You prefer the app to be a .py file in version control, reviewable as a diff.
Gradio Blocks composes more elaborate layouts than the high-level interfaces suggest. The distinction that holds is the source: a Gradio app is code that describes an interface, so the analysis that produced the model usually lives elsewhere. A Mercury app is the analysis, published.
Compare more Python app frameworksFAQ
Questions about Mercury and Gradio
Which is simpler for a basic chatbot?+
Gradio ChatInterface is arguably more concise for a standalone chatbot because it creates the chat UI and passes message history to your function automatically.
Which is better if I already have a notebook with analysis in it?+
Mercury. It adds reactive widgets to the notebook you already have, so the existing analysis cells remain the source of the application instead of being reorganized around dedicated interface functions.
Does Gradio work inside Jupyter notebooks?+
Yes. Gradio launch methods display inline by default in Python notebooks, and Gradio also provides notebook magic for developing Blocks apps. You are still writing a Gradio Interface, ChatInterface, or Blocks app inside the notebook.
Which has better managed hosting?+
They optimize for different workflows. Gradio integrates closely with Hugging Face Spaces. Mercury integrates directly with MLJAR Studio and MLJAR Platform, where a notebook can be published from Studio or uploaded with its supporting files.
Can I put a Mercury application behind a login screen?+
Yes. Mercury applications can be published as private web apps so access is restricted behind a login screen. This is useful for internal dashboards, confidential reports, and tools that should only be available to authorized users.
Do I need MLJAR Studio to deploy a Mercury application?+
No. MLJAR Studio provides the most direct workflow with its Publish integration. If you use another notebook environment, you can upload the .ipynb file, supporting data, and requirements file to MLJAR Platform instead.
Can I customize how a Mercury application looks?+
Yes. Mercury supports ready-made styles and configurable colors, typography, surfaces, widgets, navigation, and application details. You can start from an example config.toml and adapt it to a dashboard, report, internal tool, or product brand.
Can both stream chat responses token by token?+
Yes. A Gradio ChatInterface function can yield partial responses from a Python generator. Mercury updates an empty assistant message by calling append_markdown() as chunks arrive. See the complete Mercury streaming pattern.
Publish the complete notebook with Mercury
Turn your charts, controls, tables, report narrative, and model code into one web application—then share it publicly or protect it behind login.
pip install mercury