Dash is deeper than Dashboards. The missing link that makes Python a… | by Layne Sadler | Apr, 2022

The missing link that makes Python a fullstack language

Having no real-time front end experience apart from AJAX, Dash easily enabled me to develop this application

Prologue: to set the stage, reference Brief History of Reactive Web Dev, which has been abstracted out of this post.

Dash’s reactive front end is the missing link that makes Python a truly compelling full-stack language. It enables each layer of the application stack to interact with the same data using the same session of the same programming language which makes for a more rapid, simple, and intuitive development process.

Model-View-Controller Architecture

Dash revolutionizes the Model-View-Controller (MVC) paradigm of application development level by:

  • Tightly integrating a real-time Controller with the View.
  • Removing the need for redundant data serialization & overly formal APIs between different application layers/ programming languages. Once data is read into memory as a Python object, complex objects like Pandas DataFrames can be passed around the stack fluidly.
  • Enabling full-stack apps to be published as simple Python packages.

Simply put, Dash empowers any Python developer to become a full-stack, 10x powerhouse.

Dash abstracts HTML/CSS, React, Flask, and Plotly — wrapping it all in an unified and easy-to-use Python API. It does such a good job that you don’t even realize React is even involved without being told about it. There’s no Webpack JS bundling mess to deal with.

  • @app.callbacks provides a Pythonic API for defining Controller methods.
  • app.layout provides a Pythonic API for structuring Views that hook into the control layer. There are loads of pluggable Bootstrap components too.
from dash import html
import dash_bootstrap_components as dbc
from dash.dependencies import Output, Input
# Layout with a dropdown & placeholder paragraph.
app.layout = html.Div(
dbc.Select(id='dropdown', options=['hi','bye']),
html.P(id='target')
)
# Register inputs, outputs, and state (none in this case).
@app.callback(
Output(component_id='target', component_property='children'),
Input(component_id='dropdown', component_property='value'),
)
def hello_world(selection:str):
return selection
  1. The callback monitors the input elements tagged with HTML IDs.
  2. The callback function runs.
  3. The callback updates the output of elements.

It’s really that simple!

📚 If you want to learn more, I highly recommend the book,
Interactive Dashboards and Data Apps with Plotly and Dash
by my new friend, Elias Dabbas.

Dash callback debugger

Pros:

  • Pure Python — no JS nonsense! Unless you want to include your own JS /assets.
  • The callback debugger is INSANE! It is so confidence inspiring that no matter how many callbacks you chain together, this thing has your back. It monitors your app in real-time and pulses with information as callbacks are fired.
  • JupyterDash integration.
  • Cross-filtering aka interacting with Plotly charts.
  • NEW: multi-page apps & parameterized routes.

Cons (minor/ areas for improvement):

  • Couldn’t find a way to run regular app=Dash()from within Python module — it seemed like it wanted me to start it from the command line as a standalone .py file. So I am invoke it in a module via app=JupyterDash() so that I can bake it into my own package. Feels like a hack.
  • I really want a way to pass arguments into the app during initialization rather than just relying on globals in the .py file.
  • The DataTable component is disappointing for a framework that is supposed to be about “Data Apps.” It’s not easy to use and it’s not easy to style. I just wound up using Bootstrap tables.
  • It felt like callbacks were converting all inputs to strings. Can’t use bool and ints. Kind of defeats the whole zero JS thing.
  • I wish there was an option to refresh the entire app using Interval without having to painstakingly manage the State of every callback.
  • I found myself using a lot of the Dash Bootstrap Components, and those are benevolently provided and supported by a 3rd party. But it seems like they are supported by 1 person. What if they leave? Does Plotly provide them support?

In the SaaS world, first-mover advantage is typically everything. This is what makes Streamlit’s success so surprising. Just a few weeks ago, Snowflake acquired Streamlit for $800M 💸. It seemed like Streamlit came out of nowhere overnight. No offense to them, but it was so sudden that I just assumed that they either bought their likes or threw their entire first rounds of fundraising into social media campaigns to juice up their GitHub stars.

So why hasn’t Plotly taken offlotly? Allow me to paraphrase what I think it was Peter Thiel in Zero to One: “You have to be as innovative with your distribution strategy as you are with your product.”

Streamlit has a free tier, an affordable teams tier, and is pushing community-developed components. What’s Plotly’s strategy? They charge something like $50K/yr for 5 seats [looks like this is no longer public… so are they either leaning full-bore into enterprise deals or making a down-market play] for Dash Enterprise and you have to host it yourself because they have no hosted offering. They have this massive userbase but are pricing themselves out of monetizing it. It’s absurd to me that a company with such popular open-source roots is not taking a wide-funnel platform approach. They aren’t living up to their potential.

Platforms lead to exponential growth because:

  • They allow you to tap into assets of production that you don’t own. Communities literally build products and provide services for you. As opposed to relying on in-house sales/ dev teams to enterprise fulfill consulting contracts, which leads to linear growth.
  • You get a network effect with quadratic growth.

💸 Big low-code values

With companies like UiPath getting valued at $35B and GrandView forecasting the low-code market to be worth $87B by 2027 I understand the temptation for Plotly to focus on low-code. It’s easy to assume that someone will win big in the “data science low-code app” space. And if you look at what Plotly has done in the past, this is a natural progression:

  • Plotly library → Chart-maker UI
  • Dash library → Dashboard-maker UI.

From the boardroom, this looks like a great move, but as Aristotle says, “Question everything.”

🤷 Opinion piece: Plotly’s high-level APIs are already low-code

Maybe data scientists will dislike constructing and styling Their own HTML/CSS, so low-code Dash will be a big hit? Or people will get started with low-code templates and then transition to editing the underlying code. I guess low-code could knock out a lot of easy use cases.

However, having just built a Dash app with chained callbacks and interval-based refreshing State, low-code feels like a stretch. Besides, the real value of Dash is in the callbacks. Even with low-code, wouldn’t you still have to write callbacks yourself? So what’s the point? Is it just for either layouts or hypo?

People flocked to Plotly because it provides high-level APIs that simplify the creation of complex, D3-like charts. Having designed high-level APIs myself, I’ve realized that there’s not much difference between filling in API arguments vs filling in a UI form. As the developer, you’ve already abstracted away all of the complexity with your backend code and presented your end-user with simple options.

Besides, I’ve never met anyone who actually uses these Plotly chart-creator UIs, so why should we expect people to use a full-blown app-creator UI? I’m sure Plotly has some drag-n-drop functionality on a canvas-looking UI that looks slick in enterprise sales demos. Yet, as a product developer, when I think about from dash import html meets low-code — I can’t help but think of the eternal quest that Webflow has been on since 2013 to automate webpage creation.

Other doubts: If there is no code, then what’s the difference between Dash’s low-code products and other low-code competitors — are they all the same to someone who can’t code? If you can’t use a high-level API, are you actually capable of building a worthwhile data app in the first place? How much benefit does low-code really offer business users over Pivot Tables in MSFT Excel/ Google Sheets? Plotly’s current target market is enterprise, but those customers can afford to hire people that can code.

It’s not that I think it’s impossible to achieve a low-code app builder. I just get the sense it’s a high-effort/ low-value initiative.

So maybe Plotly will get a big valuation from pursuing low-code, but I think the product itself is going to gather dust.

When Dash has the entire world of code-capable Python+R+Julia users to capitalize on, why is it pursuing low-code? Streamlit didn’t have to.

From where I am sitting, Plotly needs to move down-market and do some multi-tenant platforming in order to capitalize on their existing userbase.

Leave a Comment