Just to be clear, I didn’t mean to claim that streamlit is restricted to single files; all Python dashboarding tools can use code structured into arbitrarily many files via imports. I’m just looking for a concise way to refer to the fundamental distinction between streamlit and notebooks, i.e. whether for a given source file, there are multiple distinctly separate code cells with their own associated output (the notebook approach) or whether that source file leads to a single, coherent output (the streamlit approach). That shouldn’t be a controversial idea; it’s just trying to summarize how streamlit differs from notebooks.
I also completely agree that editing code in a real editor is much, much more natural and efficient than editing in a notebook cell; that’s why my code cells get pasted back and forth in Emacs all the time, and why we developed NEI (which is still alpha code, and only for Emacs) to avoid that. Web browsers are lousy editors! I also agree with most of Joel Grus’s other complaints about notebooks and how people abuse them. Personally, I hate notebooks in the same way I hate the destructive power of water, planes, and automobiles, which are all also terrible, dangerous, and often deadly things I’d never want to live without!
I can even accept a claim that iterating in streamlit can more quickly lead to a finished, polished product; I don’t know if it’s true in general, but it could be!
So the point I am trying to make here is simply that notebooks do offer something tangible, real, and important that streamlit does not. It’s up to each person to decide whether what notebooks offer is important to them, and if so, whether what streamlit offers is important enough to justify the friction and pain that people will have if they switch between notebooks and streamlit frequently.
Simply put, notebooks (inherently and by design) offer the ability to capture and communicate to a human that this bit of code (not the whole file or collection of modules) produces this output, with human-readable text attached that can concisely and precisely explain what is going on in that one bit of code. Notebooks are thus designed to capture and convey a code-based narrative, a story, which has a linear flow and is composed of small, human-digestible steps that relate text, code, and output.
A dashboard, whether made by Panel or streamlit or voila or shiny, does not do that. A dashboard offers a coherent, integrated set of functionality not overtly tied to bits of code, where the user approaches it as a unified app that lets them do certain things. Notebooks tell stories, while dashboards provide functionality. A dashboard can be abused to tell a story, but it’s awkward – the linear flow is either lost during development or forced on the finished product, and it takes a lot of effort to convey how bits of the dashboard relate to bits of code. A notebook can be abused to be a dashboard, but it’s awkward – the code and the linear flow have to be hidden, and it takes a lot of effort to make a notebook cell appear to be a unified app.
So the question people need to face is one of what is important to them. Is it important to capture a process of understanding data or models incrementally, preserving each bit and explaining it to others or yourself for posterity? If so, notebooks should be important to you. Or are you ok with losing all the individual steps that lead up to a particular dashboard-like artifact, “efficiently and productively” forgetting how you got that code? If so, streamlit is a great approach. From what I can see, if all you care about is the final artifact, streamlit will be useful. If you only care about capturing a step-by-step process or telling a story, then a notebook is the only way to go.
I think most people are in between those extremes. For my own work and for that of our clients, we believe that both activities are important, and that it’s important to lower the friction between them. At any moment, I can be exploring some data freely, capturing a series of reproducible steps for my own later understanding and use, telling a story to others, creating a dashboard for a particular audience, and going back and forth between all those things. That’s precisely what Panel is designed to encourage, i.e. to make it simple and lossless to switch between those activities and contexts, making there be very little cost to make a dashboard out of a notebook, make a notebook out of a dashboard, explore interactively, write a blog post, document a thought process for posterity, and so on. (See examples.pyviz.org for lots of examples of each of these activities.) Streamlit is what you get if you want to optimize (but not capture or explain) the process of getting to a final artifact. Panel is what you get if you think all those activities are important. It’s very nice for users to have these alternatives now!