Agreed…feels like this is as much a cultural problem as a tech one. Meaning, from my experience at large companies, I feel like those lawyers get off on the fight of who gets to write the terms
Not specific to specific examples in the article, I think some of the things people perceive as "bugs" other people see as features or an opportunity to correct past mistakes.
I can remember an example where I suggested automatic treatment of missing values in a stats library, and the library maintainer disagreed. Meaning, my lobbying for Julia to do what R/Python did was seen as "Yes, but that's wrong and we shouldn't promote that sort of treatment". As a business user, I didn't care that it was theoretically wrong, the maintainer as an academic did.
That ends up becoming open-source prerogative. I could do it wrong "on my own time" in my own code...doesn't make either a bug, but a different choice based on perspective.
(Note: I'm Head of Developer Relations at Streamlit)
While I cannot speak to your experience with either project, I do want to point out that open-source doesn't have to be a zero-sum game. Gradio has different goals than Streamlit, which has different goals than Flask and Django.
In the end, congratulations to both HuggingFace and Gradio, Streamlit looks forward to seeing what they end up building!
If you want to use some other combination of technologies for hosting, we've created a Deployment Guide to aggregate the best answers from the community:
The main advantage is that not everyone knows Python, and those who do don't necessarily use Jupyter. Once you deploy a Streamlit app, it's the same in-browser interactive experience people are already used to.
> It appears to be like a chatroom in the sense that its live but with an API or live application refresh where the programmer can write lines of code that immediately show app results. This is pretty cool but I don't know if its a real product other than live coding interviews or the most intense pressure cooker of your manager having you do the TPS reports right now
If that's what you're taking away, we need to improve our marketing copy!
The point of Streamlit is to have a nimble way to create applications, where auto-refresh/hot-reload is part of the developer experience. But the goal of the overall project is to make interactive data apps available to the broad public, not just people who have front-end experience or a front-end developer working on their team.
We just released themeing in the past few weeks, so there's definitely more options than there used to be! We'd love to get any additional feedback about the types of customizations you'd like to see.
(Note, I'm Head of Developer Relations for Streamlit, so clearly not a non-biased observer!)
You're absolutely right that Streamlit isn't a Jupyter replacement (we're not trying to be!), in the same way that Spyder isn't a "replacement" for the JetBrains set of IDEs. Maybe Streamlit will one day move to multiple language support, but for now, we're trying to be the best Python library we can be for creating web apps.
As far as GPU-support goes, as mentioned above, Streamlit "supports" GPU in as much as Python does. It's important to separate out front-end/UI from backend. If something is supported with GPU as a backend, "data science" (however defined) functionality, Streamlit supports that in the same way a React app calling a GPU API endpoint or other workflow is "GPU-enabled"
(Note: I work at Posit, but not on the Positron team)