I don't think you're getting the difference between possible & clean for programmers, vs. easy & straightforward for the target market. Most non-engineers don't want to spend time learning and tweaking this stuff, they want to work on the analysis, domain problem, and later, sharing it with others, not spending hours learning & debugging development & UI stuff. That's time away from their actual work & their families.

Ex: It took me awhile to appreciate StreamLit's builtin layout: it largely eliminates "HTML-in-Python", so one less thing. Likewise, decorators are weird magic, so yet another educational hurdle. If a tool could do excel -> dashboard, most would rather that! While I love that stuff, and I can recommend it to coders, I've learned to not recommend it to teams that can't guarantee everyone is... which is most. It sounds like Panel is slowly reinventing StreamLit, but as StreamLit isn't even there yet, for most corporate use, I'd be trying to do much more than catchup on this specific aspect if you want it to be relevant here.

Fun story: a PhD friend for a much-lauded company on HN led a team of ~20 analysts. About ~2 people loved Python, and the rest would write pages of SQL to avoid it.

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...

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.