I'm specifically talking about say jinja2 rendering to WASM and doing any sort of application logic client side like Blazor does. Blazor can also do server-side logic. It's essentially a SPA framework on serious steroids with minimal mental overhead of having to go to JavaScript and back.
I use plotnine whenever I need to make (static) plots in Python. It's really quite well done, a close match to R's ggplot2, and more feature complete than any of the other Python grammar of graphics packages I've tried.
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
Culture is definitely part of the problem, and I completely agree that tech alone can't solve it. I also think it's critical to change the incentives that lawyers are responding to.
I've spoken with lots of lawyers in procurement at large companies. They're typically perceived as a cost center, and they often have to deal with lots of people from the rest of the business complaining that the contracts need to be reviewed/approved faster.
If they are processing thousands of vendor contracts per year, think about how much faster they can be if most/all of those contracts are on their in-house template, rather than a different template for each vendor.
But if lots of their vendors are using a standard contract, then there isn't the same cost in terms of time for using it.
All that said, this is going to be hard, and we're not expecting everyone to change overnight. We have, however, been encouraged to see examples of large companies signing the standard contracts, and we're grateful to have attorneys from big companies like Thompson Reuters and Salesforce on our committee.
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:
(Note: I work at Posit, but not on the Positron team)