[throwaway2568]

Thanks for the response and context. I work in a different domain to data science and it's fair to say that most people I work with would prefer writing a few 10s of lines of python than many pages of SQL!

Regarding your second point, looking at streamlits announcements page [1] it seems many features being added, layouts/themes and session state/callbacks for example, indicate to me that streamlit is heading in the direction of panel/dash more than the other way. Streamlit also emphasizes using decorators for caching [2], which I agree can end up with some overall state that is a bit magic.

Overall I think the optimal use cases are a bit different for the sets of tools, and I find the approach of dynamically calculating a full script for every change of a slight widget quite onerous, and actually just not feasible for the use cases I have.

[1] https://blog.streamlit.io/tag/announcements/

[2] https://blog.streamlit.io/six-tips-for-improving-your-stream...

[lmeyerov]

Right, but the key is "you must do X" vs "later, and only if you want, you can optionally layer on X". Users of StreamLit disinterested in programming noise have a lot fewer framework-mandated operational burdens than Panel because the smart defaults are smart. In contrast, anyone using Panel has do a lot more practically + conceptually to get a minimally reasonable result. That's the difference between 1-2 people in a team/org being successful, vs most.

Though again, I'm not a zealot: the StreamLit starting point is still too high in my experience for most teams, so both are wrong. For most people, the default should be no Python, at most SQL or whatever DB lang, and optionally drop down to Python for some cool bits. Ironically, I just got off a call a few hours ago where this exact issue makes us excited about starting with StreamLit, yet we're also already scheduling tools to replace it with something more realistic for 10X+ wider enterprise adoption.