The Biggest Lie in Data Science: 'You Need to Build an App'

Most data scientists don’t need to build web apps. But if you must, this no-BS guide breaks down which frameworks actually make sense (and which don't).

If you're a data scientist trying to build web apps, chances are you're using the wrong framework. And, no, the answer isn't just “Use Streamlit and call it a day.”

Data scientists and engineers think about web apps differently, leading to bad advice and poor framework choices. So, which one should you actually use? Let's break it down - no sugarcoating.

The Fantasy vs. The Reality

Most data scientists don't actually want to build apps. Let's be real: you want to analyze data, create models, and maybe visualize results in a way your boss won't ignore.

But then someone says, "Hey, can we make this an interactive tool?” And suddenly, you're debugging CSS issues in Dash or screaming at Streamlit for reloading your entire app when you tweak one input.

So, let's set the record straight. If your goal is to make a quick, one-off tool, you don't need a real web framework. And if you're building a serious app? You probably shouldn't be doing it at all.

The Tier List: Which Framework Actually Fits Your Needs?

So, which framework tier is for you?

1. S-Tier ("S" As in "Shit Needs to Get Done Fast")

Streamlit: If you need an app up yesterday, Streamlit is your best friend. It’s simple, pure Python, and lets you turn scripts into apps with zero front-end knowledge.

But, the moment your app gets complex - think multiple users, real authentication, long-running tasks - Streamlit starts falling apart. It refreshes unnecessarily, lacks fine-grained control, and doesn’t scale well.

Shiny for Python: Like Streamlit, but slightly more production-ready. It's got better reactivity but still suffers from limitations in complex apps.

2. A-Tier (Mo Power, Mo Problems)

Dash: The “grown-up” version of Streamlit. Built on Flask, gives you way more control, but requires you to actually understand web development. Good for production, but the learning curve is real.

But if you don't like HTML/CSS/JavaScript, you're going to suffer. And it's not great for truly large-scale apps.

FastHTML: A new contender from the FastAPI authors that lets you build full-stack apps without touching JavaScript. Sounds too good to be true? Maybe. But it's promising if you want async capabilities without dealing with FastAPI + React.

3. B-Tier (For Those Who Think They Are Software Developers)

FastAPI + React: This is the real software engineer approach. Fully scalable, async, highly flexible…but also a huge pain for most data scientists. If you like coding in JavaScript and setting up frontend-backend communication, go for it.

But this is overkill for 90% of data scientists. If your main job is ML or analytics, you'll spend more time debugging API calls than doing actual data science.

Flask + Custom Frontend: A lighter version of the above. Good if you need full control but don't want to deal with React. But again, do you really want to be a web developer?

4. C-Tier (For When You Hate Yourself)

R Shiny: If you're an R user, you might be tempted. Don't be. Shiny's async support is painful, and its Python version isn't mature enough yet. if you must use it, fine…but be prepared for weird bugs.

Tableau/PowerBI/Looker Studio: Not even web frameworks, but a surprising number of companies just use these for “apps”. If your goal is data presentation, this might actually be smarter than trying to build an app from scratch.

5. D-Tier (Performing BDSM on Yourself)

Gradio, NiceGUI, Taipy, Panel, Quarto: These are fun toys, but they aren't widely supported, and you'll regret choosing them when you run into a roadblock and realize the community is tiny.

Preswald: Some people say it's a lightweight way to spin up dashboards with SQL or CSVs. But let's be honest - if you're doing that, you might as well use Excel.

Clojure + Vega Lite: Look, I respect anyone who wants to do data science in Clojure. But unless you enjoy being part of an obscure programming cult, this is a hard pass.

Arkalos: A niche framework that technically uses FastAPI under the hood, but adds a bunch of extra abstractions. If you like living on the bleeding edge and don't mind no Stack Overflow answers, go for it.

No Tier: The Weirdest, Most Niche Frameworks You’ve Never Heard Of (But Might Actually Work?!)

Alright, let's get really weird. These are the frameworks no one talks about the dark horses, the underdogs, the tools you bring up in a meeting just to sound smarter than everyone else.

Will they solve all your problems? Probably not. But if you love being that person who uses obscure tech just to flex, these might be for you.

H2O Wave: Built by the same folks who made H2O.ai, this is for hardcore ML nerds who want slick dashboards without becoming front-end developers. Think of it as Streamlit's eccentric cousin who actually knows machine learning.

Pinecone (Now Reflex): Marketed as the “next-gen” Dash but in pure Python. Looks cool on paper, but let's be real - it's still figuring itself out, like a teenager going through an identity crisis.

Vaadin: A Java-based UI framework that somehow lets you build interfaces in Python. If you're cool with JVM weirdness and enjoy debugging stack traces that look like the Matrix, this might be your thing.

Tornado: Super-fast, non-blocking, and great for real-time data streams. But ask yourself: Do you really need that kind of speed, or are you just trying to impress someone?

Svelte + Python Backend: React is bloated, Angular is overcomplicated, and Vue is…fine. But if you want an actually fun frontend experience while keeping Python on the backend, Svelte is a criminally underrated choice. Will data scientists use it? Probably not. Should they? Maybe.

Conclusion

So, which framework should you use?

Want something fast and simple? Streamlit or Shiny.

Need more control but still want ease of use? Dash or FastHTML.

Actually building a real production app? FastAPI + React (or let engineers handle it).

Most data scientists should not be writing full-fledged web apps. If your company is forcing you to, maybe the real solution is to tell them to hire an actual web developer.